I'll toss out my top 10, which are probably applicable to other vendors: 1. Entirely separate accounts for each stage, and, past dev, all stages are identical.

I'll toss out my top 10, which are probably applicable to other vendors: 1. Entirely separate accounts for each stage, and, past dev, all stages are identical. 2. Include a beta stage that doesn't have crap developers set up and forgot. Consider not even giving devs write access to it. 3. Deploy all infrastructure from code via cloudformation or terraform. If you have to use scripts, include deletion logic. 4. Enable cloud custodian to chase down untagged resources. Run it aggressively in dev and beta so it doesn't break prod. 5. Deploy code via artifacts so rolling back is trivial. 6. Integ tests to prove your least privileges IAM roles, routing, security groups, etc. are sufficient. 7. Use CloudTrail and flow logs to prove components still need that access. 8. Load testing in beta to find all the AWS limits before you find them in prod. (Especially, load test any blue/green deployments!) 9. Kill alarm spam with fire. If there's a remedy, automate fixing it. If it's not a real problem, make it a metric. Review your metrics. 10. Figure out where your state (e.g. database) lives and doesn't (which should be most components), and the architecture to make your application resilient should become clear. And a bonus: You have total control over your AWS environment. Rather than deploying pages of configuration, structure your services so they are configured by convention or introspection[1] as much as possible. [1]: e.g. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-inst...