AWS Lambda

AWS LabsOfficialPublished by AWS Labs

Skill
Tool integration
Cloud and DevOps
Apache-2.0
Low risk

From the author

Design, build, deploy, test, and debug serverless applications with AWS Lambda. Triggers on phrases like: Lambda function, event source, serverless application, API Gateway, EventBridge, Step Functions, serverless API, event-driven architecture, Lambda trigger. For deploying non-serverless apps to AWS, use deploy-on-aws plugin instead.

— the description by AWS Labs

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides comprehensive support for developing serverless applications on AWS. It integrates with the AWS Serverless MCP Server to assist with project initialization, infrastructure-as-code (IaC) generation, deployment, and debugging. It covers event-driven architectures, web application deployment via Lambda Web Adapter, and performance optimization, while enforcing best practices for security, idempotency, and observability.

What it does

Initializes and builds serverless projects using SAM CLI or CDK.
Configures event source mappings for services like DynamoDB, SQS, and Kinesis.
Deploys full-stack web applications using the Lambda Web Adapter.
Implements event-driven architectures with EventBridge and schema management.
Provides troubleshooting guidance for common deployment and runtime errors.
Enforces security best practices including least-privilege IAM and secret management.

When to use it

When starting a new serverless project on AWS.
When configuring event-driven triggers for Lambda functions.
When deploying web APIs or full-stack applications to AWS Lambda.
When optimizing Lambda performance, cost, or cold-start times.
When debugging deployment failures or runtime errors in serverless stacks.

Advantages

Automated validation of IaC templates via SAM CLI integration.
Built-in support for AWS Lambda Powertools for logging and idempotency.
Clear guidance on choosing between choreography and orchestration patterns.
Comprehensive troubleshooting and limit references for rapid debugging.
Standardized project setup using industry-recognized frameworks.

Usage examples

“Create a new serverless API project using TypeScript and CDK.”: The agent will initialize a new project structure, generate the necessary CDK constructs for an API Gateway and Lambda function, and set up the project configuration.
“How do I configure my Lambda to process messages from an SQS queue?”: The agent will provide the configuration steps for an Event Source Mapping, including best practices for batch sizes and partial failure handling.
“My Lambda function is failing with a timeout error, how can I debug it?”: The agent will guide you through checking CloudWatch logs, reviewing memory settings, and potentially using X-Ray tracing to identify the bottleneck.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/awslabs/aws-lambda/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip aws-lambda.zip -d .agents/skills

Documentation by AWS Labs

AWS Lambda Serverless Development

Design, build, deploy, and debug serverless applications with AWS serverless services. This skill provides access to serverless development guidance through the AWS Serverless MCP Server, helping you to build production-ready serverless applications with best practices built-in.

Use SAM CLI for project initialization and deployment, Lambda Web Adapter for web applications, or Event Source Mappings for event-driven architectures. AWS handles infrastructure provisioning, scaling, and monitoring automatically.

Key capabilities:

SAM CLI Integration: Initialize, build, deploy, and test serverless applications
Web Application Deployment: Deploy full-stack applications with Lambda Web Adapter
Event Source Mappings: Configure Lambda triggers for DynamoDB, Kinesis, SQS, Kafka
Lambda durable functions: Resilient multi-step applications with checkpointing — see the durable-functions skill for guidance
Lambda Managed Instances: Run Lambda on dedicated EC2 instances with managed lifecycle — see the managed-instances skill for evaluation, configuration, and migration guidance
Schema Management: Type-safe EventBridge integration with schema registry
Observability: CloudWatch logs, metrics, and X-Ray tracing
Performance Optimization: Right-sizing, cost optimization, and troubleshooting

When to Load Reference Files

Load the appropriate reference file based on what the user is working on:

Getting started, what to build, project type decision, or working with existing projects -> see references/getting-started.md
SAM, CDK, deployment, IaC templates, CDK constructs, or CI/CD pipelines -> see the aws-serverless-deployment skill (separate skill in this plugin)
Web app deployment, Lambda Web Adapter, API endpoints, CORS, authentication, custom domains, or sam local start-api -> see references/web-app-deployment.md
Event sources, DynamoDB Streams, Kinesis, SQS, Kafka, S3 notifications, or SNS -> see references/event-sources.md
EventBridge, event bus, event patterns, event design, Pipes, or schema registry -> see references/event-driven-architecture.md
Durable functions, checkpointing, replay model, saga pattern, or long-running Lambda workflows -> see the durable-functions skill (separate skill in this plugin with full SDK reference, testing, and deployment guides)
Lambda Managed Instances, LMI, capacity providers, multi-concurrency, EC2-backed Lambda, cold start elimination, or Lambda cost optimization with Reserved Instances -> see the managed-instances skill (separate skill in this plugin for evaluation, configuration, and migration)
Orchestration, workflows, or Durable Functions vs Step Functions -> see references/orchestration-and-workflows.md
Step Functions, ASL, state machines, JSONata, Distributed Map, SDK integrations, TestState API, mocking service integrations, or state machine unit tests -> see the aws-step-functions skill for comprehensive guidance
Observability, logging, tracing, metrics, alarms, or dashboards -> see references/observability.md
Optimization, cold starts, memory tuning, cost, or streaming -> see references/optimization.md
Powertools, idempotency, feature flags, parameters, parser, batch processing, or data masking -> see references/powertools.md
Troubleshooting, errors, debugging, or deployment failures -> see references/troubleshooting.md

Best Practices

Project Setup

Do: Use sam_init or cdk init with an appropriate template for your use case
Do: Set global defaults for timeout, memory, runtime, and tracing (Globals in SAM, construct props in CDK)
Do: Use AWS Lambda Powertools for structured logging, tracing, metrics (EMF), idempotency, and batch processing — available for Python, TypeScript, Java, and .NET
Don't: Copy-paste templates from the internet without understanding the resource configuration
Don't: Use the same memory and timeout values for all functions regardless of workload

Security

Do: Follow least-privilege IAM policies scoped to specific resources and actions
Do: Use secure_esm_* tools to generate correct IAM policies for event source mappings
Do: Store secrets in AWS Secrets Manager or SSM Parameter Store, never in environment variables
Do: Use VPC endpoints instead of NAT Gateways for AWS service access when possible
Do: Enable Amazon GuardDuty Lambda Protection to monitor function network activity for threats (cryptocurrency mining, data exfiltration, C2 callbacks)
Don't: Use wildcard (*) resource ARNs or actions in IAM policies
Don't: Hardcode credentials or secrets in application code or templates
Don't: Store user data or sensitive information in module-level variables — execution environments can be reused across different callers

Idempotency

Do: Write idempotent function code — Lambda delivers events at least once, so duplicate invocations must be safe
Do: Use the AWS Lambda Powertools Idempotency utility (backed by DynamoDB) for critical operations
Do: Validate and deduplicate events at the start of the handler before performing side effects
Don't: Assume an event will only ever be processed once

For topic-specific best practices, see the dedicated guide files in the reference table above.

Lambda Limits Quick Reference

Limits that developers commonly hit:

Resource	Limit
Function timeout	900 seconds (15 minutes)
Memory	128 MB – 10,240 MB
1 vCPU equivalent	1,769 MB memory
Synchronous payload (request + response)	6 MB each
Async invocation payload	1 MB
Streamed response	200 MB
Deployment package (.zip, uncompressed)	250 MB
Deployment package (.zip upload, compressed)	50 MB
Container image	10 GB
Layers per function	5
Environment variables (aggregate)	4 KB
`/tmp` ephemeral storage	512 MB – 10,240 MB
Account concurrent executions (default)	1,000 (requestable increase)
Burst scaling rate	1,000 new executions per 10 seconds

Check Service Quotas for your account limits: aws lambda get-account-settings

Troubleshooting Quick Reference

Error	Cause	Solution
`Build Failed`	Missing dependencies	Run `sam_build` with `use_container: true`
`Stack is in ROLLBACK_COMPLETE`	Previous deploy failed	Delete stack with `aws cloudformation delete-stack`, redeploy
`IteratorAge` increasing	Stream consumer falling behind	Increase `ParallelizationFactor` and `BatchSize`. Use `esm_optimize`
EventBridge events silently dropped	No DLQ, retries exhausted	Add `RetryPolicy` + `DeadLetterConfig` to rule target
Step Functions failing silently	No retry on Task state	Add `Retry` with `Lambda.ServiceException`, `Lambda.AWSLambdaException`
Durable Function not resuming	Missing IAM permissions	Add `lambda:CheckpointDurableExecution` and `lambda:GetDurableExecutionState` — see durable-functions skill

For detailed troubleshooting, see references/troubleshooting.md.

Configuration

AWS CLI Setup

This skill requires that AWS credentials are configured on the host machine:

Verify access: Run aws sts get-caller-identity to confirm credentials are valid

SAM CLI Setup

Install SAM CLI: Follow the SAM CLI installation guide
Verify: Run sam --version

Container Runtime Setup

Install a Docker compatible container runtime: Required for sam_local_invoke and container-based builds
Verify: Use an appropriate command such as docker --version or finch --version

MCP Server Configuration

Write access is enabled by default. The plugin ships with --allow-write in .mcp.json, so the MCP server can create projects, generate IaC, and deploy on behalf of the user.

Access to sensitive data (like Lambda and API Gateway logs) is not enabled by default. To grant it, add --allow-sensitive-data-access to .mcp.json.

SAM Template Validation Hook

This plugin includes a PostToolUse hook that runs sam validate automatically after any edit to template.yaml or template.yml. If validation fails, the error is returned as a system message so you can fix it immediately. The hook requires SAM CLI and jq to be installed; if either is missing, validation is skipped with a system message. Users can disable it via /hooks.

Verify: Run jq --version

Language selection

Default: TypeScript

Override syntax:

"use Python" → Generate Python code
"use JavaScript" → Generate JavaScript code

When not specified, ALWAYS use TypeScript

IaC framework selection

Default: CDK

Override syntax:

"use CloudFormation" → Generate YAML templates
"use SAM" → Generate YAML templates

When not specified, ALWAYS use CDK

Serverless MCP Server Unavailable

Inform user: "AWS Serverless MCP not responding"
Ask: "Proceed without MCP support?"
DO NOT continue without user confirmation

Resources

Files

ATTRIBUTION.mdAdded by AutoGineer906 B
LICENSELicence file added by AutoGineer9.9 KiB
NOTICELicence file added by AutoGineer89 B
SKILL.md12.1 KiB
references/event-driven-architecture.md15.6 KiB
references/event-sources.md16.3 KiB
references/getting-started.md6.0 KiB
references/observability.md22.7 KiB
references/optimization.md14.5 KiB
references/orchestration-and-workflows.md6.2 KiB
references/powertools.md10.2 KiB
references/troubleshooting.md11.3 KiB
references/web-app-deployment.md10.6 KiB

references/event-driven-architecture.md

Event-Driven Architecture Guide

Choreography vs Orchestration

The most important architectural decision in an event-driven system is whether services coordinate through choreography or orchestration.

	Choreography	Orchestration
How it works	Services emit events; other services react independently	A central coordinator (Step Functions, Durable Functions) directs each step
Coupling	Loose — publisher doesn't know about consumers	Tighter — coordinator knows about each step
Visibility	Distributed; hard to see the full flow	Centralized; execution history in one place
Failure handling	Each service handles its own failures	Central error handling and retry logic
Best for	Independent services reacting to facts about the world	Business-critical workflows requiring audit trails, visibility, and reliable sequencing

Use choreography (EventBridge + Lambda) when services are genuinely independent and don't need to know the outcome of each other's processing.

Use orchestration (Step Functions / Lambda durable functions) when you need reliable sequencing, compensating transactions, human approval steps, or the ability to visualize and debug the full workflow.

In practice, most systems use both: orchestration within a bounded context, choreography between bounded contexts.

EventBridge Concepts

Event Bus Types

Type	Use Case
Default bus	Receives AWS service events (EC2 state changes, S3 events, CodePipeline, etc.)
Custom bus	Your application events; recommended for all custom event routing
Partner bus	Receives events from SaaS partners (Datadog, Zendesk, Stripe, etc.)

Always use a custom event bus for application events — keeps your events separate from AWS service noise and simplifies IAM and monitoring.

Standard EventBridge Event Structure

Every event on the bus has this envelope (added automatically by EventBridge):

{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "source": "com.mycompany.orders",
  "detail-type": "OrderPlaced",
  "account": "123456789012",
  "time": "2025-01-15T10:30:00Z",
  "region": "us-east-1",
  "resources": [],
  "detail": {
    "orderId": "ord-987",
    "userId": "usr-123",
    "total": 49.99
  }
}

source — identifies the publishing service (com.mycompany.orders)
detail-type — identifies the event type (OrderPlaced)
detail — your business payload (up to 1 MB per event entry)

SAM Configuration

Custom event bus:

OrderEventBus:
  Type: AWS::Events::EventBus
  Properties:
    Name: order-events

OrderEventBusArn:
  Type: AWS::SSM::Parameter
  Properties:
    Name: /myapp/order-event-bus-arn
    Value: !GetAtt OrderEventBus.Arn
    Type: String

Lambda publishing events:

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Policies:
      - Statement:
          - Effect: Allow
            Action: events:PutEvents
            Resource: !GetAtt OrderEventBus.Arn
    Environment:
      Variables:
        EVENT_BUS_ARN: !GetAtt OrderEventBus.Arn

Lambda subscribing via rule:

ProcessOrderFunction:
  Type: AWS::Serverless::Function
  Properties:
    Events:
      OrderPlaced:
        Type: EventBridgeRule
        Properties:
          EventBusName: !Ref OrderEventBus
          Pattern:
            source:
              - com.mycompany.orders
            detail-type:
              - OrderPlaced
          RetryPolicy:
            MaximumRetryAttempts: 3
            MaximumEventAgeInSeconds: 3600
          DeadLetterConfig:
            Type: SQS
            QueueLogicalId: ProcessOrderDLQ

ProcessOrderDLQ:
  Type: AWS::SQS::Queue
  Properties:
    MessageRetentionPeriod: 1209600  # 14 days

Publishing Events from Lambda

Python:

import json
import os
from datetime import datetime, timezone
import uuid
import boto3
from aws_lambda_powertools import Logger

logger = Logger()
events_client = boto3.client("events")
event_bus_arn = os.environ["EVENT_BUS_ARN"]

def publish_order_placed(order: dict):
    events_client.put_events(
        Entries=[{
            "EventBusName": event_bus_arn,
            "Source": "com.mycompany.orders",
            "DetailType": "OrderPlaced",
            "Detail": json.dumps({
                "metadata": {
                    "id": str(uuid.uuid4()),
                    "version": "1",
                    "timestamp": datetime.now(timezone.utc).isoformat(),
                    "correlationId": logger.get_correlation_id(),
                    "service": "order-service",
                },
                "data": order,
            }),
        }]
    )

TypeScript:

import { EventBridgeClient, PutEventsCommand } from '@aws-sdk/client-eventbridge';
import { randomUUID } from 'crypto';

const client = new EventBridgeClient({});
const eventBusArn = process.env.EVENT_BUS_ARN!;

async function publishOrderPlaced(order: Record<string, unknown>): Promise<void> {
  await client.send(new PutEventsCommand({
    Entries: [{
      EventBusName: eventBusArn,
      Source: 'com.mycompany.orders',
      DetailType: 'OrderPlaced',
      Detail: JSON.stringify({
        metadata: {
          id: randomUUID(),
          version: '1',
          timestamp: new Date().toISOString(),
          service: 'order-service',
        },
        data: order,
      }),
    }],
  }));
}

Event Patterns (Content-Based Routing)

EventBridge rules use event patterns to filter which events reach a target. Patterns match against the standard envelope fields and anything inside detail.

All values are arrays — a field matches if the event value equals any element in the array:

{
  "source": ["com.mycompany.orders"],
  "detail-type": ["OrderPlaced", "OrderUpdated"],
  "detail": {
    "status": ["CONFIRMED"],
    "total": [{ "numeric": [">", 100] }]
  }
}

Common pattern operators:

Operator	Example	Matches
Exact match	`"status": ["ACTIVE"]`	status equals "ACTIVE"
Multiple values	`"status": ["ACTIVE", "PENDING"]`	status is either
Prefix	`"id": [{"prefix": "ord-"}]`	id starts with "ord-"
Anything-but	`"status": [{"anything-but": ["CANCELLED"]}]`	status is not "CANCELLED"
Exists	`"refundId": [{"exists": true}]`	refundId field is present
Numeric range	`"amount": [{"numeric": [">=", 0, "<", 1000]}]`	0 ≤ amount < 1000
Null	`"coupon": [null]`	coupon field is null

Up to 5 targets per rule. If you need to fan out to more consumers, route to an SNS topic or use the rule to fan out via SQS.

Event Design

Event Envelopes

Wrap your business payload in a custom metadata layer inside detail. This provides consistent fields for filtering, deduplication, and observability across all events regardless of the transport (EventBridge, SNS, SQS, Kinesis):

{
  "metadata": {
    "id": "01HXHMF28A94NS7NSHC5GM80F4",
    "version": "1",
    "timestamp": "2025-01-15T10:30:00Z",
    "domain": "orders",
    "service": "order-service",
    "correlationId": "req-abc123"
  },
  "data": {
    "orderId": "ord-987",
    "userId": "usr-123",
    "total": 49.99
  }
}

Key metadata fields:

id — unique event identifier; use for idempotency deduplication
version — schema version of the data payload
timestamp — when the event occurred (not when it was received)
correlationId — trace ID that flows through the entire request chain
domain / service — for filtering and observability

Light Events vs Rich Events

Light events carry only IDs and directly relevant fields. Consumers fetch additional data they need.

Rich events include expanded entities — the complete state of the object at the time of the event.

	Light events	Rich events
Payload size	Small	Large
Subscriber complexity	Higher (must hydrate)	Lower (self-contained)
Race conditions	Risk between event publish and data fetch	None
Coupling	Consumer coupled to publisher's API	Consumer coupled to event schema only

Guidance:

Within a bounded context (same team, same domain): light events are fine — you control both sides
Across bounded contexts (different teams, different domains): prefer rich events — unknown consumers shouldn't need to call back into your service to understand what happened

Event Versioning

Prefer the no-breaking-changes policy: always add new fields, never remove or rename existing fields, never change a field's type. Consumers that ignore unknown fields continue working without any changes.

When a breaking change is unavoidable, the cleanest approach is versioning in the detail-type:

OrderPlaced.v1   →   OrderPlaced.v2

Consumers subscribe to specific versions. The publisher emits both versions during the migration window, then retires v1 once all consumers have migrated.

Avoid: using Lambda versions/aliases or API Gateway stages to version event-driven integrations — IAM roles don't version alongside function versions, which creates subtle permission bugs.

Retry Policy and Dead-Letter Queues

EventBridge retries failed Lambda invocations with exponential backoff. Configure both RetryPolicy and a DLQ on every rule target that processes important events:

Events:
  OrderEvent:
    Type: EventBridgeRule
    Properties:
      Pattern:
        source: [com.mycompany.orders]
      RetryPolicy:
        MaximumRetryAttempts: 3         # 0–185; default 185
        MaximumEventAgeInSeconds: 3600  # 60–86400; default 86400 (24h)
      DeadLetterConfig:
        Type: SQS
        QueueLogicalId: MyDLQ

MaximumRetryAttempts — how many times EventBridge retries before sending to DLQ
MaximumEventAgeInSeconds — EventBridge stops retrying after this age, even if retries remain
Without a DLQ, events that exhaust retries are silently dropped

Process your DLQ actively. Set a CloudWatch alarm on ApproximateNumberOfMessagesVisible and reprocess events by replaying them back to the event bus.

Archive and Replay

EventBridge can archive all events (or a filtered subset) and replay them at any time. This is invaluable for:

Reprocessing events after deploying a bug fix
Bootstrapping new consumers with historical events
Disaster recovery

Create an archive in SAM:

OrderEventArchive:
  Type: AWS::Events::Archive
  Properties:
    SourceArn: !GetAtt OrderEventBus.Arn
    EventPattern:
      source:
        - com.mycompany.orders
    RetentionDays: 30

Replay from the console, CLI, or API by specifying the archive, a time range, and optionally a different target bus.

EventBridge Pipes

Pipes provide point-to-point integrations following a Source → Filter → Enrich → Target pattern. Use Pipes when you need to:

Connect a stream/queue source to a target with enrichment (e.g., add customer data before sending to Step Functions)
Filter events before they reach the target (you only pay for events that pass the filter)
Transform payloads without writing a Lambda function

OrderPipe:
  Type: AWS::Pipes::Pipe
  Properties:
    Source: !GetAtt OrderQueue.Arn
    SourceParameters:
      SqsQueueParameters:
        BatchSize: 10
    Filter:
      Filters:
        - Pattern: '{"body": {"eventType": ["ORDER_CREATED"]}}'
    Enrichment: !GetAtt EnrichOrderFunction.Arn
    Target: !Ref OrderProcessingStateMachine
    TargetParameters:
      StepFunctionStateMachineParameters:
        InvocationType: FIRE_AND_FORGET
    RoleArn: !GetAtt PipeRole.Arn

Pipes vs Rules:

Use Pipes for point-to-point (one source → one target) with enrichment or transformation
Use Rules for fan-out (one event → multiple targets) or when the source is the event bus itself

Schema Registry

The EventBridge Schema Registry discovers and stores schemas for events on your bus. Use it to generate typed code bindings and enforce contracts.

Discover schemas automatically by enabling schema discovery on your event bus:

OrderBusDiscovery:
  Type: AWS::EventSchemas::Discoverer
  Properties:
    SourceArn: !GetAtt OrderEventBus.Arn

Once events flow through the bus, schemas appear in the registry. Then use the MCP tools to work with them:

list_registries — browse available registries
search_schema with keywords (e.g., "order") — find relevant schemas
describe_schema — get the full schema definition
Download code bindings from the console (Java, Python, TypeScript) — generates typed event classes

Use schemas as contracts: consumer teams reference a specific schema version. The publisher must not make breaking changes to a versioned schema without bumping the version.

Push vs Poll

Pattern	Services	Characteristics
Push	EventBridge, SNS	Low latency; event delivered as soon as it occurs; minimal compute waste at low volume
Poll	SQS+ESM, Kinesis, DynamoDB Streams	Full throughput control; ordered processing; higher latency; better for batching

Choose push (EventBridge) when:

You need real-time fan-out to multiple independent consumers
Services are loosely coupled and don't need ordering guarantees
You want content-based routing without consumer-side filtering code

Choose poll (SQS/Kinesis) when:

You need strict ordering within a partition or message group
Consumer needs to control throughput (e.g., protect a downstream database)
You need large batch sizes for cost efficiency (e.g., bulk database writes)

Observability

For EventBridge metrics to alarm on, CloudWatch Logs Insights queries, and correlation ID propagation patterns, see observability.md.

Key principle: X-Ray traces Lambda execution but does not automatically connect publisher to consumer across the event bus. Propagate correlationId in the event metadata envelope (see Event Envelopes above) and use CloudWatch Logs Insights to reconstruct cross-service request chains.

Requirements and compatibility

Written for: Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter, Needs an MCP server

Security

What our scanner noticed· Low risk

Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

AWS Labs

Publisher

AWS Labs (Official)

Source

awslabs/agent-plugins · plugins/aws-serverless/skills/aws-lambda · commit fbefb37

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
NOTICE (added by AutoGineer from NOTICE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

AutoGineer is not affiliated with or endorsed by AWS Labs.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aws-lambda.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by AWS Labs

AWS Lambda Serverless Development

When to Load Reference Files

Best Practices

Project Setup

Security

Idempotency

Lambda Limits Quick Reference

Troubleshooting Quick Reference

Configuration

AWS CLI Setup

SAM CLI Setup

Container Runtime Setup

MCP Server Configuration

SAM Template Validation Hook

Language selection

IaC framework selection

Serverless MCP Server Unavailable

Resources

Files

references/event-driven-architecture.md

Event-Driven Architecture Guide

Choreography vs Orchestration

EventBridge Concepts

Event Bus Types

Standard EventBridge Event Structure

SAM Configuration

Publishing Events from Lambda

Event Patterns (Content-Based Routing)

Event Design

Event Envelopes

Light Events vs Rich Events

Event Versioning

Retry Policy and Dead-Letter Queues

Archive and Replay

EventBridge Pipes

Schema Registry

Push vs Poll

Observability

Requirements and compatibility

Security

Attribution and licence

Related skills

Modal

Cloud Infrastructure Network Engineer

Deployment Validation Cloud Architect

Airflow Dag Patterns

Cost Optimization

Hybrid Cloud Networking

Download ZIP