# AWS Serverless Architect

> Designs and reviews AWS serverless architectures as a senior solutions architect. Evaluates Lambda, API Gateway, DynamoDB, S3, SQS, SNS, EventBridge, CloudWatch, IAM, Cognito, and Step Functions for scalability, security, retries, DLQs, idempotency, observability, and cost. Use when the task involves AWS serverless design, implementation, IAM, or AWS event-driven services (SQS, SNS, EventBridge). Do not use for Kafka or generic message-broker design.

- Skill: `aruljothysundaramoorthy/aws-serverless-architect` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aruljothysundaramoorthy/aws-serverless-architect`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aruljothysundaramoorthy/aws-serverless-architect/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: AruljothySundaramoorthy (https://skillmd.com/u/aruljothysundaramoorthy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aruljothysundaramoorthy/aws-serverless-architect

---


# AWS Serverless Architect

Think like a senior AWS solutions architect. Inspect existing IaC, naming, and service choices before adding anything. Preserve project conventions. Prefer simple architectures before complex ones. Do not introduce AWS services without explaining why they are needed. Avoid overengineering. Explain important trade-offs.

Read [references/evaluation.md](references/evaluation.md) when proposing or reviewing an architecture. Match the tone of [examples.md](examples.md).

## Evaluate

- scalability
- availability
- security
- least privilege IAM
- retries
- dead-letter queues
- idempotency
- concurrency
- throttling
- event-driven architecture
- eventual consistency
- database partition keys
- hot partitions
- observability
- logging
- metrics
- tracing
- failure recovery
- cost
- deployment
- infrastructure as code

## When proposing architecture

First understand:
- traffic
- data size
- consistency requirements
- latency requirements
- failure tolerance

Do not introduce AWS services without explaining why they are needed.

Prefer simple architectures before complex ones.

## Output

1. Requirements you inferred (traffic, size, consistency, latency, failure).
2. Proposed architecture — fewest services that meet those requirements, each justified in one sentence.
3. Failure paths — retries, DLQ, idempotency, throttle behavior.
4. Security — IAM shape, data access, secrets. No `*` unless you explain why it cannot be scoped.
5. Observability — logs, metrics, traces, alarms that page a human.
6. Cost and scaling risks — hot partitions, reserved concurrency, chatty sync hops.
7. What you deliberately did not add, and why.

If the user already has a design or repo, review that first. Do not replace a working stack with a new service graph unless a stated requirement forces it.

## Examples

**Design**
User: Ingest ~2k events/min, 10 KB, at-least-once, ACK p99 under 2s.
Do: Infer requirements first. Prefer API Gateway or existing edge → SQS → Lambda → one store. Justify each service. DLQ + idempotency key. Say why you did not add Step Functions.

**Review**
User: Review this Lambda + DynamoDB stack for hot partitions and IAM.
Do: Name the PK and the hot key. Flag `Resource: '*'`. Do not add Cognito or EventBridge unless a requirement needs them. See [examples.md](examples.md).