Build serverless event-driven architectures on AWS

AWS Serverless & Event-Driven Architecture is a community expert skill for building serverless applications and event-driven architectures on AWS following the Well-Architected Framework. It is published under the MIT license by the zxkane/aws-skills project. AWS facts must be verified with MCP documentation tools before answering, and the aws-mcp-setup dependency is loaded automatically. It leans on the CDK MCP server (via the aws-cdk-development dependency) and the AWS Documentation MCP; four more AWS MCP servers are available separately through the Full AWS MCP Server and are not bundled: AWS Serverless (SAM CLI lifecycle), Lambda Tool (direct invocation), Step Functions (orchestration) and SNS/SQS (messaging).

It teaches seven Well-Architected serverless design principles, each with good and bad TypeScript examples:

1. Speedy, simple, singular: keep functions concise and single-purpose, minimize cold starts, tune memory, use provisioned concurrency only when needed and reuse connections.
2. Think concurrent requests, not total requests: design around concurrency limits, downstream throttling, shared resource contention and connection pool sizing, for example DynamoDB with pay-per-request billing or provisioned capacity with auto-scaling.
3. Share nothing: runtime environments are short-lived, so persist state in DynamoDB, workflow state in Step Functions, session state in ElastiCache and files in S3 rather than on the local file system.
4. Assume no hardware affinity: avoid hardware-specific optimizations, use environment variables for configuration and test across environments.
5. Orchestrate with state machines, not function chaining: Step Functions give visual workflows, built-in error handling and retries, execution history, parallel and sequential execution, and service integrations without code.
6. Use events to trigger transactions: favor event-driven flows such as S3 event notifications and EventBridge rules over synchronous request and response, for loose coupling, asynchronous processing, fault tolerance and independent scaling.
7. Design for failures and duplicates: make operations idempotent by checking a DynamoDB record before processing an SQS message, and retry with exponential backoff.

Use it when building serverless applications with Lambda, designing event-driven architectures, implementing microservices, creating asynchronous processing workflows, orchestrating multi-service transactions, building real-time data pipelines, implementing saga patterns for distributed transactions, or designing for scale and resilience. It applies to serverless APIs, REST APIs and async workflows.

It should be used only when the task clearly matches its upstream source and project context. Verify commands, generated code, dependencies, credentials and external service behavior before applying changes, and do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions. When using CDK examples, avoid hardcoding resource names such as restApiName or eventBusName; let CDK generate unique names so stacks are reusable and can deploy in parallel.

Inputs are the workload requirements and event sources. Outputs are CDK and TypeScript designs and handlers. Two reference files hold detailed patterns. references/eda-patterns.md covers an event router with EventBridge (custom event bus, schema registry, rule-based routing), queue-based processing with SQS (standard and FIFO, DLQ, Lambda consumers), pub/sub fan-out with SNS and SQS (multiple consumers, filtering), the saga pattern with Step Functions (compensating actions) and event sourcing with DynamoDB Streams (append-only store, projections). references/serverless-patterns.md covers API-driven microservices, stream processing with Kinesis (real-time, batch windowing, bisect on error), async task processing with SQS, scheduled jobs with EventBridge cron or rate schedules and webhook processing with signature validation and async queue forwarding.

Best-practice guidance includes returning partial batch failures from SQS handlers so only failed records are retried, and always configuring dead letter queues with monitoring on their depth:

const dlq = new sqs.Queue(this, 'DLQ', {
  retentionPeriod: Duration.days(14),
});

const queue = new sqs.Queue(this, 'Queue', {
  deadLetterQueue: {
    queue: dlq,
    maxReceiveCount: 3,
  },
});

For observability, enable active X-Ray tracing and use Lambda Powertools settings such as a service name, metrics namespace and log level. Four more references cover security (shared responsibility, IAM least privilege, encryption, VPC network security), observability (metrics, logs and traces, structured logging, X-Ray, alarms and dashboards), performance (cold start optimization, memory and CPU tuning, package size reduction, provisioned concurrency) and deployment (CI/CD design, unit, integration and load testing, canary and blue/green strategies, rollback mechanisms).

It works with AWS Lambda, DynamoDB, S3, SQS, SNS, EventBridge, Step Functions, Kinesis, ElastiCache, X-Ray, CloudWatch and AWS CDK, alongside the AWS Well-Architected Serverless Lens and ServerlessLand patterns.

It suits cloud and backend engineers designing serverless and event-driven systems on AWS who want Well-Architected principles, tested patterns and anti-patterns to avoid.