A large amount of work around the web, cloud and backend systems revolves around resource provisioning and automation. In AWS efficient resource provisioning is typically done through CloudFormation or Serverless Application Model.
Here’s a few quick tips that may help you work better with AWS.
Please keep in mind that the AWS cloud is a changing landscape which means some details described here are subject to change, improvements or future development.
CloudFormation
CloudFormation is AWS service for organizing your infrastructure as code. Organizing your cloud resources in templates or as code has numerous benefits. These benefits include ability to review, test and reproduce changes in all environments. In other words, IaC or infrastructure as code is the most efficient way to manage your infrastructure.
Under the hood CloudFormation stores the state of your application stack and its resources. Changes to your application stack or infrastructure template are translated into CRUD operation calls to respective AWS services.
CloudFormation Custom Resources AWS::CloudFormation::CustomResource are one of the most powerful IaC tools. Combined with AWS Lambda they allow you to manage any services or resources directly from inside your stacks. This can include even services outside the AWS cloud.
Parts of Serverless Application Model are built on top of CloudFormation. If you’re considering building new applications, SAM may be your best choice. SAM template extensions allow you to use CloudFormation on steroids.
If you’re interested in SAM check out this article about Serverless and Scaling at The Overflow.
Security Groups
Security Groups are the stateful firewall in AWS. Security Groups can be used to control network access to resources on the Transport Layer.
Be careful when you provision Security Groups through AWS::EC2::SecurityGroup CloudFormation resource.
Automation or CloudFormation templating attaching Egress AWS::EC2::SecurityGroupEgress or Ingress AWS::EC2::SecurityGroupIngress resources to Security Groups can create duplicate rules.
Security Groups seem to have internal logic and tick that will eventually de-duplicate your firewall rules. This internal rule de-duplication event can cause outage when your rules are removed.
Make sure you never create duplicate rules for Security Groups in CloudFormation to prevent unexpected service interruptions.
Lambda@Edge
Lambda@Edge combines the best from AWS Lambda with CloudFront content delivery network. This means Lambda@Edge is a unique service allowing you to do interesting tricks closer to users, in other words - much faster.
If you care about perfect global user experience, you’re likely already using a content delivery network. Lambda@Edge allows you to execute logic on the network before the traffic hits your origin destinations. Your users will see the shortest possible load times. With CDN edge compute you can rewrite HTTP requests or responses between the user and the edge cache or between the edge cache and your origin.
Keep in mind the Lambda@Edge compute model is very strict. Lambda@Edge functions are highly limited on size, available memory, response sizes, and most importantly on execution time. These limits can create interesting engineering challenges, and it’s better to review them and work with them while you’re prototyping your solution.
The Easiest way to deploy Lambda@Edge functions is through Serverless Application Model (SAM). However, keep in mind the SAM deployment still uses CloudFormation under the hood.
You should be aware that Lambda@Edge functions currently don’t support Environment Variables as input. This forces you to bake all configuration in before deploying your function.
You’ll also learn that attempt to delete a stack, or the Lambda@Edge function resources from your stack will fail with 400 errors. This problem is related to the distributed nature of CloudFront where all CRUD operations take a long time to propagate. CloudFormation times out before CloudFront operations propagate. Both problems exist as of writing this post.