Availability-Zone Architecture
Availability-Zone Architecture
Baseline: three AZs, no single point of failure. Users hit Route 53 → CloudFront/WAF → an ALB spread across AZs; stateless app instances (ASG or ECS/Fargate) sit in private subnets behind it, with NAT or VPC endpoints for outbound calls. Data stores handle their own HA: Aurora with a writer and readers across AZs (or RDS Multi-AZ), ElastiCache with a multi-AZ replica group, SQS decoupling the worker tier so spikes buffer instead of cascading.
Every layer states its failure mode: lose an AZ, and the ALB drains to healthy targets while the ASG replaces capacity; the database fails over in under a minute. Stateless tiers need no data migration — that is the whole argument for pushing state into managed services.
Disaster Recovery Layer
Disaster Recovery Layer
Multi-AZ is not disaster recovery — a region event takes all of it. Pick a strategy from objectives: for RTO ~15 min/RPO ~1 min, run a warm standby in a second region with Aurora Global Database replicating and Route 53 failover on health checks; for looser numbers, pilot light with scripted promotion and cross-region backups via AWS Backup.
Replicate the unglamorous dependencies: KMS keys for encrypted data, AMIs or container images in ECR, Secrets Manager entries, and DNS records — a secondary region without them cannot boot the application even if data replicated perfectly. Infrastructure lives in IaC so the standby is a parameterized deploy, not a document.
State the pair — RTO and RPO — before any service is named.
Security and Review
Security and Review
Layer defenses: edge (WAF rules, Shield, CloudFront geo/rate rules), network (private subnets, least-privilege security groups with no 0.0.0.0/0 on the data tier, VPC endpoints for S3/Secrets), identity (roles per service, no long-lived access keys, IRSA/instance profiles), data (KMS CMKs, TLS in transit, Secrets Manager over hardcoded values), and detection (CloudTrail, GuardDuty, Config rules, alarms on auth anomalies).
A capstone review asks: where is the blast radius of a single compromised task? If the answer is "the whole account," IAM scoping failed. Interview: present the architecture as decisions under constraints — each choice (Aurora over EC2+Postgres, SQS over synchronous calls) justified by availability, cost, or operations, with the alternative named.
Quiz
1. Why keep application tiers stateless?
2. What does multi-AZ NOT protect against?
3. Which dependency commonly breaks cross-region failover?
Flashcards
Question
Multi-AZ vs DR
Click to reveal answer
Answer
Multi-AZ handles zone failure; DR (cross-region) handles region failure — different budgets.
Question
Stateless tier
Click to reveal answer
Answer
No local durable state → replaceable instances, safe autoscaling, fast drain.
Question
DR dependencies
Click to reveal answer
Answer
KMS keys, images, secrets, DNS — replicate or the standby cannot boot.
Question
Edge security layer
Click to reveal answer
Answer
WAF + Shield + CloudFront rules in front of the ALB.
Question
Blast radius question
Click to reveal answer
Answer
What can one compromised task reach? Answer reflects your IAM scoping.
Revision Notes
Key Takeaways
- 1. Design top-down: users → edge → stateless compute → managed data
- 2. State objectives (RTO/RPO) before naming DR services
- 3. Security is layered; IAM scoping defines the blast radius
Interview Tips
- • Present each choice as alternatives compared under a constraint — interviewers grade reasoning
- • End with failure walkthroughs: lose an AZ, lose the region, lose the database writer
Cheat Sheet
Capstone: R53→WAF/CF→ALB→private ASG/Fargate; Aurora/ElastiCache/SQS for state; 3 AZs + cross-region DR from RTO/RPO (replicate KMS/ECR/secrets). Layers: WAF→SG→roles→KMS→CloudTrail/GuardDuty.
Continue Learning
Before You Start
- No prerequisites listed.