Search the Community

Customers often ask for help with implementing Blue/Green deployments to Amazon Elastic Container Service (Amazon ECS) using AWS CodeDeploy. Their use cases usually involve cross-Region and cross-account deployment scenarios. These requirements are challenging enough on their own, but in addition to those, there are specific design decisions that need to be considered when using CodeDeploy. These include how to configure CodeDeploy, when and how to create CodeDeploy resources (such as Application and Deployment Group), and how to write code that can be used to deploy to any combination of account and Region. Today, I will discuss those design decisions in detail and how to use CDK Pipelines to implement a self-mutating pipeline that deploys services to Amazon ECS in cross-account and cross-Region scenarios. At the end of this blog post, I also introduce a demo application, available in Java, that follows best practices for developing and deploying cloud infrastructure using AWS Cloud Development Kit (AWS CDK)... View the full article

CDK for Terraform (CDKTF) lets you write HashiCorp Terraform configurations in your choice of TypeScript, Python, C#, Java, or Go, and still benefit from the full ecosystem of Terraform providers and modules. CDKTF reached general availability in August, 2022. Today, we’re releasing CDKTF 0.18, which: Improves performance, drastically reducing synthesization time for TypeScript, Python, and Java Further improves the cdktf convert command, which translates HCL to TypeScript, Python, C#, Java, or Go View the full article

CDK for Terraform (CDKTF) lets you write HashiCorp Terraform configurations in your choice of TypeScript, Python, C#, Java, or Go, and still benefit from the full ecosystem of Terraform providers and modules. CDKTF reached its GA in August, 2022. Today, we’re releasing CDKTF 0.16, which improves the ability of the Cloud Development Kit (CDK) to convert HCL to TypeScript, Python, C#, Java, or Go. These improvements, primarily in the CDKTF CLI’s convert command, include: Type coercion based on Terraform provider schema: When converting from HCL to a supported language, the CDKTF convert command now matches the type of the value being assigned to an attribute and converts it to the correct type. Enhanced iterators support: Iterators are used by CDKTF to replace attributes like for_each and dynamic blocks within Terraform. The conversion from HCL in the 0.16 release now also uses iterators when possible, reducing the need for escape hatches. Better functions support: The generated code now uses CDKTF library functions to replace Terraform HCL functions, instead of relying solely on string templating. This improves the readability of the code. Apart from improvements in the convert command, 0.16 upgrades the underlying JSII compiler to use TypeScript 5. This change will improve the performance of CDKTF synth and get. We’ve also updated the minimum version of Node.js to 16 as Node.js 14 will be hitting end of life on April 30, 2023. The convert command The CDKTF CLI released the convert command in version 0.5, which allowed users to automatically convert their existing Terraform HCL code to a CDKTF-compatible language automatically. This is really useful for teams with either an HCL background or a HCL code base who would like to use CDKTF. While we have been releasing minor bug fixes and improvements to convert, the 0.16 release focuses on improving the conversion process. More information about usage and parameters to the convert command can be found in our documentation. To give an example of the conversion process, consider the following Terraform HCL: provider "aws" { region = "us-west-2" } resource "aws_instance" "app_server" { ami = "ami-830c94e3" instance_type = "t2.micro" tags = { Name = "ExampleAppServerInstance" } } When converted into TypeScript through the convert command, it becomes a construct that can be used directly within a CDKTF application: import * as constructs from "constructs"; /*Provider bindings are generated by running cdktf get. See https://cdk.tf/provider-generation for more details.*/ import * as aws from "./.gen/providers/aws"; class MyConvertedCode extends constructs.Construct { constructor(scope: constructs.Construct, name: string) { super(scope, name); new aws.provider.AwsProvider(this, "aws", { region: "us-west-2", }); new aws.instance.Instance(this, "app_server", { ami: "ami-830c94e3", instanceType: "t2.micro", tags: { Name: "ExampleAppServerInstance", }, }); } } Type coercion based on Terraform provider schema Since CDKTF uses Terraform to perform any infrastructure changes, problems like type mismatches are hard to detect until the terraform plan stage. Prior to the 0.16 release, the convert command could generate invalid code because it would try to convert by only looking at the HCL source code. With 0.16, convert also compares the type being generated from HCL and matches it with the provider schema. In case of a type mismatch, it wraps the incoming value to the type expected by the attribute. This makes the conversion process a lot more accurate and results in fewer conversion errors. Take a look at a simple contrived example: resource "aws_route53_record" "my_record" { name = "example.com" type = "TXT" ttl = "300" records = ["test"] } The schema for aws_route53_record marks ttl as a number here, so it seems like an error. However, Terraform automatically converts primitive types to match the schema, therefore the above code will not trigger an error within Terraform. Contrary to that, CDKTF code wouldn’t allow that, since strongly typed languages will not allow a string to be assigned to a number type. To handle these scenarios, we built type coercion into convert. The code above will now generate the following: new aws.route53Record.Route53Record( this, "my_record", { name: "example.com", records: ["test"], ttl: cdktf.Token.asNumber("300"), type: "TXT", } ); Here, convert wraps the string value to a number before passing it to ttl. convert not only does this for primitive types, but also for more complex types like Maps, and Lists. Enhanced iterators support Terraform HCL has meta-arguments that help users create multiple resources, like count, and for_each. There’s also the concept of dynamic blocks, which deals with complex resources that have repeated configurations within. The equivalent concept within CDKTF is called iterators. In the 0.16 release, the count meta-attribute can also be represented as iterators through an escape hatch. For more details about usage and code examples, please refer to our documentation. convert is now also able to use iterators to replace for_each, count, and even dynamic blocks. Previously convert reverted to using escape hatches for iterators. Using CDKTF functions when converting from built-in Terraform functions HCL to CDKTF conversion is now able to convert Terraform functions to their corresponding CDKTF functions. This is nicer for readability as well as being able to get autocomplete and documentation support from the IDE for CDKTF projects. convert also uses functions representing unary, binary, or ternary expressions. If we take the contrived example of an HCL expression containing functions and operators below: replace("hello-${22+22}", "44", "world") This now gets converted into: cdktf.Fn.replace("hello-" + cdktf.Token.asString(cdktf.Op.add(22, 22)), "44", "world") What's next for CDKTF? The upcoming CDKTF 0.17 release will focus on building on top of the 0.16 improvements, especially with regard to converting HCL to languages like Java, C#, and Go. Try CDK for Terraform If you’re new to the project, these tutorials for CDK for Terraform are the best way to get started. You can dive deeper into our documentation with this overview of CDKTF. Whether you’re still experimenting or actively using CDK for Terraform, we’d love to hear from you. Please file any bugs you encounter, let us know about your feature requests, and share your questions, thoughts, and experiences in the CDK for Terraform discussion forum. View the full article

We are excited to announce the release of Cloud Development Kit for Terraform (CDKTF) 0.11. With CDK for Terraform, you can write Terraform configurations in your choice of C#, Python, TypeScript, or Java (with experimental support for Go), and still benefit from the full ecosystem of Terraform providers and modules. Key improvements in CDK for Terraform 0.11 include: New provider add command: This new CLI workflow does the work for you to check whether or not a prebuilt package exists for the provider that you want to use. If a prebuilt package exists, it will be installed for you. If not, the get command will be run in the background to generate your provider resources classes. Improved debugging tools: Relevant version information is now included in CLI error messages. View the full article

Infrastructure as Code (IaC) is an important part of Cloud Applications. Developers rely on various Static Application Security Testing (SAST) tools to identify security/compliance issues and mitigate these issues early on, before releasing their applications to production. Additionally, SAST tools often provide reporting mechanisms that can help developers verify compliance during security reviews. cdk-nag integrates directly into AWS Cloud Development Kit (AWS CDK) applications to provide identification and reporting mechanisms similar to SAST tooling. This post demonstrates how to integrate cdk-nag into an AWS CDK application to provide continual feedback and help align your applications with best practices... View the full article

The Amazon Elastic Container Service (Amazon ECS) extensions module that extends the service construct in AWS Cloud Development Kit (AWS CDK), is now generally available. The new Amazon ECS service construct for AWS CDK supports extensions that automatically add additional capabilities such as AWS App Mesh or FireLens to your containerized services using familiar programming languages. View the full article

The EKS Construct Library is an AWS CDK module that helps customers provision Amazon EKS clusters using infrastructure-as-code best practices. Up until now, it has been in an experimental state, incorporating lots of customer feedback and undergoing multiple API and behavioral changes. Starting from version 1.65.0 (https://github.com/aws/aws-cdk/releases/tag/v1.65.0), the library is graduating to Developer Preview. This means that we are not planning any breaking changes going forward and are preparing the library for GA. View the full article

Just as higher level languages like BASIC and C abstracted away the details of assembly language and made developers more productive, the AWS Cloud Development Kit (AWS CDK) provides a programming model above the native template languages, a model that makes developers more productive when creating IaC. When you instantiate CDK objects in your Typescript (or Python, Java, etc.) application, those objects “compile” into a YAML template that the CDK deploys as an AWS CloudFormation stack. AWS Solutions Constructs take this simplification a step further by providing a library of common service patterns built on top of the CDK. These multi-service patterns allow you to deploy multiple resources with a single object, resources that follow best practices by default – both independently and throughout their interaction. Application Development Stack vs. IaC Development Stack Solution overview To demonstrate how using Solutions Constructs can accelerate the development of IaC, in this post you will create an architecture that ingests and stores sensor readings using Amazon Kinesis Data Streams, AWS Lambda, and Amazon DynamoDB. Prerequisite – Setting up the CDK environment Tip – If you want to try this example but are concerned about the impact of changing the tools or versions on your workstation, try running it on AWS Cloud9. An AWS Cloud9 environment is launched with an AWS Identity and Access Management (AWS IAM) role and doesn’t require configuring with an access key. It uses the current region as the default for all CDK infrastructure. To prepare your workstation for CDK development, confirm the following: Node.js 10.3.0 or later is installed on your workstation (regardless of the language used to write CDK apps). You have configured credentials for your environment. If you’re running locally you can do this by configuring the AWS Command Line Interface (AWS CLI). TypeScript 2.7 or later is installed globally (npm -g install typescript) View the full article

The AWS Cloud Development Kit (AWS CDK) is an open-source software development framework to model and provision your cloud application resources using familiar programming languages. You can automate release pipelines for your infrastructure defined by the AWS CDK by using tools such as AWS CodePipeline. As the architecture for your application becomes more complex, so too can your release pipelines. When you first create an AWS CDK application, you define a top-level AWS CDK app. Within the app, you typically define one or more stacks, which are the unit of deployment, analogous to AWS CloudFormation stacks. Each stack instance in your AWS CDK app is explicitly or implicitly associated with an environment (env). An environment is the target AWS account and Region into which you intend to deploy the stack. When you attempt to deploy an AWS CDK app that contains multiple environments, managing the credentials for each environment can become difficult and usually involves using custom scripts. This post shows how to use an AWS CDK credential plugin to simplify and streamline deploying AWS CDK apps that contain multiple stacks to deploy to multiple environments. This post assumes that you are explicitly associating your stacks with an environment and may not work with environment-agnostic stacks. AWS CDK credential plugin overview AWS CDK allows the use of plugins during the credential process. By default, it looks for default credentials in a few different places. For more information, see Prerequisites. When you run an AWS CDK command such as synth or deploy, the AWS CDK CLI needs to perform actions against the AWS account that is defined for the stack. It attempts to use your default credentials, but what happens if you need credentials for multiple accounts? This is where credential plugins come into play. The basic flow that the AWS CDK CLI takes when obtaining credentials is as follows: Determine the environment for the stack. Look for credentials to use against that environment. If the default credentials match, the environment uses those. If the default credentials don’t match the environment, it loads any credential plugins and attempts to fetch credentials for the environment using those credential plugins. Walkthrough overview In this walkthrough, you use the cdk-assume-role-credential plugin to read information from multiple AWS accounts as part of the synthesis process. This post assumes you have the following three accounts: Shared services – Where you run the AWS CDK commands from. It has access to assume the role in the other two accounts. This is where you can also deploy a pipeline to automate the deployment of your AWS CDK app. Development application – The development environment (dev) for the application. Production application – The production environment (prod) for the application. However, you can still follow the walkthrough if you only have access to the shared services and either the development or production accounts. The walkthrough follows this high-level process: Download and install the plugin Create the required resources Use the plugin to synthesize CloudFormation templates for the dev and prod account. The sample project used for this walkthrough is located on GitHub. Prerequisites For this walkthrough, you should have the following prerequisites: Access to at least the shared services and either the development or production account. AWS CDK installed with its prerequisites Familiarity with running AWS commands from the AWS CLI Downloading and installing the plugin The cdk-assume-role-credential plugin and sample code used in this post are on the GitHub repo. You need to first clone this repo locally and install the plugin as a global package. Download the GitHub project with the following code: $ git clone https://github.com/aws-samples/cdk-assume-role-credential-plugin.git Install the plugin globally with the following code: $ npm install -g git+https://github.com/aws-samples/cdk-assume-role-credential-plugin.git Creating the required resources Because this plugin uses pre-provisioned roles in the target account, you need to first create those roles. For this post, you create two AWS Identity and Access Management (IAM) roles with the default names that the plugin looks for: cdk-readOnlyRole – Has the ReadOnlyAccess AWS managed policy attached cdk-writeRole – Has the AdministratorAccess AWS managed policy attached Both roles also are configured to trust the shared services account. Before completing the following steps, make sure you have the account IDs for the three accounts and can obtain AWS CLI credentials for each account. Move to the sample-app folder: $ cd cdk-assume-role-credential-plugin/aws-samples Install dependencies: $ npm install Edit the bin/required-resources.ts file and fill in the account numbers where indicated: new RequiredResourcesStack(app, 'dev', { env: { account: 'REPLACE_WITH_DEV_ACCOUNT_ID', region: 'REPLACE_WITH_REGION' }, trustedAccount: 'REPLACE_WITH_SHARED_SERVICES_ACCOUNT_ID' }); new RequiredResourcesStack (app, 'prod', { env: { account: 'REPLACE_WITH_PROD_ACCOUNT_ID', region: 'REPLACE_WITH_REGION' }, trustedAccount: 'REPLACE_WITH_SHARED_SERVICES_ACCOUNT_ID' }); Build the AWS CDK app: $ npm run build Using the AWS CLI credentials for the dev account, run cdk deploy to create the resources: $ cdk deploy dev Using the AWS CLI credentials for the prod account, run cdk deploy to create the resources: $ cdk deploy prod Now you should have the required roles created in both the dev and prod accounts. Synthesizing the AWS CDK app Take a look at the sample app to see what it’s comprised of. When you open the bin/sample-app.ts file, you can see that the AWS CDK app is comprised of two SampleApp stacks: one deployed to the dev account in the us-east-2 region, and the other deployed to the prod account in the us-east-1 region. To synthesize the application, complete the following steps: Edit the bin/sample-app.ts file (fill in the account numbers where indicated): const dev = { account: 'REPLACE_WITH_DEV_ACCOUNT_ID', region: 'us-east-2' } const prod = { account: 'REPLACE_WITH_PROD_ACCOUNT_ID', region: 'us-east-1' } new SampleApp(app, 'devSampleApp', { env: dev }); new SampleApp(app, 'prodSampleApp', { env: prod }); Build the AWS CDK app: $ npm run build Using the AWS CLI credentials for the shared services account, try to synthesize the app: $ cdk synth –-app "npx ts-node bin/sample-app.ts" You should receive an error message similar to the following code, which indicates that you don’t have credentials for the accounts specified: [Error at /devSampleApp] Need to perform AWS calls for account 11111111111, but the current credentials are for 222222222222. [Error at /prodSampleApp] Need to perform AWS calls for account 333333333333, but the current credentials are for 222222222222. Enter the code again, but this time tell it to use cdk-assume-role-credential-plugin: $ cdk synth –-app "npx ts-node bin/sample-app.ts" –-plugin cdk-assume-role-credential-plugin You should see the command succeed: Successfully synthesized to /cdk.out Supply a stack id (devSampleApp, prodSampleApp) to display its template. Cleaning up To avoid incurring future charges, delete the resources. Make sure you’re in the cdk-assume-role-credential-plugin/sample-app/. Using the AWS CLI credentials for the dev account, run cdk destroy to destroy the resources: $ cdk destroy dev Using the AWS CLI credentials for the prod account, run cdk destroy to destroy the resources: $ cdk destroy prod Conclusion You can simplify deploying stacks to multiple accounts by using a credential process plugin cdk-assume-role-credential-plugin. This post provided a straightforward example of using the plugin while deploying an AWS CDK app manually. View the full article