AutoGineer
Generated banner for AWS Lambda
Generated logo for AWS Lambda

AWS Lambda

AWS LabsOfficialPublished by AWS Labs

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Low risk
Download ZIP

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

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/awslabs/aws-lambda/download

  2. 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:

ResourceLimit
Function timeout900 seconds (15 minutes)
Memory128 MB – 10,240 MB
1 vCPU equivalent1,769 MB memory
Synchronous payload (request + response)6 MB each
Async invocation payload1 MB
Streamed response200 MB
Deployment package (.zip, uncompressed)250 MB
Deployment package (.zip upload, compressed)50 MB
Container image10 GB
Layers per function5
Environment variables (aggregate)4 KB
/tmp ephemeral storage512 MB – 10,240 MB
Account concurrent executions (default)1,000 (requestable increase)
Burst scaling rate1,000 new executions per 10 seconds

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

Troubleshooting Quick Reference

ErrorCauseSolution
Build FailedMissing dependenciesRun sam_build with use_container: true
Stack is in ROLLBACK_COMPLETEPrevious deploy failedDelete stack with aws cloudformation delete-stack, redeploy
IteratorAge increasingStream consumer falling behindIncrease ParallelizationFactor and BatchSize. Use esm_optimize
EventBridge events silently droppedNo DLQ, retries exhaustedAdd RetryPolicy + DeadLetterConfig to rule target
Step Functions failing silentlyNo retry on Task stateAdd Retry with Lambda.ServiceException, Lambda.AWSLambdaException
Durable Function not resumingMissing IAM permissionsAdd 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

  1. Install SAM CLI: Follow the SAM CLI installation guide

  2. Verify: Run sam --version

Container Runtime Setup

  1. Install a Docker compatible container runtime: Required for sam_local_invoke and container-based builds

  2. 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

references/web-app-deployment.md

Web Application Deployment Guide

Overview

Deploy web applications to AWS Serverless using the deploy_webapp tool and Lambda Web Adapter. This covers backend APIs, static frontends, and full-stack applications — from endpoint selection through custom domains and frontend updates.

Deployment Types

Choose the deployment type based on your application:

TypeUse CaseWhat Gets Created
backendAPI services, microservicesLambda + API Gateway
frontendStatic sites, SPAsS3 + CloudFront
fullstackComplete web appsLambda + API Gateway + S3 + CloudFront

API Endpoint Options

OptionBest ForNotes
HTTP API (API Gateway v2)Most REST/HTTP APIs70% cheaper than REST API, lower latency
REST API (API Gateway v1)APIs needing WAF, caching, usage plans, request transformsMore features, higher cost
Lambda Function URLSimple HTTPS endpoints, webhooks, single-function APIsNo API Gateway; free (pay only for Lambda). Supports streaming.
Application Load BalancerHigh-traffic APIs with mixed Lambda/container targets, existing ALBFixed hourly cost; efficient at high request volumes
Lambda Function URLs

The simplest option for a single Lambda function that needs an HTTPS endpoint:

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    FunctionUrlConfig:
      AuthType: AWS_IAM   # or NONE for public endpoints
      Cors:
        AllowOrigins:
          - "https://myapp.example.com"

Use AuthType: NONE only for public webhook receivers or assets where you handle auth in the function. For internal services, use AWS_IAM and sign requests with SigV4.

Prefer Function URLs over API Gateway when:

  • Serving payloads larger than 10 MB (API Gateway's response limit)

  • Handling requests longer than 29 seconds (API Gateway's integration timeout)

  • Building a Lambdalith where per-endpoint metrics are managed in-code

  • Internal service-to-service calls authenticated with AWS_IAM

Prefer API Gateway when:

  • You need per-endpoint CloudWatch metrics without custom instrumentation

  • You require Cognito authorizers, usage plans, API keys, or request validation

  • You are exposing WebSocket APIs

  • You want WAF integration at the API level

CORS

Configure CORS on the API Gateway for browser-based frontend access:

  • Set AllowOrigin to your frontend domain in production (avoid *)

  • Include necessary headers: Content-Type, Authorization, X-Api-Key

  • Set appropriate MaxAge for preflight caching

Custom Domains

Use the configure_domain tool to set up custom domains with:

  • ACM certificate (must be in us-east-1 for CloudFront)

  • Route 53 DNS record

  • API Gateway base path mapping

Lambda Web Adapter

Lambda Web Adapter allows standard web frameworks to run on Lambda without code changes. The deploy_webapp tool automatically configures it.

How it works:

  • Adds the Lambda Web Adapter layer to your function

  • Sets AWS_LAMBDA_EXEC_WRAPPER to /opt/bootstrap

  • Configures the PORT environment variable for your application

  • Your framework listens on that port as it would normally

Custom startup: For applications needing pre-start steps (migrations, config loading), provide a startup script that runs setup commands before exec-ing your application.

Supported backend frameworks: Express.js, FastAPI, Flask, Spring Boot, ASP.NET Core, Gin

Supported frontend frameworks: React, Vue.js, Angular, Next.js, Svelte

Project Structure

Backend-Only
my-backend/
├── src/
│   ├── app.js          # Express application
│   ├── routes/         # API routes
│   └── middleware/     # Custom middleware
├── package.json
└── Dockerfile          # Optional
Frontend-Only
my-frontend/
├── dist/               # Built assets
│   ├── index.html
│   └── assets/
└── package.json
Full-Stack
my-fullstack-app/
├── frontend/
│   ├── dist/           # Built frontend
│   └── package.json
├── backend/
│   ├── src/
│   └── package.json
└── deployment-config.json

Frontend Updates

Use update_webapp_frontend to push new frontend assets to S3 and optionally invalidate the CloudFront cache. For zero-downtime updates, use content-hashed filenames so old and new assets can coexist.

Database Integration

RDS with Lambda

  • Place Lambda in VPC with private subnets for RDS access

  • Use VPC endpoints to avoid NAT Gateway costs for AWS service calls

  • Set connection pool max to 1 per Lambda instance — but note that Lambda Managed Instances handle multiple concurrent requests, so use a proper connection pool there

  • Store connection strings in Secrets Manager

For DynamoDB optimization (billing, key design, query patterns), see optimization.md.

Environment Management

Use samconfig.toml environment-specific sections for multi-environment deployments. See sam-project-setup.md for configuration details.

Store environment-specific secrets in Secrets Manager or SSM Parameter Store, referenced by environment name.

Authentication & Authorization

Choosing an Auth Approach
ApproachBest ForAPI Type
Cognito User Pools + JWT authorizerUser sign-up/sign-in for your own appHTTP API (v2)
Cognito User Pools + Cognito authorizerSame, with built-in token validationREST API (v1)
Lambda authorizer (token-based)Custom auth logic, third-party IdPsBoth
Lambda authorizer (request-based)Multi-source auth (headers, query, IP)Both
IAM authorizationService-to-service, internal APIsBoth + Function URLs
API keys + usage plansRate limiting third-party API consumersREST API (v1) only
Cognito User Pools vs Identity Pools

  • User Pools = authentication (who are you?). Handles sign-up, sign-in, MFA, and issues JWT tokens. This is what most web APIs need.

  • Identity Pools = authorization (what AWS resources can you access?). Exchanges tokens (from User Pools, Google, Facebook) for temporary AWS credentials. Use this when clients need direct AWS access (S3 upload from browser, IoT).

Most API backends only need User Pools + a JWT or Cognito authorizer on API Gateway.

JWT Authorizer (HTTP API)

The simplest and cheapest option for HTTP APIs backed by Cognito:

MyCognitoUserPool:
  Type: AWS::Cognito::UserPool

MyCognitoUserPoolClient:
  Type: AWS::Cognito::UserPoolClient
  Properties:
    UserPoolId: !Ref MyCognitoUserPool
    ExplicitAuthFlows:
      - ALLOW_USER_SRP_AUTH
      - ALLOW_REFRESH_TOKEN_AUTH

MyApi:
  Type: AWS::Serverless::HttpApi
  Properties:
    Auth:
      DefaultAuthorizer: MyCognitoAuth
      Authorizers:
        MyCognitoAuth:
          AuthorizationScopes:
            - email
          IdentitySource: $request.header.Authorization
          JwtConfiguration:
            issuer: !Sub "https://cognito-idp.${AWS::Region}.amazonaws.com/${MyCognitoUserPool}"
            audience:
              - !Ref MyCognitoUserPoolClient

JWT authorizers validate the token signature and claims at the API Gateway level — no Lambda invocation needed for auth. This is free (no extra cost beyond HTTP API pricing).

Lambda Authorizer

Use Lambda authorizers when you need custom auth logic: validating tokens from a third-party IdP, checking database-backed permissions, or combining multiple auth signals.

Token-based authorizers receive only the Authorization header. Request-based authorizers receive the full request (headers, query string, path, IP) — use these when auth depends on more than just a bearer token.

MyApi:
  Type: AWS::Serverless::Api
  Properties:
    Auth:
      DefaultAuthorizer: MyLambdaAuth
      Authorizers:
        MyLambdaAuth:
          FunctionArn: !GetAtt AuthFunction.Arn
          FunctionPayloadType: TOKEN
          Identity:
            Header: Authorization
            ReauthorizeEvery: 300  # Cache auth result for 5 minutes

Set ReauthorizeEvery > 0 to cache authorization results and avoid invoking the authorizer Lambda on every request. A value of 300 (5 minutes) is a reasonable default.

API Keys and Usage Plans

API keys are for tracking and throttling third-party API consumers — they are not an authentication mechanism. Always combine API keys with a proper authorizer.

MyApi:
  Type: AWS::Serverless::Api
  Properties:
    Auth:
      ApiKeyRequired: true
      UsagePlan:
        CreateUsagePlan: PER_API
        Throttle:
          BurstLimit: 100
          RateLimit: 50
        Quota:
          Limit: 10000
          Period: MONTH

API keys and usage plans are REST API (v1) only. HTTP APIs do not support them.

Auth Best Practices

  • [ ] Use JWT authorizers with HTTP API for most web applications — cheapest, lowest latency

  • [ ] Cache Lambda authorizer results (ReauthorizeEvery > 0) to avoid per-request invocations

  • [ ] Never use API keys as the sole authentication mechanism — they are for usage tracking, not identity

  • [ ] Use IAM authorization (SigV4) for service-to-service calls, not shared API keys

  • [ ] Store JWT client IDs and secrets in SSM Parameter Store, not in template literals

Performance

  • Caching: Use CloudFront caching for static assets. Disable caching for API paths.

  • Response streaming: For LLM/AI responses, large payloads (> 6 MB), or long-running operations, use Lambda response streaming to reduce TTFB. See optimization.md for configuration.

For cold start optimization, memory right-sizing, and connection pooling, see optimization.md.

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

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