These are some unsorted notes I am taking along my journey with AWS CloudFormation (CFN). I plan to collect some good practices here
While AWS can be used cost for cost-saving, it is not for the weak of wallet at first. If you just want to run a VM with a public IP, you probably won't benefit from AWS at all.
- Do you ever want to route to those subnets? If yes, pick a class B subnet to place your VPCs in.
- For easier routing over DirectConnect or VPN, you might want to subdivide your more permanent VPCs by region.
Example:
ALL VPC in: 10.10/16 VPCs in eu-west-1 in 10.10.1/21 Prod VPCs in eu-west-1 in 10.10.1/22 Prod VPCs in eu-west-1 in 10.10.9/22
- Look into Route53 early on, preferably one of your first services. It can mitigate a lot of problems with AWS CFN early on, such as changing RDS Endpoints and changing ELB CNAMEs
- Use Auto Scaling Groups wherever possible. Avoid Usage of ElasticIPs wherever possible.
- Use exports wisely and include a parameter in your templates that allows you to prefix them. You can only export the same key once per account and region.
- Free yourself of the notion that the CloudFormation Dashboard on the AWS console must be clean and well-aranged. Name your stacks in a structured manner and make yourself comfortable with the search function.
Never touch Route53 entries managed by CloudFormation with anything else. Any change may render CloudFormation unable to change the entry in any way, resulting in stacks unable to update at all, until the last status known to CloudFormation is restored.
- If you are providing infrastructure for others, emphasise early on, that EC2 instances can and will be be terminated at any time.