playbooks

home / skills / shotaiuchi / dotclaude / aws-sam

aws-sam skill

/dotclaude/skills/aws-sam

This skill helps you design, test, and deploy AWS SAM serverless apps with best practices for templates, functions, and local debugging.

npx playbooks add skill shotaiuchi/dotclaude --skill aws-sam

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.0 KB
---
name: AWS SAM
description: Skill for AWS SAM serverless application development, Lambda function implementation, template design, local testing, and deployment.
references:
  - path: ../../references/services/aws/conventions.md
  - path: ../../references/services/aws/sam-architecture-patterns.md
external:
  - id: aws-sam-docs
    url: https://docs.aws.amazon.com/serverless-application-model/
  - id: aws-lambda-docs
    url: https://docs.aws.amazon.com/lambda/
  - id: aws-api-gateway
    url: https://docs.aws.amazon.com/apigateway/
  - id: lambda-powertools-python
    url: https://docs.powertools.aws.dev/lambda/python/
---

**Always respond in Japanese.**

# AWS SAM (Serverless Application Model)

AWS SAM is an IaC framework for building serverless applications.

Read and apply the patterns from the referenced documents to the user's implementation task.

## Reference Documents

- [AWS SAM Project Conventions](../../references/services/aws/conventions.md)
- [Architecture Patterns](../../references/services/aws/sam-architecture-patterns.md)

Overview

This skill provides hands-on guidance for AWS SAM serverless application development, focusing on Lambda function implementation, SAM template design, local testing, and deployment automation. It helps you structure projects, create reusable templates, and streamline CI/CD for serverless workloads using shell-based workflows. The goal is to accelerate reliable, production-ready serverless deployments with clear conventions.

How this skill works

The skill inspects your project layout and SAM templates to validate resource definitions, runtime settings, and packaging configuration. It suggests improvements for function handlers, IAM least-privilege, environment configuration, and event sources. It also outlines local testing steps with sam local, build and package commands, and deployment patterns for repeatable, automated releases.

When to use it

  • Starting a new serverless project on AWS using Lambda, API Gateway, DynamoDB, or S3 triggers
  • Refactoring an existing SAM template to follow best-practice conventions and modular structure
  • Setting up local testing and debugging workflows using sam local and Docker
  • Automating build/package/deploy in CI pipelines with shell scripts and SAM CLI
  • Designing multi-environment deployments (dev/stage/prod) with parameter overrides

Best practices

  • Organize functions and shared code in clear directories and keep templates modular with nested stacks
  • Define explicit IAM roles per function to enforce least privilege and avoid wildcard policies
  • Use sam build and sam package/artifact storage (S3) in CI, keeping builds reproducible
  • Test locally with sam local invoke and sam local start-api using Docker that matches runtime
  • Manage environment-specific values with Parameters, Mappings, or separate parameter files

Example use cases

  • Create a REST API backed by Lambda and DynamoDB with a SAM template and local test harness
  • Migrate monolithic functions into smaller handlers, updating templates to use separate IAM roles
  • Implement event-driven processing from S3 or SNS with retry and dead-letter configurations
  • Add CI steps: sam build, sam package to S3, and sam deploy in a shell-based pipeline
  • Set up multiple stages with parameterized templates and per-stage deployment buckets

FAQ

Do I need Docker to test locally?

Yes—use Docker so sam local can emulate Lambda runtimes accurately for invoke and API testing.

How should I manage secrets and environment variables?

Keep secrets out of templates; use Parameter Store, Secrets Manager, or encrypted deployment artifacts and reference them via secure parameters.

Can I deploy multiple environments from one template?

Yes—use Parameters or separate parameter files and distinct S3 buckets/stacks per environment to avoid cross-environment interference.