4 ms·

Are there any good resources for AWS best practices? Esp for medium sized companies. Esp stuff like best way to separate between production and dev.

sushshshsh 6y ago
If you ask my current company, apparently the answer is to split the company up into 4 goddamn environments, which apparently just slows things down and makes everything more complicated rather than secure.
- lykr0n 6y ago
  Or mine. There is no direction, and everything is encumbered with complex business logic so you're waiting weeks for a S3 bucket.
  - MG9991ep545a1l3 6y ago
    Or mine: creation of EC2 instances or changes to IAM can only be done via JIRA ticket. Happy hacking!
    - sushshshsh 6y ago
      Do we work for the same company? Devs have just been running scripts on personal machines and uploading the output to google drive LOL
ben509 6y ago
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...
- viraptor 6y ago
  > Include a beta stage that doesn't have crap developers set up and forgot. Consider not even giving devs write access to it. Or use iamy model and create users with no rights in a completely separate account. Then grant them AssumeRole on other roles/accounts as needed.
ramimac 6y ago
Scott Piper's security maturity roadmap [1] is generally well regarded and outlines some recommendations that I would say are fairly "one-size fits most." AWS also recently released their "Foundational Security Best Practices" in Security Hub. [2] [1] https://summitroute.com/downloads/aws_security_maturity_roadmap-Summit_Route.pdf https://summitroute.com/downloads/aws_security_maturity_road... [2] https://aws.amazon.com/blogs/security/aws-foundational-security-best-practices-standard-now-available-security-hub/ https://aws.amazon.com/blogs/security/aws-foundational-secur...
staticassertion 6y ago
https://summitroute.com/downloads/aws_security_maturity_roadmap-Summit_Route.pdf https://summitroute.com/downloads/aws_security_maturity_road... Scott Piper is the definitive AWS security expert, and this is a guide he publishes and maintains. I'd also suggest following him on Twitter, I learn a lot just from his idle tweets. https://twitter.com/0xdabbad00 https://twitter.com/0xdabbad00

sushshshsh 6y ago

If you ask my current company, apparently the answer is to split the company up into 4 goddamn environments, which apparently just slows things down and makes everything more complicated rather than secure.

lykr0n 6y ago
Or mine. There is no direction, and everything is encumbered with complex business logic so you're waiting weeks for a S3 bucket.
- MG9991ep545a1l3 6y ago
  Or mine: creation of EC2 instances or changes to IAM can only be done via JIRA ticket. Happy hacking!
  - sushshshsh 6y ago
    Do we work for the same company? Devs have just been running scripts on personal machines and uploading the output to google drive LOL

ben509 6y ago

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...

viraptor 6y ago
> Include a beta stage that doesn't have crap developers set up and forgot. Consider not even giving devs write access to it. Or use iamy model and create users with no rights in a completely separate account. Then grant them AssumeRole on other roles/accounts as needed.

ramimac 6y ago

Scott Piper's security maturity roadmap [1] is generally well regarded and outlines some recommendations that I would say are fairly "one-size fits most." AWS also recently released their "Foundational Security Best Practices" in Security Hub. [2] [1] https://summitroute.com/downloads/aws_security_maturity_roadmap-Summit_Route.pdf https://summitroute.com/downloads/aws_security_maturity_road... [2] https://aws.amazon.com/blogs/security/aws-foundational-security-best-practices-standard-now-available-security-hub/ https://aws.amazon.com/blogs/security/aws-foundational-secur...

staticassertion 6y ago

https://summitroute.com/downloads/aws_security_maturity_roadmap-Summit_Route.pdf https://summitroute.com/downloads/aws_security_maturity_road... Scott Piper is the definitive AWS security expert, and this is a guide he publishes and maintains. I'd also suggest following him on Twitter, I learn a lot just from his idle tweets. https://twitter.com/0xdabbad00 https://twitter.com/0xdabbad00