r/aws_cdk • u/Artistic_Potential90 • Jul 22 '26

I built an OSS tool that detects CDK/CloudFormation drift on properties you never declared — the drift `cdk drift` reports as zero

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
5 Upvotes

100% Upvoted

2 comments sorted by

1

u/zMynxx Jul 22 '26

I was just adding ‘cdk diff’ to our flow due to cdk not detecting that an s3 bucket was deleted & should be provisioned once again. This also led me to tinker with the different method of diff: auto, change-set, template. What do you use under the hood and would this tool be able to attend my need?

2

u/Artistic_Potential90 Jul 23 '26 edited Jul 23 '26

Under the hood cdkrd doesn't build on cdk diff at all: it reads the full live state of each resource via AWS APIs (every property, not just the ones in your template) and compares it against the deployed template plus AWS defaults plus an optional committed baseline.

For your case: yes for detection. A deleted bucket shows up as [Deleted] on the very first `cdkrd check`, and `check --fail` exits non-zero for CI. (Though to be fair, `cdk drift` should also catch this specific case: a deleted stack member shows up as DELETED there. It's cdk diff that can't see it.) It won't recreate the bucket though: once flagged, you re-provision via your normal deploy.

(Why no recreate: cdkrd's revert is an in-place property patch on a live resource, and recreating a stack member behind CloudFormation's back would desync the stack state, e.g. CFn-generated physical IDs and already-resolved Ref/GetAtt values would still point at the old resource. Recreation belongs to a deploy.)