What this prompt does
This prompt turns the model into a senior AWS serverless engineer and asks for working code plus a deployable template.yaml, not pseudocode. You give it three inputs — [resource], [runtime], and [access_pattern] — and it returns API Gateway routes wired to Lambda handlers for full CRUD, a DynamoDB table design, least-privilege IAM, structured logging with X-Ray, local SAM development, and a GitHub Actions deploy workflow.
The structure works because it forces the single decision that makes or breaks a serverless backend: the DynamoDB key design. By feeding the real [access_pattern] (for example, list orders by customer sorted by date) into step 2, the model designs partition and sort keys around how you actually read data, rather than copying a relational schema. The [runtime] value pins the Lambda execution environment so the handler code and the SAM template match, and [resource] names the entity every route and table revolves around. Because the deliverables are ordered — table design before handlers, IAM before CI — the output reads as a buildable sequence rather than a pile of disconnected snippets, which is exactly what you want when you intend to deploy it the same day.
When to use it
- You're standing up a new serverless REST API and want low idle cost from day one.
- You need a DynamoDB schema that fits a known query pattern, not a guess.
- You want IAM scoped per function instead of one over-broad role.
- You're prototyping but still want CloudWatch logging and X-Ray tracing baked in.
- You want a SAM local setup so you can invoke handlers offline before deploying.
- You need a CI pipeline that builds, tests, and ships the stack on push.
Example output
Expect a set of fenced code blocks: the Lambda handler code for each CRUD operation, a complete template.yaml defining the API, functions, DynamoDB table, and IAM roles, plus a GitHub Actions workflow file. The DynamoDB section will spell out the keys and any secondary indexes chosen to satisfy your access pattern, and the SAM instructions explain how to invoke functions locally.
Pro tips
- Make
[access_pattern]as concrete as possible — name the lookups, sort order, and filters; this is what shapes the whole table design. - Lock the DynamoDB schema (step 2) before you accept any handler code; redesigning the table later means a data migration.
- Match
[runtime]to a version your CI and local SAM both support, or the template and handlers will drift. - If you have more than one access pattern, list them all so the model can decide whether a global secondary index is warranted.
- Ask it to add a second access pattern after the first draft to test whether the key design holds up.
- Treat the generated IAM as a starting point and review each policy against what the function actually calls.
- Run the SAM local invoke instructions before deploying; catching a handler error offline is far cheaper than debugging it through CloudWatch after a failed stack update.
- Once the CRUD path works, ask for pagination and conditional writes if your resource needs them, rather than asking for everything in the first pass.
