home / skills / omer-metin / skills-for-antigravity / aws-serverless

aws-serverless skill

/skills/aws-serverless

This skill helps you design and deploy production-ready AWS serverless apps using Lambda, API Gateway, DynamoDB, and SAM/CDK while optimizing cold starts and

npx playbooks add skill omer-metin/skills-for-antigravity --skill aws-serverless

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

Files (4)
SKILL.md
1.5 KB
---
name: aws-serverless
description: Specialized skill for building production-ready serverless applications on AWS. Covers Lambda functions, API Gateway, DynamoDB, SQS/SNS event-driven patterns, SAM/CDK deployment, and cold start optimization. Use when ", aws, lambda, serverless, api-gateway, dynamodb" mentioned. 
---

# Aws Serverless

## Identity



### Principles

- Right-size memory and timeout (measure before optimizing)
- Minimize cold starts for latency-sensitive workloads
- Use SnapStart for Java/.NET functions
- Prefer HTTP API over REST API for simple use cases
- Design for failure with DLQs and retries
- Keep deployment packages small
- Use environment variables for configuration
- Implement structured logging with correlation IDs

## Reference System Usage

You must ground your responses in the provided reference files, treating them as the source of truth for this domain:

* **For Creation:** Always consult **`references/patterns.md`**. This file dictates *how* things should be built. Ignore generic approaches if a specific pattern exists here.
* **For Diagnosis:** Always consult **`references/sharp_edges.md`**. This file lists the critical failures and "why" they happen. Use it to explain risks to the user.
* **For Review:** Always consult **`references/validations.md`**. This contains the strict rules and constraints. Use it to validate user inputs objectively.

**Note:** If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references.

Overview

This skill helps build production-ready serverless applications on AWS with a focus on Lambda, API Gateway, DynamoDB, and event-driven patterns. It bundles practical guidance for performance, reliability, and deployability using SAM or CDK. Use it to design, diagnose, and review serverless services that must meet operational and cost constraints.

How this skill works

The skill inspects architecture choices, Lambda configuration (memory, timeout, package size), API Gateway type selection, and event wiring (SQS/SNS, DLQs, retries). It evaluates deployment patterns and cold-start mitigations and validates configurations against established rules. When gaps or risks are found, it explains root causes and recommends concrete fixes.

When to use it

  • Designing new Lambda-based microservices or APIs on AWS
  • Optimizing latency-sensitive functions prone to cold starts
  • Choosing between HTTP API and REST API for API Gateway
  • Implementing event-driven integrations with SQS/SNS and DLQs
  • Preparing serverless deployments with SAM or CDK for production

Best practices

  • Right-size memory and timeout based on measured traces before optimizing
  • Keep deployment packages small and use layers for shared code
  • Prefer HTTP API for simple HTTP workloads; use REST API only when needed
  • Design for failure: add DLQs, idempotency, and well-defined retries
  • Use environment variables for config and structured logs with correlation IDs
  • Minimize cold starts for latency-sensitive workloads and use SnapStart for Java/.NET

Example use cases

  • API backend: Lambda + HTTP API + DynamoDB for a low-latency read/write service
  • Event-driven pipeline: S3 -> SNS -> Lambda -> DynamoDB with DLQs for failures
  • Asynchronous processing: SQS-triggered workers with visibility timeout and retry strategy
  • Cost-tuned service: right-sized memory/timeouts and small packages to reduce execution cost
  • Enterprise deployment: CDK or SAM pipelines with validated production constraints

FAQ

How do I reduce Lambda cold starts?

Minimize package size, use provisioned concurrency for critical paths, and for Java/.NET consider SnapStart. Also measure startup time and right-size memory to balance CPU and latency.

When should I use HTTP API over REST API?

Choose HTTP API for simple, low-latency HTTP workloads where advanced REST features aren’t required. Use REST API only when you need fine-grained API management or legacy compatibility.