/aws-serverless

name: aws-serverless
description: Routes serverless requests to a compute form factor and the skill that owns it. Applies to Lambda, API Gateway, EventBridge, Step Functions and event-driven work while the compute, orchestration or integration choice is open — API backends, webhooks, jobs, cron, queue/stream consumers, durable workflows, event routing, Step Functions vs Durable Functions, and Pipes vs native event source mappings for queues and streams. Decides Event Functions on-demand vs Managed Instances, Web Functions, MicroVMs, EventBridge rules/Scheduler/Pipes/bus, HTTP vs REST API. Owns shared Lambda references (cold starts, SnapStart, concurrency, event sources, function URLs, throttling, troubleshooting). Defers to the specialized skill once a request commits to one form factor or service, or describes its defining feature without naming it (durable checkpointing and automatic step retries, Firecracker sandbox, managed instances, Node.js server). Not for EC2, ECS/EKS/Fargate or Amplify hosting.
metadata:
  version: "6"

AWS Serverless

Overview

This skill is the **router** for serverless work on AWS. It makes one opinionated recommendation for each application component and each raised decision dimension (form factor + capacity provider + orchestration + feature choices), then hands off to every specialized skill needed for that composition. Do not force a multi-component application onto one form factor. This skill keeps only the shared Lambda reference material that has no dedicated skill.

**Works best with** the [AWS MCP server](https://docs.aws.amazon.com/aws-mcp/) — recommended for sandboxed command execution and audit logging. All guidance also works with standard AWS CLI access.

**How to use this skill:** Step 0 fixes the entry point (new, optimizing, migrating); Step 1 routes components that already name the technology; Step 2 walks the compute decision flow (Tier 1 → 2) for each component until its form factor and capacity provider are locked, with the Tier 3 edge cases detailed in [compute-decision-edge-cases.md](references/compute-decision-edge-cases.md); Steps 3–5 resolve orchestration, eventing and the HTTP front door only when the request raises them, with the full comparisons in [orchestration.md](references/orchestration.md) and [api-gateway.md](references/api-gateway.md). Then hand off to every applicable specialized skill and fall back to the [shared references](#shared-references-in-this-skill) for anything without a dedicated skill.

If a routed skill is not available in your environment, **the decision made here still stands**.

Rules (apply to every recommendation)

1. **Be opinionated per component and resolved dimension.** State *"Use X because …"*. Do not force one service across components with different requirements, and do not present neutral comparison tables as the answer. For a *Decided* dimension, add one clause naming why the closest alternative does not fit (for example, Event and Web Functions have no OS-level access for eBPF; Durable Functions has no native `.sync` integration to start and wait on Glue or ECS jobs), and keep the recommendation and its reasons in the final response even after consulting other skills or documentation. 2. **Resolve every raised component and decision dimension independently.** Form factor, capacity provider, orchestration and feature constraints are separate decisions; resolving one does not close another. Different components may use different form factors, and one component may pair a compute form factor with an orchestration layer. 3. **Infer facts, not boundaries: classify each raised dimension before answering.**

• *Decided* — the request states the fact that separates the candidates (runtime, trigger, a stated duration or size, "all steps are Lambda functions", "runs continuously") → commit and ask nothing about that dimension.
• *Leaning* — the request gives only a qualitative hint ("bursty", "uneven", "quiet overnight", "large dependencies", "untrusted", "thousands of short tasks", "takes a while") while a candidate still depends on an observable fact it leaves unstated → lead with the provisional choice and why, then put the missing fact to the user as a direct question (ending in "?") and say which answer flips the route. Stating what *would* change the answer is not a substitute for asking. A hint supports the lean; it never substitutes for the deciding fact.
• *Open* — no usable hint → use that tier's narrowing question.
• *Unraised* — the request neither asks about a dimension nor gives a signal for it → apply its default without a question (for example, an event-triggered function with no traffic, duration, instance-type or pricing signal is **Event Functions · On-Demand**).

Do not reopen an unraised or decided dimension, ask no more than 3–4 questions overall, and never reply with questions alone. When a numeric threshold decides the route, name it in the question so the customer can answer from their metrics (for example, a peak-to-mean ratio below 2 within 5–10 minutes for Managed Instances, Tier 2). 4. **Revise.** New information → re-run the affected tier and update the recommendation. 5. **Do not guess facts.** Ground limits, runtimes, pricing and timeouts in the shared references below and confirm against current AWS documentation when precision matters. 6. **Route, do not duplicate.** Once a specialized skill is chosen, follow it rather than re-deriving its content here.

Step 0 — Entry point: what is the user doing?

If unclear, ask once: *"Are you starting something new, tuning a workload you already have, or moving an existing workload onto serverless?"*

| Context | Signals | Path | |---|---|---| | **New application** | "building", "starting", "new project", "greenfield", no existing compute named | Step 1, then the Step 2 decision flow | | **Optimizing existing** | "bill is too high", "cold starts", "too slow", "lag", names a current Lambda setup |