If you deploy on Cloudflare or Vercel, every pull request gets its own URL and you stop thinking about it. One of the platforms I've worked on was different. Lambdas, HTTP APIs, and managed databases defined in CDK. The default workflow was one shared staging environment, and a team that serialized behind it. Testing a change against real managed services meant queueing for staging or waiting out a several-minute full deploy per iteration.
First, prove the gap is real
Before building anything I surveyed what AWS actually offers, because "AWS must have this" is a reasonable prior. AWS has product-specific deployment options, but not a turnkey Workers- or Vercel-style preview URL for this CDK-managed Lambda/API/RDS shape: CodeCatalyst closed to new customer spaces on November 7, 2025; App Runner stopped accepting new customers on April 30, 2026 and points new container users to ECS Express Mode; Amplify's preview branches assume an Amplify-shaped app and would have meant a rewrite. That survey went into the proposal deck, because a design review that starts with the actual platform gap goes very differently from one that starts with a claim about AWS as a whole.
The design: ephemeral stateless, imported state
The insight that makes previews cheap is that a preview environment doesn't need its own database. It needs its own code. Each pull request gets a CDK stack that provisions only the stateless layer: the functions, the HTTP APIs, custom domains, and a client alias. The stateful layer (SQL, key-value, queues) is imported from a shared environment by reference, never duplicated and never at risk of recreation.
an explicit iam deny protects live stacks from the reaper.
Two mundane details did most of the work. Hostnames: previews live at single-label names under a preview subdomain, which fit under the existing wildcard certificate. Zero certificate changes, zero core-stack changes. Cleanup: a reaper workflow tears previews down after seven days, with an active cap on concurrent previews. Its IAM role carries an explicit Deny against the long-lived stacks, so the reaper is mechanically incapable of eating production.
The inner loop got the same treatment
Preview stacks solve review. They do not solve the edit-compile-test loop. Two companions do. Per-branch service environments deploy with CDK hotswap, which updates functions and containers in place. Iteration collapses from full-CloudFormation minutes to under a minute, an order of magnitude on deploy time. And local development runs with deliberate no-emulation: laptops run only the code under edit against real shared databases (through an SSM tunnel via an IAM-only relay host), real key-value and queue services, and the real identity provider. We chose not to run LocalStack-style emulation on purpose. Local behavior that cannot drift from managed-service reality is worth more than offline development. The in-memory store stays local for one specific reason: rate-limit tests from one developer must not throttle another's review.
What it cost
Idle previews cost close to nothing. Functions and HTTP APIs bill per request, and the expensive stateful layer is shared by reference. Those figures came from the proposal analysis. The design was presented to the team before it was built, then shipped. The pattern generalizes to any serverless-ish platform: split your stacks along the stateful and stateless line, and previews stop being an infrastructure project and become a naming scheme.
Provenance of numbers:Ppresented (architecture-review figures)Iimplemented