CDK Synth Playground

Does your stack do what you meant?

Paste any CDK — hand-written, generated, or inherited. It runs through a real synth, every cdk-nag rule, and intent checks that compare the stack against what it was supposed to do. Nothing is deployed, no credentials, no account.

Your stack
Ready when you are

Press Run. The stack loaded here fails in a way worth seeing.

Presets

Or start from a stack that fails interestingly

Public S3 bucket

The single most common AI-generated CDK mistake: a bucket left open to the world.

3 rules · 2 intent checks
From Concepts · S3 · Granting public read access
Security group open to 0.0.0.0/0

SSH open to the entire internet — the classic copy-paste ingress rule.

2 rules · 1 intent check
From Concepts · EC2 · Opening the security group for HTTP
S3 static website

Website hosting straight off a bucket — no CDN, no TLS, no access logging.

3 rules · 2 intent checks
Unencrypted RDS instance

A database with storage encryption off and backups barely configured.

6 rules · 2 intent checks
Wildcard IAM policy

Action "*" on Resource "*" — the permission grant that ends incident reviews.

1 rule · 2 intent checks
Public API Gateway with no authorizer

A REST API wired to Lambda, wide open, with no access logging.

7 rules · 1 intent check
DynamoDB table without point-in-time recovery

Fast to write, impossible to restore — no PITR, no encryption choice.

1 rule · 1 intent check
CloudFront distribution allowing HTTP

A CDN that will happily serve your site unencrypted, with no logging.

6 rules · 1 intent check
Unencrypted SQS queue

A queue with no server-side encryption and no dead-letter queue.

2 rules · 2 intent checks
VPC without flow logs

Network traffic no one can reconstruct after the fact.

1 rule · 1 intent check
Cognito pool with a weak password policy

Six characters, no symbols, no MFA — defaults nobody revisited.

3 rules · 2 intent checks
Clean serverless data layerPasses

The one that passes. Encrypted, recoverable, with a dead-letter queue — what good looks like.

no findings — this is what passing looks like

What actually runs

01
Synth

Your TypeScript is compiled and synthesized in an isolated sandbox with no network and no permissions. If it can't produce a CloudFormation template, you find out here.

02
cdk-nag

Every AwsSolutions rule runs against the synthesized template — the same ruleset teams use in CI, not a subset chosen to look impressive.

03
Intent

Checks declared in cloudsynth.intent.yml — the same file cloudsynth verify reads in CI — compare the stack against what it was supposed to do. A VPC with no flow logs synthesizes perfectly and passes every linter; only stated intent catches it.

Why the third stage is the point

Infrastructure code is usually syntactically fine — whoever, or whatever, wrote it. It compiles, it synthesizes, and most linters pass it. What it gets wrong is subtler: a bucket that is public when it should not be, a role with a wildcard nobody enumerated, a database with no way back from a bad write. Those are not syntax errors. They are the stack quietly not being what you asked for.

See the full engine grade a real project

The playground runs the same engine that grades CloudSynth’s projects — there, it checks your work against a brief, checkpoint by checkpoint.

Browse projects — the first checkpoint is free →