
Aws Serverless Eda
Design and implement AWS serverless APIs and event-driven workflows with Lambda, API Gateway, queues, and Step Functions aligned to Well-Architected practices.
Overview
AWS Serverless EDA is an agent skill most often used in Build (also Operate) that guides Lambda, API Gateway, and event-driven AWS architectures using Well-Architected practices.
Install
npx skills add https://github.com/zxkane/aws-skills --skill aws-serverless-edaWhat is this skill?
- Well-Architected-aligned guidance for Lambda, API Gateway REST/HTTP, DynamoDB, and Step Functions
- Event-driven patterns with EventBridge, SQS, SNS, and async processing flows
- Fork context with aws-mcp-setup and aws-cdk-development dependency chain
- SAM and AWS CLI hooks with identity check before sam deploy
- TypeScript and Python Lambda coverage for scalable serverless APIs and microservices
- Depends on 2 chained skills: aws-mcp-setup and aws-cdk-development
- Covers 8+ AWS service families including Lambda, API Gateway, DynamoDB, Step Functions, EventBridge, SQS, and SNS
Adoption & trust: 1 installs on skills.sh; 306 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You need a scalable serverless API or async pipeline on AWS but service wiring, deploy safety, and event patterns are easy to get wrong without verified docs and IaC habits.
Who is it for?
Solo developers shipping Lambda-backed APIs, webhooks, or queue-driven workers who already chose AWS and want agent steps tied to official docs and CDK.
Skip if: Local-only prototypes with no AWS account, or teams standardizing on Kubernetes/long-lived EC2 without serverless goals.
When should I use this skill?
User mentions serverless, Lambda, API Gateway, event-driven design, async queues, pub/sub, or scalable serverless applications on AWS.
What do I get? / Deliverables
You structure serverless and event-driven AWS solutions with MCP-verified guidance and can hand off to CDK or SAM deploy flows after MCP setup is in place.
- Serverless or EDA architecture aligned to Well-Architected pillars
- Service wiring plan across Lambda, API Gateway, and chosen messaging or orchestration services
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Serverless assembly is core Build work for solo founders shipping APIs and async jobs without managing servers day one. Integrations captures wiring managed AWS services, IAM, events, and deployment tooling into a cohesive architecture.
Where it fits
Map a webhook ingestion path through API Gateway, Lambda, and SQS before you write handler code.
Run STS-checked SAM deploy steps when you first push a staging API for beta users.
Adjust DLQ handling and Step Functions error branches after production traffic spikes.
How it compares
AWS serverless architecture playbook with MCP doc gates—not a single-purpose Lambda snippet generator.
Common Questions / FAQ
Who is aws-serverless-eda for?
Indie builders and small teams building on AWS who want agent-guided serverless APIs, queues, and step workflows with Well-Architected framing and MCP-backed fact checking.
When should I use aws-serverless-eda?
During Build when designing Lambda plus API Gateway services or EventBridge/SQS pipelines; during Operate when hardening retries, monitoring, and deploy paths for those same stacks.
Is aws-serverless-eda safe to install?
Review the Security Audits panel on this Prism page; the skill authorizes shell and AWS API tooling—use least-privilege IAM and confirm deploy hooks match your account before running sam deploy or aws CLI commands.
Workflow Chain
Requires first: aws mcp setup, aws cdk development
SKILL.md
READMESKILL.md - Aws Serverless Eda
# AWS Serverless & Event-Driven Architecture This skill provides comprehensive guidance for building serverless applications and event-driven architectures on AWS based on Well-Architected Framework principles. ## AWS Documentation Requirement Always verify AWS facts using MCP tools (`mcp__aws-mcp__*` or `mcp__*awsdocs*__*`) before answering. The `aws-mcp-setup` dependency is auto-loaded — if MCP tools are unavailable, guide the user through that skill's setup flow. ## Serverless MCP Servers This skill leverages the CDK MCP server (provided via `aws-cdk-development` dependency) and AWS Documentation MCP for serverless guidance. > **Note**: The following AWS MCP servers are available separately via the Full AWS MCP Server (see `aws-mcp-setup` skill) and are not bundled with this plugin: > - AWS Serverless MCP — SAM CLI lifecycle (init, deploy, local test) > - AWS Lambda Tool MCP — Direct Lambda invocation > - AWS Step Functions MCP — Workflow orchestration > - Amazon SNS/SQS MCP — Messaging and queue management ## When to Use This Skill Use this skill when: - Building serverless applications with Lambda - Designing event-driven architectures - Implementing microservices patterns - Creating asynchronous processing workflows - Orchestrating multi-service transactions - Building real-time data processing pipelines - Implementing saga patterns for distributed transactions - Designing for scale and resilience ## AWS Well-Architected Serverless Design Principles ### 1. Speedy, Simple, Singular **Functions should be concise and single-purpose** ```typescript // ✅ GOOD - Single purpose, focused function export const processOrder = async (event: OrderEvent) => { // Only handles order processing const order = await validateOrder(event); await saveOrder(order); await publishOrderCreatedEvent(order); return { statusCode: 200, body: JSON.stringify({ orderId: order.id }) }; }; // ❌ BAD - Function does too much export const handleEverything = async (event: any) => { // Handles orders, inventory, payments, shipping... // Too many responsibilities }; ``` **Keep functions environmentally efficient and cost-aware**: - Minimize cold start times - Optimize memory allocation - Use provisioned concurrency only when needed - Leverage connection reuse ### 2. Think Concurrent Requests, Not Total Requests **Design for concurrency, not volume** Lambda scales horizontally - design considerations should focus on: - Concurrent execution limits - Downstream service throttling - Shared resource contention - Connection pool sizing ```typescript // Consider concurrent Lambda executions accessing DynamoDB const table = new dynamodb.Table(this, 'Table', { billingMode: dynamodb.BillingMode.PAY_PER_REQUEST, // Auto-scales with load }); // Or with provisioned capacity + auto-scaling const table = new dynamodb.Table(this, 'Table', { billingMode: dynamodb.BillingMo