Skip to content
advanced Phase 20 · AWS Capstone Project

Project Architecture

Design a production-ready AWS architecture with HA, DR, and security.

1h 30m
0 problems
Topic Progress 0%

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?

Question 1 options

2. What does multi-AZ NOT protect against?

Question 2 options

3. Which dependency commonly breaks cross-region failover?

Question 3 options

Flashcards

Question

Multi-AZ vs DR

Answer

Multi-AZ handles zone failure; DR (cross-region) handles region failure — different budgets.

Question

Stateless tier

Answer

No local durable state → replaceable instances, safe autoscaling, fast drain.

Question

DR dependencies

Answer

KMS keys, images, secrets, DNS — replicate or the standby cannot boot.

Question

Edge security layer

Answer

WAF + Shield + CloudFront rules in front of the ALB.

Question

Blast radius question

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