AWS Cloud Architect & Developer · AWS Cloud Architecture
Well Architected Framework and Resilience
The six pillars of the AWS Well Architected Framework and designing resilient multi AZ systems.
Seven concepts on the Well-Architected Framework: map a requirement to its pillar, size disaster recovery from RTO and RPO, pick a strategy on the cost spectrum, and remove single points of failure across Availability Zones.
- AWS Cloud Architect & Developer
- Medium level
- 7 concepts
- 5 practice questions
1Six pillars
The AWS Well-Architected Framework organizes good cloud design into six pillars — Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. Each pillar asks a different question about a workload: can you run and observe it, protect it, survive failure, use resources well, pay only what you need, and limit long-term environmental impact.
Sustainability became the sixth pillar in 2021; older material and some questions still behave as if there were only five. On the exam, a requirement almost always maps to one primary pillar even though real designs trade them against each other — automated deployment pipelines and runbooks belong under Operational Excellence, encryption and least-privilege access under Security, multi-AZ layouts under Reliability.
Figure. Six pillars frame design reviews — exam stems usually tip which pillar is in play.
How it works
- Read the stemName the primary concern — operations, protection, failure recovery, resource fit, spend, or environmental impact.
- Match one pillarPick the pillar whose question that concern answers; secondary trade-offs are rarely the scored answer.
- Watch the fifth-pillar trapIf Sustainability is absent from the options, the stem may predate 2021 — still choose among the five offered, but know the live framework has six.
| Pillar | Primary question | Typical exam signals |
|---|---|---|
| Operational Excellence | Can you run, observe and improve the workload? | CI/CD, runbooks, metrics, automated deployment |
| Security | Is data and access protected? | encryption, IAM least privilege, logging, compliance |
| Reliability | Does the workload recover from failure? | multi-AZ, Auto Scaling, backups, no single point of failure |
| Performance Efficiency | Are the right resources used efficiently? | right-sizing, caching, serverless vs always-on |
| Cost Optimization | Are you paying only for what you need? | Reserved Instances, lifecycle policies, turning off idle capacity |
| Sustainability | Is environmental impact minimized? | Graviton/ARM choices, efficient utilization, region selection |
A team wants automated deployment pipelines, operational metrics dashboards, and runbooks for common incidents. Which Well-Architected pillar is the primary focus?
- Reliability
- Operational Excellence
- Cost Optimization
CI/CD, observability and runbooks are how a team runs and improves the workload day to day — that is Operational Excellence. Reliability would be the answer if the stem stressed failure recovery or eliminating single points of failure; Cost Optimization if it stressed eliminating waste in spend.
2Pillar exam traps
Three pairings confuse more often than any other on SAA-style stems. Operational Excellence owns how you run and change the system — CI/CD, runbooks, CloudWatch dashboards — while Reliability owns surviving failure through redundancy, automatic recovery and horizontal scaling. A stem that mentions both automation and multi-AZ still has one primary pillar: read which concern the question stresses first.
Cost Optimization and Performance Efficiency both mention using resources well, but Cost asks whether you are paying only for what you need while Performance asks whether the chosen resource type and size fit the workload. Turning off idle instances is Cost; picking Graviton or provisioned IOPS for latency is Performance. IAM roles on EC2, encryption at rest, least privilege and audit logging are Security — even when the service named is S3 or RDS — so do not reassign those stems to Cost or Performance just because a billable service appears.
Stem signals map to pillars: running cost and rightsizing to Cost Optimization, blast radius and recovery to Reliability, least privilege to Security. The stem-signal table is the disambiguation tool — a flowchart of the same forks would restate those rows.
How it works
- Operational vs ReliabilityAutomation, metrics and runbooks → Operational Excellence. Auto-recovery, scaling to meet demand and multi-AZ → Reliability.
- Cost vs PerformanceEliminating waste and cheaper tiers → Cost Optimization. Right-sizing, caching and faster instance families → Performance Efficiency.
- Security boundaryEncryption, IAM, logging and compliance frameworks → Security regardless of which service implements them.
| If the stem stresses… | Primary pillar | Wrong lure |
|---|---|---|
| automated deployments and operational metrics | Operational Excellence | Reliability — failure is not the focus |
| automatic recovery and horizontal scaling | Reliability | Operational Excellence — ops process is not the focus |
| Reserved Instances and lifecycle policies | Cost Optimization | Performance Efficiency — spend, not latency |
| right-sizing and caching for throughput | Performance Efficiency | Cost Optimization — fit, not bill reduction |
Designing a system to automatically recover from failure and to scale horizontally best supports which Well-Architected pillar?
- Cost Optimization
- Reliability
- Operational Excellence
Automatic recovery and horizontal scaling address whether the workload survives disruption and meets demand — the Reliability question. Operational Excellence would fit if the stem stressed deployment automation or runbooks instead.
3RTO and RPO
Recovery Time Objective (RTO) is how quickly the workload must be back online after a disaster — measured in minutes, hours or days. Recovery Point Objective (RPO) is how much data loss is tolerable — how far back in time your restored data may be. Both are business requirements; the architect's job is to pick infrastructure that meets them at acceptable cost.
Tighter RTO demands faster failover or warm capacity standing by. Tighter RPO demands more frequent or continuous replication, which costs more in bandwidth and storage. A stem that gives numeric targets for both is asking you to map those targets onto a disaster-recovery strategy, not to recalculate the numbers.
Figure. RPO is how much data you may lose; RTO is how long service may stay down — different clocks.
How it works
- RTO — time to restore serviceHow long can the business wait before the app is usable again?
- RPO — acceptable data lossHow many minutes or hours of writes can be lost? Near-zero RPO needs continuous replication; true zero RPO needs synchronous replication (or equivalent no-loss commit).
- Both constrain DR designStricter targets push you rightward on the DR cost spectrum toward warm or active standby.
| Target | What it forces | Typical AWS lever |
|---|---|---|
| Short RTO | Warm or active capacity ready to take traffic | Warm Standby, Route 53 failover, Auto Scaling in DR Region |
| Short RPO | Frequent or continuous data copy | Cross-Region replication, DynamoDB global tables, DB read replica promotion |
| Loose RTO/RPO | Backup-based restore acceptable | AWS Backup, S3 versioning, periodic snapshots |
A finance app must lose no more than 30 seconds of transaction data after a Region failure. Which objective does that constrain most directly?
- RTO — the app must restart within 30 seconds
- RPO — at most 30 seconds of data may be lost
- Neither — 30 seconds is an availability percentage
Data-loss tolerance is RPO. RTO would be how quickly service resumes, which could be longer than 30 seconds even when RPO is 30 seconds.
4DR strategy spectrum
AWS disaster-recovery strategies form a cost-versus-speed spectrum. Backup and Restore keeps only backups in a second Region and rebuilds after disaster — cheapest, slowest RTO and loosest RPO. Pilot Light continuously replicates core data but keeps minimal compute running, scaling up on failover. Warm Standby runs a scaled-down but live copy of the stack in another Region, ready to scale to full production. Multi-Site Active/Active runs full production in two or more Regions simultaneously — near-zero RTO and RPO at the highest cost.
Match the strategy to the business targets: RTO in tens of minutes with cost sensitivity often lands on Pilot Light; minute-scale RTO with a live scaled-down stack points to Warm Standby; near-zero RTO and RPO with budget for duplicate capacity points to Active/Active. Backup and Restore is ruled out when the stem names RTO in minutes, not hours or days.
Figure. DR strategies trade cost for RTO/RPO: backup/restore → pilot light → warm standby → active/active.
How it works
- Backup and RestoreBackups off-site; rebuild infrastructure after disaster. Highest RTO/RPO, lowest ongoing cost.
- Pilot Light and Warm StandbyData replicated continuously; compute minimal (pilot) or scaled-down but live (warm). Middle of the spectrum.
- Active/ActiveFull stacks in multiple Regions serving traffic together. Fastest recovery, highest spend.
| Strategy | RTO / RPO (typical) | Cost | Always-on footprint |
|---|---|---|---|
| Backup and Restore | hours to days / hours | lowest | backups only |
| Pilot Light | tens of minutes / minutes | low–medium | core DB + minimal infra |
| Warm Standby | minutes / seconds | medium | scaled-down full stack |
| Multi-Site Active/Active | near zero / near zero | highest | full production in each Region |
A business needs an RTO of about 10 minutes and an RPO of a few seconds for its critical app, balancing cost. Which DR approach fits best?
- Backup and Restore from nightly snapshots
- Warm Standby with continuous database replication
- Multi-Site Active/Active in two Regions
Warm Standby meets minute-scale RTO and second-scale RPO without paying for full duplicate production. Backup and Restore is too slow on RTO; Active/Active exceeds the cost constraint when the stem asks for balance.
5Multi-AZ high availability
High availability within a Region means spreading capacity across at least two Availability Zones so the loss of one AZ does not take down the workload. An Application Load Balancer distributes traffic to healthy targets; an Auto Scaling group replaces unhealthy instances and maintains desired capacity across AZs. The data tier needs the same redundancy — Multi-AZ RDS or replicated state in S3, DynamoDB or EFS — instead of a database on a single instance's disk.
Eliminating a single point of failure almost always means multi-AZ (or multi-Region for disaster recovery) with load balancing and Auto Scaling, not a larger single server or a second Elastic IP on one instance. Use at least two AZs; three AZs help quorum-based services and match AWS's own highly available designs.
Figure. Traffic enters through the load balancer, fans out to instances in two AZs, and reads/writes a Multi-AZ database — no single AZ or instance carries the whole workload.
How it works
- Spread computeAuto Scaling group across ≥2 AZs; ALB health checks route only to healthy targets.
- Remove data SPOFMulti-AZ RDS or managed stores (S3, DynamoDB, EFS) instead of local disk on one EC2.
- Automate replacementUnhealthy instances terminate and relaunch without manual intervention.
A critical web app runs on one large EC2 instance with an Elastic IP. What change best removes the compute single point of failure?
- Upgrade to a larger instance type in the same AZ
- Auto Scaling group across at least two AZs behind an Application Load Balancer
- Attach a second Elastic IP to the same instance
Multi-AZ Auto Scaling with an ALB survives AZ and instance failure. A larger instance or extra Elastic IP still leaves one AZ and one machine.
6Parallel availability math
Component availability is the fraction of time a piece works — 99% means about 3.65 days of downtime per year. Independent components in series multiply availabilities: both must work, so the chain is only as good as its weakest link. Independent components in parallel multiply downtime probabilities: the system stays up if at least one path works.
Exam stems often give two identical 99% components and ask for combined availability. In parallel, downtime probabilities multiply: system availability = 1 − (1 − 0.99)(1 − 0.99) = 99.99%. In series, multiply the availabilities directly: 0.99 × 0.99 = 98.01%. Read whether the diagram shows redundancy (parallel) or a dependency chain (series) before applying the formula.
Figure. Independent redundant components in parallel multiply downtime down; series multiplies availability down.
How it works
- SeriesAll parts must work: multiply availabilities — two 99% parts → 98.01%.
- ParallelEither path suffices: multiply downtime (1 − A), subtract from 1 — two 99% parts → 99.99%.
- Independent redundancyAdding a redundant parallel component always raises availability when failures are independent.
Two 99% components
Two independent servers each offer 99% availability. Find combined availability if they are in parallel (either can serve) and if they are in series (both required).
- Parallel downtime = (1 − 0.99) × (1 − 0.99)0.0001
- Parallel availability = 1 − 0.000199.99%
- Series availability = 0.99 × 0.9998.01%
Pro tip. Parallel redundancy adds nines; series stacks weaknesses. A stem with multi-AZ or load-balanced duplicates is parallel; a pipeline where step B needs step A is series.
Two independent 99%-available components operate in parallel (either one keeps the service up). What is the combined availability?
- 98.01%
- 99.00%
- 99.99%
Parallel: 1 − (0.01)(0.01) = 0.9999 = 99.99%. 98.01% is the series product 0.99²; 99.00% ignores redundancy.
7Warm Standby in practice
Warm Standby is the sweet spot when RTO is measured in minutes and RPO in seconds but paying for full Active/Active is too much. Core data replicates continuously to a second Region; a scaled-down copy of the stack stays running so failover is scale-up plus DNS shift, not rebuild from tape.
On disaster, scale the standby Auto Scaling group to production size, promote or fail over the database replica, and shift traffic with Route 53 health checks or weighted routing. Pilot Light differs by keeping almost no compute always on — acceptable when RTO can stretch to tens of minutes while data stays continuously replicated. Active/Active serves production traffic from both Regions at once — justified only when the stem demands near-zero RTO and RPO with no cost ceiling.
Figure. Warm Standby keeps a live but smaller copy in a second Region with continuous data replication. Failover scales the standby and swings Route 53 — minutes of RTO without paying for full Active/Active.
How it works
- Rule out Backup and RestoreRTO in minutes cannot wait for restore-from-backup rebuilds.
- Rule out Active/ActiveWhen the stem adds cost balance, full duplicate production is overspend.
- Deploy Warm StandbyContinuous DB replication plus scaled-down live stack; scale and fail over Route 53 on disaster.
After a Region failure, a team must restore service in about 10 minutes with at most a few seconds of data loss, without running full duplicate production 24/7. What pattern fits?
- Pilot Light with hourly snapshot restore
- Warm Standby with continuous replication and scaled-down DR stack
- Backup and Restore from weekly archives
Minute-scale RTO and second-scale RPO need warm capacity and continuous replication. Pilot Light and Backup and Restore are too slow on RTO; the stem rejects always-on full duplication.
Notes
- Six Pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability guide well-architected design and trade-off decisions.
- Reliability Pillar: Emphasizes recovery from failure, automatic scaling, and eliminating single points of failure via multi-AZ and multi-Region designs.
- High Availability: Deploy across multiple Availability Zones so the loss of one AZ does not take down the workload; use ELB and Auto Scaling to spread and replace capacity.
- RTO and RPO: Recovery Time Objective is how quickly you must recover; Recovery Point Objective is how much data loss is tolerable - both drive the DR strategy choice.
- DR Strategies: Backup & Restore (cheapest, slow), Pilot Light, Warm Standby, and Multi-Site Active/Active (fastest recovery, highest cost).
Formulas
- Number of pillars: 6 (Sustainability was added as the sixth pillar in 2021).
- DR spectrum: Backup & Restore has the highest RTO/RPO and lowest cost; Multi-Site Active/Active has near-zero RTO/RPO and highest cost.
- AZ design: use at least 2 AZs (ideally 3) for quorum-based and highly available services.
- Availability math: adding independent redundant components multiplies availability, e.g., two 99% components in parallel approach 99.99%.
- Pilot Light: core data replicated continuously; minimal always-on infrastructure scaled up on disaster.
Exam traps & shortcuts
- Match DR strategy to RTO/RPO: minutes-to-hours and cost-sensitive => Pilot Light/Warm Standby; near-zero => Active/Active.
- 'Eliminate single point of failure' almost always means multi-AZ (or multi-Region) with load balancing and Auto Scaling.
- If a question stresses operational metrics and automation of deployments, that's the Operational Excellence pillar.
- Tighter (smaller) RPO requires more frequent/continuous replication, which costs more - map the requirement to the cheapest strategy that still meets it.
Reference tables
Pillar signals, DR placement and HA moves that recur on SAA-style stems.
| Topic | Remember | Exam trap |
|---|---|---|
| Six pillars | Sustainability is the sixth pillar (2021) | Five-pillar answer keys on older stems |
| Operational vs Reliability | Ops = run/change; Reliability = survive/scale | Auto-recovery stems → Reliability, not Operational Excellence |
| RTO vs RPO | RTO = time to restore; RPO = data loss window | Do not swap them when seconds of data loss are stated |
| DR spectrum | Backup ← Pilot ← Warm ← Active/Active | Minute RTO rules out Backup and Restore |
| HA in a Region | ≥2 AZs + ALB + Auto Scaling + Multi-AZ data | Bigger instance or second Elastic IP is not HA |
| Availability math | Parallel: 1 − ∏(1 − A_i); Series: ∏ A_i | Two 99% parallel → 99.99%, not 98.01% |
Recap
Read this before a practice block on Well-Architected and resilience.
- Pillars
- Six pillars from 2021 — map the stem's primary concern to one column; Sustainability is real even when options list five.
- Traps
- CI/CD and runbooks → Operational Excellence; auto-recovery and scaling → Reliability; do not swap them.
- RTO / RPO
- RTO is time to restore service; RPO is tolerable data loss — tighter RPO needs more replication spend.
- DR pick
- Backup and Restore is slow and cheap; Warm Standby fits minute RTO with balanced cost; Active/Active is fastest and priciest.
- HA
- Multi-AZ with ALB, Auto Scaling and Multi-AZ RDS — not a bigger box or extra Elastic IP.
- Math
- Parallel 99% + 99% → 99.99%; series 99% × 99% → 98.01%.
Practise Well Architected Framework and Resilience
Reading is free and needs no account. Practice, mocks and progress live in the app.
- 5 exam-style questions on this topic, with explanations
- A 6-question practice set that ends the chapter
- Timed mocks scored with the real marking scheme
- Readiness tracked per topic, kept on your device