Skip to content

Designing resilient, secure, performant and cost-efficient systems by combining the services from the other AWS notes.

Services at a glance (design toolbox)

Goal Services
High availability Multi-AZ, ELB, Auto Scaling, RDS Multi-AZ, Aurora, Route 53
Disaster recovery AWS Backup, S3 CRR, Aurora Global Database, DynamoDB Global Tables, Elastic Disaster Recovery
Decoupling SQS, SNS, EventBridge, Kinesis, Step Functions
Caching CloudFront, ElastiCache, DAX, API Gateway cache
Security IAM, KMS, WAF, Shield, GuardDuty, Security Groups, Secrets Manager
Cost Savings Plans, Spot, S3 lifecycle, Cost Explorer, Compute Optimizer
Hybrid / migration Direct Connect, VPN, DMS, Application Migration Service, DataSync, Snow Family
Governance Organizations, Control Tower, Config, CloudTrail

Design Principles

  • Design for failure: assume any component, AZ or region can fail
  • Loose coupling: queues and events between tiers instead of direct calls
  • Stateless compute: keep session state in ElastiCache / DynamoDB, uploads in S3
  • Automate everything: IaC, CI/CD, auto scaling, auto recovery
  • Right-size and use managed services to reduce undifferentiated work
  • Least privilege and defence in depth
  • Measure and iterate (CloudWatch, X-Ray)

Framework pillars are in 1. AWS Cloud Concepts.

Resilient Architecture

High availability within a region

Spread across at least two AZs:

Route 53
   │
CloudFront ── WAF
   │
ALB (spans AZ-a, AZ-b)
   ├── ASG: app servers in private subnets AZ-a
   └── ASG: app servers in private subnets AZ-b
          │
   Aurora writer (AZ-a) ◄──replicates──► Aurora reader (AZ-b)
   ElastiCache (Multi-AZ)
  • Multi-AZ RDS / Aurora for automatic database failover
  • NAT Gateway per AZ, ASG across AZs, cross-zone load balancing
  • Health checks at Route 53 / ELB, replace unhealthy automatically
  • S3 and DynamoDB are already multi-AZ

Disaster Recovery strategies

Defined by RPO (acceptable data loss) and RTO (acceptable downtime). Cheaper means slower recovery.

Strategy RPO / RTO How Cost
Backup and restore Hours Backups to S3 / another region, rebuild with IaC $
Pilot light 10s of minutes Core data replicated, minimal infra always on, scale up on failover $$
Warm standby Minutes Scaled-down full environment running $$$
Multi-site active-active Near zero Full capacity in 2+ regions, Route 53 routes both $$$$

Tools: Aurora Global Database, DynamoDB Global Tables, S3 Cross-Region Replication, Route 53 failover routing, Elastic Disaster Recovery (DRS), AWS Backup cross-region copy.

Decoupling and Integration

Need Pattern
Absorb spikes, async work SQS between web tier and workers; scale workers on queue depth
One event, many consumers SNS → SQS fan-out
React to AWS and SaaS events EventBridge
Ordered high-throughput stream Kinesis Data Streams
Multi-step workflow with retries Step Functions
Real-time to client API Gateway WebSocket / AppSync / IoT Core

Performance

  • CloudFront for static and cacheable dynamic content, Global Accelerator for TCP/UDP
  • ElastiCache / DAX to offload databases
  • Read replicas for read-heavy relational loads; DynamoDB for key-based access at scale
  • EBS io2 or instance store for IOPS-heavy workloads; placement groups for HPC
  • S3 Transfer Acceleration and multipart upload; prefix parallelism for S3 throughput
  • Choose instance family by bottleneck: CPU (C), memory (R), IO (I), GPU (P/G)

Security Architecture

  • Account strategy: separate accounts per environment / workload under Organizations, SCPs as guardrails, centralised logging account
  • Network: public subnets only for load balancers / NAT; app and data tiers in private subnets; VPC endpoints for AWS services; NACLs as a coarse layer, SGs as the main control
  • Data: encrypt at rest (KMS) and in transit (ACM); S3 Block Public Access; Macie
  • Identity: roles over keys, IAM Identity Center, MFA, Access Analyzer
  • Edge: CloudFront + WAF + Shield
  • Detect: GuardDuty, Security Hub, CloudTrail, Config

Reference: 2. AWS IAM and Security, 5. AWS Networking

Cost Optimisation

  • Right-sizing with Compute Optimizer, delete idle resources
  • Savings Plans / Reserved for steady load; Spot for stateless, fault-tolerant work (ASG mixed instances policy)
  • S3 lifecycle to IA / Glacier, Intelligent-Tiering
  • Serverless (Lambda, Fargate, DynamoDB on-demand) for spiky or low-traffic
  • Cut data transfer: CloudFront, VPC endpoints, keep chatty traffic in one AZ where acceptable
  • Budgets and tagging for accountability

Storage Selection

Need Choose
Objects, static assets, data lake S3
Boot / database volume for one instance EBS
Shared POSIX (Linux) files EFS
Shared Windows files, AD FSx for Windows
HPC scratch FSx for Lustre
Temporary highest IOPS Instance store
On-prem to cloud file access Storage Gateway

Database Selection

Need Choose
Relational, managed RDS / Aurora
Key-value at massive scale DynamoDB
Caching ElastiCache / DAX
Analytics warehouse Redshift
Ad-hoc SQL on S3 Athena
Graph Neptune
Time series Timestream

Typical Architectures

Static website

S3 (private) + CloudFront (OAC) + Route 53 + ACM, optional Lambda@Edge and WAF.

Three-tier web application

Route 53 → CloudFront → ALB → ASG (EC2) in private subnets → RDS Multi-AZ, with ElastiCache for sessions and S3 for uploads.

Serverless API

Route 53 → CloudFront → API Gateway → Lambda → DynamoDB, Cognito for auth, SQS / EventBridge for async work.

Event-driven processing

S3 upload → EventBridge/SNS → SQS → Lambda → DynamoDB, failures to a DLQ.

Hybrid

On-prem ⇄ Direct Connect (+ VPN backup) ⇄ Transit Gateway ⇄ VPCs, DataSync / Storage Gateway for data, DMS to migrate databases.

Questions to Ask When Designing

  1. What are the RTO / RPO and availability target?
  2. Read-heavy or write-heavy? Latency needs?
  3. Spiky or steady load? Predictable?
  4. Where are the users? Any data residency rules?
  5. What must stay private? What compliance applies?
  6. What is the budget, and what can be managed for us?

See also: System Design for the vendor-neutral patterns behind these services.