Simple Custom Constructs in AWS CDK
Using Custom Constructs to ensure consistency in deployments
This article came about as part of a project to learn about and test TypeScript Lambda PowerTools. PowerTools is a set of AWS Labs modules to assist with and enhance Lambda logging, tracing and metrics. PowerTools are available for Python, Java, .Net and more recently for TypeScript.
The key benefit of PowerTools is standardising CloudWatch logging across all your Lambda functions, using a JSON log format designed for parsing and filtering. Testing required creating a basic application to create some log data, and some CloudWatch queries, filters and widgets to view the results.
In building the application it made sense to use one of the most useful features in the AWS CDK toolset — the custom construct. Custom constructs can be as simple as ensuring default settings for S3 buckets, or as complex as you want to make them — for example deploying mini-applications like this CDK Workshop HitCounter example.
Vendors and community members share constructs for specific tasks on the AWS sponsored Construct Hub.
While it is more complex to build and share on the Construct Hub, creating your own constructs to simplify and standardise repetitive configurations is surprisingly simple.
The code repository referenced here includes a full application for testing PowerTools logging and for viewing in CloudWatch, all created in CDK. Follow up articles will cover the PowerTools themselves, we are starting here with the constructs.
I won’t go over it again in detail, but here’s the essentials of the CDK constructs used to create your application stacks:
Level 1 Constructs:
- Are a mapping directly to CloudFormation resources
- Provide no additional logic or default settings
Level 2 Constructs:
- Are the primary CDK classes used to create resources in your stacks
- Provide additional logic and (generally) sensible defaults for most resources
Level 3 Constructs:
- AWS refer to as patterns
- They include combinations of L2 constructs and additonal logic to create more complex sets of related resources
Custom Constructs:
- Write yourself or use one from the community or other vendors
- Can include L2 Constructs, custom logic, connections to third party API’s, your preferred defaults — or just about anything else you can think of
A more detailed overview of the various construct levels and structures is provided by AWS here.
Creating Custom Constructs
Let’s just get straight into an example — standardising settings for DynamoDB tables used in a serverless application.
Using the standard CDK L2 Table construct is not difficult, but there are a few choices to make. If you are making the same choices every time you create a table, then it makes sense to simplify like this:
The construct creates a table with standard settings (for our application) with the only required fields being the table name and sort key.
Of course we can create far more complex constructs if required. In the full code repository linked below you will see that the Table construct above, along with a custom Lambda function and custom API Gateway all include CloudWatch dashboard widgets specific for those resources.
Other custom contracts I use in various projects include:
- EC2, Fargate and RDS schedulers — they create EventBridge rules and a Lambda function to start and stop the servers as required (especially to save money in dev environments)
- An EC2 construct that uses the scheduler above to create a default stop rule (a custom construct using another custom construct)
- A construct that takes an array of data, or builds it from the Stack resources, and writes the data to a DynamoDB table — used for writing application settings into a table, or for initialising data in test environments.
- A comprehensive API Gateway construct that sets up CORs, Cognito authorizers, load balancer connections and many other defaults to ensure consistency across microservice API’s
PowerTools Demo Example
Check out the working example on GitHub for the rest of the construct detail and an introduction to PowerTools.
A follow up article on the PowerTools and CloudWatch components is now available here.
Hope that helps you all, please leave a comment if you have any questions or suggestions.
About the Author
Mark is a 20+yr IT industry veteran, with technical expertise and entrepreneurial experience in a range of fields. For many years now his passion has been building on AWS, and he holds certifications including Solution Architect Professional and the Advanced Networking Specialty. He wants you to know that he is an infrastructure and architecture expert who writes code, not a professional software developer — just in case you spot something odd.
Mark has spent the last few years in the banking industry, were he is currently building and leading a team focused on using AWS serverless technologies to reduce costs and speed up the time to market for new services and products.
You can also find Mark on:
GitHub — https://github.com/markilott
LinkedIn — https://www.linkedin.com/in/markilott/
