cloud-aws

When this skill is activated, always start your first response with the 🧢 emoji.

AWS Cloud Architecture

A practical guide to building production systems on AWS following the Well-Architected Framework. This skill covers service selection, VPC design, IAM least-privilege, serverless patterns, cost optimization, and monitoring - with an emphasis on when to use each service, not just how. Designed for engineers who know AWS basics and need opinionated guidance on trade-offs and common pitfalls.

When to use this skill

Trigger this skill when the user:

• Chooses between AWS compute options (EC2, ECS, Fargate, Lambda, App Runner)
• Designs or reviews a VPC, subnet, or security group setup
• Needs IAM roles, policies, or permission boundaries
• Architects a serverless application (API Gateway + Lambda + DynamoDB)
• Asks about cost reduction, Reserved Instances, Savings Plans, or right-sizing
• Sets up CloudWatch alarms, dashboards, or log insights
• Selects a database service (RDS, Aurora, DynamoDB, ElastiCache)
• Plans multi-region or high-availability architecture

Do NOT trigger this skill for:

• General Linux/shell scripting unrelated to AWS
• Kubernetes internals that are cloud-agnostic (use a k8s skill instead)

Key principles

1. Operational excellence - Automate everything that can be automated.

Infrastructure-as-code (CloudFormation, CDK, Terraform) is not optional. Every change should be reviewable, reproducible, and reversible. Run post-incident reviews and feed learnings back into runbooks.

1. Security - Apply least-privilege IAM everywhere. No * actions in production

policies. Encrypt data at rest (KMS) and in transit (TLS). Treat every AWS account boundary as a trust boundary. Use VPC endpoints to keep traffic off the public internet where possible.

1. Reliability - Design for multi-AZ by default. Use health checks, auto-scaling,

and managed services that handle failure transparently. Define Recovery Time Objective (RTO) and Recovery Point Objective (RPO) before choosing a database tier.

1. Performance efficiency - Right-size before you scale out. Understand the

access patterns of your workload and match them to the service that handles them natively (e.g., DynamoDB for key-value at scale, Aurora for relational OLTP). Use CloudFront and edge caching to reduce origin load.

1. Cost optimization - Cost is an architecture decision, not an afterthought.

Tag every resource. Use Cost Explorer weekly. Commit to Reserved Instances or Savings Plans for stable workloads. Delete idle resources aggressively.

Core concepts

Regions and Availability Zones

A region is a geographic area with multiple isolated data centers. Each region contains at least 3 Availability Zones (AZs) - physically separate facilities with independent power and networking. Deploy stateful services across 2+ AZs for high availability. Some services (S3, IAM, CloudFront) are global; most are regional.

IAM model

IAM has four building blocks:

| Concept | What it is | |---|---| | Principal | Who is acting (user, role, service) | | Policy | JSON document defining allowed/denied actions | | Role | Identity assumed by services or users (no long-term credentials) | | Trust policy | Who is allowed to assume a role |

The golden rule: use roles, not users. EC2 instances, Lambda functions, and ECS tasks all assume roles at runtime. Never embed access keys in code or AMIs.

Compute spectrum

Control / Cost                              Managed / Speed
<------------------------------------------>
EC2 -> ECS on EC2 -> ECS Fargate -> Lambda -> App Runner

• EC2 - full OS control, GPU support, long-running workloads
• ECS on EC2 - containerized, you manage the host fleet
• ECS Fargate - containerized, AWS manages hosts (preferred default)
• Lambda - event-driven, sub-second billing, 15-min max duration
• App Runner - HTTP services from container or source, zero infra management

Storage tiers

| Service | Use case | |---|---| | S3 Standard | Frequently accessed objects | | S3 Intelligent-Tiering | Unpredictable access patterns | | S3 Glacier Instant | Archives needing millisecond retrieval | | EBS | Block storage attached to EC2 | | EFS | Shared POSIX filesystem across multiple EC2s |

Networking primitives

A VPC is a logically isolated network. Inside it, subnets span a single AZ. Public subnets have a route to an Internet Gateway; private subnets do not. Security groups are stateful firewalls attached to ENIs (deny by default). NACLs are stateless subnet-level firewalls (less common). Use VPC endpoints to reach AWS services (S3, DynamoDB, SQS) without traversing the internet.

Common tasks

Choose the right compute service

| Workload type | Recommended service | Why | |---|---|---| | Long-running stateful app, GPU needed | EC2 | Full OS control, persistent storage | | Containerized microservice, >15 min tasks | ECS Fargate | No host management, predictable billing | | Event-driven, short tasks (<15 min) | Lambda | Pay-per-invocation, auto-scales to zero | | HTTP API from container, zero-ops | App Runner | Automated deployments, TLS, scaling | | Large-scale batch processing | AWS Batch on Fargate | Managed job queues, spot support | | Kubernetes required | EKS | When you need k8s primitives or portability |

Decision rule: start with Lambda or Fargate. Move to EC2 only when you need control over the OS, persistent GPU, or a runtime Lambda does not support.

Design a VPC with public/private subnets

A standard 3-tier VPC layout:

VPC 10.0.0.0/16
  Public subnets  (10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24)  - one per AZ
    - Internet Gateway route
    - Load balancers, NAT Gateways, bastion hosts
  Private subnets (10.0.10.0/24, 10.0.11.0/24, 10.0.12.0/24) - one per AZ
    - Application servers, ECS tasks, Lambda (VPC-attached)
    - Route outbound through NAT Gateway in the public subnet
  Database subnets (10.0.20.0/24, 10.0.21.0/24, 10.0.22.0/24) - one per AZ
    - RDS, ElastiCache
    - No internet route at all

CIDR planning rules:

• Use /16 for the VPC to leave room for growth
• Use /24 per subnet (251 usable IPs - AWS reserves 5 per subnet)
• Reserve CIDR ranges to avoid conflicts with on-premises networks or VPC peering

Never put application workloads in public subnets. Only load balancers and NAT

Gateways belong in public subnets.

Set up IAM roles with least privilege

Start from zero-permissions and add only what's needed. Example Lambda role that reads from one S3 bucket and writes to DynamoDB:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:PutItem",
        "dynamodb:UpdateItem"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}

Key rules:

• Scope Resource to specific ARNs, never "*" for data plane actions
• Use permission boundaries to cap what a role can grant to child roles
• Use IAM Access Analyzer to find overly permissive policies automatically
• Rotate any long-term credentials (access keys) every 90 days or eliminate them

Design a serverless API

Standard pattern: API Gateway -> Lambda -> DynamoDB

Client
  -> API Gateway (REST or HTTP API)
      - Request validation, auth (Cognito/JWT authorizer), throttling
  -> Lambda function (per route or single handler)
      - Business logic, input validation
  -> DynamoDB table
      - Partition key = entity type + ID, sort key =