
Aws Serverless
Stand up production AWS serverless stacks—Lambda, API Gateway, DynamoDB, and event-driven wiring—with sizing, DLQs, and SAM/CDK deploy habits.
Overview
AWS Serverless is an agent skill most often used in Build (also Ship and Operate) that teaches production-ready Lambda, API Gateway, DynamoDB, and SQS/SNS patterns with SAM/CDK deployment and cold-start tuning.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill aws-serverlessWhat is this skill?
- Lambda handler pattern with client reuse outside the handler and structured error handling
- API Gateway guidance: HTTP API vs REST API, plus DynamoDB and SQS/SNS event-driven patterns
- Cold start mitigation: memory/timeouts, SnapStart for Java/.NET, and small deployment packages
- Failure design with DLQs, retries, correlation IDs, and env-based configuration
- SAM/CDK deployment framing aligned with eight core serverless principles
- 8 core serverless principles in the skill header
- Covers Lambda, API Gateway, DynamoDB, SQS/SNS, SAM/CDK, and cold start optimization
Adoption & trust: 1.1k installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need a serverless API or worker on AWS but cold starts, oversized packages, and missing DLQs will burn you the first time traffic spikes.
Who is it for?
Solo builders shipping APIs, webhooks, or async jobs on Lambda who want opinionated patterns instead of copying random Stack Overflow snippets.
Skip if: Teams that only need a one-off Lambda hello-world or are committed to Kubernetes/ECS-first architectures with no serverless slice.
When should I use this skill?
Building or hardening AWS serverless APIs, schedulers, or event processors with Lambda, API Gateway, DynamoDB, and queue/topic patterns.
What do I get? / Deliverables
You get reusable handler structure, event-driven wiring, and deployment-minded defaults so the stack is measurable, failure-tolerant, and ready to harden in Ship and Operate.
- Lambda handler modules with reuse-friendly initialization and error handling
- Event-driven integration sketch (SQS/SNS + DLQ) and API Gateway choice notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Most builders reach for this skill while implementing APIs and background workers in the build phase. Backend is the canonical shelf because the skill centers on Lambda handlers, DynamoDB access, and HTTP/event integration—not frontend or launch marketing.
Where it fits
Scaffold a Node.js Lambda handler with DynamoDB document client initialized outside the handler for connection reuse.
Wire SNS or SQS consumers with retry and DLQ defaults before exposing a public API Gateway route.
Right-size memory and timeout from measured traces and trim deployment artifacts ahead of first real users.
Apply SnapStart or packaging rules when latency regressions show up in production metrics.
How it compares
Use instead of generic “AWS overview” chat answers when you need executable handler and event patterns tied to SAM/CDK habits.
Common Questions / FAQ
Who is aws-serverless for?
Indie and solo developers building real backends on AWS Lambda who already know basic cloud concepts and want procedural patterns for APIs and events.
When should I use aws-serverless?
During Build when implementing Lambda handlers and DynamoDB; in Ship when tightening timeouts, DLQs, and package size before launch; and in Operate when tuning cold starts and structured logging in production.
Is aws-serverless safe to install?
Treat it as guidance that may suggest shell, network, and cloud API usage in your project—review the Security Audits panel on this Prism page and your own IAM least-privilege before deploying.
SKILL.md
READMESKILL.md - Aws Serverless
# AWS Serverless Specialized skill for building production-ready serverless applications on AWS. Covers Lambda functions, API Gateway, DynamoDB, SQS/SNS event-driven patterns, SAM/CDK deployment, and cold start optimization. ## Principles - Right-size memory and timeout (measure before optimizing) - Minimize cold starts for latency-sensitive workloads - Use SnapStart for Java/.NET functions - Prefer HTTP API over REST API for simple use cases - Design for failure with DLQs and retries - Keep deployment packages small - Use environment variables for configuration - Implement structured logging with correlation IDs ## Patterns ### Lambda Handler Pattern Proper Lambda function structure with error handling **When to use**: Any Lambda function implementation,API handlers, event processors, scheduled tasks ```javascript // Node.js Lambda Handler // handler.js // Initialize outside handler (reused across invocations) const { DynamoDBClient } = require('@aws-sdk/client-dynamodb'); const { DynamoDBDocumentClient, GetCommand } = require('@aws-sdk/lib-dynamodb'); const client = new DynamoDBClient({}); const docClient = DynamoDBDocumentClient.from(client); // Handler function exports.handler = async (event, context) => { // Optional: Don't wait for event loop to clear (Node.js) context.callbackWaitsForEmptyEventLoop = false; try { // Parse input based on event source const body = typeof event.body === 'string' ? JSON.parse(event.body) : event.body; // Business logic const result = await processRequest(body); // Return API Gateway compatible response return { statusCode: 200, headers: { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' }, body: JSON.stringify(result) }; } catch (error) { console.error('Error:', JSON.stringify({ error: error.message, stack: error.stack, requestId: context.awsRequestId })); return { statusCode: error.statusCode || 500, headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ error: error.message || 'Internal server error' }) }; } }; async function processRequest(data) { // Your business logic here const result = await docClient.send(new GetCommand({ TableName: process.env.TABLE_NAME, Key: { id: data.id } })); return result.Item; } ``` ```python # Python Lambda Handler # handler.py import json import os import logging import boto3 from botocore.exceptions import ClientError # Initialize outside handler (reused across invocations) logger = logging.getLogger() logger.setLevel(logging.INFO) dynamodb = boto3.resource('dynamodb') table = dynamodb.Table(os.environ['TABLE_NAME']) def handler(event, context): try: # Parse input body = json.loads(event.get('body', '{}')) if isinstance(event.get('body'), str) else event.get('body', {}) # Business logic result = process_request(body) return { 'statusCode': 200, 'headers': { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' }, 'body': json.dumps(result) } except ClientError as e: logger.error(f"DynamoDB error: {e.response['Error']['Message']}") return error_response(500, 'Database error') except json.JSONDecodeError: return error_response(400, 'Invalid JSON') except Exception as e: logger.error(f"Unexpected error: {str(e)}", exc_info=True) return error_response(500, 'Internal server error') def process_reque