[deleted]
Great points siddharth_mal
AWS mistakes to avoid
11–20 of 276 posts
Re: AWS mistakes to avoid
#12What are the current ways to make creating CloudFormation templates not so painful?
Re: AWS mistakes to avoid
#13I'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 EC2Re: AWS mistakes to avoid
#14I'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
+1 I concentrated on non security related mistakes. security will follow next week... :)
Re: AWS mistakes to avoid
#15Also, dont use Dynamo unless you have a really good reason. "It scales better than MySQL" is not a good reason. Have fun migrating data and re-indexing constantly!
Can you expand on your last statement?
Re: AWS mistakes to avoid
#16I 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 incomplete implementation (missing parameters or resource types) or ultimately making a leaky abstraction on top of CloudFormation somehow.
I ended up brewing a reasonably straightforward solution using Python as a (minimal) DSL which emits JSON. Its primary purpose is to support the whole of the CFN ecosystem (not just implement some small part of EC2, for instance) while also not trying to be too clever.
It has about 50-100 lines of python which implements helper functions such as ref(), join() and load_user_data(), and not many other things. There is an almost 1-to-1 correspondence between the generated CFN configuration and the python source. As a bonus it checks for a few common mistakes like broken refs or parameters which aren't used.
I have heard that similar solutions have been reinvented in a few places, including the BBC. But I'm yet to see a good public solution!
Re: AWS mistakes to avoid
#17My 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?
Re: AWS mistakes to avoid
#18I 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…
Some people like SparkleFormation (http://www.sparkleformation.io/). I'll warn you, though, that it's not a good example of how to program in Ruby. It abuses method_missing to the point that it makes your implementations difficult to debug.
Re: AWS mistakes to avoid
#19My 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?
If you segment production instances from develop/staging you can use IAM rules to grant specific privileges based on the entire region, instead of by tag (which is fragile). Additionally, it is less error prone when you are making manual changes in the console as it requires switching regions between production and develop/staging.
Re: AWS mistakes to avoid
#20I warmly recommend the Serverless framework for building basic web applications on AWS. It handles CloudFormation details for you, but lets you customize them if needed. Not suitable for every possible app though.