Serverless Development Patterns

Serverless development patterns for AI coding agents are recipes that make Claude Code, Codex and Cursor produce AWS Lambda, Cloudflare Workers and Vercel code that survives production: handlers that stay idempotent when events are redelivered, Worker bindings that match wrangler.toml, and cold-start fixes that come before provisioned concurrency. Each recipe ends in a test or gate, not a manual read.

This page is for backend developers who already ship functions and now let an agent write most of them. The situation it fixes: your image-processing Lambda fires twice on the same S3 upload, CloudWatch is a wall of unstructured console.log, and the p99 spike every morning was “fixed” by provisioned concurrency on every function, which doubled the bill. Serverless removes the servers, not the distributed-systems problems. Retries, idempotency, cold starts and per-platform limits are still your code, and an agent writes the happy path unless you ask for more.

The recipes assume a TypeScript project with Vitest; if you do not have that toolchain yet, set it up with Node.js patterns first, or pick another stack from the backend recipes hub.

What you’ll walk away with from these serverless recipes

• A prompt that produces an idempotent S3-to-Lambda handler, plus the corrected handler shape to check it against.
• A test prompt that proves the handler survives a duplicate delivery and a mid-flight failure, so you verify behaviour instead of reading the diff.
• A Cloudflare Worker API gateway prompt with a matching wrangler.toml, and two commands that catch binding drift and bundle bloat before deploy.
• Per-tool setup for the Cloudflare MCP server and the Cloudflare skills, with the context cost of the MCP server.
• A cold-start triage prompt that tells you when provisioned concurrency is worth paying for.
• The failure modes that reach production (duplicate SQS deliveries, recursive S3 triggers, Workers CPU limits, stuck idempotency claims) and how to recover from each.

How do you scaffold a serverless service with an agent?

Give the agent one concrete service, a region, a runtime and the event sources. All three tools drive the same framework CLIs (Serverless Framework, AWS SAM, Wrangler), so pick the tool by where the work lives, not by capability. The scaffold prompt below uses Serverless Framework v4 (serverless 4.43.0 on npm, checked 2026-09-26) and Node.js 22.

Claude Code

Run from the empty repo in a terminal. For the first run, pass --permission-mode manual to approve each edit yourself (from v2.1.283, on both release channels on 2026-10-12, interactive sessions otherwise start in auto mode). Switch to --permission-mode acceptEdits, as below, once you trust the plan.

claude --permission-mode acceptEdits "Set up a Serverless Framework v4 service in TypeScript for AWS eu-central-1: one HTTP Lambda behind API Gateway (GET /health), one S3-triggered image Lambda that only fires for the uploads/ prefix, and a DynamoDB table 'media' (PK id) plus a 'dedupe' table with TTL on 'ttl'. esbuild bundling, Node.js 22 runtime, dev and prod stages. Add a vitest setup and an npm 'test' script. Do not deploy."

Use claude -p with the same prompt when the scaffold has to be reproducible in a script.

Codex

Keep writes inside the workspace and let Codex ask before anything wider:

codex --sandbox workspace-write -a on-request "Set up a Serverless Framework v4 service in TypeScript for AWS eu-central-1: one HTTP Lambda behind API Gateway (GET /health), one S3-triggered image Lambda that only fires for the uploads/ prefix, a DynamoDB table 'media' (PK id) and a 'dedupe' table with TTL on 'ttl'. esbuild, Node.js 22, dev and prod stages, vitest with an npm 'test' script. Do not deploy."

Permission profiles (-c default_permissions=":workspace", beta) are the newer control; --sandbox still works in codex-cli 0.157.1. Do not combine the two.

To run the same task in Codex Cloud and review a branch instead, codex cloud exec --env ENV_ID "<same prompt>" submits it (--env is required in codex-cli 0.157.1; list environments with codex cloud).

Cursor

Paste the same prompt into Cursor’s agent in the open repository and review the proposed diff file by file before you accept it. For a larger scaffold, ask for a plan first with Plan Mode, then let the agent execute it.

Note

Stay on your tool’s default model for this work and raise effort before switching models. The current defaults and prices live on the AI models hub.

How do you make an AWS Lambda handler idempotent?

S3, SQS and EventBridge deliver events at least once. A handler with side effects (writes, emails, charges) must claim a stable key before it acts, skip the work when the claim already exists, and release the claim when the work fails, so the retry can run. Generated handlers often get the first two right and miss the third: they write the dedupe record, crash in sharp, and every retry is then skipped as a “duplicate”. The object is never processed.

Copy-paste prompt: idempotent S3 to Lambda image processor

Write an AWS Lambda handler in TypeScript (Node.js 22) for an S3 ObjectCreated trigger on the uploads/ prefix. It resizes the image to 256, 512 and 1024px WebP with sharp and writes them under derived/ in a SEPARATE destination bucket (never the source bucket, to avoid a recursive trigger).

Idempotency: URL-decode the object key (S3 encodes spaces as '+'). Before any side effect, claim pk = <bucket>/<key>#<eTag> with a DynamoDB PutItem using ConditionExpression 'attribute_not_exists(pk)' and a 'ttl' attribute 7 days out. If the condition fails, log status 'duplicate-skipped' and continue. If the resize or write fails, DELETE the claim, log status 'failed', and rethrow so the event reaches the on-failure destination.

Logging: exactly one JSON line per record with requestId, bucket, key, pk, status and durationMs.

Then give me the serverless.yml function block: memorySize 1024, timeout 30, the s3 event with the uploads/ prefix rule, an SQS on-failure destination, and IAM limited to GetObject on the source, PutObject on derived/ in the destination, and PutItem/DeleteItem on the dedupe table.

Check the output against this shape. The order of operations is what matters, not the style:

// handler.ts: claim, work, release on failure
import type { S3Event } from 'aws-lambda';
import { DynamoDBClient, PutItemCommand, DeleteItemCommand } from '@aws-sdk/client-dynamodb';
import { resizeAndWrite } from './resize';

const ddb = new DynamoDBClient({});
const TABLE = process.env.DEDUPE_TABLE!;

export const handler = async (event: S3Event) => {
  for (const rec of event.Records) {
    const start = Date.now();
    const bucket = rec.s3.bucket.name;
    const key = decodeURIComponent(rec.s3.object.key.replace(/\+/g, ' '));
    const pk = `${bucket}/${key}#${rec.s3.object.eTag}`;
    const log = { requestId: rec.responseElements['x-amz-request-id'], bucket, key, pk };

    try {
      await ddb.send(new PutItemCommand({
        TableName: TABLE,
        Item: { pk: { S: pk }, ttl: { N: String(Math.floor(start / 1000) + 7 * 86400) } },
        ConditionExpression: 'attribute_not_exists(pk)',
      }));
    } catch (err) {
      if ((err as Error).name !== 'ConditionalCheckFailedException') throw err;
      console.log(JSON.stringify({ ...log, status: 'duplicate-skipped' }));
      continue;
    }

    try {
      await resizeAndWrite(bucket, key);
      console.log(JSON.stringify({ ...log, status: 'ok', durationMs: Date.now() - start }));
    } catch (err) {
      await ddb.send(new DeleteItemCommand({ TableName: TABLE, Key: { pk: { S: pk } } }));
      console.error(JSON.stringify({ ...log, status: 'failed', error: (err as Error).message }));
      throw err;
    }
  }
};

A timeout can still kill the function between the claim and the release, which leaves a claim that blocks every retry. If you would rather not hand-roll a lease with an expiry, ask the agent to use @aws-lambda-powertools/idempotency (2.35.0 on npm, checked 2026-09-26) instead: it stores an in-progress record with its own expiry and a completed record with the result, which covers that case.

How do you prove the handler survives a duplicate delivery?

Do not read the handler line by line. Write down the four behaviours that matter and make a test fail if any of them breaks. Tell the agent the tests are the specification, so a failing test leads to a handler fix and not to an edited assertion. Protect the oracle explains why that instruction matters.

Copy-paste prompt: duplicate-delivery and failure tests

Write a vitest suite for src/handler.ts using aws-sdk-client-mock (mock DynamoDBClient) and vi.mock('./resize'). Build S3Event fixtures by hand. Cover exactly these behaviours:
1. The same S3 event delivered twice: resizeAndWrite is called once, and the second invocation logs status 'duplicate-skipped'.
2. resizeAndWrite throws: the handler sends DeleteItemCommand for the same pk and rethrows.
3. A key 'uploads/my+photo.jpg' reaches resizeAndWrite as 'uploads/my photo.jpg'.
4. A DynamoDB error other than ConditionalCheckFailedException is rethrown without calling resizeAndWrite.
Do not modify src/handler.ts to make a test pass. If a test fails, stop and tell me which behaviour the handler gets wrong.

Then run the gates. Each one goes red for a specific bug, which is what lets you trust the result without reviewing every line:

Gate	Command (terminal or CI)	Goes red when
Behaviour tests	npx vitest run	A duplicate is processed twice, the claim is not released after a failed resize, or a key is not decoded
Types	npx tsc --noEmit	The handler reads a field the event type does not have
Package	npx serverless package --stage dev	serverless.yml does not parse or a handler path is wrong
Worker bindings	npx wrangler types, then npx tsc --noEmit	Worker code reads a binding that wrangler.toml does not declare
Worker bundle	npx wrangler deploy --dry-run --outdir dist	The printed Total Upload exceeds the size budget a CI step compares it against (for example, fail above 1 MiB); the dry run itself never fails on size, and nothing is uploaded
Production signal	CloudWatch Logs Insights: stats count(*) by status	The duplicate-skipped or failed count moves after a release

You own the tests and the gates. Changes to IAM policies, on-failure destinations and stage configuration go to a human reviewer, because a wrong IAM grant passes every test above. Deploys run from CI, not from an agent session. The evidence bundle page shows how to attach the gate results to the pull request.

To have the agent run the gates and fix what fails without supervision:

Claude Code

claude -p "Run npx vitest run and npx tsc --noEmit. If anything fails, fix src/, never tests/, and rerun until both pass. Print which behaviour was wrong and what you changed." \
  --permission-mode acceptEdits \
  --allowedTools "Bash(npx vitest *)" "Bash(npx tsc *)" \
  --disallowedTools "Edit(tests/**)" "Write(tests/**)"

Codex

codex exec --sandbox workspace-write "Run npx vitest run and npx tsc --noEmit. If anything fails, fix src/, never tests/, and rerun until both pass. Print which behaviour was wrong and what you changed."

Cursor

Paste the same instruction into the agent. To run it on every pull request instead, use a Cloud Agent automation with a Source control trigger, and let Bugbot review the resulting pull request, as described in Cursor CI/CD.

The prompt alone only asks the agent to leave tests/ alone. In Claude Code, --disallowedTools makes that a rule the session cannot break. For Codex and Cursor, enforce it outside the agent: a CODEOWNERS entry that requires a human review for tests/, or a CI check that fails when an agent branch changes files under tests/.

How do you build a Cloudflare Worker API gateway with matching bindings?

Workers have no Node.js runtime by default, a CPU-time budget per request, and bindings instead of SDK clients. Ask for the Worker and its config in one prompt so the binding names in code and in wrangler.toml come from the same answer.

Copy-paste prompt: Cloudflare Worker API gateway

Write a Cloudflare Worker in TypeScript (ES modules) that acts as an API gateway: proxy GET /v1/* to the origin in the ORIGIN var with fetch, check a bearer token against the TOKENS KV namespace, rate-limit each token to 100 requests per minute with a Durable Object class RateLimiter, and cache successful GETs in the Cache API for 60 seconds. Return JSON errors { error, requestId } with correct status codes. Keep synchronous CPU work small: move heavy CPU work out of the request into a Queue consumer or a Durable Object, and use ctx.waitUntil only for non-blocking I/O such as logging and analytics. Then give me wrangler.toml with the KV binding, the Durable Object binding and its migration, and the ORIGIN var, and add a test with @cloudflare/vitest-pool-workers that asserts 401 without a token and 429 on the 101st request.

# wrangler.toml: binding names must match the Worker's Env type
name = "api-gateway"
main = "src/index.ts"
compatibility_date = "2026-09-01"

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

[[kv_namespaces]]
binding = "TOKENS"
id = "KV_NAMESPACE_ID"

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

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

Replace KV_NAMESPACE_ID with the id that npx wrangler kv namespace create TOKENS prints. Then run npx wrangler types: it regenerates the Env type from this file, so a Worker that reads env.TOKEN instead of env.TOKENS fails tsc instead of failing at runtime.

How do you give the agent live Cloudflare state?

Generated code is half the job. The other half is the state it runs against: a mistyped namespace id, a stale KV value, a route that throws in production. Cloudflare offers two ways to put that in front of the agent, and they solve different problems.

• The Cloudflare MCP server reads and changes your live account. The recommended Code Mode server at https://mcp.cloudflare.com/mcp exposes three tools (search, execute, docs) over the whole Cloudflare API. Cloudflare puts its schema cost at about 1,000 tokens, against about 244,000 for native tool schemas of the same API (Cloudflare, cloudflare/mcp README, read 2026-09-26). Results are capped at about 6,000 tokens by default. Domain servers such as https://observability.mcp.cloudflare.com/mcp cover one area each.
• The Cloudflare skills (cloudflare/skills, 14 skills for Workers, Wrangler, Durable Objects and more) teach the agent the platform’s conventions. The plugin form bundles the same Code Mode MCP server.

The MCP server needs a URL entry per tool. Authentication is OAuth on first use, or a Cloudflare API token sent as a bearer token.

Claude Code

claude mcp add --transport http cloudflare https://mcp.cloudflare.com/mcp
# or the plugin, which brings the skills and the MCP server together:
# /plugin marketplace add cloudflare/skills
# /plugin install cloudflare@cloudflare

Leave out --transport http and Claude Code 2.1.283 still saves the URL as a stdio command. It prints a warning, but the entry is written and fails at connect time.

Codex

codex mcp add cloudflare --url https://mcp.cloudflare.com/mcp
# or the plugin:
codex plugin marketplace add cloudflare/skills
codex plugin add cloudflare@cloudflare

Cursor

Add the server to .cursor/mcp.json:

{ "mcpServers": { "cloudflare": { "url": "https://mcp.cloudflare.com/mcp" } } }

For the skills alone, npx skills add https://github.com/cloudflare/skills installs them for Cursor and other agents.

Before MCP, finding a stale token meant copying namespace ids between dashboard tabs. With it, one prompt answers from the live account:

Copy-paste prompt: read live Worker state

Using the Cloudflare MCP server: list the bindings of the api-gateway Worker, confirm the TOKENS KV namespace id matches the one in wrangler.toml, and show the last hour of errors for api-gateway grouped by route. Read only: do not change any resource.

Pick the skill when the agent only needs to know wrangler commands and conventions. Pick the MCP server when it has to read or change live state, and keep write access out of sessions where you do not need it. For AWS, the equivalent is AWS’s own plugin set (aws/agent-toolkit-for-aws, with an aws-core plugin for serverless and CDK work). In Claude Code, install it with /plugin install aws-core@claude-plugins-official. In Codex, run codex plugin marketplace add aws/agent-toolkit-for-aws, then install aws-core from /plugins. The full server list and OAuth details are on the Cloudflare MCP page.

More serverless prompts: cold starts, queues and Vercel

Copy-paste prompt: cold-start triage before provisioned concurrency

My Lambda image-processor (Node.js 22, 1024 MB, in a VPC) has a p99 of 4 s in the morning and about 300 ms the rest of the day. Write a CloudWatch Logs Insights query that splits REPORT lines into Init Duration and Duration and shows how many invocations were cold. Then rank the likely causes: bundle size, SDK clients created at module scope, VPC networking, unused dependencies. Propose the cheapest fixes first (esbuild tree-shaking, dropping unused packages, lazy imports, removing the VPC if it is only there for DynamoDB). Recommend provisioned concurrency, with a concrete number, only if those fixes cannot bring p99 under 1 s, and say how to measure the result.

Copy-paste prompt: SQS consumer with partial batch failures

Write an SQS to Lambda consumer in TypeScript for order events with batchSize 10 and functionResponseType ReportBatchItemFailures, so one poison message does not fail the whole batch. Validate each message with a zod schema. Make the handler idempotent on orderId with a DynamoDB conditional write that is released on failure. Give me the serverless.yml for the queue and a DLQ with maxReceiveCount 3, a replay.ts script that moves DLQ messages back to the main queue, and vitest tests for: one invalid message in a batch of ten, and the same orderId delivered twice.

Copy-paste prompt: Vercel Function with geolocation A/B routing

Write a Vercel Function that assigns a stable A/B variant: read the visitor country with geolocation(request) from @vercel/functions; bucket visitors whose country is in the comma-separated AB_COUNTRIES environment variable into the experiment, with the variant derived from a hash of a 'variant' cookie (set one if it is missing), and send everyone else to variant A; then stream the chosen origin's HTML through unchanged. Set the cookie on the first visit only. Use Web standard Request, Response and streams so the code has no Node.js-only APIs. Add tests that the same cookie always yields the same variant and that a visitor from a country outside AB_COUNTRIES always gets variant A.

What breaks when agent-written serverless code reaches production?

Duplicate processing on retries

A frequent serverless bug, and happy-path output rarely handles it. Symptom: two emails, two charges, or thumbnails overwritten. Recovery: find the stable key (S3 eTag, SQS messageId, your own orderId), then re-prompt: “This handler is not idempotent. Add a DynamoDB conditional-write claim on KEY before any side effect, release it on failure, and add a test that delivers the same event twice.”

An idempotency claim that never clears

Symptom: an object is never processed and every retry logs duplicate-skipped. Cause: the claim was written, then the function timed out or crashed before the release ran. Recovery: delete the stuck record, then replace the plain claim with a lease that expires (an in-progress status plus an expiry shorter than the retry window), or switch to @aws-lambda-powertools/idempotency.

A recursive S3 trigger

Symptom: invocation count and bill climb within minutes. Cause: the function writes its output into the bucket that triggers it. Recovery: set the function’s reserved concurrency to 0 to stop it, then write output to a separate bucket or restrict the trigger to an input prefix such as uploads/. Add that constraint to every S3 prompt. Lambda’s recursive loop detection, on by default, covers loops through Amazon S3 and stops the function after about 16 invocations in the same chain, but only when the function uses a supported AWS SDK version (AWS Lambda recursive loop detection docs, checked 2026-09-26). Treat it as a backstop, not the fix: the separate bucket or prefix is what prevents the loop.

Cloudflare Workers CPU limits, not wall-clock limits

Workers cap CPU time per request, not time spent waiting on fetch: 10 ms on the Free plan, and on the Paid plan 30 seconds by default, raisable to 5 minutes with limits.cpu_ms (Cloudflare Workers limits page, checked 2026-09-26). A Worker that parses large JSON or hashes in a loop fails with Error 1102 even though it is fast on your laptop. Recovery: ask the agent to “profile the synchronous CPU work in the request path, move heavy CPU work out of the request into a Queue consumer or a Durable Object, and use ctx.waitUntil only for non-blocking I/O such as logging”.

DynamoDB hot partitions

A low-cardinality partition key (for example status#PENDING) sends all traffic to one partition, and you get ProvisionedThroughputExceededException under load while average utilisation looks low. Recovery: ask the agent to “check the partition-key cardinality and propose a write-sharding suffix or a GSI” instead of raising capacity.

Provisioned concurrency as a reflex

Enabling it on every function is how the bill doubles. It pays off only on a latency-sensitive synchronous path with predictable traffic. Asynchronous handlers such as the S3 and SQS consumers above rarely need it. Run the cold-start triage prompt first and measure Init Duration before and after each fix.

Where to go next with serverless

API development patterns Idempotency keys, pagination and OpenAPI for the routes behind the gateway Worker.

NoSQL patterns DynamoDB key design and access patterns for the tables these handlers use.

Infrastructure as code Promote these stacks to Terraform or Pulumi with multi-stage deploys.

Monitoring and observability Turn the structured log lines into alerts and dashboards.

Cloudflare MCP Code Mode, the domain servers, OAuth and per-tool setup.

Best backend and platform skills Cloudflare, AWS and database skills compared.