Aws Serverless
Bootstrap AWS Lambda handlers with Powertools logging, tracing, metrics, and DynamoDB-backed idempotency for production-safe serverless APIs.
Overview
AWS Serverless is an agent skill for the Build phase that scaffolds Lambda handlers with Powertools Logger, Tracer, Metrics, and DynamoDB idempotency.
Install
npx skills add https://github.com/aws/agent-toolkit-for-aws --skill aws-serverlessWhat is this skill?
- Production-ready handler skeleton with Logger, Tracer, and Metrics decorators
- DynamoDB persistence layer and JMESPath-based idempotency for duplicate payloads
- Cold-start metric capture and structured JSON responses with CORS headers
- Explicit guidance to avoid logging full events in production (PII/tokens)
- Separate traced process() method pattern for testable business logic
- Decorators for Logger, Tracer, Metrics, and idempotent execution on one handler
- DynamoDB-backed persistence layer with event_key_jmespath on body
Adoption & trust: 1.6k installs on skills.sh; 819 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need a Lambda entrypoint that logs cleanly, traces requests, emits metrics, and deduplicates retries without copying fragile boilerplate from blog posts.
Who is it for?
Solo builders shipping JSON APIs or workers on Lambda who already chose AWS and want Powertools defaults on day one.
Skip if: Teams needing full SAM/CDK stacks, non-AWS runtimes, or serverless functions with no idempotency or observability requirements.
When should I use this skill?
You are implementing or refactoring an AWS Lambda function and need Powertools observability plus idempotent handling.
What do I get? / Deliverables
You get a decorator-ready handler and process stub you can drop business logic into, with idempotency and observability aligned to AWS best practices.
- Handler module with logging, tracing, metrics, and idempotency decorators
- process() stub for domain logic separated from the Lambda entrypoint
Recommended Skills
Journey fit
Serverless handler scaffolding is a core backend build task when you ship logic on Lambda rather than long-running servers. Powertools wiring, handler structure, and idempotency belong in backend implementation, not launch or operate runbooks alone.
How it compares
Use as a handler template skill, not a replacement for infrastructure-as-code or generic debugging playbooks.
Common Questions / FAQ
Who is aws-serverless for?
Indie and solo developers building AWS Lambda backends who want Powertools logging, tracing, metrics, and idempotency wired correctly from the start.
When should I use aws-serverless?
During Build when you create or refactor a Lambda function, especially before you wire API Gateway, SQS, or other triggers that can deliver duplicate events.
Is aws-serverless safe to install?
Review the Security Audits panel on this Prism page for the upstream package; the skill is code guidance and does not grant cloud credentials by itself.
SKILL.md
READMESKILL.md - Aws Serverless
"""Lambda handler with Powertools Logger, Tracer, Metrics, and Idempotency wired.""" import json from aws_lambda_powertools import Logger, Metrics, Tracer from aws_lambda_powertools.metrics import MetricUnit from aws_lambda_powertools.utilities.idempotency import ( DynamoDBPersistenceLayer, IdempotencyConfig, idempotent, ) from aws_lambda_powertools.utilities.typing import LambdaContext logger = Logger() tracer = Tracer() metrics = Metrics() persistence = DynamoDBPersistenceLayer(table_name="IdempotencyTable") # Idempotency key: "body" deduplicates identical payloads. config = IdempotencyConfig(event_key_jmespath="body") # Set log_event=True only in non-production environments; # events may contain auth tokens, cookies, or PII. @logger.inject_lambda_context(log_event=False) @tracer.capture_lambda_handler @metrics.log_metrics(capture_cold_start_metric=True) @idempotent(config=config, persistence_store=persistence) def handler(event: dict, context: LambdaContext) -> dict: logger.info("Processing request") result = process(event) metrics.add_metric(name="RequestsProcessed", unit=MetricUnit.Count, value=1) return { "statusCode": 200, "headers": { "Content-Type": "application/json", "Access-Control-Allow-Origin": "https://your-domain.example", # Replace with your domain }, "body": json.dumps(result), } @tracer.capture_method def process(event: dict) -> dict: """Replace with your business logic.""" return {"message": "success"} # API Gateway Reference Quick-reference for REST API, HTTP API, WebSocket API — debugging, configuration, and quotas. ## Contents - [REST vs HTTP API Comparison](#rest-vs-http-api-comparison) - [CORS Debugging](#cors-debugging) - [Lambda Authorizers](#lambda-authorizers) - [Throttling and Quotas](#throttling-and-quotas) - [WebSocket APIs](#websocket-apis) - [502/504 Debugging](#502504-debugging) --- ## REST vs HTTP API Comparison ### Decision Tree ``` Need any of these? → REST API ├── API keys / usage plans / per-client throttling ├── Request validation (built-in) ├── Request/response body transformation (VTL) ├── Caching (built-in) ├── Private API endpoints ├── Edge-optimized endpoints ├── Canary deployments ├── Execution logs / X-Ray tracing ├── Resource policies ├── Mock integrations └── Response streaming None of the above? → HTTP API (lower latency, simpler) ``` ### Feature Comparison | Feature | REST API | HTTP API | |---|---|---| | **Latency** | Higher | Lower | | **Endpoint types** | Edge, Regional, Private | Regional only | | **AWS WAF** | Yes | No | | **API keys / usage plans** | Yes | No | | **Per-client throttling** | Yes | No | | **Request validation** | Yes | No | | **Body transformation (VTL)** | Yes | No | | **Parameter mapping** | Yes | Yes | | **Caching (built-in)** | Yes | No | | **Custom domains** | Yes | Yes | | **Lambda authorizers** | Yes (TOKEN + REQUEST) | Yes (REQUEST only) | | **JWT authorizers (native)** | No | Yes | | **IAM auth** | Yes | Yes | | **Cognito (native)** | Yes | Yes (via JWT) | | **Resource policies** | Yes | No | | **Mutual TLS** | Yes | Yes | | **CORS setup** | Manual OPTIONS method | Built-in config | | **Automatic deployments** | No | Yes | | **Canary deployments** | Yes | No | | **Custom gateway responses** | Yes | No | | **Execution logs** | Yes | No | | **Access logs (CloudWatch)** | Yes | Yes | | **Access logs (Firehose)** | Yes | No | | **X-Ray tracing** | Yes | No | | **Mock integrations** | Yes | No | | **Private integrations (NLB)** | Yes | Yes | | **Private integrations (ALB)** | Yes | Yes | | **Private integrations (Cloud Map)** | No | Yes | | **Response streaming** | Yes | No | | **Console test invocations** | Yes | No | | **Integration timeout** | 50ms–29s (configurable) | 30s hard max | | **Payload size** | 10 MB | 10 MB | > **REST API streaming caveats:** Response streaming via REST API proxy integration does