Serverless Development Patterns

Your image-processing Lambda fires twice on the same S3 upload, so half your thumbnails get written, deleted, and re-written — and CloudWatch is a wall of unstructured console.log you can’t correlate to a request. Meanwhile p99 latency spikes to 4 seconds every morning because of cold starts, and the “fix” someone shipped (provisioned concurrency on every function) doubled the bill. Serverless removes the servers, not the distributed-systems problems: retries, idempotency, cold starts, and per-platform limits are now your code.

This recipe shows how to drive Cursor, Claude Code, and Codex to generate serverless code that survives those problems — not the happy-path demo that breaks the first time SQS redelivers a message.

What You’ll Walk Away With

• A copy-paste prompt that produces an idempotent AWS Lambda handler (dedupe on retries) with structured CloudWatch logging
• A Cloudflare Worker API-gateway pattern with a real wrangler.toml, plus how the Cloudflare MCP server inspects KV/R2/D1 without leaving your editor
• A cold-start triage workflow that tells you when provisioned concurrency is actually worth the money
• The three-tool split: when to use Cursor’s agent, Claude Code’s headless runs, and Codex Cloud for deploy PRs
• The failure modes that bite in production — duplicate SQS deliveries, DynamoDB hot partitions, Workers CPU limits — and the prompts that pre-empt them

The Workflow

Step 1: Scaffold the service (where the three tools differ)

The scaffolding step is where tool ergonomics diverge most. Cursor edits files visually in your repo; Claude Code runs the framework CLI from the terminal and is scriptable in CI; Codex can fan the same task out to a cloud worktree and open a deploy PR. Pick by where the work lives, not by capability — all three drive the same AWS SAM / Serverless Framework / Wrangler CLIs.

Cursor

Open Agent mode (Cmd/Ctrl + I) in an empty repo and give it a concrete, single service to build:

Set up a Serverless Framework v4 service in TypeScript targeting AWS eu-central-1. One HTTP Lambda behind API Gateway (GET /health), one S3-triggered Lambda for image processing, and a DynamoDB table media (PK id). Use esbuild bundling, Node 22 runtime, and put stage/region in serverless.yml provider vars. Add a dev and prod stage.

The agent writes serverless.yml, the handler stubs, and package.json. Review the diff in the sidebar before accepting — Cursor checkpoints each edit so you can roll back a bad file without losing the rest.

Claude Code

Claude Code runs the framework CLI for you and is the right choice when you want the scaffold reproducible in a script or CI step. Give it the same concrete spec as a positional prompt:

claude "Set up a Serverless Framework v4 service in TypeScript targeting AWS eu-central-1: one HTTP Lambda behind API Gateway (GET /health), one S3-triggered image-processing Lambda, and a DynamoDB table 'media' (PK id). Use esbuild bundling, Node 22 runtime, and stage/region provider vars in serverless.yml."

The agent edits the files and runs npx serverless itself; it does not pop a provider-selection wizard — you state the provider in the prompt. Add --permission-mode acceptEdits once you trust the plan so it stops asking before each write.

Codex

Codex spans CLI, IDE, and Cloud. For a one-off local scaffold, run it non-interactively and let it edit the workspace:

codex exec --full-auto "Scaffold a Serverless Framework v4 TypeScript service for AWS eu-central-1 with an HTTP /health Lambda, an S3-triggered image Lambda, a DynamoDB 'media' table, esbuild, Node 22, and stage/region provider vars."

--full-auto sets --ask-for-approval on-request and --sandbox workspace-write, so Codex can write files but still pauses before anything risky. When you want the scaffold and a reviewable PR, push it to a cloud worktree with codex cloud exec "<same prompt>, then open a PR" — Codex runs in an isolated environment and hands back a branch.

Note

The model matters here. For multi-file scaffolds, from-scratch service builds, and the cold-start refactor below, Claude Fable 5 (claude-fable-5, or /model fable in Claude Code) delivers the best results — it outperforms Opus 4.8 on complex multi-file work. Use it when velocity and quality matter more than cost. When budget is a constraint, use Fable 5 for planning and final verification, then drop to Claude Opus 4.8 or Sonnet 4.6 for the implementation grind. See model comparison for current pricing. Codex runs on GPT-5.5 across every surface; use gpt-5.2-codex only when you’re authenticating Codex with an API key instead of a ChatGPT plan.

Step 2: Make the handler idempotent (the part demos skip)

S3, SQS, and EventBridge all deliver at least once. A naive handler reprocesses the same object on a retry. The fix is a dedupe key — for S3, the object’s eTag — checked against a conditional write before doing the work. This is the single most valuable thing to put in your prompt, so make it explicit:

Tip

Copy-paste prompt — idempotent S3 → Lambda image processor:

Write an AWS Lambda handler in TypeScript (Node 22) for an S3 ObjectCreated trigger that resizes the uploaded image to 256/512/1024px WebP with sharp and writes them to a derived/ prefix in a destination bucket. Make it idempotent across S3 retries: before processing, do a DynamoDB PutItem with ConditionExpression: 'attribute_not_exists(pk)' on pk = <bucket>/<key>#<eTag>, and skip (return early) if the condition fails. Emit one structured JSON log line per invocation with requestId, bucket, key, eTag, and durationMs. Wrap the work in try/catch, log the error with the same requestId, and rethrow so the event lands in the configured DLQ. Then give me the matching serverless.yml function block with memorySize: 1024, timeout: 30, an onError DLQ, and the s3 event.

That prompt produces something close to this — note the early return on a duplicate and the structured log, which is what makes it debuggable in production:

// handler.ts — the AI-generated shape worth reviewing for
import { S3Event } from 'aws-lambda';
import { DynamoDBClient, PutItemCommand } from '@aws-sdk/client-dynamodb';

const ddb = new DynamoDBClient({});

export const handler = async (event: S3Event) => {
  const start = Date.now();
  for (const rec of event.Records) {
    const { bucket, object } = rec.s3;
    const pk = `${bucket.name}/${object.key}#${object.eTag}`;
    const log = { requestId: rec.responseElements['x-amz-request-id'], bucket: bucket.name, key: object.key, eTag: object.eTag };
    try {
      await ddb.send(new PutItemCommand({
        TableName: process.env.DEDUPE_TABLE!,
        Item: { pk: { S: pk } },
        ConditionExpression: 'attribute_not_exists(pk)',
      }));
    } catch (err: any) {
      if (err.name === 'ConditionalCheckFailedException') {
        console.log(JSON.stringify({ ...log, status: 'duplicate-skipped' }));
        continue; // already processed — S3 redelivery
      }
      throw err;
    }
    // ... resize with sharp, write derived/ objects ...
    console.log(JSON.stringify({ ...log, status: 'ok', durationMs: Date.now() - start }));
  }
};

The thing to verify in the AI’s output: that the dedupe write happens before the side effects, and that the catch block rethrows (so the DLQ actually catches failures) instead of swallowing the error.

Step 3: The Cloudflare Worker API gateway

On Workers the constraints are different — no Node runtime, a CPU-time budget per request, and bindings instead of SDK clients. Ask for the gateway and the config together so the wrangler.toml bindings match the code:

Tip

Copy-paste prompt — Cloudflare Worker API gateway:

Write a Cloudflare Worker (TypeScript, ES modules) that acts as an API gateway: route GET /v1/* to an origin via fetch, enforce a bearer-token check against a TOKENS KV namespace, rate-limit per token to 100 req/min using a Durable Object counter, and cache successful GETs in the Cache API for 60s. Read the origin URL from an ORIGIN var. Return structured JSON errors { error, requestId } with the right status codes, and keep synchronous CPU work minimal — the Free plan caps CPU at 10ms per request — so defer non-blocking work with waitUntil where possible. Then give me the wrangler.toml with the KV namespace binding, the Durable Object binding + migration, and the ORIGIN var.

# wrangler.toml — the AI should produce bindings that match the Worker
name = "api-gateway"
main = "src/index.ts"
compatibility_date = "2026-06-01"

[vars]
ORIGIN = "https://origin.internal.example.com"

[[kv_namespaces]]
binding = "TOKENS"
id = "<your-kv-id>"

[[durable_objects.bindings]]
name = "RATE_LIMITER"
class_name = "RateLimiter"

[[migrations]]
tag = "v1"
new_sqlite_classes = ["RateLimiter"]

Step 4: Inspect live infra with the Cloudflare MCP server

Generating the Worker is half the job; the bugs live in the binding values — a mistyped KV namespace id, a stale D1 row. Without MCP, you alt-tab between the dashboard and your editor. With Cloudflare’s managed remote MCP servers, the AI reads your real account state and the docs in the same conversation. Setup is identical across all three tools — point them at the remote endpoints (full server catalog and OAuth flow in the Cloudflare MCP guide):

{
  "mcpServers": {
    "cloudflare-bindings": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://bindings.mcp.cloudflare.com/mcp"]
    },
    "cloudflare-observability": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://observability.mcp.cloudflare.com/mcp"]
    }
  }
}

Before MCP, debugging the stale-cache bug meant copying namespace ids between four browser tabs. After: “Read the TOKENS KV namespace bound to the api-gateway Worker and list the keys written in the last hour” and the AI answers from your live account. For deploys and binding edits from the CLI, the lighter-weight alternative is the Cloudflare wrangler skill — install it with npx skills add cloudflare/skills/wrangler (from the cloudflare/skills repo, listed on skills.sh). A skill is the better fit when you just want the agent to know wrangler commands and conventions; the MCP server wins when you need it to read live state.

Copy-Paste Prompts

Tip

Cold-start triage — before you pay for provisioned concurrency:

My Lambda image-processor (Node 22, 1024MB, in a VPC) has p99 latency of 4s in the morning and ~300ms otherwise. Analyze the cold-start cost: check whether the VPC ENI attachment, the bundle size, or SDK client init at module scope is the dominant cost. Show me the init vs invocation split I’d see in a CloudWatch REPORT line. Then propose the cheapest fix first (lazy-init SDK clients, drop unused deps, esbuild tree-shaking, remove the VPC if it’s only there for DynamoDB) and only recommend provisioned concurrency with a concrete number if the others don’t get p99 under 1s.

Tip

Event-driven fan-out with a DLQ and replay:

Design an SQS → Lambda consumer (TypeScript) that processes order events with batchSize: 10 and functionResponseType: ReportBatchItemFailures so one poison message doesn’t fail the whole batch. Validate each message against a zod schema, send invalid ones to a DLQ, and make the handler idempotent on orderId via a DynamoDB conditional write. Give me the serverless.yml for the queue, the DLQ with maxReceiveCount: 3, and a small replay.ts script that re-drives the DLQ back to the main queue.

Tip

Vercel Function with streaming and A/B routing:

Write a Vercel Function that does geographic A/B routing: read the visitor country with geolocation(request) from @vercel/functions (standalone Edge Functions and request.geo are deprecated), assign a stable variant by hashing a cookie (set one if absent), and stream the chosen origin’s HTML response straight through with TransformStream. Return a Set-Cookie for the variant on first visit. Keep it Web-Streams based so it runs on either the Node.js or Edge runtime.

When This Breaks

Caution

Duplicate processing on retries. This is the number-one serverless bug and AI happy-path output almost never handles it. S3, SQS, and EventBridge are at-least-once. If your handler has side effects (writes, emails, charges), it must dedupe on a stable key (S3 eTag, SQS messageId, your own orderId) before acting. Re-prompt: “This handler isn’t idempotent — add a DynamoDB conditional-write dedupe on <key> and return early on a duplicate.”

Caution

DynamoDB hot partitions. A single-table design with a low-cardinality partition key (e.g. status#PENDING) funnels all traffic to one partition and you get ProvisionedThroughputExceededException under load despite low average utilization. Ask the AI to “check the partition-key cardinality and suggest a write-sharding suffix or a GSI” rather than just bumping capacity.

Caution

Cloudflare Workers CPU limits, not wall-clock. Workers cap CPU time (10ms on the Free plan; 30s default on the paid/Standard plan, raisable to 5 min via cpu_ms), not how long you wait on fetch. A Worker that does heavy JSON parsing or crypto in a loop gets Error 1102 (Worker exceeded CPU limit) even though it’s fast on your laptop. Move heavy work off the hot path (waitUntil, a Queue consumer, or a Durable Object) and ask the AI to “profile the synchronous CPU work and move anything non-blocking out of the request path.”

Caution

Provisioned concurrency as a reflex. Blanket-enabling it on every function is how the bill doubles. It only helps functions on a latency-sensitive synchronous path with predictable spikes. For async/event-driven Lambdas (the S3 and SQS handlers above), cold starts rarely matter — fix the bundle and VPC first.

What’s Next

API Design Patterns REST and validation patterns that pair with the gateway Worker above.

Database Patterns DynamoDB single-table design, connection pooling, and serverless SQL options.

Infrastructure as Code Promote these stacks to Terraform/Pulumi and wire up multi-stage deploys.

Cloudflare MCP Servers The full 16-server catalog, OAuth flow, and per-tool setup.