Overview
Pick SST when you are shipping an application on AWS and the dev loop is the thing you optimize for: live Lambda reload, typed bindings between resources, a console that mirrors prod. Pick CDK when you need raw cloud control: multi-account landing zones, custom constructs for security and compliance, or infrastructure that has nothing to do with an app. The 2026 split: SST owns “AWS as a product backend”; CDK owns “AWS as a cloud platform.” Many teams run both: SST for product services, CDK for shared platform constructs.
When SST wins
SST is the right pick when the team’s job is shipping an app, not running a cloud.
- Live Lambda: edit a handler, save, and the next request runs the new code without a redeploy. CDK requires
cdk deployfor every change; round-trip is 30 to 120 seconds. - Typed bindings: SST’s
Resourceobject exposes typed handles to S3 buckets, queues, and tables. CDK gives you ARNs and string names; you wire them up. - App-aware defaults: Next.js, SvelteKit, Astro, and Remix all have first-class SST components that wire up CloudFront, Lambda, and the right cache headers without ceremony.
- Console: a Cloudflare-style web UI for tailing logs, invoking functions, and inspecting resources. CDK has no equivalent; you use the AWS console.
- One config file:
sst.config.tsdeclares stacks, components, and stages. CDK’s app, stack, and construct layering is more verbose for the same outcome. - LLM agents pattern-match SST well: the components are declarative and uniformly typed.
When CDK wins
CDK is the right pick when AWS is a platform, not just a deploy target.
- Construct library: every AWS service has a typed L1, L2, and often L3 construct. SST covers app-shaped services well and leaves the long tail to CDK escape hatches.
- Multi-account, multi-region governance: AWS Control Tower, Organizations, SCPs, and landing zones are all CDK-shaped. SST is single-app-focused.
- Security and compliance: CDK pairs with cdk-nag, cfn-guard, and CloudFormation drift detection. SST inherits this through CDK escape hatches but the ergonomics are worse.
- Custom constructs: a shared internal library of “the way we do RDS at this company” is a CDK construct package. SST does not replace that.
- Non-app workloads: data pipelines, security automations, ETL jobs, and IAM bootstrapping. SST does not target these.
- Multi-cloud or hybrid: CDK has a Terraform output mode (CDKTF). SST is AWS-only.
Trade-offs at a glance
| Dimension | SST | CDK |
|---|---|---|
| Mental model | Application framework on AWS | Cloud library in TypeScript |
| Live reload | Yes (Live Lambda) | No |
| App-shape components | Next.js, SvelteKit, Astro, API | Build yourself from L2 constructs |
| Typed resource bindings | Native | Manual (ARNs, env vars) |
| Multi-account governance | Limited | First-class |
| Construct breadth | App-focused | Every AWS service |
| Console | Yes; web UI | None; AWS console only |
| Dev-loop speed | Seconds | 30 to 120 seconds |
| Stage management | Built-in (sst deploy --stage) | Manual via context or parameters |
| Lock-in | AWS | AWS (CDKTF supports more) |
| Learning curve | One day for a basic app | One week for a basic stack |
| LLM agent output | Strong; small surface | Strong; verbose but consistent |
Migration cost
SST builds on CDK; the escape hatch is always there. The interesting move is direction-by-direction.
- CDK to SST: only for app-shaped CDK stacks. Plan one engineer-week per major service to port. Platform constructs do not move; keep them in CDK.
- SST to CDK: rare. Triggered when a team outgrows SST’s abstractions and needs raw control over every resource. Plan two to four engineer-weeks per service; you write the typed bindings yourself.
- Coexistence: SST stacks can consume CDK constructs directly via
sst.aws.cdk(). Most teams run a CDK platform layer (networking, IAM, baseline security) plus SST per app. This is the durable split. - Cross-cloud: if AWS lock-in is a concern, look at Pulumi or Terraform before either. See cloudflare-workers for a Cloudflare-first alternative.
Recommendation
- New product on AWS, single team, fast iteration: SST. See vercel for a non-AWS alternative.
- Platform team owning networking, IAM, and shared services: CDK with a typed construct library.
- App team in a larger org that has a CDK platform: SST on top of the platform constructs.
- Single-developer side project on AWS: SST; the live reload alone pays for itself.
- Multi-cloud bet: neither; pick Pulumi or Terraform.
- Edge-first workload: skip both; ship to Cloudflare. See vercel-vs-cloudflare.