AWS-CDK Common Mistakes

The AWS Cloud Development Kit (AWS CDK) is a framework for defining cloud resources in code and provisioning them through AWS CloudFormation. While it simplifies many aspects of defining cloud resources, there are still potential pitfalls or AWS-CDK Common Mistakes that users might encounter. Here are some of the common mistakes:

Pinning CDK Versions:

  • Given the rapid pace of development in CDK, there can be breaking changes between versions. It’s a good practice to pin the versions of CDK libraries in your package.json or equivalent to ensure consistent behavior.
// Do this:
"dependencies": {
  "@aws-cdk/core": "1.100.0"

Imperative vs. Declarative:

  • While CDK is more imperative than raw CloudFormation, you should still focus on describing “what” you want rather than “how” you get there.

Hardcoding Values:

  • Avoid hardcoding resource properties like ARNs, account IDs, or region names. Instead, use CDK’s mechanisms for parameterization.
// Instead of this:
const bucketArn = 'arn:aws:s3:::my-hardcoded-bucket-name';

// Do this:
const bucket = new s3.Bucket(this, 'MyBucket');
const bucketArn = bucket.bucketArn;

Overuse of Default Permissions:

  • The CDK has constructs that by default grant permissions that are too broad. Always review and restrict permissions to the least privilege necessary.
// Instead of this, which grants Lambda full S3 permissions:
const fn = new lambda.Function(this, 'MyFunction', {/* ... */});
const bucket = new s3.Bucket(this, 'MyBucket');

// Do this, which only grants the necessary permissions:

Failing to use Environment Agnostic Code:

  • Not using Stack.of(this).account or Stack.of(this).region can make the code non-portable between accounts and regions.
// Instead of this:
const region = 'us-west-2';

// Do this:
const region = Stack.of(this).region;

Not Handling Dependencies Explicitly:

  • While CDK does a good job of figuring out dependencies between resources, there are situations where it’s necessary to define dependencies explicitly using the addDependency method.
const bucket = new s3.Bucket(this, 'MyBucket');
const fn = new lambda.Function(this, 'MyFunction', {
  environment: {
    BUCKET_NAME: bucket.bucketName

// Ensure Lambda has permissions and the bucket exists before deployment

Inefficient Loops:

  • When using loops to create resources, be cautious. For instance, creating hundreds of resources in a loop might hit CloudFormation limits.
// Be cautious with loops like this:
for (let i = 0; i < 500; i++) {
  new s3.Bucket(this, `Bucket${i}`);

Forgetting to use Staging:

  • Not taking advantage of CDK’s staging and environment capabilities can lead to potential issues when promoting code through different environments.

Forgetting Cost Implications:

  • Just because it’s easy to spin up resources with CDK doesn’t mean they are free. Always consider the costs associated with the AWS resources you are provisioning.

Skipping Unit Tests:

  • CDK code is still code. You can and should write unit tests, especially for more complex infrastructures.
// Sample jest test for a CDK stack
test('ECS Cluster Created', () => {
  const app = new cdk.App();
  const stack = new MyEcsStack(app, 'TestStack');

Not Reviewing Synthesized CloudFormation:

  • While one of the benefits of the CDK is not having to write raw CloudFormation, it’s still a good practice to occasionally review the synthesized CloudFormation template to understand what’s being created.

Ignoring Resource Limits:

  • AWS services have various default and maximum limits. Be aware of these limits when designing and deploying resources.
// If creating many DynamoDB tables, be aware of account limits:
for (let i = 0; i < 300; i++) {
  new dynamodb.Table(this, `Table${i}`, {
    partitionKey: { name: 'id', type: dynamodb.AttributeType.STRING }

Directly Modifying Resources After Deploy:

  • Making manual changes to resources provisioned by the CDK can lead to drift and potential issues during subsequent deploys.

Not Keeping Up With CDK Updates:

  • AWS often releases updates and bug fixes for the CDK. Regularly check for and apply updates.

Forgetting Cleanup:

  • Especially in development, you might create and test numerous stacks. Always remember to clean up to avoid unnecessary costs.

Not Leveraging Existing Constructs:

  • The CDK has a growing library of constructs (L1, L2, and L3). Before reinventing the wheel, check if there’s an existing construct that meets your needs.
// Instead of using L1 constructs (low-level):
new s3.CfnBucket(this, 'Bucket', {
  bucketName: 'my-bucket'

// Use L2 constructs when available for additional features and ease:
new s3.Bucket(this, 'MyBucket', {
  removalPolicy: cdk.RemovalPolicy.DESTROY

To avoid these and other AWS-CDK Common Mistakes, always read the AWS CDK documentation, use best practices, and test thoroughly before deploying to production environments.

Elsewhere On TurboGeek:  Understanding AWS-CDK Directory Structure


Richard Bailey, a seasoned tech enthusiast, combines a passion for innovation with a knack for simplifying complex concepts. With over a decade in the industry, he's pioneered transformative solutions, blending creativity with technical prowess. An avid writer, Richard's articles resonate with readers, offering insightful perspectives that bridge the gap between technology and everyday life. His commitment to excellence and tireless pursuit of knowledge continues to inspire and shape the tech landscape.

You may also like...

1 Response

  1. 29/08/2023

    […] can automate infrastructure provisioning and application deployment by leveraging AWS services like AWS CloudFormation and AWS OpsWorks, reducing human error and streamlining operations. Regular monitoring and logging […]

Leave a Reply

Your email address will not be published. Required fields are marked *

Translate »