AWS CDK Toolkit (`cdk` command)

The AWS CDK Toolkit, the CLI command cdk, is the primary tool for interacting with your AWS CDK app. It executes your app, interrogates the application model you defined, and produces and deploys the AWS CloudFormation templates generated by the AWS CDK. It also provides other features useful for creating and working with AWS CDK projects. This topic contains information about common use cases of the CDK Toolkit.

The AWS CDK Toolkit is installed with the Node Package Manager. In most cases, we recommend installing it globally.

npm install -g aws-cdk             # install latest version
npm install -g aws-cdk@X.YY.Z      # install specific version

Tip
If you regularly work with multiple versions of the AWS CDK, consider installing a matching version of the AWS CDK Toolkit in individual CDK projects. To do this, omit -g from the npm install command. Then use npx aws-cdk to invoke it. This runs the local version if one exists, falling back to a global version if not.

Toolkit commands

All CDK Toolkit commands start with cdk, which is followed by a subcommand (list, synthesize, deploy, etc.). Some subcommands have a shorter version (ls, synth, etc.) that is equivalent. Options and arguments follow the subcommand in any order. The available commands are summarized here.

Command	Function
`cdk list` (`ls`)	Lists the stacks in the app
`cdk synthesize` (`synth`)	Synthesizes and prints the CloudFormation template for one or more specified stacks
`cdk bootstrap`	Deploys the CDK Toolkit staging stack; see Bootstrapping
`cdk deploy`	Deploys one or more specified stacks
`cdk destroy`	Destroys one or more specified stacks
`cdk diff`	Compares the specified stack and its dependencies with the deployed stacks or a local CloudFormation template
`cdk metadata`	Displays metadata about the specified stack
`cdk init`	Creates a new CDK project in the current directory from a specified template
`cdk context`	Manages cached context values
`cdk docs` (`doc`)	Opens the CDK API Reference in your browser
`cdk doctor`	Checks your CDK project for potential problems

For the options available for each command, see Built-in help.

Specifying options and their values

Command line options begin with two hyphens (--). Some frequently used options have single-letter synonyms that begin with a single hyphen (for example, --app has a synonym -a). The order of options in an AWS CDK Toolkit command is not important.

All options accept a value, which must follow the option name. The value may be separated from the name by white space or by an equals sign =. The following two options are equivalent.

--toolkit-stack-name MyBootstrapStack
--toolkit-stack-name=MyBootstrapStack

Some options are flags (Booleans). You may specify true or false as their value. If you do not provide a value, the value is taken to be true. You may also prefix the option name with no- to imply false.

# sets staging flag to true
--staging
--staging=true
--staging true

# sets staging flag to false
--no-staging
--staging=false
--staging false

A few options, namely --context, --parameters, --plugin, --tags, and --trust, may be specified more than once to specify multiple values. These are noted as having [array] type in the CDK Toolkit help. For example:

cdk bootstrap --tags costCenter=0123 --tags responsibleParty=jdoe

Built-in help

The AWS CDK Toolkit has integrated help. You can see general help about the utility and a list of the provided subcommands by issuing:

cdk --help

To see help for a particular subcommand, for example deploy, specify it before the --help flag.

cdk deploy --help

Issue cdk version to display the version of the AWS CDK Toolkit. Provide this information when requesting support.

Version reporting

To gain insight into how the AWS CDK is used, the constructs used by AWS CDK applications are collected and reported by using a resource identified as AWS::CDK::Metadata. This resource is added to AWS CloudFormation templates, and can easily be reviewed. This information can also be used by AWS to identify stacks using a construct with known security or reliability issues. It can also be used to contact their users with important information.

Note
Before version 1.93.0, the AWS CDK reported the names and versions of the modules loaded during synthesis, instead of the constructs used in the stack.

By default, the AWS CDK reports the use of constructs in the following NPM modules that are used in the stack:

AWS CDK core module
AWS Construct Library modules
AWS Solutions Constructs module
AWS Render Farm Deployment Kit module

The AWS::CDK::Metadata resource looks something like the following.

CDKMetadata:
  Type: "AWS::CDK::Metadata"
  Properties:
    Analytics: "v2:deflate64:H4sIAND9SGAAAzXKSw5AMBAA0L1b2PdzBYnEAdio3RglglY60zQi7u6TWL/XKmNUlxeQSOKwaPTBqrNhwEWU3hGHiCzK0dWWfAxoL/Fd8mvk+QkS/0X6BdjnCdgmOOQKWz+AqqLDt2Y3YMnLYWwAAAA="

The Analytics property is a gzipped, base64-encoded, prefix-encoded list of the constructs in the stack.

To opt out of version reporting, use one of the following methods:

Use the cdk command with the --no-version-reporting argument to opt out for a single command.
```
cdk --no-version-reporting synth
```
Remember, the AWS CDK Toolkit synthesizes fresh templates before deploying, so you should also add --no-version-reporting to cdk deploy commands.
Set versionReporting to false in ./cdk.json or ~/.cdk.json. This opts out unless you opt in by specifying --version-reporting on an individual command.
```
{
  "app": "...",
  "versionReporting": false
}
```

Specifying credentials and Region

The CDK Toolkit needs to know your AWS account credentials and the AWS Region that you're deploying into. This is needed for deployment operations and to retrieve context values during synthesis. Together, your account and Region make up the environment.

Important
We strongly recommend against using your main AWS account for day-to-day tasks. Instead, create a user in IAM and use its credentials with the CDK.

Credentials and Region may be specified using environment variables or in configuration files. These are the same variables and files used by other AWS tools such as the AWS CLI and the various AWS SDKs. The CDK Toolkit looks for this information in the following order.

The AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_DEFAULT_REGION environment variables. Always specify all three variables, not only one or two.
A specific profile defined in the standard AWS config and credentials files, and specified using the --profile option on cdk commands.
The [default] section of the standard AWS config and credentials files.

Note
The standard AWS config and credentials files are located at ~/.aws/config and ~/.aws/credentials (macOS/Linux) or %USERPROFILE%\.aws\config and %USERPROFILE%\.aws\credentials (Windows).

The environment that you specify in your AWS CDK app by using the stack's env property is used during synthesis. It's used to generate an environment-specific AWS CloudFormation template, and during deployment, it overrides the account or Region specified by one of the preceding methods. For more information, see Environments.

If you have the AWS CLI installed, the easiest way to configure your account credentials and a default Region is to issue the following command:

aws configure

Provide your AWS access key ID, secret access key, and default Region when prompted. These values are written to the [default] section of the config and credentials files.

If you don't have the AWS CLI installed, you can manually create or edit the config and credentials files to contain default credentials and a default Region. Use the following format.

In ~/.aws/config or %USERPROFILE%\.aws\config
```
[default]
region=us-west-2
```

In ~/.aws/credentials or %USERPROFILE%\.aws\credentials

[default]
aws_access_key_id=AKIAI44QH8DHBEXAMPLE
aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

Besides specifying AWS credentials and a Region in the [default] section, you can also add one or more [profile NAME] sections, where NAME is the name of the profile.

In ~/.aws/config or %USERPROFILE%\.aws\config

[profile test]
region=us-east-1

[profile prod]
region=us-west-1

In ~/.aws/credentials or %USERPROFILE%\.aws\credentials

[profile test]
aws_access_key_id=AKIAI44QH8DHBEXAMPLE
aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

[profile test]
aws_access_key_id=AKIAI44QH8DHBEXAMPLE
aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

Always add named profiles to both the config and credentials files. The AWS CDK Toolkit doesn't fall back to using the Region in the [default] section when the specified named profile is not found in the config file. However, some other AWS tools do.

Important
Do not name a profile default. That is, do not use a [profile default] section in either config or credentials.

Note
The AWS CDK uses credentials from the same sources files as other AWS tools and SDKs, including the AWS Command Line Interface. However, the AWS CDK might behave somewhat differently from these tools. It uses the AWS SDK for JavaScript under the hood. For complete details on setting up credentials for the AWS SDK for JavaScript, see Setting credentials.

You may optionally use the --role-arn (or -r) option to specify the ARN of an IAM role that should be used for deployment. This role must be assumable by the AWS account being used.

Specifying the app command

Many features of the CDK Toolkit require one or more AWS CloudFormation templates be synthesized, which in turn requires running your application. The AWS CDK supports programs written in a variety of languages. Therefore, it uses a configuration option to specify the exact command necessary to run your app. This option can be specified in two ways.

First, and most commonly, it can be specified using the app key inside the file cdk.json. This is in the main directory of your AWS CDK project. The CDK Toolkit provides an appropriate command when creating a new project with cdk init. Here is the cdk.json from a fresh TypeScript project, for instance.

{
  "app": "npx ts-node bin/hello-cdk.ts"
}

The CDK Toolkit looks for cdk.json in the current working directory when attempting to run your app. Because of this, you might keep a shell open in your project's main directory for issuing CDK Toolkit commands.

The CDK Toolkit also looks for the app key in ~/.cdk.json (that is, in your home directory) if it can't find it in ./cdk.json. Adding the app command here can be useful if you usually work with CDK code in the same language.

If you are in some other directory, or to run your app using a command other than the one in cdk.json, use the --app (or -a) option to specify it.

cdk --app "npx ts-node bin/hello-cdk.ts" ls

When deploying, you may also specify a directory containing synthesized cloud assemblies, such as cdk.out, as the value of --app. The specified stacks are deployed from this directory; the app is not synthesized.

Specifying stacks

Many CDK Toolkit commands (for example, cdk deploy) work on stacks defined in your app. If your app contains only one stack, the CDK Toolkit assumes you mean that one if you don't specify a stack explicitly.

Otherwise, you must specify the stack or stacks you want to work with. You can do this by specifying the desired stacks by ID individually on the command line. Recall that the ID is the value specified by the second argument when you instantiate the stack.

cdk synth PipelineStack LambdaStack

You may also use wildcards to specify IDs that match a pattern.

? matches any single character
* matches any number of characters (* alone matches all stacks)
** matches everything in a hierarchy

You may also use the --all option to specify all stacks.

If your app uses CDK Pipelines, the CDK Toolkit understands your stacks and stages as a hierarchy. Also, the --all option and the * wildcard only match top-level stacks. To match all the stacks, use **. Also use ** to indicate all the stacks under a particular hierarchy.

When using wildcards, enclose the pattern in quotes, or escape the wildcards with \. If you don't, your shell may try to expand the pattern to the names of files in the current directory. At best, this won't do what you expect; at worst, you could deploy stacks you didn't intend to. This isn't strictly necessary on Windows because cmd.exe does not expand wildcards, but is good practice nonetheless.

cdk synth "*Stack"    # PipelineStack, LambdaStack, etc.
cdk synth 'Stack?'    # StackA, StackB, Stack1, etc.
cdk synth \*          # All stacks in the app, or all top-level stacks in a CDK Pipelines app
cdk synth '**'        # All stacks in a CDK Pipelines app
cdk synth 'PipelineStack/Prod/**'   # All stacks in Prod stage in a CDK Pipelines app

Note
The order in which you specify the stacks is not necessarily the order in which they will be processed. The AWS CDK Toolkit accounts for dependencies between stacks when deciding the order in which to process them. For example, let's say that one stack uses a value produced by another (such as the ARN of a resource defined in the second stack). In this case, the second stack is synthesized before the first one because of this dependency. You can add dependencies between stacks manually using the stack's https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.Stack.html#addwbrdependencytarget-reason method.

Bootstrapping your AWS environment

Deploying stacks with the CDK requires special dedicated AWS CDK resources to be provisioned. The cdk bootstrap command creates the necessary resources for you. You only need to bootstrap if you are deploying a stack that requires these dedicated resources. See Bootstrapping for details.

cdk bootstrap

If issued with no arguments, as shown here, the cdk bootstrap command synthesizes the current app and bootstraps the environments its stacks will be deployed to. If the app contains environment-agnostic stacks, which don't explicitly specify an environment, the default account and Region are bootstrapped, or the environment specified using --profile.

Outside of an app, you must explicitly specify the environment to be bootstrapped. You may also do so to bootstrap an environment that's not specified in your app or local AWS profile. Credentials must be configured (e.g. in ~/.aws/credentials) for the specified account and Region. You may specify a profile that contains the required credentials.

cdk bootstrap ACCOUNT-NUMBER/REGION # e.g.
cdk bootstrap 1111111111/us-east-1
cdk bootstrap --profile test 1111111111/us-east-1

Important
Each environment (account/region combination) to which you deploy such a stack must be bootstrapped separately.

You may incur AWS charges for what the AWS CDK stores in the bootstrapped resources. Additionally, if you use -bootstrap-customer-key, an AWS KMS key will be created, which also incurs charges per environment.

Note
Earlier versions of the bootstrap template created a KMS key by default. To avoid charges, re-bootstrap using --no-bootstrap-customer-key.

Note
CDK Toolkit v2 does not support the original bootstrap template, dubbed the legacy template, used by default with CDK v1.

Important
The modern bootstrap template effectively grants the permissions implied by the --cloudformation-execution-policies to any AWS account in the --trust list. By default, this extends permissions to read and write to any resource in the bootstrapped account. Make sure to configure the bootstrapping stack with policies and trusted accounts that you are comfortable with.

Creating a new app

To create a new app, create a directory for it, then, inside the directory, issue cdk init.

mkdir my-cdk-app
cd my-cdk-app
cdk init TEMPLATE --language LANGUAGE

The supported languages (LANGUAGE) are:

Code	Language
`typescript`	TypeScript
`javascript`	JavaScript
`python`	Python
`java`	Java
`csharp`	C#

TEMPLATE is an optional template. If the desired template is app, the default, you may omit it. The available templates are:

Template	Description
`app` (default)	Creates an empty AWS CDK app.
`sample-app`	Creates an AWS CDK app with a stack containing an Amazon SQS queue and an Amazon SNS topic.

The templates use the name of the project folder to generate names for files and classes inside your new app.

Listing stacks

To see a list of the IDs of the stacks in your AWS CDK application, enter one of the following equivalent commands:

cdk list
cdk ls

If your application contains CDK Pipelines stacks, the CDK Toolkit displays stack names as paths according to their location in the pipeline hierarchy. (For example, PipelineStack, PipelineStack/Prod, and PipelineStack/Prod/MyService.)

If your app contains many stacks, you can specify full or partial stack IDs of the stacks to be listed. For more information, see Specifying stacks.

Add the --long flag to see more information about the stacks, including the stack names and their environments (AWS account and Region).

Synthesizing stacks

The cdk synthesize command (almost always abbreviated synth) synthesizes a stack defined in your app into a CloudFormation template.

cdk synth         # if app contains only one stack
cdk synth MyStack
cdk synth Stack1 Stack2
cdk synth "*"     # all stacks in app

Note
The CDK Toolkit actually runs your app and synthesizes fresh templates before most operations (such as when deploying or comparing stacks). These templates are stored by default in the cdk.out directory. The cdk synth command simply prints the generated templates for one or more specified stacks.

See cdk synth --help for all available options. A few of the most frequently used options are covered in the following section.

Specifying context values

Use the --context or -c option to pass runtime context values to your CDK app.

# specify a single context value
cdk synth --context key=value MyStack

# specify multiple context values (any number)
cdk synth --context key1=value1 --context key2=value2 MyStack

When deploying multiple stacks, the specified context values are normally passed to all of them. If you want, you can specify different values for each stack by prefixing the stack name to the context value.

# different context values for each stack
cdk synth --context Stack1:key=value Stack2:key=value Stack1 Stack2

Specifying display format

By default, the synthesized template is displayed in YAML format. Add the --json flag to display it in JSON format instead.

cdk synth --json MyStack

Specifying output directory

Add the --output (-o) option to write the synthesized templates to a directory other than cdk.out.

cdk synth --output=~/templates

Deploying stacks

The cdk deploy subcommand deploys one or more specified stacks to your AWS account.

cdk deploy        # if app contains only one stack
cdk deploy MyStack
cdk deploy Stack1 Stack2
cdk deploy "*"    # all stacks in app

Note
The CDK Toolkit runs your app and synthesizes fresh AWS CloudFormation templates before deploying anything. Therefore, most command line options you can use with cdk synth (for example, --context) can also be used with cdk deploy.

See cdk deploy --help for all available options. A few of the most useful options are covered in the following section.

Skipping synthesis

The cdk deploy command normally synthesizes your app's stacks before deploying to make sure that the deployment reflects the latest version of your app. If you know that you haven't changed your code since your last cdk synth, you can suppress the redundant synthesis step when deploying. To do so, specify your project's cdk.out directory in the --app option.

cdk deploy --app cdk.out StackOne StackTwo

Disabling rollback

AWS CloudFormation has the ability to roll back changes so that deployments are atomic. This means that they either succeed or fail as a whole. The AWS CDK inherits this capability because it synthesizes and deploys AWS CloudFormation templates.

Rollback makes sure that your resources are in a consistent state at all times, which is vital for production stacks. However, while you're still developing your infrastructure, some failures are inevitable, and rolling back failed deployments can slow you down.

For this reason, the CDK Toolkit lets you disable rollback by adding --no-rollback to your cdk deploy command. With this flag, failed deployments are not rolled back. Instead, resources deployed before the failed resource remain in place, and the next deployment starts with the failed resource. You'll spend a lot less time waiting for deployments and a lot more time developing your infrastructure.

Hot swapping

Use the --hotswap flag with cdk deploy to attempt to update your AWS resources directly instead of generating an AWS CloudFormation changeset and deploying it. Deployment falls back to AWS CloudFormation deployment if hot swapping is not possible.

Currently hot swapping supports Lambda functions, Step Functions state machines, and Amazon ECS container images. The --hotswap flag also disables rollback (i.e., implies --no-rollback).

Important
Hot-swapping is not recommended for production deployments.

Watch mode

The CDK Toolkit's watch mode ( cdk deploy --watch, or cdk watch for short) continuously monitors your CDK app's source files and assets for changes. It immediately performs a deployment of the specified stacks when a change is detected.

By default, these deployments use the --hotswap flag, which fast-tracks deployment of changes to Lambda functions. It also falls back to deploying through AWS CloudFormation if you have changed infrastructure configuration. To have cdk watch always perform full AWS CloudFormation deployments, add the --no-hotswap flag to cdk watch.

Any changes made while cdk watch is already performing a deployment are combined into a single deployment, which begins as soon as the in-progress deployment is complete.

Watch mode uses the "watch" key in the project's cdk.json to determine which files to monitor. By default, these files are your application files and assets, but this can be changed by modifying the "include" and "exclude" entries in the "watch" key. The following cdk.json file shows an example of these entries.

{
  "app": "mvn -e -q compile exec:java",
  "watch": {
    "include": "src/main/**",
    "exclude": "target/*"
  }
}

cdk watch executes the "build" command from cdk.json to build your app before synthesis. If your deployment requires any commands to build or package your Lambda code (or anything else that's not in your CDK app), add it here.

Git-style wildcards, both * and **, can be used in the "watch" and "build" keys. Each path is interpreted relative to the parent directory of cdk.json. The default value of include is **/*, meaning all files and directories in the project root directory. exclude is optional.

Important
Watch mode is not recommended for production deployments.

Specifying AWS CloudFormation parameters

The AWS CDK Toolkit supports specifying AWS CloudFormation parameters at deployment. You may provide these on the command line following the --parameters flag.

cdk deploy MyStack --parameters uploadBucketName=UploadBucket

To define multiple parameters, use multiple --parameters flags.

cdk deploy MyStack --parameters uploadBucketName=UpBucket --parameters downloadBucketName=DownBucket

If you are deploying multiple stacks, you can specify a different value of each parameter for each stack. To do so, prefix the name of the parameter with the stack name and a colon. Otherwise, the same value is passed to all stacks.

cdk deploy MyStack YourStack --parameters MyStack:uploadBucketName=UploadBucket --parameters YourStack:uploadBucketName=UpBucket

By default, the AWS CDK retains values of parameters from previous deployments and uses them in later deployments if they are not specified explicitly. Use the --no-previous-parameters flag to require all parameters to be specified.

Specifying outputs file

If your stack declares AWS CloudFormation outputs, these are normally displayed on the screen at the conclusion of deployment. To write them to a file in JSON format, use the --outputs-file flag.

cdk deploy --outputs-file outputs.json MyStack

Security-related changes

To protect you against unintended changes that affect your security posture, the AWS CDK Toolkit prompts you to approve security-related changes before deploying them. You can specify the level of change that requires approval:

cdk deploy --require-approval LEVEL

LEVEL can be one of the following:

Term	Meaning
`never`	Approval is never required
`any-change`	Requires approval on any IAM or security-group-related change
`broadening` (default)	Requires approval when IAM statements or traffic rules are added; removals don't require approval

The setting can also be configured in the cdk.json file.

{
  "app": "...",
  "requireApproval": "never"
}

Comparing stacks

The cdk diff command compares the current version of a stack (and its dependencies) defined in your app with the already-deployed versions, or with a saved AWS CloudFormation template, and displays a list of changes.

Stack HelloCdkStack
IAM Statement Changes
┌───┬──────────────────────────────┬────────┬──────────────────────────────┬──────────────────────────────┬───────────┐
│   │ Resource                     │ Effect │ Action                       │ Principal                    │ Condition │
├───┼──────────────────────────────┼────────┼──────────────────────────────┼──────────────────────────────┼───────────┤
│ + │ ${Custom::S3AutoDeleteObject │ Allow  │ sts:AssumeRole               │ Service:lambda.amazonaws.com │           │
│   │ sCustomResourceProvider/Role │        │                              │                              │           │
│   │ .Arn}                        │        │                              │                              │           │
├───┼──────────────────────────────┼────────┼──────────────────────────────┼──────────────────────────────┼───────────┤
│ + │ ${MyFirstBucket.Arn}         │ Allow  │ s3:DeleteObject*             │ AWS:${Custom::S3AutoDeleteOb │           │
│   │ ${MyFirstBucket.Arn}/*       │        │ s3:GetBucket*                │ jectsCustomResourceProvider/ │           │
│   │                              │        │ s3:GetObject*                │ Role.Arn}                    │           │
│   │                              │        │ s3:List*                     │                              │           │
└───┴──────────────────────────────┴────────┴──────────────────────────────┴──────────────────────────────┴───────────┘
IAM Policy Changes
┌───┬────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────┐
│   │ Resource                                               │ Managed Policy ARN                                     │
├───┼────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────┤
│ + │ ${Custom::S3AutoDeleteObjectsCustomResourceProvider/Ro │ {"Fn::Sub":"arn:${AWS::Partition}:iam::aws:policy/serv │
│   │ le}                                                    │ ice-role/AWSLambdaBasicExecutionRole"}                 │
└───┴────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────┘
(NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299)

Parameters
[+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/S3Bucket AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392S3BucketBF7A7F3F: {"Type":"String","Description":"S3 bucket for asset \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""}
[+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/S3VersionKey AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392S3VersionKeyFAF93626: {"Type":"String","Description":"S3 key for asset version \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""}
[+] Parameter AssetParameters/4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392/ArtifactHash AssetParameters4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392ArtifactHashE56CD69A: {"Type":"String","Description":"Artifact hash for asset \"4cd61014b71160e8c66fe167e43710d5ba068b80b134e9bd84508cf9238b2392\""}

Resources
[+] AWS::S3::BucketPolicy MyFirstBucket/Policy MyFirstBucketPolicy3243DEFD
[+] Custom::S3AutoDeleteObjects MyFirstBucket/AutoDeleteObjectsCustomResource MyFirstBucketAutoDeleteObjectsCustomResourceC52FCF6E
[+] AWS::IAM::Role Custom::S3AutoDeleteObjectsCustomResourceProvider/Role CustomS3AutoDeleteObjectsCustomResourceProviderRole3B1BD092
[+] AWS::Lambda::Function Custom::S3AutoDeleteObjectsCustomResourceProvider/Handler CustomS3AutoDeleteObjectsCustomResourceProviderHandler9D90184F
[~] AWS::S3::Bucket MyFirstBucket MyFirstBucketB8884501
 ├─ [~] DeletionPolicy
 │   ├─ [-] Retain
 │   └─ [+] Delete
 └─ [~] UpdateReplacePolicy
     ├─ [-] Retain
     └─ [+] Delete

To compare your app's stacks with the existing deployment:

cdk diff MyStack

To compare your app's stacks with a saved CloudFormation template:

cdk diff --template ~/stacks/MyStack.old MyStack

Configuration (`cdk.json`)

Default values for many CDK Toolkit command line flags can be stored in a project's cdk.json file or in the .cdk.json file in your user directory. Following is an alphabetical reference to the supported configuration settings.

Key	Notes	CDK Toolkit option
app	The command that executes the CDK application.	--app
assetMetadata	If false, CDK does not add metadata to resources that use assets.	--no-asset-metadata
bootstrapKmsKeyId	Overrides the ID of the AWS KMS key used to encrypt the Amazon S3 deployment bucket.	--bootstrap-kms-key-id
build	The command that compiles or builds the CDK application before synthesis. Not permitted in ~/.cdk.json.	--build
browser	The command for launching a Web browser for the cdk docs subcommand.	--browser
context	See Runtime context. Context values in a configuration file will not be erased by cdk context --clear. (The CDK Toolkit places cached context values in cdk.context.json.)	--context
debug	If true, CDK Toolkit emits more detailed information useful for debugging.	--debug
language	The language to be used for initializing new projects.	--language
lookups	If false, no context lookups are permitted. Synthesis will fail if any context lookups need to be performed.	--no-lookups
notices	If false, suppresses the display of messages about security vulnerabilities, regressions, and unsupported versions.	--no-notices
output	The name of the directory into which the synthesized cloud assembly will be emitted (default "cdk.out").	--output
outputsFile	The file to which AWS CloudFormation outputs from deployed stacks will be written (in JSON format).	--outputs-file
pathMetadata	If false, CDK path metadata is not added to synthesized templates.	--no-path-metadata
plugin	JSON array specifying the package names or local paths of packages that extend the CDK	--plugin
profile	Name of the default AWS profile used for specifying Region and account credentials.	--profile
progress	If set to "events", the CDK Toolkit displays all AWS CloudFormation events during deployment, rather than a progress bar.	--progress
requireApproval	Default approval level for security changes. See Security-related changes	--require-approval
rollback	If false, failed deployments are not rolled back.	--no-rollback
staging	If false, assets are not copied to the output directory (use for local debugging of the source files with AWS SAM).	--no-staging
tags	JSON object containing tags (key-value pairs) for the stack.	--tags
toolkitBucketName	The name of the Amazon S3 bucket used for deploying assets such as Lambda functions and container images (see Bootstrapping your AWS environment.	--toolkit-bucket-name
toolkitStackName	The name of the bootstrap stack (see Bootstrapping your AWS environment.	--toolkit-stack-name
versionReporting	If false, opts out of version reporting.	--no-version-reporting
watch	JSON object containing "include" and "exclude" keys that indicate which files should (or should not) trigger a rebuild of the project when changed. See Watch mode.	--watch

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cli.md

cli.md

AWS CDK Toolkit (`cdk` command)

Toolkit commands

Specifying options and their values

Built-in help

Version reporting

Specifying credentials and Region

Specifying the app command

Specifying stacks

Bootstrapping your AWS environment

Creating a new app

Listing stacks

Synthesizing stacks

Specifying context values

Specifying display format

Specifying output directory

Deploying stacks

Skipping synthesis

Disabling rollback

Hot swapping

Watch mode

Specifying AWS CloudFormation parameters

Specifying outputs file

Security-related changes

Comparing stacks

Configuration (`cdk.json`)

Files

cli.md

Latest commit

History

cli.md

File metadata and controls

AWS CDK Toolkit (cdk command)

Toolkit commands

Specifying options and their values

Built-in help

Version reporting

Specifying credentials and Region

Specifying the app command

Specifying stacks

Bootstrapping your AWS environment

Creating a new app

Listing stacks

Synthesizing stacks

Specifying context values

Specifying display format

Specifying output directory

Deploying stacks

Skipping synthesis

Disabling rollback

Hot swapping

Watch mode

Specifying AWS CloudFormation parameters

Specifying outputs file

Security-related changes

Comparing stacks

Configuration (cdk.json)

AWS CDK Toolkit (`cdk` command)

Configuration (`cdk.json`)