What this prompt does
This prompt drives the AI to design a complete serverless AWS architecture for [application_type] handling [traffic_pattern]. It configures an API Gateway ([api_type]) front for [endpoint_count] endpoints, designs [runtime] Lambda functions with memory, timeout, and cold-start mitigation for [latency_requirement], chooses between DynamoDB and Aurora Serverless for [data_pattern] and models [access_patterns], wires [event_sources] with DLQs and retries, sets up [auth_method], adds X-Ray and CloudWatch observability, estimates monthly cost for [expected_load], and applies provisioned concurrency or SnapStart.
The structure works because it forces the model to reason about cold starts, capacity, and a real monthly cost estimate before any IaC is written. Naming [access_patterns] up front is what produces a sound DynamoDB key design instead of a relational schema bolted onto a key-value store. Pricing [expected_load] early surfaces cost surprises while they are still cheap to fix.
When to use it
- You are scoping a new serverless backend and want a defensible design before writing CDK or Terraform.
- Your traffic has spikes (
[traffic_pattern]) and you need cold-start and concurrency strategy decided up front. - You need a DynamoDB schema designed around real
[access_patterns]rather than guessed at later. - You want a monthly cost estimate for
[expected_load]before committing to the architecture. - You are integrating event sources like SQS, S3, or DynamoDB Streams and need error handling and DLQs designed in.
- You have a latency target like
[latency_requirement]and need provisioned concurrency or SnapStart planned for it.
Example output
Expect an architecture document: an API Gateway configuration for [api_type], Lambda function specs with memory/timeout/cold-start notes, a data-layer recommendation (DynamoDB vs Aurora Serverless) with a table schema including partition keys, sort keys, and GSIs mapped to [access_patterns], an event-processing design with DLQs and retries, an auth setup, an observability plan, and a monthly cost breakdown for [expected_load]. You then translate it into IaC.
Pro tips
- Spell out every
[access_patterns]entry; DynamoDB single-table design is only as good as the access patterns you give it, and missing one means a painful re-model later. - Be realistic about
[traffic_pattern]spikes — the cold-start and provisioned-concurrency strategy depends entirely on how bursty the load actually is. - Treat the
[expected_load]cost estimate as a planning input, not a quote; verify it against the AWS pricing calculator before quoting anyone. - Reserve provisioned concurrency for the endpoints that truly need
[latency_requirement]; applying it everywhere quietly inflates the bill. - Design DLQs and retry policies for every
[event_sources]integration up front; retrofitting error handling after events start dropping is the harder path. - Translate the output into CDK or Terraform rather than treating the design as final — the prompt produces a blueprint, not deployable code.
- Choose
[api_type]deliberately; HTTP API is cheaper for plain REST while WebSocket or richer features may justify the costlier option, and that choice ripples through the rest of the design.
