Deploying On AWS

AWS Patterns

Purpose

This skill provides decision frameworks and implementation patterns for Amazon Web Services. Navigate AWS's 200+ services through proven selection criteria, architectural patterns, and Well-Architected Framework principles. Focus on practical service selection, cost-aware design, and modern 2025 patterns including Lambda SnapStart, EventBridge Pipes, and S3 Express One Zone.

Use this skill when designing AWS solutions, selecting services for specific workloads, implementing serverless or container architectures, or optimizing existing AWS infrastructure for cost, performance, and reliability.

When to Use This Skill

Invoke this skill when:

• Choosing between Lambda, Fargate, ECS, EKS, or EC2 for compute workloads
• Selecting database services (RDS, Aurora, DynamoDB) based on access patterns
• Designing VPC architecture for multi-tier applications
• Implementing serverless patterns with API Gateway and Lambda
• Building container-based microservices on ECS or EKS
• Applying AWS Well-Architected Framework to designs
• Optimizing AWS costs while maintaining performance
• Implementing security best practices (IAM, KMS, encryption)

Core Service Selection Frameworks

Compute Service Selection

Decision Flow:

Execution Duration:
  <15 minutes → Evaluate Lambda
  >15 minutes → Evaluate containers or VMs

Event-Driven/Scheduled:
  YES → Lambda (serverless)
  NO → Consider traffic patterns

Containerized:
  YES → Need Kubernetes?
    YES → EKS
    NO → ECS (Fargate or EC2)
  NO → Evaluate EC2 or containerize first

Special Requirements:
  GPU/Windows/BYOL licensing → EC2
  Predictable high traffic → EC2 or ECS on EC2 (cost optimization)
  Variable traffic → Lambda or Fargate

Quick Reference:

For detailed service comparisons including cost examples, performance characteristics, and use case guidance, see references/compute-services.md.

Database Service Selection

Decision Matrix by Access Pattern:

Query Complexity Guide:

• Simple Key-Value: DynamoDB (single-digit ms latency)
• Moderate Joins (2-3 tables): Aurora or RDS (cost vs. performance)
• Complex Analytics: Redshift (dedicated) or Athena (serverless, query S3)
• Real-Time Streams: DynamoDB Streams + Lambda

For storage class selection, cost comparisons, and migration patterns, see references/database-services.md.

Storage Service Selection

Primary Decision Tree:

Data Type:
  Objects (files, media) → S3 + lifecycle policies
  Blocks (databases, boot volumes) → EBS
  Shared Files (cross-instance) → Evaluate protocol

File Protocol Required:
  NFS (Linux) → EFS
  SMB (Windows) → FSx for Windows
  High-Performance HPC → FSx for Lustre
  Multi-Protocol + Enterprise → FSx for NetApp ONTAP

Cost Comparison (1TB/month):

Recommendation: Use S3 for 80%+ of storage needs. Use EFS/FSx only when shared file access is required.

For S3 storage classes, EBS volume types, and lifecycle policy examples, see references/storage-services.md.

Serverless Architecture Patterns

Pattern 1: REST API (Lambda + API Gateway + DynamoDB)

Architecture:

Client → API Gateway (HTTP API) → Lambda → DynamoDB
                                        ↓
                                       S3 (file uploads)

Use When:

• Building RESTful APIs with CRUD operations
• Variable or unpredictable traffic
• Minimal operational overhead desired
• Pay-per-request cost model acceptable

Cost Estimate (1M requests/month):

• API Gateway: $3.50
• Lambda: $3.53
• DynamoDB: ~$7.50
• Total: ~$15/month (vs. Fargate ~$35+, EC2 ~$50+)

Key Components:

• API Gateway HTTP API (cheaper than REST API)
• Lambda with appropriate memory allocation (1024MB typically optimal)
• DynamoDB on-demand billing (for variable traffic)
• CloudWatch Logs for debugging

See examples/cdk/serverless-api/ and examples/terraform/serverless-api/ for complete implementations.

Pattern 2: Event-Driven Processing (EventBridge + Lambda + SQS)

Architecture:

S3 Upload → EventBridge Rule → Lambda (process) → DynamoDB (metadata)
                                              ↓
                                            SQS (downstream tasks)

Use When:

• Asynchronous file processing
• Decoupled microservices communication
• Fan-out patterns (one event, multiple consumers)
• Need retry logic and dead-letter queues

Key Features (2025):

• EventBridge Pipes: Simplified source → filter → enrichment → target
• Lambda Response Streaming: Stream responses up to 20MB
• Step Functions Distributed Map: Process millions of items in parallel

See references/serverless-patterns.md for additional patterns including Step Functions orchestration, API Gateway WebSockets, and Lambda SnapStart configuration.

Container Architecture Patterns

Pattern 1: ECS on Fargate (Serverless Containers)

Architecture:

ALB → ECS Service (Fargate tasks) → RDS Aurora
                                 ↓
                           ElastiCache Redis

Use When:

• Containerized applications without cluster management
• Variable traffic with auto-scaling
• Avoid EC2 instance management
• Docker-based deployment

Key Components:

• Application Load Balancer (path-based routing)
• ECS Cluster with Fargate launch type
• Task definitions (CPU, memory, container image)
• Auto-scaling based on CPU/memory or custom metrics
• Service Connect for built-in service mesh (2025 feature)

Cost Model (2 vCPU, 4GB RAM, 24/7):

• Fargate: ~$70/month
• ALB: ~$20/month
• RDS Aurora db.t3.medium: ~$50/month
• Total: ~$140/month

Pattern 2: EKS (Kubernetes on AWS)

Use When:

• Kubernetes expertise exists in team
• Multi-cloud or hybrid cloud strategy
• Need Kubernetes ecosystem (Helm, Operators, Istio)
• Complex workload orchestration requirements

Key Features (2025):

• EKS Auto Mode: Fully managed node lifecycle
• EKS Pod Identities: Simplified IAM (replaces IRSA)
• EKS Hybrid Nodes: Run on-premises nodes

Cost Considerations:

• EKS control plane: $73/month per cluster
• Worker nodes: Fargate or EC2 pricing
• Use EKS on Fargate for simplicity, EC2 for cost optimization

For ECS task definitions, EKS cluster setup with CDK/Terraform, and service mesh patterns, see references/container-patterns.md.

Networking Essentials

VPC Architecture

Standard 3-Tier Pattern:

VPC: 10.0.0.0/16

Per Availability Zone (deploy across 3 AZs):
  Public Subnet:    10.0.X.0/24   (ALB, NAT Gateway)
  Private Subnet:   10.0.1X.0/24  (ECS, Lambda, app tier)
  Database Subnet:  10.0.2X.0/24  (RDS, Aurora, isolated)

Best Practices:

• Use /16 for VPC CIDR (65,536 IPs for growth)
• Use /24 for subnet CIDRs (256 IPs, 251 usable)
• Deploy across minimum 2 AZs (3 recommended) for high availability
• Use Security Groups (stateful) for instance-level firewall
• Enable VPC Flow Logs for troubleshooting

Load Balancing

Service Selection:

ALB Features:

• Path-based routing: /api → backend, /web → frontend
• Host-based routing: api.example.com, web.example.com
• WebSocket and gRPC support
• Integration with Lambda (serverless backends)

For CloudFront CDN patterns, Route 53 routing policies, and VPC peering configurations, see references/networking.md.

Security Best Practices

IAM Principles

Least Privilege Pattern:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-bucket/uploads/*"
  }]
}

Core Practices:

• Use IAM roles (not users) for applications
• Implement least privilege (grant minimum permissions needed)
• Enable MFA for privileged users
• Use IAM Access Analyzer to validate policies
• Leverage AWS Organizations SCPs for guardrails

Data Protection

Encryption Requirements:

Secrets Management:

• Secrets Manager: Database credentials with automatic rotation
• Parameter Store: Application configuration (free tier available)
• KMS: Encryption key management (customer-managed keys)

For WAF rules, GuardDuty configuration, and network security patterns, see references/security.md.

AWS Well-Architected Framework

Six Pillars Overview

1. Operational Excellence

• Infrastructure as code (CDK, Terraform, CloudFormation)
• Automated deployments (CI/CD pipelines)
• Observability (CloudWatch Logs, Metrics, X-Ray)
• Runbooks and playbooks for common operations

2. Security

• Strong identity foundation (IAM roles and policies)
• Defense in depth (Security Groups, NACLs, WAF)
• Data protection (encryption at rest and in transit)
• Detective controls (CloudTrail, GuardDuty, Security Hub)

3. Reliability

• Multi-AZ deployments (RDS Multi-AZ, Aurora replicas)
• Auto-scaling (EC2 ASG, ECS Service Auto Scaling)
• Backup and recovery (automated snapshots, cross-region)
• Chaos engineering (Fault Injection Simulator)

4. Performance Efficiency

• Right-size resources (use Compute Optimizer)
• Use managed services (reduce operational overhead)
• Caching strategies (CloudFront, ElastiCache, DAX)
• Monitor and optimize continuously

5. Cost Optimization

• Right-sizing compute (match capacity to demand)
• Pricing models (Reserved Instances, Savings Plans, Spot)
• Storage optimization (S3 Intelligent-Tiering, lifecycle policies)
• Cost monitoring (Cost Explorer, Budgets, Trusted Advisor)

6. Sustainability (Added 2024)

• Use Graviton processors (60% less energy, 25% better performance)
• Optimize workload placement (renewable energy regions)
• Storage efficiency (delete unused data, compression)
• Software optimization (efficient code, async processing)

For detailed pillar implementation guides, architectural review checklists, and Well-Architected Tool integration, see references/well-architected.md.