AWS Serverless Kit

A Claude Code skill for building and deploying serverless applications on AWS. Covers Lambda functions, API Gateway, DynamoDB, S3, SQS, Step Functions, and EventBridge with production-ready patterns for error handling, observability, and cost optimization.

When to Use This Skill

Choose AWS Serverless Kit when:

• You're building serverless applications on AWS
• You need Lambda function patterns with proper error handling
• You want to set up API Gateway, DynamoDB, or other serverless services
• You need Step Functions for workflow orchestration
• You want to optimize serverless costs and cold start performance

Consider alternatives when:

• You need Azure serverless (use an Azure Functions skill)
• You want container-based deployment (use a Docker/Kubernetes skill)
• You need general backend development (use a backend development skill)

Quick Start

Copy
# Install the skill
claude install aws-serverless-kit

# Set up a serverless API
claude "Create a serverless REST API with Lambda, API Gateway, and DynamoDB for a todo app using SAM"

# Optimize Lambda performance
claude "My Lambda function has 3-second cold starts. Current config: Node.js 20, 256MB, VPC-connected. How do I optimize?"

# Build an event-driven pipeline
claude "Design an event-driven pipeline: S3 upload → Lambda processing → DynamoDB storage → SNS notification"

Core Concepts

Lambda Handler Pattern

Copy
import { APIGatewayProxyHandler } from 'aws-lambda';

export const handler: APIGatewayProxyHandler = async (event) => {
  try {
    const body = JSON.parse(event.body || '{}');
    const result = await processRequest(body);

    return {
      statusCode: 200,
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(result),
    };
  } catch (error) {
    console.error('Handler error:', error);
    return {
      statusCode: error.statusCode || 500,
      body: JSON.stringify({ error: error.message }),
    };
  }
};

Serverless Service Selection

Service	Use Case	Pricing Model
Lambda	Compute (API handlers, event processors)	Per invocation + duration
API Gateway	HTTP/WebSocket API management	Per request
DynamoDB	NoSQL database	Per read/write unit or on-demand
S3	Object storage	Per GB stored + requests
SQS	Message queuing	Per message
Step Functions	Workflow orchestration	Per state transition
EventBridge	Event routing	Per event

Cold Start Optimization

Technique	Impact	Effort
Provisioned Concurrency	Eliminates cold starts	$$$ cost
Smaller bundle size	20-50% faster cold start	Medium
ARM64 (Graviton2)	20% faster + 20% cheaper	Low
Avoid VPC unless needed	Removes ENI attach time	Low
Lazy initialization	Faster handler execution	Medium
SnapStart (Java)	90% cold start reduction	Low

Configuration

Parameter	Type	Default	Description
runtime	string	"nodejs20"	Runtime: nodejs20, python312, java21, dotnet8
iac_tool	string	"sam"	IaC: sam, cdk, serverless, terraform
memory	number	256	Lambda memory in MB
timeout	number	30	Lambda timeout in seconds
architecture	string	"arm64"	CPU: arm64 (cheaper), x86_64

Best Practices

1. Use ARM64 (Graviton) by default — ARM64 Lambda functions are 20% cheaper and often 20% faster than x86. Unless you have a dependency that requires x86, always deploy on ARM64.

2. Keep Lambda bundles small — Every megabyte of code increases cold start time. Use tree-shaking, exclude dev dependencies, and use Lambda Layers for shared code. A 5MB bundle cold-starts in half the time of a 50MB bundle.

3. Use DynamoDB single-table design — Instead of one table per entity, use a single table with composite keys. This enables efficient queries across entity types and reduces the number of tables to manage.

4. Set concurrency limits — Unbounded Lambda concurrency can overwhelm downstream services (databases, APIs). Set reserved concurrency to protect dependencies and prevent runaway costs.

5. Use structured logging with correlation IDs — Every Lambda invocation should log a correlation ID that traces through API Gateway → Lambda → downstream services. Use AWS X-Ray for distributed tracing.

Common Issues

Cold starts are too slow — Remove VPC attachment unless necessary (removes 1-2s of ENI creation). Reduce bundle size, initialize SDK clients outside the handler, and consider provisioned concurrency for latency-sensitive functions.

DynamoDB throttling — Switch to on-demand capacity mode for unpredictable workloads. For provisioned mode, set up auto-scaling with appropriate min/max values. Avoid hot partitions by distributing write traffic across partition keys.

Lambda timeout on long operations — Don't increase timeout beyond 30 seconds for API-facing functions. For long-running tasks, use Step Functions or SQS to break work into smaller chunks. Return a 202 Accepted and process asynchronously.