Automating CDK with Amazon Q Developer Customizations

January 21, 2025

Note: This content was originally published on the AWS Blog and is reproduced here for archival purposes. Please visit the original post for the most up-to-date version.

Welcome to another installment of Q-Bits, our regular series showcasing cool ways Amazon employees are leveraging Amazon Q Developer. Today, we're diving into how Q Developer can assist with Automating CDK Best Practices.

As an avid user of Infrastructure as Code (IaC) and the AWS Cloud Development Kit (CDK), I'm always looking for ways to improve my workflow and ensure consistent deployments across my organization. One powerful tool I've discovered is Amazon Q Developer, AWS's AI-powered code assistant that can help streamline my CDK development.

The challenge I often face is that my organization has unique requirements and best practices that need to be baked into our infrastructure provisioning. For example, we have specific instance types, Amazon Machine Images (AMIs), and security standards that must be used for resources deployed in our development, testing, and production environments. Rather than manually enforcing these standards across my CDK code, I created custom constructs that would automatically handle these details.

This is where the customization capabilities of Amazon Q Developer come in handy. By teaching Q about my organization's custom constructs, I can leverage its AI-powered suggestions to ensure our infrastructure deployments align with our standards, without having to reinvent the wheel for each new project.

Let's walk through the process I used to customize Amazon Q Developer and automate CDK best-practices.

First, I defined a few custom constructs in my CDK application. For instance, my CustomInstance construct automatically selects the appropriate Amazon Elastic Compute Cloud (Amazon EC2) AMI and Amazon Virtual Private Cloud (Amazon VPC) based on a property called environment. This simplifies the configuration for the developers and ensures consistent deployments.

1
2
3
4
5
6
const instance = new CustomInstance(this, 'WebServer', {
  name: 'web-server-01',
  environment: 'Testing',
  operatingSystem: 'Windows',
  ...
});

Similarly, my CustomBucket construct enforces our security best practices for Amazon Simple Storage Service (Amazon S3). I have overridden some properties such as blocking public access, enabling bucket encryption, and enforcing TLS. This ensure that the developers follow our standards.

1
2
3
4
5
6
const bucket = new CustomBucket(this, 'MyBucket', {
  blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
  encryption: s3.BucketEncryption.S3_MANAGED,
  enforceSSL: true,
  ...
});

With these custom constructs in place, I'm ready to teach Amazon Q Developer about them. I start by opening the Amazon Q Developer console and creating a new customization. I will not repeat the entire process here, but it involves connecting Q to the data source containing my custom CDK constructs and many examples of those constructs used in various stacks. Amazon Q Developer can use AWS CodeStar Connections (if my code is in a Git repository) or I can upload my code to an Amazon S3 bucket.

To see Q's customization in action, let's compare its suggestions before and after I've added my custom constructs.

Without any customization, Q's suggestion for provisioning a production web server would look like the following example. This is a valid CDK construct, but it doesn't align with my organization's standards.

1
2
3
4
5
6
7
8
9
10
// Create a Linux production server named web001
new cdk.aws_ec2.Instance(this, 'web001', {
  vpc: cdk.aws_ec2.Vpc.fromLookup(this, 'vpc', { isDefault: true }),
  instanceType: new cdk.aws_ec2.InstanceType('t3.micro'),
  machineImage: cdk.aws_ec2.MachineImage.latestAmazonLinux({
    generation: cdk.aws_ec2.AmazonLinuxGeneration.AMAZON_LINUX_2,
  }),
  allowAllOutbound: true,
  instanceName: 'web001',
});

Next, I imported my custom-construct module. In the following example, Q realizes that I want to use a custom construct, but it knows nothing about my constructs.

1
2
3
4
5
6
7
8
9
10
11
12
import * as myconstructs from 'custom-constructs';

...

// Create a Linux production server named web001
new myconstructs.ProductionServer(this, 'web001', {
    amiName: 'amzn2-ami-kernel-5.10-hvm-2.0*', // Amazon Linux 2 AMI
    instanceType: 't2.micro',
    keyName: 'my-key-pair',
    tags: [{ Key: 'Name', Value: 'web001' }],
    vpcId: 'XXXXXXXXXXXX'
});

Finally, I activate my customization and now Q has everything it needs. In the following example, you can see that Q properly suggests my CustomInstance construct and the correct properties.

1
2
3
4
5
6
7
8
9
10
import * as myconstructs from 'custom-constructs';

...

// Create a Linux production server named web001
new myconstructs.CustomInstance(this, 'MyInstance', {
  name: 'web001',
  environment: 'Production',
  operatingSystem: 'Linux',
});

Furthermore, Q now suggests my custom constructs even if I do not import the custom-constructs module. So Q will recommend my custom constructs even if a new developer forgets to include the module.

1
2
3
4
5
6
// Create a Linux production server named web001
new myconstructs.CustomInstance(this, 'MyInstance', {
  name: 'web001',
  environment: 'Production',
  operatingSystem: 'Linux',
});

By taking the time to customize Q, I've been able to streamline my CDK development and ensure my infrastructure deployments adhere to my organization's best practices. No more manual enforcement or reinventing the wheel - Q has my back, and it speaks my organization's language.