I'd like to add two more: 1) Not giving out your access and secret keys in scripts/buckets. 2) Always using IAM roles with your EC2
how do you avoid 1 - it seems impossible ?
AWS mistakes to avoid
21–30 of 276 posts
Re: AWS mistakes to avoid
#22Check out http://convox.com/ (YC S15) for an alternative to avoiding manual infrastructure.
Re: AWS mistakes to avoid
#23My huge recommendation is to put production instances in a completely seperate region than development and staging instances. I actually just discovered that you can limit IAM API keys to a specific region, you just need to create a custom policy. The following policy is an example: { "Version": "2012-10-17", "Statement": [ { "Sid": "SOME-ID-HERE", "Effect": "Allow", "Action": [ "ec2:*" ], "Condition": { "StringEqual…
Why would you do this instead of using multiple AWS accounts? Different regions have different feature sets (available instance types, beta eligibility, etc.). I strongly recommend instead using multiple AWS accounts instead and keeping them in the same region.
That said, since you should be using an infrastructure provisioning tool like CloudFormation, the tagging solution should not be a particularly big obstacle.
Re: AWS mistakes to avoid
#24Another, somewhat obvious one:
Be extremely careful when using public customized AMIs, a lot of times ~/.ssh/authorized_hosts contains public keys and this is obviously a huge security problem
Re: AWS mistakes to avoid
#25Another, somewhat obvious one: Be extremely careful when using public customized AMIs, a lot of times ~/.ssh/authorized_hosts contains public keys and this is obviously a huge security problem
no, public keys are not a security problem.
Re: AWS mistakes to avoid
#26I like CloudFormation. Unfortunately it is very unwieldy to write CloudFormation templates directly, and we're not about to start using the AWS CFN GUI editor! It seems like the assembly of the AWS ecosystem. Does anyone else have a favourite hammer for this particular nail? I'd love to have something better than our home-baked solution, but I'm yet to find anything which doesn't introduce other flaws, such as an inc…
Troposphere (https://github.com/cloudtools/troposphere) is a mature Python CloudFormation solution that sounds similar to your home brewed one.
Re: AWS mistakes to avoid
#27My huge recommendation is to put production instances in a completely seperate region than development and staging instances. I actually just discovered that you can limit IAM API keys to a specific region, you just need to create a custom policy. The following policy is an example: { "Version": "2012-10-17", "Statement": [ { "Sid": "SOME-ID-HERE", "Effect": "Allow", "Action": [ "ec2:*" ], "Condition": { "StringEqual…
Why would you do this instead of using multiple AWS accounts? Different regions have different feature sets (available instance types, beta eligibility, etc.). I strongly recommend instead using multiple AWS accounts instead and keeping them in the same region. That said, since you should be using an infrastructure provisioning tool like CloudFormation, the tagging solution should not be a particularly big obstacle.
yes, use multiple accounts. you can use STS to grant permissions between the accounts if needed.
Re: AWS mistakes to avoid
#28Another, somewhat obvious one: Be extremely careful when using public customized AMIs, a lot of times ~/.ssh/authorized_hosts contains public keys and this is obviously a huge security problem
no, public keys are not a security problem.
They are if you don't know who has the corresponding private key.
Re: AWS mistakes to avoid
#29Another, somewhat obvious one: Be extremely careful when using public customized AMIs, a lot of times ~/.ssh/authorized_hosts contains public keys and this is obviously a huge security problem
no, public keys are not a security problem.
But the fact they allow access to your system is.