One of the biggest hurdles i have faced in my recent tests with CloudFormation was that i can take a lot of time to test your CloudFormation scripts. The online designer works but is quirky so what’s left if you want to test our your infrastructure script?
The answer is simple, just test it out by creating a stack and update it constantly.
But wait, there are tips here that you should be aware of first hand!
Update and rollback times
Because updating and rolling back can take quite some time, it is suggested that you go incremental. Small steps to get there will be in the long run a much better investment.
Services or items that you should consider as costly when testing out your CloudFormation scripts are:
- CloudFront distributions
- RDS clusters
- ElastiCache clusters
- Route53 entries
When trying to get these to go, rely on templates or look at manually generated resources and just copy and paste the settings that worked in them into the template. The worst so far for my experience is the CloudFront distributions. These can take well over 20m to get created and rolledback when something is failing.
Progressive approach suggestion
Here is a list of services and infrastructure components i’d work on based on my experience:
- VPC, Subnets, Gateways, Security groups, Routing tables, all in one go
- IAM users, groups, roles and policies
- S3 buckets, permissions and policies
- Route53 for CloudFront distributions
- CloudFront distributions (one at a time, you’ll cry if you have 2 out of 3 that work out and lose 1h waiting for the 2 that worked to disapear)
- Simple EC2 instances
- RDS Clusters, custom parameter groups and subnet groups
- ElastiCache Clusters and subnet groups
- Load balancers, Listeners, Target Groups, SSL certificates
- AutoScaling templates and auto-scaling group
- CodeDeploy deployment groups
- Route53 records for AutoScaling groups or Load balancers
Caveats of healthchecks and code deploy
Because a lot of people rely on applicable load balancers and thus an application route, you might need to be careful with your instance configuration template and want to rely on a custom web server configuration to get your healthcheck to respond.
If you use an application based response but your application is not installed it will fail the healthcheck and your initial code-deployment project won’t work if you enable WITH_TRAFFIC_CONTROL. Thus, you need to setup a special response configuration on the EC2 instance that is not linked to your application per se or simply use a network load balancer and check for network responses (Unverified, someone suggested that) instead of application responses.