aws-patterns

# AWS Patterns ## When to Use **Use this skill when:** - User asks how to architect a specific AWS workload -- web applications, data pipelines, event-driven systems, microservices, or batch processing - User needs to choose between competing AWS service options (e.g., SQS vs. Kinesis, ECS vs. EKS vs. Lambda, RDS vs. Aurora vs. DynamoDB) - User wants production-ready infrastructure patterns with security controls, scaling configurations, and operational guardrails built in - User is designing for specific non-functional requirements: sub-100ms latency, 99.99% availability, data residency compliance, or cost optimization targets - User is migrating from on-premises or another cloud and needs AWS-idiomatic equivalents for existing patterns - User needs to understand trade-offs between synchronous and asynchronous communication patterns in a distributed AWS system - User wants to implement multi-account, multi-region, or multi-AZ strategies for enterprise workloads - User asks about specific AWS architectural concerns: cold start mitigation, fan-out patterns, circuit breaking, throttling, backpressure, or dead-letter queue design **Do NOT use this skill when:** - User needs Terraform or CloudFormation syntax help specifically -- use the IaC skill in the devops-cloud subcategory - User needs container orchestration deep dives (Kubernetes cluster configuration, Helm chart authoring) -- use the container-orchestration skill - User needs CI/CD pipeline design -- use the ci-cd-pipelines skill - User needs general cloud cost optimization without an architecture question -- use the cloud-cost-optimization skill - User is asking about a non-AWS cloud provider (Azure, GCP) -- use the appropriate cloud-provider skill - User needs application-level design patterns (DDD, CQRS at the code level) without an AWS infrastructure question - User needs incident response or AWS outage troubleshooting -- use the cloud-incident-response skill --- ## Process ### 1. Characterize the Workload Before recommending any pattern, classify the workload along four axes: - **Traffic shape:** Is demand steady, spiky, bursty, or scheduled? A SaaS application with unpredictable viral traffic needs different patterns than a nightly ETL job. Quantify: requests/second at p50 and p99, burst factor, and ramp speed (seconds to 10x load). - **Data access pattern:** Is the system read-heavy (consider ElastiCache, DAX, CloudFront), write-heavy (consider DynamoDB with write sharding, Kinesis), or mixed (consider Aurora read replicas or CQRS separation)? - **Coupling tolerance:** Can downstream failures be tolerated with degraded responses (use async patterns, SQS, SNS fan-out), or is strict consistency required (synchronous calls with circuit breakers, Step Functions orchestration)? - **Operational maturity:** A team without on-call rotation and runbooks should not operate a self-managed Kafka cluster on EC2 -- use managed services (MSK, Kinesis) even at higher per-unit cost. Determine the availability tier: - **Tier 1 (99.99%+):** Multi-region active-active or active-passive with Route 53 health checks and automated failover. RTO < 1 minute, RPO near-zero. - **Tier 2 (99.9%):** Multi-AZ within a single region. RDS Multi-AZ, ALB across 3 AZs, ECS with tasks spread across AZs. - **Tier 3 (99.5%):** Single-AZ acceptable for non-production or internal tooling. ### 2. Select the Compute Pattern Apply this decision tree: **Is the workload event-driven with discrete, short-lived invocations (< 15 minutes)?** - Yes, and cold starts are tolerable (async, non-latency-sensitive): **Lambda with SQS or SNS triggers** - Yes, but cold starts are not tolerable (customer-facing synchronous API): **Lambda with Provisioned Concurrency** or **Fargate with pre-warmed containers** - No, workload is long-running or stateful: proceed below **Is the workload containerized?** - Yes, and team lacks Kubernetes expertise or wants reduced ops overhead: **ECS on Fargate** (no cluster management, pay-per-task-second) - Yes, and team needs advanced scheduling, custom operators, or runs open-source tooling requiring Kubernetes: **EKS with managed node groups** (use Karpenter for node autoscaling, not Cluster Autoscaler for new deployments) - No: **EC2 with Auto Scaling Groups**, appropriate for gaming servers, HPC, or workloads requiring specific instance types (GPU, high-memory) **Is the workload a traditional three-tier web application?** - ALB -- ECS Fargate (or EKS) -- RDS Aurora with read replicas. This covers 80% of web workload patterns. Compute sizing rules: - Lambda: 1,769 MB RAM = 1 vCPU. For CPU-intensive functions, set memory to 1,769 MB or 3,008 MB (1.7 vCPU). Do not set 128 MB for CPU-heavy tasks -- the function will run slower and cost more due to extended duration. - Fargate task sizing: start at 0.5 vCPU / 1 GB for lightweight services; 1 vCPU / 2 GB for standard APIs; 2 vCPU / 4 GB for data-intensive processing. - EC2: Use Graviton3 (c7g, m7g, r7g) instances for 40% better price-performance than equivalent x86 instances for most workloads. Reserve Spot Instances for stateless, interruption-tolerant workloads to achieve 60-90% cost reduction vs. On-Demand. ### 3. Select the Data Storage Pattern Apply the following rules in order: **Relational workload (ACID transactions, complex joins, reporting):** - Aurora PostgreSQL-compatible: default choice for new relational workloads. Scales storage automatically to 128 TB. Aurora Serverless v2 for variable workloads (scales from 0.5 ACU to 128 ACU in ~1 second). - RDS PostgreSQL on Multi-AZ DB instances: choose over Aurora only when you need access to PostgreSQL extensions that Aurora does not support, or when running in a region without Aurora. - Read replicas: add when read:write ratio exceeds 4:1, or when read query p99 latency exceeds 100ms under load. **High-throughput key-value or document workload (>10,000 writes/second or single-digit millisecond latency required):** - DynamoDB: use on-demand capacity for unpredictable workloads; provisioned capacity with Application Auto Scaling for steady traffic (30-40% cheaper). Partition key design is critical -- avoid hot partitions by using high-cardinality keys. For time-series append patterns, append a random suffix (write sharding) or use a composite key with a timestamp component. - DynamoDB Accelerator (DAX): in-memory cache with microsecond latency for read-heavy DynamoDB workloads. Reduces DynamoDB read costs by up to 70% for cacheable access patterns. **Large object / binary / unstructured storage:** - S3 as the default object store. Enable S3 Intelligent-Tiering for objects with unknown or changing access patterns (automatically moves objects between frequent, infrequent, and archive tiers). - Use S3 Transfer Acceleration for uploads from globally distributed clients. - Enable S3 Versioning and Object Lock for data that requires immutability guarantees (compliance, audit logs). **Caching layer:** - ElastiCache for Redis 7.x: session storage, rate limiting, leaderboards, pub/sub. Use cluster mode enabled for horizontal scaling beyond a single shard's memory. - ElastiCache for Memcached: pure caching workloads where Redis data structures are not needed and multi-threading is valuable. - CloudFront: cache at the edge for any content served over HTTP/S, including API responses. Set Cache-Control headers appropriately -- even caching API responses for 5 seconds can reduce origin load by 80% during traffic spikes. **Time-series and analytical workloads:** - Amazon Timestream: purpose-built for time-series data. Ingestion is 10x cheaper than RDS for equivalent time-series write rates. - Amazon Redshift: data warehouse for analytical queries over terabyte-scale datasets. Use RA3 nodes for separation of compute and storage. Enable Redshift Spectrum to query S3 data directly without loading it into Redshift. - Amazon Athena: serverless SQL over S3 at $5/TB scanned. Best for ad-hoc analysis or infrequent queries. Use Parquet or ORC columnar formats with partition projection to reduce scan cost by 70-90%. ### 4. Design the Messaging and Integration Pattern Choose based on the required semantics: **Fan-out (one publisher, many consumers):** - SNS topic with multiple SQS queue subscriptions. Each consumer gets an independent copy of the message. This is the standard AWS fan-out pattern. - Add message filtering at the SNS subscription level to route events by type without requiring consumers to filter in code. **Work queue (competing consumers, each message processed once):** - SQS Standard Queue: at-least-once delivery, nearly unlimited throughput. Set visibility timeout to 6x the expected processing time to prevent duplicate processing during retries. - SQS FIFO Queue: exactly-once processing within a 5-minute deduplication window, 300 TPS per message group (or 3,000 TPS with batching). Use ONLY when ordering and deduplication are required -- FIFO queues are slower and more expensive. - Dead Letter Queue (DLQ): always configure a DLQ on every SQS queue. Set maxReceiveCount to 3-5 depending on retry tolerance. Send DLQ alerts to an SNS topic for operational visibility. **High-throughput streaming (>1,000 events/second, replay required, multiple independent consumers):** - Kinesis Data Streams: 1 shard = 1,000 writes/second or 1 MB/s. Shard count = max(write_rate/1000, write_throughput_MBps). Enable enhanced fan-out for consumers that need dedicated 2 MB/s throughput per shard. Retain data for 24 hours (default) to 365 days. - Amazon MSK (Managed Kafka): use when team already operates Kafka, when ecosystem tooling (Kafka Connect, Kafka Streams) is required, or when Kinesis shard limits are constraining. MSK Serverless for variable throughput without shard management. **Synchronous API integration:** - API Gateway (HTTP API): lowest latency (~1ms overhead), lowest cost ($1/million requests), supports JWT authorizers and Lambda integrations. Choose for most REST API use cases. - API Gateway (REST API): choose when you need request/response transformation, usage plans, API keys, or AWS WAF integration. ~50% more expensive than HTTP API. - Application Load Balancer direct-to-target: choose for WebSocket connections, gRPC, or when API Gateway features are not needed and you want to avoid per-request pricing. **Orchestration vs. choreography:** - Step Functions Standard Workflows: use for business-critical workflows requiring audit trails, human approval steps, or complex error handling. State transitions are persisted -- durable against Lambda/ECS restarts. 2,000 state transitions free, then $0.025 per 1,000. - Step Functions Express Workflows: use for high-volume, short-duration workflows (< 5 minutes) where durability between steps is not required. Up to 100,000 executions/second. - EventBridge: use for event-driven choreography where services need to react to state changes without knowing about each other. Define event schemas in EventBridge Schema Registry for type safety between producers and consumers. ### 5. Design the Network and Security Architecture **VPC structure (three-tier standard):** - Public subnets: ALB, NAT Gateway, bastion hosts. Never deploy application servers or databases in public subnets. - Private application subnets: ECS tasks, Lambda (VPC-attached), EC2 application tier. No direct internet access -- outbound through NAT Gateway. - Private data subnets: RDS, ElastiCache, OpenSearch. No internet access at all. Accessible only from the application subnets via security group rules. - Use /24 CIDR blocks for each subnet (251 usable IPs). Reserve /20 or larger VPC CIDR to allow future expansion. - Deploy subnets in at least 3 Availability Zones for Tier 1 and Tier 2 workloads. **Security group design:** - Never use 0.0.0.0/0 inbound on any security group except the ALB on ports 443 and 80. - Reference security group IDs in inbound rules, not CIDR ranges. This allows resources to move IPs without requiring security group updates. - ALB SG: inbound 443 from 0.0.0.0/0, outbound to application SG on application port only. - Application SG: inbound from ALB SG on application port, outbound to database SG on database port and to NAT Gateway CIDR for external calls. - Database SG: inbound from application SG on database port only. No outbound internet access. **IAM pattern:** - Use IAM Roles for all compute -- EC2 instance profiles, ECS task roles, Lambda execution roles. Never use long-lived access keys on compute resources. - Apply Permission Boundaries on all developer-created roles in multi-team accounts to prevent privilege escalation. - Use AWS Organizations SCPs to enforce guardrails at the account level (e.g., deny disabling CloudTrail, deny launching resources outside approved regions). - Enable IAM Access Analyzer in every account to detect overly permissive policies automatically. **Secrets management:** - AWS Secrets Manager for database credentials, API keys, and OAuth tokens. Enable automatic rotation for database credentials (built-in rotation for RDS/Aurora). - AWS Systems Manager Parameter Store (SecureString) for configuration values that do not require rotation. Cost: free for standard parameters, $0.05/month per advanced parameter. - Never inject secrets as plaintext environment variables. Lambda and ECS both support reading from Secrets Manager at startup via the Secrets Manager extension (Lambda) or secrets injection (ECS). **Encryption standards:** - Encrypt all S3 buckets with SSE-S3 minimum; use SSE-KMS for buckets containing sensitive data to get per-object encryption and audit logs via CloudTrail. - Enable encryption at rest on all RDS/Aurora, ElastiCache, EBS, and DynamoDB resources. This is a checkbox -- there is no performance penalty. - Enforce TLS 1.2+ on all ALB listeners. Set the security policy to ELBSecurityPolicy-TLS13-1-2-2021-06. - Enable S3 Block Public Access at the account level via AWS Organizations to prevent accidental public bucket exposure. ### 6. Design Observability and Operational Controls **The Three Pillars on AWS:** Metrics -- CloudWatch: - Enable detailed monitoring (1-minute granularity) on all EC2, RDS, and ElastiCache instances. Default is 5 minutes -- insufficient for incident response. - Define CloudWatch Alarms on: ECS CPU > 80%, RDS FreeStorageSpace < 20 GB, SQS ApproximateNumberOfMessagesNotVisible > threshold (signals consumer stuck), Lambda ErrorRate > 1%, API Gateway 5xxError > 0.5%. - Use CloudWatch Container Insights for ECS/EKS for container-level CPU/memory metrics without custom instrumentation. - Create CloudWatch Dashboards per service, not per AWS service type. A service dashboard shows ALB, ECS, RDS, and ElastiCache metrics side by side. Logs -- CloudWatch Logs / OpenSearch: - Use structured JSON logging from all application code. Include: timestamp, level, service_name, trace_id, correlation_id, and error details. - Set CloudWatch Log Group retention. Default is "never expire" and costs accrue indefinitely. Set retention to 30 days for application logs, 90 days for security/audit logs, 1 year for compliance-required logs. - For log analytics at scale, ship logs to S3 via Kinesis Data Firehose and query with Athena. Cheaper than OpenSearch for infrequent analysis. Traces -- AWS X-Ray: - Instrument all Lambda functions and ECS services with X-Ray SDK or AWS Distro for OpenTelemetry (ADOT). ADOT is the forward-looking choice for vendor-neutral instrumentation. - Enable X-Ray active tracing on API Gateway to get end-to-end traces across the full request path. - Use X-Ray Service Map to identify latency bottlenecks and error sources in distributed systems. Alerting: - Use a tiered severity model: P1 (service down) pages on-call immediately; P2 (degraded) sends to Slack; P3 (warning threshold) creates a ticket. Map CloudWatch Alarms to SNS topics that route to PagerDuty, OpsGenie, or similar. ### 7. Define the Deployment and Resilience Strategy **Deployment patterns:** - Blue/green deployment: use for ECS services via CodeDeploy or ALB target group switching. Zero downtime, instant rollback by switching traffic back. Required for Tier 1 workloads. - Canary/linear deployment: route 10% of traffic to new version, monitor for 10-30 minutes, then shift remaining 90%. Use CodeDeploy with Lambda or ECS for automated canary with automatic rollback on alarm breach. - Rolling deployment: acceptable for Tier 2/3 stateless services. ECS rolling update with minimumHealthyPercent=50 and maximumPercent=200 ensures no downtime. **Auto Scaling:** - ECS Service Auto Scaling: scale on ECSServiceAverageCPUUtilization (target 60%) and ECSServiceAverageMemoryUtilization (target 70%). Add an SQS-based scaling policy for queue consumer services -- scale on ApproximateNumberOfMessagesNotVisible / number of tasks. - Application Auto Scaling on DynamoDB: target utilization 70% for both read and write capacity units. - Predictive Scaling on EC2 ASG: for workloads with predictable daily patterns (office hours, business hours), enable predictive scaling to pre-warm capacity 15 minutes ahead of expected load. **Resilience patterns:** - Circuit breaker: implement at the application level using a library, or at the infrastructure level with App Mesh (service mesh with Envoy sidecar). Configure: failure threshold 50%, wait duration 30 seconds, half-open probe count 3. - Retry with exponential backoff and jitter: all AWS SDK calls have built-in retry logic -- verify `maxAttempts` is not set to 0. For custom retry loops: base_delay=100ms, multiplier=2, jitter=random(0, base_delay), max_delay=30 seconds. - Idempotency: design all write operations to be idempotent. Use DynamoDB conditional writes, SQS message deduplication IDs (FIFO), or a dedicated idempotency table pattern for Lambda functions. - Throttle handling: every AWS service has quotas. Request increases proactively for SES sending rate, Lambda concurrent executions (default 1,000 per region), API Gateway burst limit (default 5,000 per region), and EC2 instance limits before traffic demands it. ### 8. Document Architecture Decisions Create an Architecture Decision Record (ADR) for every non-obvious choice. A minimal ADR contains: - **Context:** what problem are we solving and what constraints exist? - **Decision:** what specific option was chosen? - **Alternatives considered:** what were the other options and why were they rejected? - **Consequences:** what are the trade-offs, ongoing costs, and known limitations? Record ADRs in a `/docs/adr/` directory in the application repository, numbered sequentially (ADR-001, ADR-002). Link from architecture diagrams to the relevant ADRs. --- ## Output Format When recommending an AWS architecture pattern, produce the following: ### Architecture Summary ``` Workload: [name and description] Tier: [1 / 2 / 3] -- [SLA target: 99.99% / 99.9% / 99.5%] Pattern: [name, e.g., "Event-Driven Microservices", "Three-Tier Web", "Serverless API"] Region: [primary region] + [DR region if applicable] ``` ### Service Selection Decision Matrix | Dimension | Selected Service | Considered Alternatives | Rationale | |-----------|-----------------|------------------------|-----------| | Compute | ECS Fargate | Lambda, EKS | Request duration > 15 min; team lacks k8s expertise | | Database | Aurora PostgreSQL | RDS PostgreSQL, DynamoDB | Complex joins required; Serverless v2 for variable load | | Cache | ElastiCache Redis | DAX, CloudFront | Session state + rate limiting; Redis data structures needed | | Messaging | SQS + SNS fan-out | Kinesis, EventBridge | < 1,000 events/sec; no replay requirement | | API | API Gateway HTTP API | REST API, ALB | No transform needed; lowest cost per request | ### Architecture Diagram (ASCII) ``` Internet | [CloudFront] -- [WAF] | [ALB -- 3 AZs] | [ECS Fargate -- Private App Subnets] | | [ElastiCache] [SQS Queue] | | [Aurora PostgreSQL] [ECS Worker -- Private App Subnets] [Multi-AZ -- Private Data Subnets] ``` ### Key Configuration Parameters ```yaml # ECS Service configuration highlights ecs_service: desired_count: 3 deployment_circuit_breaker: true auto_scaling: min_capacity: 3 max_capacity: 20 target_cpu: 60 scale_in_cooldown: 300 # seconds -- conservative to avoid thrash scale_out_cooldown: 60 # seconds -- aggressive to absorb spikes # RDS Aurora Serverless v2 aurora: engine: aurora-postgresql engine_version: "15.3" serverless_v2: min_acu: 0.5 max_acu: 32 # 32 ACU = ~64 GB RAM -- size to expected peak multi_az: true backup_retention_days: 7 deletion_protection: true # SQS Queue sqs_queue: visibility_timeout: 300 # 5x expected processing time message_retention: 1209600 # 14 days dlq: max_receive_count: 3 retention: 1209600 ``` ### Cost Estimate | Service | Configuration | Estimated Monthly Cost | |---------|--------------|----------------------| | ECS Fargate | 3 tasks @ 1vCPU/2GB, ~50% utilization | $45 | | Aurora Serverless v2 | avg 2 ACU, Multi-AZ | $175 | | ElastiCache Redis | cache.r7g.large, 1 replica | $165 | | SQS | 10M requests/month | $4 | | ALB | 1 ALB, 10 LCUs | $22 | | **Total** | | **~$411/month** | ### Security Checklist - [ ] All subnets follow public/app/data three-tier layout - [ ] Security groups use SG-ID references, not CIDR ranges - [ ] IAM roles use least-privilege policies (no `*` actions or resources) - [ ] Secrets stored in Secrets Manager with rotation enabled - [ ] Encryption at rest enabled on all data stores - [ ] S3 Block Public Access enabled at account level - [ ] CloudTrail enabled in all regions - [ ] VPC Flow Logs enabled and shipped to CloudWatch or S3 - [ ] ALB access logs enabled and stored in S3 ### Operational Runbook Outline ``` ## [Service Name] Runbook ### Health Check - URL: GET /health -- expected 200 within 2 seconds - CloudWatch Dashboard: [link] ### Scaling - ECS auto-scales at 60% CPU -- no manual action needed - If DynamoDB throttles: check CloudWatch ThrottledRequests; increase provisioned capacity or switch to on-demand ### Common Failure Modes 1. Database connection exhaustion -- check RDS max_connections; add RDS Proxy if Lambda or many ECS tasks