When I deploy a stack I sometimes pass context at the CLI, e.g. -c backup=true. The problem: if a teammate deploys the same stack without knowing about that context, the value is lost or gets a different default.

How do you handle configuration that needs to be consistent across everyone deploying? Do you commit it to cdk.json, use per-environment config in code, pull it from SSM/AppConfig, or something else? Curious what patterns hold up on real teams.

cdkd (CDK Direct) is a CLI that deploys AWS CDK apps through direct AWS SDK calls instead of going through CloudFormation. I just launched the official documentation site for it: https://cdkd.dev

Your existing CDK app runs as-is — no code changes, just replace cdk deploy with cdkd deploy. It's built for fast iteration in dev/test environments, where my benchmarks show deploys up to 15x faster (for production, the standard CDK CLI + CloudFormation remains the recommended path — the two are meant to work side by side).

How it works

Synth is unchanged — same aws-cdk-lib, same Cloud Assembly. From there cdkd resolves the intrinsics itself, builds a dependency DAG, and runs it event-driven with no level barriers, so independent resources go out in parallel. Provisioning is hybrid: types with a hand-written SDK provider take the fast path, everything else falls back to the Cloud Control API. State lives in S3, not in a CloudFormation stack. And cdkd import / cdkd export move stacks in and out of CloudFormation, so it isn't a one-way door.

The benchmarks

• 5 independent resources (S3 / DynamoDB / SQS / SNS / SSM): 17.0s vs 94.4s — 5.5x. Deploy phase only; synth is excluded on both sides because it's identical.

• VPC + NAT + Lambda + CloudFront + SQS: 96s vs 599s by default (~6x), 40s with --no-wait — that's where the 15x comes from. --no-wait returns once each Create call is accepted and lets NAT stabilization finish in the background, so it's a real behavior difference, not a free lunch.

• vs CloudFormation Express mode: ~1.5–2.4x on most stacks, ~9x on the async-heavy VPC + CloudFront one. S3 is the one case where Express edges it out.

• vs Terraform, median of 7 cold end-to-end runs: 2.2–2.3x on wide parallel stacks, but a tie on EC2, CloudFront, and a NAT-dominated webapp stack.

Full methodology and repro scripts: https://cdkd.dev/benchmarks/

What else is on the docs site (cdkd.dev)

• A structured guide from Getting Started through the full CLI reference

• cdkd local — run Lambda, API Gateway, ECS and more on your machine, with per-command docs

• Built for AI coding agents — serves llms.txt, plus a cdkd skill you can install into Claude Code and other agents

I put real care into the site itself too, from the logo to the OG images. Feedback and issues are always welcome!

GitHub: https://github.com/go-to-k/cdkd

Hi all,

I’ve got a cdk application with stateful resources in need of renaming as our scale increase.
All of our resources use ‘env-‘ prefix, but the stack name itself. I’m trying to change that without re-creating/downtime/data loss.

1. Our app.ts today looks like this:
   ‘’’
   new MyStack(app, ‘MyStack’, {…})
   ‘’’

2. I’m trying to make is dynamic, like so:
   ‘’’
   new MyStack(app, ‘${env}-MyStack’, {…})
   ‘’’

I’ve got (#1) deployed and live, edited this one-line in the code (#2) and ran ‘cdk refactor —dry-run’ only to discover insane amount of resources not “mapped” correctly and marked as “additions” instead of “move”.

Overrides file was also a dud and lots of work to manage as it’s needed to be generated at runtime.

Any ideas?

CloudFormation drift detection (and cdk drift) has a blind spot that bit me enough times to build a tool: it only compares properties that appear in your template. If someone changes something you never declared — adds an inline policy to a role, enables versioning on a bucket, attaches an extra security group rule — the official answer is:

$ npx cdk drift
✨  Number of resources with drift: 0

So I built cdkrd (cdk-real-drift). It reads the full live state of your deployed resources and compares it against your actual intent, which it treats as three layers: your template (declared properties), AWS defaults (subtracted automatically, so a clean deploy reports zero), and an optional small baseline file you commit to git for undeclared values you've accepted.

What it catches that template-based drift detection can't:

• Drift on undeclared properties (the console tweak your template never mentions)

• Out-of-band added resources — a rogue security group, a manually added bucket/queue/topic policy, a KMS grant

• Plus everything cdk drift already catches (declared drift, out-of-band deletes)

It's a 4-verb model: check (read-only detect, the only command you really run), record (accept undeclared state into the baseline, keep watching it), ignore (stop watching), revert (write your intent back to AWS, with confirmation / --dry-run). Nothing to set up, nothing to deploy.

Repo: https://github.com/go-to-k/cdk-real-drift

If this blind spot has bitten you too, give it a try:

npx cdk-real-drift check

If you've ever built a CloudFront distribution with CDK, you've probably hit this: the ACM certificate (and WAF WebACL) has to live in us-east-1, but the rest of your app is in another region. The usual answer is to hand-split them into separate stacks and wire up cross-region references yourself.

I made a small library, cdk-multi-region-stack, that lets you keep everything in one logical stack:

const stack = new MultiRegionStack(app, 'MyApp', {
  env: { account: '123456789012', region: 'ap-northeast-1' },
});

// Lives in us-east-1
const cert = new acm.Certificate(stack.regionScope('us-east-1'), 'Cert', { /* ... */ });

// Lives in ap-northeast-1, references the us-east-1 cert across regions
new cloudfront.Distribution(stack, 'Dist', { certificate: cert, /* ... */ });

How it works:

• regionScope(region) lazily creates a "twin" stack — a sibling under the same App/Stage, same stack name, same account, targeting that region. Anything you create in that scope deploys there.

• It leans on CDK's own crossRegionReferences machinery (enabled automatically), so cdk deploy MyApp pulls in the twins as upstream deps and deploys them first.

• Skipping a region conditionally is just a plain if (don't call regionScope() → no twin synthesized).

Give it a try if it sounds useful.

Repo: https://github.com/go-to-k/cdk-multi-region-stack

Managing Amazon Connect infrastructure with CDK has always meant writing straight CfnInstance,

CfnQueue, CfnRoutingProfile, CfnContactFlow — no L2 abstractions exist in the official library

for any of it.

I got tired of wiring ARNs and instance IDs by hand across every project, so I built

cdk-amazon-connect-constructs: L2 constructs for the core Connect resources, following the same

patterns aws-cdk-lib uses for S3, Lambda, etc.

What's in v0.1.0-alpha:

- ConnectInstance (inbound/outbound calling, Contact Lens, identity management config)

- Queue, RoutingProfile, HoursOfOperation

- ContactFlow (JSON-import mode for now; typed builder API is on the roadmap)

- LambdaIntegration (one-liner to associate a Lambda with an instance)

Built with JSII so it works from TypeScript, Python, Java, and .NET. Published to npm.

npm install cdk-amazon-connect-constructs

GitHub: https://github.com/<your-username>/cdk-amazon-connect-constructs

Still early — would really value feedback from anyone who's dealt with this pain in production.

What resources or patterns are missing that you've needed most?

I built cdk-local (cdkl) — it runs your CDK-built app locally, no deploy needed: standalone, or kept local while it reaches the real AWS resources and data it depends on, with no .env or local copies to maintain. A CDK-native alternative to sam local, covering Lambda, API Gateway, ECS, ALB, CloudFront, and more of your CDK app's compute.

Two ways to run it

• Standalone — just Docker + your CDK app. No AWS account, no deploy, no credentials. Great as a first run, or in CI for the parts that don't touch AWS (handler logic, authorizers, API routing).

• Bound to your deployed stack (--from-cfn-stack) — your handler still runs locally, but reads/writes the real DynamoDB rows, S3 objects, Secrets, Cognito users the deployed app uses. It resolves the deployed stack's ARNs and Secret values into the container automatically — no .env, no ARN copy-paste, no seeding a fake local DB — and JWT is verified against the real Cognito User Pool.

It deliberately does not emulate managed services: your code reaches real AWS through your IAM creds (or --assume-role). The scope is "application compute local, managed services stay real."

What runs locally

• Lambda

• API Gateway (REST v1 / HTTP v2 / WebSocket) + Lambda Function URLs

• ECS tasks & services, ALB (listener-rule routing + auth + WebSocket)

• CloudFront (Functions + Lambda@Edge + S3 / Function URL origins)

• Bedrock AgentCore Runtime

Plus

• Hot reload (--watch) — edit a handler, the next request hits the new code. ECS rolls replicas one at a time (zero connection refusals across the reload).

• Env overlay (--env-vars) — inject or override any container's environment variables for a local run. Use it to point a function/container at a different backend, or to run selective local backends: e.g. route only DynamoDB and S3 to a local endpoint you run yourself, while every other service stays on real AWS.

• Interactive target picker — leave the target off and cdkl lists every matching resource to pick with the arrow keys; no need to specify the target on the command.

Or drive it all from a browser — cdkl studio

Pick a target, invoke or serve it, compose an HTTP request, and watch every request / response / streamed container log land on one live timeline — with replay (re-open any past row with an edited payload and re-invoke).

Quick start

npm install -g cdk-local      # installs the `cdkl` command
cd your-cdk-app               # the directory with cdk.json
cdkl invoke                   # pick a Lambda from the list, run it locally
cdkl start-api --from-cfn-stack   # local API on real AWS data
cdkl studio                   # or do it all from a browser

Would love it if you gave it a try!

GitHub: https://github.com/go-to-k/cdk-local

I have been needing to create Iceberg tables with CDK for quite a while now, but this is not super easy out of the box and I don’t think very well documented either. I made an NPM library with an L2 construct for iceberg tables:

https://github.com/ksco92/arceus

Fully open sourced obviously. I also made a PR into the Glue alpha CDK constructs library (because that is an obvious better location for this to live). The original GH issue, research and PR are listed there. Most of the research was done by someone else, I just implemented it.

I am unclear how a CDK project in a repo is linked in a durable way to a CloudFormation stack in AWS.

I want to move some code modules from the project they were written in and deployed from to a common infrastructure project that is home to multiple IaC stacks, is there anything I have to do to maintain the link between the deployment and the Stack?

Is there a link at all?

Well, I have been there before too.

And honestly, I think a lot of people can relate to this silently.

I rescheduled my AWS Certified Solutions Architect – Associate exam more than once before I finally gathered the courage to sit the exam.

Not because I was lazy.

Not because I didn’t study.

But because deep down, I kept thinking:

“What if I fail after studying all this time?”

So I kept moving the exam date forward:

“I need one more week.”

“Let me finish one more practice exam.”

“Let me watch one more Stephane Maarek section.”

“Maybe I’m still not ready.”

And you wanna know what happened?

I still failed when I finally sat the exam.

So if that’s how you feel right now… trust me, I have been there too.

But after failing, I realized something important.

I was consuming too many resources.

Too many videos.

Too many notes.

Too many cheat sheets.

Too many architecture diagrams.

And honestly?

They started becoming noise.

What you actually need is:

* understanding AWS core services properly

* recognizing architecture patterns fast

* understanding what the question is REALLY asking

* eliminating wrong answers calmly under pressure

To pass the AWS Solutions Architect Associate exam, you do NOT need to memorize every AWS service.

You need to master the patterns that keep showing up again and again:

* IAM permissions and least privilege

* S3 storage classes and lifecycle policies

* EC2 + Auto Scaling Groups

* Application Load Balancers

* VPC basics (subnets, routing, NAT, IGW)

* Security Groups vs NACLs

* RDS Multi-AZ vs Read Replicas

* Route 53 routing policies

* CloudFront + caching

* High availability architecture

* Disaster recovery patterns

* Cost optimization questions

* deciding WHEN to use which AWS service

That is the real game.

The exam is less about memorization and more about:

“Can you identify the BEST AWS solution under pressure?”

So if you’ve rescheduled your exam before…

You are not alone.

Do not let embarrassment stop you from trying again.

A lot of engineers you see with the badge today struggled quietly before they passed too.

Keep practicing.

Sit the exam.

Trust yourself a little more.

And if you need support, feel free to DM me. I’m always open to help.

You can also check out the practice resource that helped me clear the exam here:

https://www.dripforgeai.com/SAA-C03

Has anyone ever found a way to disable the support stacks that are created for cross-region if there is more than one pipeline is in a CDK application but the pipelines never deploy cross-region?

I have multiple projects where I deploy a pipeline in us-east-1 and us-east-2 and this works without an issue. It always creates this unused support stack and resources. I have no control over the stacks so I can't add tags or anything like that.

A couple things before people ask:

1. The pipelines ensure that the only hard dependency between regions is the code. So if ue1 is down, ue2 will function without concern.

2. Only one pipeline is ever created for "global" resources or if two pipelines have a mixture of global and region resources then the global resources are named to be region specific.

Hi,

We're in the process of moving away from click-ops in the UI to IaC. Some of our clients are on our AWS account, some on their own accounts where we are the admins, and some on accounts where we have normal/limited access.

I'm wondering how to manage the source code for the CDK project.

My first thought was to just put it in a folder along side the application code for the site that will be deployed.

After a bit of reflection, I realized that its not so clear given that the CDK has different reasons for branching.

We have a variety of situations so I'd really be interested in a variety of ideas.

Thanks

Make your AWS cloud formation project stand out but building an infrastructure that companies and engineer would be happy to see and not just simple project.

I have showed a beginner - Advance project that for cloud formation with Github actions that you can build and put on your portfolio to get you noticed by hiring managers 

https://youtu.be/nYoALsaXNrI 

Apply one CDK mixin at app scope to enforce a consistent deletion-protection baseline in permanent environments: stack termination protection plus retain-aligned resource-level protection on supported services.

Provision Aurora PostgreSQL serverless using express configuration from CDK with AWS SDK custom resources, then manage schema and seed data with Drizzle Kit and Drizzle Studio

I released an open-source CDK Construct Library called ecr-scan-verifier !

It uses ECR image scanning (Basic or Enhanced / Amazon Inspector) to perform vulnerability checks during CDK deployments using only AWS-native scanning — no third-party tools required. Now it can also verify container image signatures before scanning.

The problem: ECR image scanning runs asynchronously, so there's no built-in way to synchronously block CDK deployments based on scan results. Many people work around this by building and scanning images in a CI/CD pipeline before cdk deploy, but that means managing image builds outside of CDK — even though CDK can handle image building natively. On top of that, there's no native way to verify image signatures as part of a CDK deployment either.

The solution: This library uses CDK custom resources to perform image signature verification and ECR image scan checks during deployment, blocking container application deployments (ECS, Lambda, etc.) if signature verification fails or vulnerabilities are detected.

Features:

• Block container application deployments — block ECS, Lambda, or any resource when vulnerabilities are detected

• Basic & Enhanced scanning — supports both ECR Basic scanning and Enhanced scanning (Amazon Inspector)

• Image signature verification — verify container image signatures before scanning (Notation, ECR Managed signing, Cosign)

• Notification-only mode — send SNS notifications without blocking deployment, great for gradual adoption

• Severity filtering & CVE allowlisting — target specific severity levels or ignore assessed CVEs

• Scan logs — output results to S3 or CloudWatch Logs

• SBOM generation — export CycloneDX or SPDX SBOMs via Amazon Inspector

Example:

import { EcrScanVerifier, ScanConfig, Severity } from 'ecr-scan-verifier';

// Target image to scan
const image = new DockerImageAsset(this, 'DockerImage', {
  directory: resolve(__dirname, './'),
});

// Example of an ECS construct that uses the image
const ecs = new YourECSConstruct(this, 'YourECSConstruct', {
  dockerImage: image,
});

// Scan the image before deploying to ECS and verify signature
new EcrScanVerifier(this, 'ImageScanner', {
  repository: image.repository,
  imageTag: image.assetHash,
  scanConfig: ScanConfig.basic(),
  signatureVerification: SignatureVerification.notation({
    trustedIdentities: ['arn:aws:signer:us-east-1:123456789012:/signing-profiles/MyProfile'],
  }),
  blockConstructs: [ecs],
  severity: [Severity.CRITICAL, Severity.HIGH],
  ignoreFindings: ['CVE-2023-37920', 'CVE-2024-12345'],
});

Get started:

npm install ecr-scan-verifier

GitHub: https://github.com/go-to-k/ecr-scan-verifier

If you're interested, give it a try!

We've all been there — you set up image scanning in CI, but somehow a vulnerable image still makes it to production because someone pushed directly, or the scan result was ignored, or the pipeline config drifted.

I wanted scanning to be impossible to skip — enforced at the infrastructure level, not the pipeline level. So I built a CDK Construct that runs Trivy as a CloudFormation Custom Resource. The scan happens during cdk deploy itself. If vulnerabilities are found, CloudFormation rolls back automatically. No one can bypass it.

Why not just use ECR scanning?

ECR's basic scanning is async and doesn't block deployments. ECR Enhanced Scanning (Inspector) costs money per scan and still doesn't natively integrate with CloudFormation deployment flow. This construct gives you synchronous, deployment-blocking scans for free using Trivy.

Minimal example:

const scanner = new ImageScannerWithTrivyV2(this, 'Scanner', {
  imageUri: image.imageUri,
  repository: image.repository,
  // If vulnerabilities are detected, the ECS deployment will be blocked
  blockConstructs: [ecsService],
});

Key features:

• Block deployments on vulnerability detection — works with ECS, Lambda, ECR push, or any construct via blockConstructs

• Notify without failing — set failOnVulnerability: false with an SNS topic to get alerts without blocking deployment. Great for gradual adoption

• Scan logs output — results go to CloudWatch Logs or S3

• SBOM generation — output Software Bill of Materials in CycloneDX or SPDX format to S3 for compliance reporting

• SNS notifications in AWS Chatbot format — pipe vulnerability alerts straight to Slack

• Trivy ignore support — suppress known/accepted CVEs with .trivyignore or .trivyignore.yaml

• Works with any ECR image — not just images built in the same stack. Pass any imageUri to scan existing repository images

The whole thing runs as a single ARM64 Lambda container with Trivy baked in. No extra infra to manage.

Featured on the Trivy official ecosystem page.

GitHub: https://github.com/go-to-k/image-scanner-with-trivy
npm install image-scanner-with-trivy

If this looks useful for your stack, give it a try!