AWS Architect

---
name: aws-architect
description: |
  Trigger when the user asks to architect on AWS, pick between AWS services,
  or review an AWS design. Phrases: "AWS architecture", "ECS vs Lambda",
  "RDS vs DynamoDB", "which AWS service", "AWS design review".
allowed-tools:
  - Read
  - Write
---

# AWS Architect

Pick the right AWS services and patterns for a workload. Focus on the
decision rules that actually matter at startup-to-growth scale, not
enterprise overengineering.

## Prerequisites

- Workload characteristics understood (traffic shape, data volume, compliance)
- Budget awareness

## Steps

1. **Compute: four real options.** Pick one:
   - **Lambda** - unpredictable or spiky traffic, simple handlers, stateless
   - **ECS Fargate** - long-running or moderately sized workloads, container-native
   - **EKS** - you already have Kubernetes expertise and need portability
   - **EC2** - you need something Lambda/ECS can't give (GPUs, specific kernel)

   Skip EC2 unless you have a concrete reason.

2. **Database: three real options.**
   - **RDS Postgres** - default. Everything starts here. Multi-AZ for prod.
   - **DynamoDB** - when you know the access patterns ahead of time and
     scale matters. Not when you need flexible queries.
   - **Aurora Serverless v2** - if you want RDS without the sizing decisions.
     Costs more at steady-state than provisioned.

   Start with RDS. Migrate to DynamoDB only when you have a specific reason.

3. **Storage tiers match access patterns.**
   - **S3 Standard** - frequent access
   - **S3 Intelligent-Tiering** - mixed access, let AWS decide
   - **S3 Glacier Deep Archive** - regulatory archive you'll never read

   Never leave large buckets on Standard without tiering rules. 80% of S3
   bill reviews find a forgotten bucket that could move to IA.

4. **Networking: VPC with public + private subnets, NAT for egress.**
   - Keep databases in private subnets, period.
   - Use VPC endpoints for S3 and DynamoDB to avoid NAT costs.
   - Transit Gateway when you have 3+ VPCs to connect.

5. **Auth and secrets:**
   - **Secrets Manager** for app secrets. KMS-encrypted, rotation available.
   - **SSM Parameter Store** for config that's not secret.
   - **Cognito** for end-user auth only if you're committed; it has
     sharp edges. Many teams end up back on Auth0/Clerk.

6. **Observability:**
   - CloudWatch Logs for logs (set retention; indefinite default is expensive).
   - CloudWatch Metrics + alarms for the basics.
   - X-Ray for tracing (or third-party like Honeycomb, Datadog).

## Cost mistakes to catch

- NAT Gateway data-processing costs (use VPC endpoints)
- CloudWatch Logs with no retention policy
- EBS volumes of terminated instances
- Elastic IPs not attached to running instances
- Unrealistic Lambda memory settings (too low = slow = expensive)

## Output

- Architecture diagram with services labeled
- Cost estimate at expected scale
- IaC (Terraform or CDK) for the design
- Decision log explaining why each service was chosen