This is the AWS CDK v2 Developer Guide. The older CDK v1 entered maintenance on June 1, 2022 and will now receive only critical bug fixes and security patches. New features will be developed for CDK v2 exclusively. Support for CDK v1 will end entirely on June 1, 2023.
Import or migrate an existing AWS CloudFormation template
The cloudformation-include.CfnInclude
construct converts the resources in
an imported AWS CloudFormation template to AWS CDK L1 constructs. You can work with these in your app in the
same way that you would if they were defined in AWS CDK code. You can use these L1 constructs
within higher-level AWS CDK constructs. For example, this can let you use the L2 permission grant
methods with the resources they define.
This construct essentially adds an AWS CDK API wrapper to any resource in the template. Use this capability to migrate your existing AWS CloudFormation templates to the AWS CDK a piece at a time. This way, you can take advantage of the AWS CDK's convenient higher-level abstractions. You can also use this feature to vend your AWS CloudFormation templates to AWS CDK developers by providing an AWS CDK construct API.
Note
AWS CDK v1 also included aws-cdk-lib.CfnInclude
, which was previously used for the same general
purpose. However, it lacks much of the functionality of
cloudformation-include.CfnInclude
.
Importing an AWS CloudFormation template
Here is a simple AWS CloudFormation template to use for the examples in this topic. Save it as
my-template.json
. After you've tried these examples with the provided
template, you might explore further using a template for an actual stack you've already
deployed. You can get this template from the AWS CloudFormation console.
Tip
You can use either a JSON or YAML template. We recommend JSON if available, since YAML parsers can vary slightly in what they accept.
{ "Resources": { "MyBucket": { "Type": "AWS::S3::Bucket", "Properties": { "BucketName": "MyBucket", } } } }
And here's how you import it into your stack using
cloudformation-include
.
By default, importing a resource preserves the resource's original logical ID from the template. This behavior is suitable for migrating an AWS CloudFormation template to the AWS CDK, where the logical IDs must be retained. AWS CloudFormation needs this to recognize these as the same resources from the AWS CloudFormation template.
You might instead be developing an AWS CDK construct wrapper for the template so it can be
used by AWS CDK developers ("vending"). If you're doing this, have the AWS CDK generate new
resource IDs instead. That way, the construct can be used multiple times in a stack without
name conflicts. To do this, set the preserveLogicalIds
property to
false
when importing the template.
To put the imported resources under the control of your AWS CDK app, add the stack to the
App
as usual.
To verify that there will be no unintended changes to the AWS resources in the stack, perform a diff, omitting the AWS CDK-specific metadata.
cdk diff --no-version-reporting --no-path-metadata --no-asset-metadata
When you cdk deploy
the stack, your AWS CDK app becomes the source of truth for
the stack. In the future, make changes to the AWS CDK app, not to the AWS CloudFormation template.
Accessing imported resources
The name template
in the example code represents the imported AWS CloudFormation template.
To access a resource from it, use this object's getResource()
method. To access the returned resource as a specific
kind of resource, cast the result to the desired type. (Casting is not necessary in Python and
JavaScript.)
In our example, cfnBucket
is now an instance of the aws-s3.CfnBucket
class, a L1 construct that exactly represents the
corresponding AWS CloudFormation resource. You can treat it like any other resource of its type, for
example getting its ARN by way of the bucket.attrArn
property.
To wrap the L1 CfnBucket
resource in a L2 aws-s3.Bucket
instance instead, use the static methods fromBucketArn()
, fromBucketAttributes()
, or fromBucketName()
. Usually the fromBucketName()
method
is the most convenient. For example:
Other L2 constructs have similar methods for creating the construct from an existing resource.
Constructing the Bucket
this way doesn't create a second Amazon S3 bucket;
instead, the new Bucket
instance encapsulates the existing
CfnBucket
.
In the example, bucket
is now an L2 Bucket
construct that you
can use as you would one you declared yourself. For example, let's say that
lambdaFunc
is an AWS Lambda function, and you want to grant it write access to
the bucket. To do so, use the bucket's convenient grantWrite()
method. You don't need to construct the necessary IAM
policy yourself.
Replacing parameters
If your included AWS CloudFormation template has parameters, you can replace these with build-time
values when you import the template, using the parameters
property. In the
following example, we replace the UploadBucket
parameter with the ARN of a bucket
defined elsewhere in our AWS CDK code.
Other template elements
You can import any AWS CloudFormation template element, not only resources. The imported elements
become part of the AWS CDK stack. To import these elements, use the following methods of the
CfnInclude
object.
-
getCondition()
- AWS CloudFormation conditions -
getHook()
- AWS CloudFormation hooks for blue/green deployments -
getMapping()
- AWS CloudFormation mappings -
getOutput()
- AWS CloudFormation outputs -
getParameter()
- AWS CloudFormation parameters -
getRule()
- AWS CloudFormation rules for AWS Service Catalog templates
Each of these methods returns an instance of a class representing the specific type of AWS CloudFormation element. These objects are mutable; changes that you make to them will appear in the template generated from the AWS CDK stack. The following code, for example, imports a parameter from the template and modifies its default.
Nested stacks
You may import nested stacks
by specifying them either when you import their main template, or at some later point. The
nested template must be stored in a local file, but referenced as a NestedStack
resource in the main template. Also, the resource name used in the AWS CDK code must match the
name used for the nested stack in the main template.
Given this resource definition in the main template, the following code shows how to import the referenced nested stack both ways.
"NestedStack": { "Type": "AWS::CloudFormation::Stack", "Properties": { "TemplateURL": "https://my-s3-template-source.s3.amazonaws.com/nested-stack.json" }
You can import multiple nested stacks with either or both methods. When importing the main
template, you provide a mapping between the resource name of each nested stack and its
template file. This mapping can contain any number of entries. To do it after the initial
import, call loadNestedStack()
once for each nested stack.
After importing a nested stack, you can access it using the main template's getNestedStack()
method.
The getNestedStack()
method returns an IncludedNestedStack
instance. From this instance, you can access the
AWS CDK NestedStack
instance via the stack
property (as shown
in the example). You can also access the original AWS CloudFormation template object via
includedTemplate
, from which you can load resources and other AWS CloudFormation
elements.