Overview
Pick SST for an application team that wants infrastructure defined beside the app with a live development loop; pick CDK when a platform team provisions AWS accounts, networking, and shared services through CloudFormation. SST is no longer built on CDK: it deploys through Pulumi (bridging Terraform providers), defines everything in one sst.config.ts, and has built-in AWS and Cloudflare components plus access to 150+ providers. CDK defines infrastructure in TypeScript, JavaScript, Python, Java, C#, or Go and deploys through CloudFormation. The SST line is at 4.x on npm.
Comparison
| Dimension | SST | AWS CDK v2 |
|---|---|---|
| Engine | Pulumi with Terraform providers | CloudFormation |
| Clouds | AWS and Cloudflare components; 150+ other providers (Vercel, Stripe, and more) | AWS only |
| Config | One sst.config.ts | Apps, stacks, and constructs across files |
| Dev loop | sst dev runs functions live without redeploying, creates VPC tunnels, and starts frontend and container services | cdk deploy; faster iteration through cdk watch and hot-swap deployments |
| Resource access | Resource linking with typed SDK access instead of hardcoded names | Pass ARNs, names, and environment variables yourself |
| Construct coverage | App-shaped components plus provider resources | Complete L1, L2, and L3 constructs for AWS services |
| Governance | Single-app focus | Fits organization-wide patterns, shared construct libraries, and policy checks |
| Console | Optional SST Console (SaaS, free tier) | AWS Console and CloudFormation |
| License | Open source | Open source (Apache 2.0) |
Pick SST when
Pick SST when shipping the app is the job.
- Frontends (Next.js, SvelteKit, Astro) and backends declared together with linked resources.
- You want live function development against real cloud resources.
- The stack spans AWS and Cloudflare or another provider.
- Know the trade-off: SST deploys through Pulumi, not CloudFormation, so CloudFormation drift detection, stack policies, and tooling built on stacks do not apply.
Pick CDK when
Pick CDK when AWS is the platform.
- Multi-account landing zones, networking, IAM baselines, and shared constructs published to internal teams.
- Native CloudFormation features: drift detection, stack policies, change sets, and rollbacks, plus linting such as
cdk-nag. - Services that SST components do not model and that you want first-class constructs for.
- A large organization already standardized on CloudFormation and CDK pipelines.
Combine or migrate
A common split: a CDK platform layer owns accounts, networking, and security baselines, and application teams use SST for app stacks. SST and CDK do not share state, so pass shared values (VPC IDs, bucket names) through parameters or SSM. For multi-cloud beyond SST’s providers, compare Pulumi or Terraform directly. For an edge-first alternative, see vercel-vs-cloudflare and cloudflare-workers.
FAQ
Is SST still built on AWS CDK?
No; SST deploys through Pulumi (bridging Terraform providers) and defines everything in one sst.config.ts. CDK deploys through CloudFormation.
Should I use SST or CDK for a new app?
Use SST when an application team wants infrastructure beside the app with the sst dev live loop, or the stack spans AWS and Cloudflare. Use CDK when a platform team provisions AWS accounts, networking, and shared services.
Does SST support CloudFormation drift detection?
No; because SST deploys through Pulumi, CloudFormation drift detection, stack policies, and stack-based tooling do not apply. Pick CDK when you need change sets, rollbacks, and linting such as cdk-nag.
Can I use SST and CDK together?
Yes; a common split is a CDK platform layer for accounts, networking, and security baselines, with application teams using SST for app stacks. They do not share state, so pass VPC IDs and bucket names through parameters or SSM.