Right, let’s talk about the CDK CLI. This is your new best friend and the primary way you’ll stop drawing architecture diagrams and start actually building the things on them. Forget the AWS console’s point-and-click ballet; we’re conducting the orchestra with code now. The CLI is your baton. It’s a surprisingly sharp tool, but like any good power tool, you can lose a finger if you’re not paying attention.

The first thing you need to know is that under its sleek exterior, the CDK CLI is basically a very sophisticated code generator and a deployment orchestrator. It takes your beautiful, abstract, object-oriented TypeScript (or Python, or whatever you prefer) and translates it, through a process called synthesis, into a massive, gnarly CloudFormation template. Then it hands that template to CloudFormation and says, “You deal with this.” We’re writing poetry; CloudFormation is reading it back to us as assembly instructions. The CLI manages that whole, slightly awkward, relationship.

Your First CDK App: cdk init

You don’t build a house by first laying bricks; you pour a foundation. cdk init pours the foundation. It scaffolds a new project with all the necessary wiring, dependencies, and a sample “Hello, World” stack to prove it works.

Open a terminal and run:

cdk init app --language typescript

This does a few key things you should care about:

  1. It creates a new directory with your project name (usually the name of the current folder).
  2. It sets up a proper Node.js project with a package.json, locking your dependencies so your project doesn’t randomly break in six months when a new CDK version drops.
  3. It generates a tsconfig.json because we’re not savages; we use type safety.
  4. It creates bin/<your-project-name>.ts and lib/<your-project-name>-stack.ts. This separation is crucial. The bin file is the app’s entry point—it instantiates the stack. The lib file defines the stack. This matters later when you have multiple stacks.

The sample code it generates will, almost certainly, deploy an S3 bucket. It’s the “Hello, World” of infrastructure. Run npm install to get all the dependencies, and then you’re ready for the next step.

Peeking Under the Hood: cdk synth

Here’s where the magic—or, more accurately, the tedious translation—happens. Running cdk synth tells the CDK, “Take my code, resolve all those imports and logic, and show me the raw CloudFormation JSON/YAML you would generate.” It does this without touching AWS. It’s a dry run.

cdk synth

You’ll be greeted with a wall of YAML text scrolling through your terminal. It’s… ugly. But it’s beautiful because it’s exactly what CloudFormation will see. Use this constantly. Before you deploy, always synth. It’s the best way to catch silly mistakes like forgetting to grant an IAM permission or creating a circular dependency. If the synth output looks sane, you’re probably good. If it’s a mess, your code is a mess.

The “What If?” Machine: cdk diff

This is arguably the most useful command in the entire kit. cdk diff does a synth, takes the generated template, and compares it against the currently deployed template for that stack in AWS. It then shows you exactly what will change if you run deploy.

cdk diff

You’ll see green lines with a + for new resources, red lines with a - for resources that will be deleted, and yellow changes for modifications. Pay very close attention to the red lines. CloudFormation’s default behavior is to delete resources that are no longer in your template. This is usually what you want, unless that resource is a database full of production data. cdk diff is your last line of defense against accidentally nuking something important. I don’t just recommend using it; I insist. It should be muscle memory.

The Point of No Return: cdk deploy

This is it. The button that makes the magic happen. cdk deploy will:

  1. Synthesize your app into a CloudFormation template.
  2. Package up any local assets (like Lambda function code).
  3. Create a Change Set in CloudFormation (a preview of the changes).
  4. And then, after prompting you, execute that Change Set.
cdk deploy

It will ask for confirmation. Always read the list of IAM changes it shows you. It’s telling you, “Hey, I’m about to create these roles and policies with these permissions.” Make sure they’re not hilariously over-permissive. You can auto-approve with --require-approval never, but I only use that for CI/CD pipelines. For local development, always approve manually. It’s a good habit.

The “Oh Crap” Button: cdk destroy

This does exactly what it says on the tin. It tells CloudFormation to delete all the resources in the stack. It’s the nuclear option.

cdk destroy

This command is dangerous and irrevocable. It will delete S3 buckets (and their contents!), databases, everything managed by the stack. There is no trash can to recover from. Use it with extreme prejudice and always, always, always run cdk diff first to see what it plans to obliterate. The CDK and CloudFormation are ruthless efficiency experts; they won’t ask twice. They’ll just start tearing things down.

A final pro tip: most of these commands accept a --profile flag. Use it religiously if you work with multiple AWS accounts. Specifying cdk deploy --profile production is a much better way to avoid deploying your silly test stack to prod than sweating bullets and double-checking your AWS config. Trust me. I’ve learned this the hard way so you don’t have to.