Infrastructure as Code (IaC) has exploded in popularity in recent years, and the reasoning is clear. Reusable infrastructure that can be deployed in minutes, or even seconds, is far more advantageous than manually deploying and managing infrastructure. However, with this explosion in popularity several IaC options have become available to infrastructure teams. Terraform, Pulumi, and AWS CloudFormation are all examples of IaC tools that are used in large enterprises. However, this article will focus on determining when the AWS Cloud Development Kit (CDK) is the right choice for your organization, as well as the benefits that can be gained from selecting it.
The AWS CDK is a framework for defining infrastructure as code in syntax languages that your developers are comfortable with. While Terraform uses a proprietary domain-specific language, AWS CDK is written in familiar syntax including TypeScript and Python. CDK then transpiles the code into CloudFormation templates – much like code written in C gets compiled to assembly. This way, CDK allows developers to use familiar syntax and a higher level of abstraction rather than learn yet another language. As an example, below are two examples of provisioning an identical S3 Bucket to AWS, one written in CloudFormation and the other written in Python using AWS CDK. As shown, AWS CDK allows the provisioning of resources using familiar syntax and structure, whereas deploying the same resource using CloudFormation may involve a learning curve.
CDK also helps developers leverage some of the less intuitive features of CloudFormation, which may be frustrating to deal with when manually writing templates. Developers can write more complex expressions in familiar programming languages, allowing for the use of powerful programming elements like loops, conditional statements, and more.
Another benefit of AWS CDK is the ability to test cloud infrastructure definitions. This is possible since AWS CDK is written in testable programming languages with existing testing frameworks. AWS CDK can test “fine-grained assertions” (e.g., ensuring a Lambda function has the proper runtime) as well as “snapshot testing” (i.e., comparing synthesized CloudFormation templates against baseline templates). Fine-grained assertion testing is the most common, and can be especially useful for test-driven development if that is an organizational pattern. Additionally, the library integ-runner can be used to run integration tests on CDK code, validating that the resources are working as expected.
One of the more difficult aspects of operating in a cloud environment is permissions management. Granting least privilege is critical in protecting cloud infrastructure, and AWS CDK assists in this with the auto-generation of AWS IAM permissions. AWS resources function in such a way that each resource needs a policy explicitly allowing them to take actions in AWS.
Without getting into the weeds too much, AWS CDK offers constructs at levels one, two and three. Each of these construct levels offer differing levels of abstraction from specific AWS resources. For example, level one (L1) constructs map directly to CloudFormation resources, where level three (L3) constructs operate as patterns, often representing several resources at a high level of abstraction. Level two (L2) constructs sit in the middle, incorporating “sane defaults” around security and permissions best practices. When AWS CDK L2 code is deployed, AWS CDK automatically adds the permissions required for the created resource to operate as desired. This is especially useful with serverless resources such as Lambda functions where manually adding permissions can be a headache and can often lead to mistakes.
As an example, I have provisioned a basic Lambda function that returns a message when an API Gateway endpoint is triggered. Since Lambda functions need permissions to take actions in AWS, manually provisioning these permissions can be taxing and frustrating, especially at scale. However, as seen below, AWS CDK can identify the permissions required by the Lambda function and automatically adds them to the IAM policy. While this may seem simple with this example, in an environment with hundreds or even thousands of Lambda functions this functionality can be invaluable.
One major benefit of using AWS CDK is that platform teams can develop, test, and deploy opinionated constructs for use by the rest of the organization. These custom constructs can operate at L2 or L3, incorporating IAM policies and other required security resources from the start. This benefits all sides, as the platform team can build in security best practices and development teams can use these constructs without worrying about building secure infrastructure on their own.
As an example, say that there is an organizational pattern of using EKS clusters to deploy applications in AWS. However, due to the sensitive nature of the data involved there are certain controls that must be in place for all EKS clusters (i.e. network policies must be in place to restrict pod-to-pod traffic). With AWS CDK, custom EKS constructs can be built with all of the security protocols in place. These can then be pushed to a private repository in CodeArtifact, making them available for developers to use.
Another security benefit to AWS CDK is that all infrastructure for your environment can be subject to a CI/CD pipeline, incorporating existing security checks as well as allowing for new checks as well. For example, cdk-nag is a tool developed by AWS to provide rule packs to check CDK applications against best practices. Rule packs such as HIPAA and NIST 800-53 can be applied, and findings can either be remediated or suppressed. This tool can be integrated into the CI/CD pipeline to provide automated checks during the build phase, or can be implemented as a pre-commit hook to provide the tool’s functionality before the build phase even begins.
Another tool for security and visibility into AWS CDK is the AWS CDK Explorer, which allows you to visualize the resources that you define in CDK constructs. As seen below, the AWS CDK Explorer provides a “tree view” of applications, stacks, and resources. This allows you to more easily browse components of a CDK application, increasing development speed and visibility while decreasing potentially costly confusion. While this feature is still in a “preview” state, it can still help increase the security of your application through increased visibility.
As demonstrated, the AWS CDK is a powerful tool in deploying infrastructure in your AWS environment. Further, embracing CDK can open up benefits to your organization that other IaC tools cannot. The ability to write IaC in programming languages your team is comfortable with, unit testing functionality, and auto-generation of IAM policies make AWS CDK a prime candidate for many organizations. Along with that, AWS CDK can increase infrastructure security through tools like cdk-nag and AWS CDK Explorer, as well as custom constructs developed with security in mind. Overall, AWS CDK is a great IaC option for many organizations and should be considered strongly against other players in the IaC market.