Native validation and CDK Insights
Use native CDK validation to check template correctness, CDK Insights to review security, cost and operational findings, and AWS deployment validation to check account readiness. Both CDK and CDK Insights can map findings back to constructs.
Choose the check for the question
| Check | What it answers | AWS access |
|---|---|---|
| Native CDK template validation | Does this template satisfy structural and service-specific constraints? | Local validation; your app may still need credentials for lookups. |
| CDK Insights static analysis | Which security, cost or operational configurations deserve attention? | No credentials for existing synthesized templates. |
| CloudFormation deployment validation | Is this deployment ready for the target account, including quotas and resource conflicts? | Requires access to the target account. |
A reproducible example
With CDK 2.271.0 and CDK Insights rules 0.6.0, a shared fixture produces these results:
- Native validation flags a GameLift fleet whose desired capacity exceeds its maximum:
CDK-GameLift-003. - CDK Insights, scoped to ECS, flags a task using
nginx:latestwithout container logging:ecs-task-definition-mutable-image-tagandecs-logging-disabled. - Running both reports both sets of findings against their constructs.
This small fixture demonstrates complementary findings. It does not measure total coverage or prove either tool catches every problem.
Run the fixture and inspect its resultsDecide what should block
Native default rules warn unless @aws-cdk/core:validateAgainstDefaultRules is enabled. The CDK Insights synth plugin blocks on findings at or above its configured minimumSeverity.
For PR adoption, start the GitHub Action with fail-on: never, review the reports, then choose an explicit gate such as critical,high. Leave fail-on-class unset in advisory mode. CLI failures and separately enabled deployment, policy, reliability and live checks retain their failure behavior.
Keep exceptions scoped
Use CDK 2.271.0 or later for synth-time inline acknowledgements. Ordinary CLI scans keep their existing compatibility. Older CDK versions can apply an acknowledgement in one stack to the same rule in unrelated stacks. The synth plugin rejects inline acknowledgements on affected versions. Acknowledge the intended resource and include a reason:
Validations.of(developmentService).acknowledge({
id: 'cdk-insights::ecs-service-connect-access-logs-missing',
reason: 'Development-only service; production keeps access logs',
});Project-wide ignoreRules entries also accept { id, reason }. Use those only when the exception applies throughout the project. Verify that an unsuppressed finding elsewhere still appears and blocks when enforcement is enabled.