AWS recently announced CDK Mixins, a new AWS CDK feature that lets developers add reusable capabilities like security, monitoring, and configuration to AWS resources. Mixins work across different construct types, making infrastructure code more flexible and reusable.
Michael Kaiser, senior software development engineer at AWS, and Momo Kornher, solutions architect at AWS, write:
CDK Mixins represent a fundamental shift in how we think about infrastructure abstractions. By decoupling capabilities from construct implementations, Mixins give you the freedom to compose exactly the infrastructure you need, whether you are using L1 constructs for access to new CloudFormation resources, L2 constructs for convenience, or custom constructs for enterprise requirements.
The AWS Cloud Development Kit (CDK) is an open-source infrastructure-as-code framework for provisioning cloud resources through AWS CloudFormation. The CDK relies on modular, reusable components organized into three levels: L1 maps directly to CloudFormation, L2 adds higher-level abstractions and defaults, and L3 combines resources into reusable patterns. This creates a trade-off between access to new AWS features and higher-level abstractions, often forcing teams to heavily customize or rebuild constructs.
While Kaiser and Kornher claimed on the AWS blog in late May to be "excited to announce CDK Mixins", the cloud provider announced the general availability of the new feature earlier in March.
CDK Mixins are built into aws-cdk-lib and use the same service imports developers already use, working across L1, L2, and L3 constructs. Explaining the difference with CDK Aspects, a way to apply an operation to all constructs in a given scope, Kaiser and Kornher add:
Mixins and Aspects are complementary. Mixins apply features immediately to specific constructs, while Aspects enforce rules broadly across a scope during synthesis. A common pattern is to use Mixins to configure resources and Aspects to validate that the configuration is correct.
Previously, teams had to choose between direct access to new AWS features via L1 constructs and the convenience of L2 abstractions, often requiring additional customization to meet security and compliance requirements. Monica Colangelo, head of hyperscaler operations at ReeVo, explains the benefits of Mixins:
Think about what happens when AWS releases a new feature on any service. The L1 construct (CfnBucket) supports it immediately because L1s are auto-generated from CloudFormation specs. The L2 construct (Bucket), the one with nice defaults and convenience methods (...), won't support it for weeks or months until someone on the CDK team writes the abstraction. So until now, you either used L2 and waited, or dropped to L1 and manually configured everything you were getting for free. Not ideal. Mixins changes this. You can use an L1 construct for day-one access and then chain on the behaviors you need (...) The boundary between L1 and L2 just got a lot blurrier.
CDK Mixins allow developers to add reusable features and policies to constructs with a .with() syntax, making infrastructure easier to customize, secure, and maintain while preserving access to new capabilities. Corey Quinn, chief cloud economist at The Duckbill Group, writes in his newsletter:
CDK now has Mixins, because L1, L2, and L3 constructs apparently weren't enough construct types to confuse newcomers. Now you can compose abstractions across all three, which sounds great until you realize you're writing TypeScript to generate YAML to provision JSON to summon God. Somewhere, a Terraform user is laughing into their coffee.
The CDK Mixins documentation is available on GitHub.