🎯 By the end of this module you should be able to…
- Explain what the Well-Architected Framework is and how a review is run.
- Name the six pillars and state the central question each one asks.
- Give the key design principles of the Operational Excellence and Security pillars.
- Distinguish reliability from high availability, and RTO from RPO.
- Compare the four disaster-recovery strategies by cost and recovery time.
- Describe Trusted Advisor's categories and what a check actually reports.
- Interpret a Trusted Advisor recommendation and decide what to do about it.
The Well-Architected Framework
A set of questions AWS uses to review an architecture, distilled from many thousands of customer reviews. It is not a certification and not a product — it is a structured conversation, and the free Well-Architected Tool in the console records the answers and produces an improvement plan.
⚙️ 1. Operational Excellence
Can we run and monitor systems, and keep improving how we do it?
🔒 2. Security
Can we protect data, systems and assets — and detect it when something goes wrong?
🔄 3. Reliability
Does the workload do what it is supposed to, correctly and consistently, and recover from failure?
⚡ 4. Performance Efficiency
Are we using computing resources efficiently, and can we stay efficient as demand changes?
💰 5. Cost Optimization
Are we delivering business value at the lowest price point?
🌱 6. Sustainability
Are we minimising the environmental impact of running this workload?
Sustainability was added in 2021. A lot of older study material still lists five. If a question offers both, six is correct.
The general design principles
- 📏Stop guessing your capacity needs Scale automatically instead of buying for an imagined peak.
- 🧪Test systems at production scale In the cloud you can create a full-size test environment and delete it afterwards.
- 🤖Automate to make experimentation easier Infrastructure as code makes a change cheap to try and cheap to undo.
- 🔄Allow for evolutionary architectures Your design should be able to change as requirements do.
- 📊Drive architectures using data Measure, then decide. CloudWatch exists for this.
- 🎮Improve through game days Rehearse failure on purpose, so the real one is boring.
Operational Excellence and Security
Operational Excellence — design principles
AWS now lists eight. Older material says five, so learn the current list.
| # | Principle | What it means in practice |
|---|---|---|
| 1 | Organise around business outcomes | Teams should understand what the workload is for, not just what it runs on. |
| 2 | Perform operations as code | Infrastructure and runbooks in version control; no undocumented clicking. |
| 3 | Implement observability | Metrics, logs and traces that let you understand internal state — Module 9. |
| 4 | Make frequent, small, reversible changes | A small change that fails is easy to diagnose and easy to roll back. |
| 5 | Refine operations procedures frequently | The runbook is a living document. |
| 6 | Anticipate failure | Pre-mortems and game days, before the real incident. |
| 7 | Learn from all operational events | Blameless post-incident reviews that produce actions. |
| 8 | Use managed services | Let AWS carry the undifferentiated operational load. |
Security — design principles
- 🔐Implement a strong identity foundation Least privilege, and separation of duties enforced by IAM.
- 👁️Enable traceability Log and audit everything: CloudTrail, Config, VPC Flow Logs.
- 🧅Apply security at all layers Edge, VPC, subnet, instance, OS, application — defence in depth.
- 🤖Automate security best practices Guardrails as code, so compliance does not depend on somebody remembering.
- 🗝️Protect data in transit and at rest TLS everywhere, KMS for storage, classification so you know what matters.
- 🚫Keep people away from data Remove the need for direct human access — use tooling instead.
- 🚨Prepare for security events An incident response plan you have actually rehearsed.
Reliability, Performance Efficiency, Cost and Sustainability
Reliability
🔄 Automatically recover from failure
Monitor key indicators and trigger remediation before a human notices.
🧪 Test recovery procedures
Do not just test that it works — test that recovery works. Most outages are long because recovery was never rehearsed.
↔️ Scale horizontally
Several small resources beat one large one, because the failure of one is survivable.
🤖 Manage change in automation
Change infrastructure through code so changes are reviewable and repeatable.
Performance Efficiency
Democratise advanced technologies (use managed services rather than becoming an expert in everything), go global in minutes, use serverless where it fits, experiment often, and choose the right tool for the job — a data warehouse is the wrong place to store shopping carts and vice versa.
Cost Optimization
| Practice | Concrete action |
|---|---|
| Adopt a consumption model | Stop development instances at night and at weekends. |
| Measure overall efficiency | Track cost per customer or per transaction, not just total spend. |
| Stop spending on undifferentiated work | Use S3 and RDS instead of running your own storage and database servers. |
| Analyse and attribute expenditure | Tag everything; use Cost Explorer to see who spends what. |
| Use the right pricing model | Savings Plans for steady load, Spot for batch, On-Demand for spiky. |
| Manage data lifecycle | S3 lifecycle rules to move cold data to Glacier automatically. |
Sustainability
Right-size so you are not running idle capacity, prefer managed services with high utilisation, choose efficient instance types such as Graviton, delete unused data, and set user-experience targets that do not demand more resource than the job needs.
Reliability and high availability in practice
| Term | Definition | Question it answers |
|---|---|---|
| Reliability | The system performs its function correctly and consistently | Does it do the right thing? |
| Availability | The proportion of time the system is usable | Is it up? |
| Durability | The probability that stored data survives | Is my data still there? |
| RTO | Recovery Time Objective | How long may we be down? |
| RPO | Recovery Point Objective | How much data may we lose? |
What the nines actually cost you
| Availability | Downtime per year | Downtime per month | Typical design |
|---|---|---|---|
| 99% | 3.65 days | 7.2 hours | One server, backups |
| 99.9% — three nines | 8.77 hours | 43.8 minutes | Multi-AZ with automatic failover |
| 99.95% | 4.38 hours | 21.9 minutes | Multi-AZ, load balanced, auto scaling |
| 99.99% — four nines | 52.6 minutes | 4.4 minutes | Multi-Region active–passive |
| 99.999% — five nines | 5.26 minutes | 26 seconds | Multi-Region active–active, very expensive |
The four disaster-recovery strategies
| Strategy | RTO | RPO | Cost | How it works |
|---|---|---|---|---|
| Backup & restore | Hours | Hours | $ | Back up to S3; rebuild when needed. |
| Pilot light | Tens of minutes | Minutes | $$ | Core services (usually the database) replicating and running; the rest is off. |
| Warm standby | Minutes | Seconds | $$$ | A scaled-down but fully working copy running all the time. |
| Multi-site active–active | Near zero | Near zero | $$$$ | Full capacity in two Regions, both serving traffic. |
Building blocks in AWS
AWS Trusted Advisor
An automated adviser that inspects your account and reports where it differs from AWS best practice. Think of it as a Well-Architected review that runs continuously and needs no meeting.
| Category | Example checks |
|---|---|
| 💰 Cost Optimization | Idle load balancers, under-utilised EC2 instances, unattached EBS volumes, unassociated Elastic IPs, Reserved Instance opportunities |
| ⚡ Performance | High-utilisation instances, over-utilised EBS volumes, CloudFront not used for static content |
| 🔒 Security | Security groups open to 0.0.0.0/0, public S3 buckets, MFA missing on root, exposed access keys, expiring certificates |
| 🔄 Fault Tolerance | Single-AZ deployments, missing backups, ASGs without health checks, no Multi-AZ on RDS |
| 📏 Service Limits | Usage approaching an account quota — flagged at 80% |
| ⚙️ Operational Excellence | Gaps in logging, monitoring and change management |
How to read a recommendation
| Status | Means | What to do |
|---|---|---|
| 🟢 Green | No problem found | Nothing |
| 🟡 Yellow | Investigation recommended | Look at it this sprint |
| 🔴 Red | Action recommended | Fix it now, or write down why not |
A recommendation is a signal, not an instruction. "Idle load balancer" may be a disaster-recovery standby that is meant to be idle. Read the finding, understand the context, then act — and record the reason when you choose not to.
Basic and Developer plans expose only the core checks — mostly service limits and a handful of security checks. The full set of checks requires a business-level paid plan or higher. AWS is replacing the current plan names from 1 January 2027, but that gating principle is unchanged.
Key takeaways
- ✅Six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability.
- ✅The Well-Architected Tool is free and turns the review into a documented improvement plan.
- ✅Operational Excellence now lists eight design principles, not five.
- ✅RTO is how long you may be down; RPO is how much data you may lose.
- ✅Backup & restore → pilot light → warm standby → active–active, in increasing cost and decreasing RTO.
- ✅Multi-AZ is the baseline for high availability; multi-Region is for four nines and above.
- ✅Trusted Advisor has six categories; red means act, yellow means investigate.
- ✅The full Trusted Advisor check set needs a paid business-level support plan.