Disclaimer: if you’re new to CloudFormation custom resources, then I recommend you start by reading this excellent post by Alex Debrie first.
Custom resources bring a whole new dimension to CloudFormation and enable some fascinating use cases. For example:
- provision DataDog dashboards as part of your CloudFormation stack
- run a load test every time you deploy a CloudFormation stack
- provision/modify AWS resources that are not natively supported by CloudFormation (e.g. EventBridge)
You can use custom resources to run one-off tasks as part of every CloudFormation deployment. Which is something I wanted to do in many of my SAR apps such as this and this. However, I had always assumed that this would require a two-step process:
- deploy a SAR/CloudFormation stack to provision the custom resource Lambda function
- deploy the intended SAR app which uses the custom resource
Turns out, I was wrong. You can include the custom resource Lambda function in the same CloudFormation stack that uses it. In hindsight, I was overthinking things – in essence, all we are doing is referencing a Lambda function by ARN. You’ll see what this means later.
My latest SAR app, propagate-cfn-tags, tackles the issue that CloudFormation does not propagate its tags to some resources such as CloudWatch log groups. This means you can’t include CloudWatch log groups in your cost monitoring (via cost allocation tags), amongst other things.
When you deploy the app, I want to run a one-off script to process all existing stacks in the region and propagate their tags. This is where custom resources come in.
With the help of custom resources, I can:
- create a
PropagateAllLambda function to process existing CloudFormation stacks
- create a Lambda function to support a
Custom::LambdaInvocationcustom resource type
- create a
Custom::LambdaInvocationresource to trigger the
PropagateAllfunction during the CloudFormation deployment
I can do all these in the same SAR app. This gives the user a seamless experience. As far as they’re concerned, you just deploy the app and everything happens as advertised. No two-step deployment process, no need to trigger functions manually.
This simple pattern combines very well with CloudWatch events (or EventBridge):
- a custom resource to update existing resources (e.g. propagate tags for existing CloudFormation stacks)
- CloudTrail + event pattern to process future changes (e.g. propagate tags for future CloudFormation stack deployments)
I find this combination especially useful when building “platform” features. That is, features that span across all my applications running in AWS. For example, making sure all CloudWatch log groups are subscribed to a Kinesis stream. These are not decision points that should be taken at the project level. Which is why I’m not a fan of using Serverless framework plugins to configure these settings.
Enjoy what you’re reading? Subscribe to my newsletter and get more content on AWS and serverless technologies delivered straight to your inbox.
I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.
In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, design patterns and best practices.
Come learn about operational BEST PRACTICES for AWS Lambda: CI/CD, testing & debugging functions locally, logging, monitoring, distributed tracing, canary deployments, config management, authentication & authorization, VPC, security, error handling, and more.
You can also get 40% off the face price with the code ytcui.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong