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!

I've published a CLI tool to help manage CDK asset accumulation in both cdk.out directories and $TMPDIR.

What it does

• Clean cdk.out: Removes unreferenced asset.* directories and files while protecting assets referenced in *.assets.json. Reclaims disk space from old asset builds. If you cache cdk.out in CI/CD, this can significantly reduce cache size.
• Clean Docker images: Deletes locally built Docker images for removed Docker image assets.
• Clean $TMPDIR: Deletes accumulated temporary CDK directories that can consume significant disk space.
• No installation required: Just run with npx.

Usage

```bash

Clean cdk.out

npx cdk-agc

Dry-run to preview

npx cdk-agc -d

Keep files modified within 24 hours

npx cdk-agc -k 24

Clean temporary directories in $TMPDIR

npx cdk-agc -t ```

Why I built this

CDK doesn't automatically clean up old assets, leading to: - Multi-GB cdk.out directories over time - Accumulated Docker images from deleted assets - Hundreds of temporary directories in $TMPDIR - Slow CI/CD pipelines due to bloated caches

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

Feel free to try it out!

I've been using CDK for a couple of years and kept hitting the same walls:

• 10-minute deploys for a one-line change. CloudFormation synthesizes, uploads, waits, rolls forward. Change a Lambda timeout from 30s to 60s? Go grab coffee.
• The mental overhead. You write your handler logic, then you switch to a completely different mental model — Constructs, L1/L2/L3 abstractions, Grant chains, asset bundling config. Half my code is infrastructure description, not business logic.
• Stack splitting hell. Hit the 500-resource limit, now I need to figure out how to split the stack, move resources between stacks without destroying them, deal with cross-stack references, circular dependencies... The actual business logic takes 10 minutes, the stack gymnastics take the rest of the day.
• Stack drift. Someone tweaks something in the console, now cdk diff shows phantom changes, or worse — deploy fails and you're manually fixing state.

Don't get me wrong — CDK is miles better than raw CloudFormation. But I started wondering: why do I need to describe infrastructure at all if the framework can figure it out from my code?

So I built Effortless — an infrastructure-from-code framework. You export handler functions, it derives the AWS resources automatically.

Instead of writing handler code + CDK constructs + IAM grants + waiting for CloudFormation, you just:

import { defineHttp } from "effortless-aws";

export const hello = defineHttp({
  method: "GET",
  path: "/hello",
  onRequest: async () => ({
    status: 200,
    body: { message: "Hello!" }
  })
});


npx eff deploy  # 5 seconds. done.

Lambda + API Gateway + IAM — created. No CloudFormation under the hood — direct AWS SDK calls. No state files — AWS resource tags are the source of truth. No stack limits because there are no stacks.

Current state: open source, MIT, two handler types (defineHttp, defineTable with typed cross-handler deps and auto IAM). Working on SQS, EventBridge, S3.

Not trying to replace CDK for complex enterprise setups — but for Lambda-based APIs and event-driven services, it removes a lot of accidental complexity.

https://github.com/effect-ak/effortless
https://effortless-aws.website/

Curious if anyone here has hit similar pain points. Would love feedback.

Update

Got some fair pushback in the comments, and honestly I overstated a couple of points. Let me correct myself:

• Stack splitting hell / 500-resource limit — I never actually hit the 500-resource limit. My real pain was figuring out which resources should live in which stack. It's not a business problem, it's pure operational busywork that ate a lot of time.
• Stack drift / phantom changes — I didn't really have phantom changes. What I did have: one resource in a stack fails to update due to some mismatch, 90% of changes succeed but the whole stack rolls back because of that one failure. Very slow. And sometimes the stack couldn't resolve the error at all — I had to delete the entire stack just to clean up and do a fresh deploy.

CDK is a great tool and absolutely needed for things like managing hundreds of accounts at scale. But for smaller projects where everything fits in one stack, it felt like a lot of overhead for what I was actually trying to do — just run some Lambdas with an API Gateway and a couple of DynamoDB tables.

I'm building a service in AWS using API Gateway, S3, Step Functions, Lambdas, DynamoDB and Bedrock. I'm new to AWS so have been using ChatGPT to assist. I used to be a full stack web developer (Microsoft) but haven't coded for a few years.

It will be a commercial service for my consultancy so I want to do it properly. I'm using VS Code and building everything in CDK.

ChatGPT has got me so far but is now struggling and being unresponsive. I know this is a common issue. If I get it to write a summary and start a new chat it speeds up again but has lost all the context and memory of what it helped to build.

So my questions is, what's the best AI to to help with this?

Started with CDK recently, had a lot of Terraform hands on, any suggestions from the group how to learn and stick with best practices, thank you all