--- title: "SST vs CDK" slug: "sst-vs-cdk" category: "comparisons" tags: ["comparisons", "sst", "cdk", "aws", "iac", "serverless"] status: "stable" last_updated: 2026-05-14 summary: "Pick SST for app-aware AWS deployments where the dev loop matters; pick CDK for raw cloud control, multi-account governance, or constructs beyond app shapes." related: ["[[ops/vercel]]", "[[ops/cloudflare-workers]]", "[[comparisons/vercel-vs-cloudflare]]", "[[file-organization/project-structure]]", "[[file-organization/monorepo]]", "[[backend/fastapi]]", "[[ops/index]]"] --- ## 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 deploy` for every change; round-trip is 30 to 120 seconds. - Typed bindings: SST's `Resource` object 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.ts` declares 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 [[ops/cloudflare-workers]] for a Cloudflare-first alternative. ## Recommendation - New product on AWS, single team, fast iteration: SST. See [[ops/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 [[comparisons/vercel-vs-cloudflare]]. ## Related - [[ops/vercel]] - [[ops/cloudflare-workers]] - [[comparisons/vercel-vs-cloudflare]] - [[file-organization/project-structure]] - [[file-organization/monorepo]] - [[ops/index]]