This is the AWS CDK v2 Developer Guide. The older CDK v1 entered maintenance on June 1, 2022 and ended support on June 1, 2023.
AWS CDK stacks
An AWS Cloud Development Kit (AWS CDK) stack is a collection of one or more constructs, which define AWS resources. Each CDK stack represents an AWS CloudFormation stack in your CDK app. At deployment, constructs within a stack are provisioned as a single unit, called an AWS CloudFormation stack. To learn more about AWS CloudFormation stacks, see Working with stacks in the AWS CloudFormation User Guide.
Since CDK stacks are implemented through AWS CloudFormation stacks, AWS CloudFormation quotas and limitations apply. To learn more, see AWS CloudFormation quotas.
How to define a stack
Stacks are defined within the context of an app. You define a stack using the Stack
construct from the AWS Construct Library. Stacks can be
defined in any of the following ways:
-
Directly within the scope of the app.
-
Indirectly by any construct within the tree.
The following example defines a CDK app that contains two stacks:
The following example is a common pattern for defining a stack on a separate file. Here, we extend or inherit the
Stack
class and define a constructor that accepts scope
, id
, and
props
. Then, we invoke the base Stack
class constructor using super
with the
received scope
, id
, and props
.
The following example declares a stack class named MyFirstStack
that includes a single Amazon S3
bucket.
However, this code has only declared a stack. For the stack to actually be synthesized into an
AWS CloudFormation template and deployed, it must be instantiated. And, like all CDK constructs, it must be instantiated in
some context. The App
is that context.
If you're using the standard AWS CDK development template, your stacks are instantiated in the same file where you
instantiate the App
object.
The stack API
The Stack object provides a rich API, including the following:
-
Stack.of(construct)
– A static method that returns the Stack in which a construct is defined. This is useful if you need to interact with a stack from within a reusable construct. The call fails if a stack cannot be found in scope. -
stack.stackName
(Python:stack_name
) – Returns the physical name of the stack. As mentioned previously, all AWS CDK stacks have a physical name that the AWS CDK can resolve during synthesis. -
stack.region
andstack.account
– Return the AWS Region and account, respectively, into which this stack will be deployed. These properties return one of the following:-
The account or Region explicitly specified when the stack was defined
-
A string-encoded token that resolves to the AWS CloudFormation pseudo parameters for account and Region to indicate that this stack is environment agnostic
For information about how environments are determined for stacks, see Environments for the AWS CDK.
-
-
stack.addDependency(stack)
(Python:stack.add_dependency(stack)
– Can be used to explicitly define dependency order between two stacks. This order is respected by the cdk deploy command when deploying multiple stacks at once. -
stack.tags
– Returns a TagManager that you can use to add or remove stack-level tags. This tag manager tags all resources within the stack, and also tags the stack itself when it's created through AWS CloudFormation. -
stack.partition
,stack.urlSuffix
(Python:url_suffix
),stack.stackId
(Python:stack_id
), andstack.notificationArn
(Python:notification_arn
) – Return tokens that resolve to the respective AWS CloudFormation pseudo parameters, such as{ "Ref": "AWS::Partition" }
. These tokens are associated with the specific stack object so that the AWS CDK framework can identify cross-stack references. -
stack.availabilityZones
(Python:availability_zones
) – Returns the set of Availability Zones available in the environment in which this stack is deployed. For environment-agnostic stacks, this always returns an array with two Availability Zones. For environment-specific stacks, the AWS CDK queries the environment and returns the exact set of Availability Zones available in the Region that you specified. -
stack.parseArn(arn)
andstack.formatArn(comps)
(Python:parse_arn
,format_arn
) – Can be used to work with Amazon Resource Names (ARNs). -
stack.toJsonString(obj)
(Python:to_json_string
) – Can be used to format an arbitrary object as a JSON string that can be embedded in an AWS CloudFormation template. The object can include tokens, attributes, and references, which are only resolved during deployment. -
stack.templateOptions
(Python:template_options
) – Use to specify AWS CloudFormation template options, such as Transform, Description, and Metadata, for your stack.
Working with stacks
Stacks are deployed as part of an AWS CloudFormation stack into an AWS environment. The environment covers a specific AWS account and AWS Region.
When you run the cdk synth command for an app with multiple stacks, the cloud assembly includes a separate template for each stack instance. Even if the two stacks are instances of the same class, the AWS CDK emits them as two individual templates.
You can synthesize each template by specifying the stack name in the cdk synth command. The following example synthesizes the template for stack1.
$
cdk synthstack1
This approach is conceptually different from how AWS CloudFormation templates are normally used, where a template can be deployed multiple times and parameterized through AWS CloudFormation parameters. Although AWS CloudFormation parameters can be defined in the AWS CDK, they are generally discouraged because AWS CloudFormation parameters are resolved only during deployment. This means that you cannot determine their value in your code.
For example, to conditionally include a resource in your app based on a parameter value, you must set up an AWS CloudFormation condition and tag the resource with it. The AWS CDK takes an approach where concrete templates are resolved at synthesis time. Therefore, you can use an if statement to check the value to determine whether a resource should be defined or some behavior should be applied.
Note
The AWS CDK provides as much resolution as possible during synthesis time to enable idiomatic and natural usage of your programming language.
Like any other construct, stacks can be composed together into groups. The following code shows an example of a service that consists of three stacks: a control plane, a data plane, and monitoring stacks. The service construct is defined twice: once for the beta environment and once for the production environment.
This AWS CDK app eventually consists of six stacks, three for each environment:
$
cdk ls
betacpDA8372D3 betadataE23DB2BA betamon632BD457 prodcp187264CE proddataF7378CE5 prodmon631A1083
The physical names of the AWS CloudFormation stacks are automatically determined by the AWS CDK based on the stack's construct
path in the tree. By default, a stack's name is derived from the construct ID of the Stack
object.
However, you can specify an explicit name by using the stackName
prop (in Python,
stack_name
), as follows.
Nested stacks
The NestedStack construct offers a way around the AWS CloudFormation 500-resource limit for stacks. A nested stack counts as only one resource in the stack that contains it. However, it can contain up to 500 resources, including additional nested stacks.
The scope of a nested stack must be a Stack
or NestedStack
construct. The nested stack
doesn't need to be declared lexically inside its parent stack. It is necessary only to pass the parent stack as the
first parameter (scope
) when instantiating the nested stack. Aside from this restriction, defining
constructs in a nested stack works exactly the same as in an ordinary stack.
At synthesis time, the nested stack is synthesized to its own AWS CloudFormation template, which is uploaded to the AWS CDK
staging bucket at deployment. Nested stacks are bound to their parent stack and are not treated as independent
deployment artifacts. They aren't listed by cdk list
, and they can't be deployed by cdk
deploy
.
References between parent stacks and nested stacks are automatically translated to stack parameters and outputs in the generated AWS CloudFormation templates, as with any cross-stack reference.
Warning
Changes in security posture are not displayed before deployment for nested stacks. This information is displayed only for top-level stacks.