CDK Static Analysisbuilt around the construct tree
Static analysis for AWS CDK that does not stop at synthesised CloudFormation. CDK Insights walks the construct tree alongside the template, then reports 104 rules across 35 AWS services with attribution back to the file and line in your CDK source.
Run it now
npx cdk-insights scanOne command. No account, no license key, no configuration. Run it from any AWS CDK project root and the static analysis pack runs locally — your code never leaves the machine.
Four pillars of CDK static analysis
The 104-rule pack is organised by AWS Well-Architected pillar so the fail-on gate can be tuned to what your team actually wants to block on.
Security
IAM wildcards, public S3 buckets, unencrypted data stores, open security groups, missing TLS enforcement. The pillar most static analysers cover, with the highest signal-to-noise ratio in this rule pack.
- IAM policies with wildcard actions or resources
- S3 bucket policies that lock the account out of the bucket
- RDS instances reachable from the public internet
- Lambda permissions granting public invoke
Cost optimisation
The static rules that surface obvious money leaks before deploy. Less interpretive than security, but easier to action — most of these have a one-line fix.
- Lambda functions over-provisioned on memory
- S3 buckets without lifecycle or Intelligent-Tiering
- NAT Gateway usage flagged for VPC architectures that could use endpoints
- EBS volumes oversized for their instance class
Reliability
Findings that catch the day you wish you had backups. Backup retention, multi-AZ, point-in-time recovery, dead-letter queues — the operational hygiene that does not earn praise but earns trust.
- DynamoDB tables without point-in-time recovery
- RDS instances missing Multi-AZ and short backup retention
- Lambda functions without dead-letter queues
- CloudFront distributions without WAF associations
Best practices
Operational and structural patterns that matter at scale: CloudWatch alarms wired up, VPC flow logs enabled, CloudTrail configured, encryption everywhere by default.
- CloudWatch log retention configured
- VPC flow logs enabled on production VPCs
- CloudTrail multi-region trails enabled
- Cognito user pools with MFA enabled
Why CDK-native static analysis matters
Generic IaC scanners read raw CloudFormation. That works, but CloudFormation has lost most of the structure that made the original CDK code legible — construct hierarchies, L2/L3 abstractions, source locations. CDK Insights keeps that structure and uses it.
Findings map to your CDK code, not just CloudFormation
The CDK Insights aspect captures construct paths and source locations during synth. Every finding has a `lib/my-stack.ts:42` style attribution, not just a logical resource ID.
L2 / L3 construct awareness
Static rules know the difference between a raw `CfnBucket`, an `s3.Bucket`, and a bucket created by an `@aws-solutions-constructs` pattern. Findings on L3-pattern resources get downgraded automatically because you cannot fix them at the CFN level.
Captures CDK Nag findings non-blocking
If you already use cdk-nag, its findings flow into the same report. By default they do not block your deploy — you decide what to fail on, per WAF pillar, per severity.
Construct-tree suppressions
The `.cdk-insights.json` `ignorePaths` works on construct paths, and `Validations.of(scope).acknowledge(...)` is supported as a CDK-first suppression API. No magic comments, no inline JSON.
How a scan flows
From `cdk synth` to a parseable report — what happens when you run the static analysis pack.
cdk synth
CDK Insights synthesises your CDK app the way the AWS CDK CLI does, capturing the construct tree alongside the generated CloudFormation.
104 rules run
Each rule reads either the synthesised template, the construct tree, or both. Rules are scoped to specific AWS services and well-defined patterns — there is no fuzzy matching.
Findings carry source locations
When `@aws-cdk/core:stackTrace` context is enabled (the `cdk-insights setup` command writes it), each finding includes the file, line, and column in your CDK source.
Output the way you want it
Table for terminals. JSON or SARIF for CI. Markdown for issue bodies. GitHub Actions workflow commands for inline annotations on PRs.
Try CDK static analysis right now
One command, no signup. The 104-rule pack is free forever via npm.