Well-Architected Framework and Trusted Advisor

By the end of this lesson you will be able to

• Explain what the AWS Well-Architected Framework is (a body of guidance: design principles, pillars, questions and best practices, not a service you deploy) and use it as the yardstick every exam answer is judged by.
• Apply the six general design principles, including “improve through game days”, and say what each one changes in a design.
• Name the six pillars with their goals, their main design principles, the services from this course that implement them, and the exam keywords that point to each; recognise when pillars help each other and when the question forces a trade-off.
• Run a review in the AWS Well-Architected Tool: workloads, lenses, high and medium risk issues, improvement plans, milestones, profiles, review templates, sharing and integrations.
• Describe AWS Trusted Advisor: its six check categories, typical checks, status colours, what each support plan unlocks after the 2025–26 support plan changes, the API, EventBridge and organizational view.
• Tell the Well-Architected Tool, Trusted Advisor, AWS Config, Compute Optimizer, the AWS Health Dashboard and their neighbours apart, and know where reference architectures and the Disaster Recovery whitepaper fit.

#Why a framework: judging an architecture

Every chapter of this course ended with choices: one AZ or three, On-Demand or Spot, SQS or Kinesis, pilot light or warm standby. How do you know a design is good? AWS answers with the Well-Architected Framework: a set of documents in which AWS writes down what it learned from reviewing many thousands of customer architectures.

The framework is guidance, not a service. Nothing is deployed and nothing is billed. It contains:

• General design principles for building in the cloud (next section).
• Six pillars, each with its own design principles, a set of questions (“How do you back up data?”) and best practices that a good answer would include.
• Lenses: extra questions for a kind of workload (serverless, SaaS, financial services and more).

It is published as the AWS Well-Architected Framework whitepaper and one whitepaper per pillar, all on docs.aws.amazon.com/wellarchitected. The free AWS Well-Architected Tool (later in this lesson) turns the questions into a questionnaire you answer for your own workload.

#The general design principles

Before the pillars, the framework lists six principles that apply to every design. They are what changes when you stop owning a data centre (lesson 1.1).

The slides use the older wording of two of them (“automate to make architectural experimentation easier”, “allow for evolutionary architectures”); the meaning is the same.

#Improve through game days

A game day is a planned rehearsal: you write a hypothesis (“at 10× traffic checkout stays under 1 second”, “if one AZ fails, users notice nothing”), cause the event on purpose, watch, and fix what breaks. Load generators create the traffic; AWS Fault Injection Service injects failures in a controlled way (stop instances, fail over a database, disrupt an AZ) with stop conditions that halt the experiment if real damage starts (lesson 23.1 covers drills and chaos testing for DR).

#The six pillars

The framework judges a design through six pillars. Learn their names, their one-line goal, and the words that point to each.

Sustainability is the newest: it was added in late 2021 (the Well-Architected Tool gained it in March 2022), which is why older material lists five pillars. Lessons 1.1 and 9.1 gave you a first look; here is each one in depth.

#Operational excellence

Goal: run the workload well, see what it is doing, and keep improving how you operate it.

Design principles (AWS names eight; the five most examined):

• Safely automate where possible: define the whole workload and its operations as code, triggered by events, with guardrails such as rate limits and approvals.
• Make frequent, small, reversible changes: smaller deployments mean a smaller blast radius and a quick rollback.
• Implement observability for actionable insights: metrics, logs and traces tied to business outcomes, so you act before customers notice.
• Anticipate failure and learn from all operational events: rehearse failures, run post-incident reviews, share the lessons.
• Use managed services: less undifferentiated operational work.

Services in this course: CloudFormation and IaC (lesson 25.1), Systems Manager runbooks, Patch Manager and Session Manager (lesson 25.3), CloudWatch metrics, logs, alarms and dashboards (lessons 19.1 to 19.4), X-Ray, EventBridge automation (19.5), Elastic Beanstalk (9.4).

Exam keywords: “least operational overhead”, “automate deployments”, “infrastructure as code”, “roll back quickly”, “runbook”, “monitor and respond to events”, “reduce manual effort”.

Example: a ride-sharing startup that deploys by hand over SSH every Friday night moves to CloudFormation and an automated pipeline with one-click rollback. Releases become small and boring, which is exactly the point.

#Security

Goal: protect information, systems and assets while still delivering value.

Design principles:

• Implement a strong identity foundation: least privilege, separation of duties, central identity, no long-term static credentials.
• Maintain traceability: log, monitor and alert on every action and change.
• Apply security at all layers: defence in depth from the network edge to the code.
• Protect data in transit and at rest: classify data and use encryption, tokenisation and access control.
• Keep people away from data, automate security best practices, and prepare for security events (incident response plans and simulations).

Services in this course: IAM, roles and MFA (Chapter 2), Organizations and SCPs (20.1), KMS (21.2), ACM (21.4), Secrets Manager (21.3), AWS WAF and Shield (21.6), GuardDuty, Inspector, Macie and Security Hub (21.7), CloudTrail (19.6), security groups and NACLs (3.5).

Exam keywords: “protect data at rest and in transit”, “least privilege”, “temporary credentials”, “audit who did what”, “encrypt with keys we control”, “detect threats”, “block common web exploits”.

Example: a microfinance app that stores scanned national ID cards encrypts them with SSE-KMS and a customer managed key, so every use of the key appears in CloudTrail, and no engineer can read the bucket without a role that the security team approves.

#Reliability

Goal: the workload performs its intended function correctly and consistently, and recovers quickly from failure.

Design principles (all five):

• Automatically recover from failure: watch key indicators and trigger recovery automatically.
• Test recovery procedures: simulate failures and prove that restores and failovers work.
• Scale horizontally to increase aggregate workload availability: many small resources instead of one big one, so one failure is small.
• Stop guessing capacity: watch demand and add or remove resources automatically (saturation is a classic cause of outages; quotas still exist).
• Manage change through automation: changes to infrastructure go through automation that is tracked and reviewed.

Services in this course: Multi-AZ RDS and Aurora (7.1, 7.3), Auto Scaling groups across AZs (6.5), load balancer health checks (6.2), Route 53 health checks and failover (8.3, 8.4), SQS decoupling (13.1), backups and DR (23.1, 23.2), Service Quotas.

Exam keywords: “recover from failure”, “highly available”, “fault tolerant”, “survive the loss of an AZ / a Region”, “RTO and RPO”, “no single point of failure”, “self-healing”.

Example: a hospital that takes nightly backups but has never restored one does not have a backup; it has a hope. Restoring every month and timing it against the RTO is the “test recovery procedures” principle.

#Performance efficiency

Goal: use computing resources efficiently to meet requirements, and keep that efficiency as demand and technology change.

Design principles (all five):

• Democratise advanced technologies: consume hard things (NoSQL, machine learning, media transcoding) as services instead of building them.
• Go global in minutes: deploy in several Regions and at the edge for lower latency.
• Use serverless architectures: no servers to run for many jobs.
• Experiment more often: try other instance types, storage or configurations quickly.
• Consider mechanical sympathy: choose the technology that fits the access pattern (a graph database for relationships, a cache for hot reads).

Services in this course: CloudFront (11.1) and Global Accelerator (11.4), ElastiCache and DAX (7.5, 15.5), read replicas (7.1), purpose-built databases (16.1, 16.2), Lambda and serverless designs (15.8), instance families and placement groups (4.1, 4.5), EBS volume types (5.2).

Exam keywords: “lowest latency”, “global users”, “millisecond / microsecond response”, “read-heavy”, “high throughput”, “the right instance type”, “improve performance”.

Example: a Bangladeshi e-learning site hosted in Mumbai adds students in Malaysia and the Gulf; CloudFront serves the videos from edge locations near them instead of moving the whole platform.

#Cost optimization

Goal: run systems that deliver business value at the lowest price point.

Design principles (all five):

• Implement cloud financial management: give cost an owner, a process and tools, like security.
• Adopt a consumption model: pay for what you use; a development environment used 8 hours on workdays can be stopped for the rest, saving about 75%.
• Measure overall efficiency: cost per unit of business output (per order, per student).
• Stop spending money on undifferentiated heavy lifting: managed services instead of racking servers and patching databases yourself.
• Analyse and attribute expenditure: tags and reports show which team or product spends what.

Services in this course: purchasing options, Savings Plans and Spot (4.4), S3 storage classes and lifecycle (10.5), right-sizing with Compute Optimizer (4.1), Cost Explorer, Budgets and Cost Anomaly Detection (1.4, 25.4), Instance Scheduler (25.5), networking costs (22.8).

Exam keywords: “most cost-effective”, “lowest cost”, “reduce cost”, “idle”, “underutilised”, “pay only when used”, “infrequently accessed”, “interruptible workload”.

Example: a Dhaka software firm keeps 30 development instances running 24/7 although developers work 9 to 6, Sunday to Thursday. Stopping them out of hours cuts that line of the bill by about three quarters.

#Sustainability

Goal: reduce the energy and resources each workload needs, and so its environmental impact.

Design principles (AWS names six):

• Understand your impact and establish sustainability goals: measure, for example with the customer carbon footprint tool in the billing console, and set targets per transaction or per user.
• Maximise utilisation: two hosts at 30% use more energy than one at 60%; right-size and remove idle resources.
• Anticipate and adopt new, more efficient hardware and software: for example Graviton (Arm) processors.
• Use managed services: shared infrastructure at AWS scale (Fargate, Lambda, S3 lifecycle, Auto Scaling).
• Reduce the downstream impact of your cloud workloads: lighter apps that do not force users to buy new phones.

Services in this course: right-sizing and Graviton instances (4.1), Auto Scaling (6.5), serverless and Fargate (15.1, 14.2), S3 lifecycle and Intelligent-Tiering (10.5), choosing a Region (AWS publishes which Regions run closer to fully renewable power; latency and data rules still come first).

Exam keywords: “reduce carbon footprint”, “environmental impact”, “energy efficiency”, “minimise the resources provisioned”.

#Shared responsibility in two pillars

Two pillars explicitly split the work with AWS, following the shared responsibility model from lesson 1.1:

• Security: AWS secures of the cloud (facilities, hardware, the virtualisation layer); you secure what you put in it (IAM, data, encryption settings, security groups, patches on your instances).
• Sustainability: AWS is responsible for the sustainability of the cloud (efficient shared infrastructure, renewable power, water stewardship); you are responsible for sustainability in the cloud (right-sizing, utilisation, deleting what you do not need, choosing efficient services).

#A synergy, but the question names a priority

The slides say the pillars are “not something to balance, or trade-offs, they’re a synergy”. Often that is true: Graviton plus right-sizing improves cost, performance and sustainability at once; infrastructure as code helps operations, security and reliability together.

But be honest: real designs do trade. A multi-site active/active DR setup gives the best reliability and roughly doubles the bill. Encrypting and inspecting everything adds a little latency. The framework’s own guidance says to choose deliberately, based on business priorities.

In the exam this is the most important habit of the whole course: find the priority word in the question and honour it. “Most cost-effective” with an RTO of 30 minutes means pilot light, not multi-site. “Highest availability regardless of cost” means multi-site. “Least operational overhead” beats a cheaper option that you must run yourself.

#The AWS Well-Architected Tool

#A free questionnaire for one workload

The AWS Well-Architected Tool is a free service in the AWS console that turns the framework’s questions into a questionnaire for one workload. You answer; it compares your answers with the best practices and tells you where the risks are. It does not deploy, scan or change anything by itself.

#How a review works

1. Define a workload: a name, a description, the environment (production or pre-production), the AWS Regions (or non-AWS locations, such as an on-premises data centre), a review owner, and optionally the accounts, an architecture diagram link and an industry.
2. Apply lenses: the Well-Architected Framework lens is always applied; add others from the Lens Catalog or your custom lenses.
3. Answer the questions pillar by pillar: for each question, tick the best practices you really follow, mark questions or choices that do not apply, and add notes. Do it as a workshop with the people who build and run the workload.
4. Read the risks: the tool marks each question as a high risk issue (HRI: a choice AWS has found might have a significant negative impact on the business) or a medium risk issue (MRI: a smaller impact), or no risk.
5. Use the improvement plan: the questions with risks, ordered by your pillar priorities with HRIs first, each linked to the best practice, guidance and videos.
6. Save a milestone: a frozen copy of the review at that moment (“Before Eid review”). After fixes, update the answers and save another; the dashboard compares them.
7. Report and share: generate a PDF report, view the dashboard (and a consolidated report across workloads), and share a workload or custom lens with other IAM users, accounts or the whole organization.

#Features added since the slides

• Trusted Advisor integration (2022, enhanced 2023): related Trusted Advisor check results appear next to the questions, so answers meet evidence from the live account. The resources are found through applications registered in AWS Service Catalog, or through tags; the checks you see still depend on your support plan.
• Profiles (June 2023): you record business context and priorities, and the tool prioritises the questions that matter most for them.
• Review templates (October 2023): pre-filled answers and notes for many similar workloads, for example the shared landing zone answers every team would otherwise retype.
• Jira connector (April 2024): improvement items sync to a Jira project as issues, and their status flows back.
• API and CLI (aws wellarchitected …): create workloads, read risk counts and improvement items, create milestones from scripts.

#AWS Trusted Advisor

#An automatic check-up of the account

AWS Trusted Advisor is an automated check-up of your whole account. There is nothing to install: it reads your resources’ configuration and usage through a service-linked role and runs AWS’s own list of best-practice checks, then recommends actions. Where the Well-Architected Tool asks you questions, Trusted Advisor looks for itself.

#Six categories

The notes list five categories. There are six: the slide already shows the sixth.

1. Cost optimization: unused or underused resources and savings opportunities.
2. Performance: speed and responsiveness.
3. Security: settings that leave the account exposed.
4. Fault tolerance: redundancy and resiliency gaps.
5. Service limits: usage close to or over a quota.
6. Operational excellence: operating the environment effectively at scale (for example logging switched off).

#Example checks

Many checks now come from other services: some are powered by AWS Config rules or Security Hub CSPM controls, and the cost checks can show Compute Optimizer right-sizing results when you opt in.

#Status colours, refresh and notifications

• Red: action recommended. Yellow: investigation recommended. Green: no problem detected. Grey counts checks with items you chose to exclude.
• With a plan that includes all checks, Trusted Advisor refreshes them automatically every week; you can also refresh a check on demand. On Basic Support you refresh the security checks by hand.
• A weekly email summarises results for the contacts you choose.
• Check status changes go to Amazon EventBridge, where a rule can notify SNS or run Lambda (lesson 19.5).
• Programmatic access: the Trusted Advisor API (aws trustedadvisor …, 2023) or the older Trusted Advisor operations in the AWS Support API (aws support describe-trusted-advisor-checks, us-east-1 endpoint). Both need a paid plan that includes all checks.
• Organizational view: the management account of an AWS Organization can build a report across all member accounts.
• Trusted Advisor Priority: for Enterprise Support and Unified Operations customers, the AWS account team adds prioritised recommendations (from Trusted Advisor, Security Hub, Well-Architected and their own analysis) and tracks them to resolution across the organization.

#What your support plan unlocks

#Well-Architected Tool vs Trusted Advisor vs the neighbours

The notes call this confusion “very important” for the exam. The key contrast in one line: in the Well-Architected Tool you answer questions about one workload; Trusted Advisor scans the account automatically.

And the other look-alikes:

#AWS Health Dashboard

The AWS Health Dashboard shows events about AWS itself that may affect you. It has two views:

• Service health: the public status of every AWS service in every Region (no sign-in needed). Is there an issue with EC2 in ap-southeast-1 right now?
• Your account health: events for your resources: scheduled maintenance or retirement of the hardware under your EC2 instances, an RDS engine version reaching end of support, an issue in an AZ where you run instances, certificate or key events. This view was once called the Personal Health Dashboard; since 2022 both views live in the AWS Health Dashboard, and older questions may still use the old name.

All accounts get the dashboard at no cost, and all accounts receive AWS Health events in Amazon EventBridge, so a rule can open a ticket or run an automation when maintenance is scheduled (lesson 19.5). The AWS Health API (for your own tools) needs Business Support+, Enterprise Support or Unified Operations (or the legacy Business and Enterprise plans). With AWS Organizations, an organizational view aggregates Health events for every member account.

#Reference architectures: do not start from a blank page

For a real project (an e-commerce site, a gaming backend, a data lake) you rarely need to invent the design. AWS publishes proven ones:

• AWS Architecture Center (aws.amazon.com/architecture): reference architecture diagrams, patterns, whitepapers and guides, grouped by technology and industry. The slides’ two families are both there: classic (EC2, ELB, RDS, ElastiCache) and serverless (S3, Lambda, DynamoDB, CloudFront, API Gateway), the same ones you built in Chapters 9 and 15.
• AWS Solutions Library (aws.amazon.com/solutions): vetted solutions you can deploy, many built by AWS with a CloudFormation template and an implementation guide. Instance Scheduler on AWS (lesson 25.5) is one of them.
• AWS Prescriptive Guidance (side note): step-by-step strategies, guides and patterns for migrations and modernisation.

#The Disaster Recovery whitepaper in one table

The section overview of the slides ends with the Disaster Recovery of Workloads on AWS whitepaper, the companion of the Reliability pillar. You studied it in depth in lesson 23.1 (RPO, RTO, the four strategies) and lesson 23.2 (Elastic Disaster Recovery, AWS Backup). The recap:

• RTO (recovery time objective): how long the system may be down after a disaster, for example 2 hours.
• RPO (recovery point objective): how much data, measured in time, you may lose, for example the last 1 hour of writes.

The cheaper the strategy, the longer the recovery. The method from 23.1: find the RTO and the RPO, take the stricter, then pick the cheapest strategy that meets both.

#Which pillar? Which tool?

Practise both habits from this lesson: put a requirement on the right pillar, and send a question to the right tool.

#What goes wrong

#Well-Architected in system design

• A rhythm, not a ceremony. Review a workload before launch, before peak events (Eid, 11.11, admission season), after major changes and after significant incidents. Save a milestone each time.
• Prevent, detect, review. SCPs, IAM and service settings prevent (lesson 20.1); Config and Security Hub detect continuously; Trusted Advisor gives a weekly best-practice view; the Well-Architected review covers design and process that no scanner sees.
• Shared answers at scale. In a multi-account organization, review templates hold the landing zone’s common answers, a custom lens holds company standards, and shared workloads let a central architecture team see every team’s risks.
• Decide with the requirement. Every architecture answer in this course was a pillar trade-off. State the priority (availability target, budget, latency, carbon goal) before choosing services; that is also how to read every exam question (lesson 26.2).
• Rehearse. Game days and DR drills turn the diagram into evidence.

#Try it yourself

Create a workload in the Well-Architected Tool, read its risks, save a milestone, and query Trusted Advisor and AWS Health. Output is shortened; IDs and numbers are examples. The Well-Architected Tool is free; the Trusted Advisor, Support and Health API calls need Business Support+ or higher (on Basic they return a subscription error).

1. 1. Define a workload

   aws wellarchitected create-workload \
     --workload-name wallet-payments \
     --description "Payments API before the Eid peak" \
     --environment PRODUCTION \
     --aws-regions ap-southeast-1 ap-south-1 \
     --review-owner architect@example.com \
     --lenses wellarchitected serverless
   

   { "WorkloadId": "0123456789abcdef0123456789abcdef",
     "WorkloadArn": "arn:aws:wellarchitected:ap-southeast-1:111122223333:workload/0123456789abcdef0123456789abcdef" }
   

   --description, --environment, --lenses and either --aws-regions or --non-aws-regions are required; the API also expects a review owner. Now open the workload in the console and answer the questions with your team.

2. 2. Read the risk counts and the improvement plan

   aws wellarchitected get-lens-review --workload-id 0123456789abcdef0123456789abcdef \
     --lens-alias wellarchitected --query 'LensReview.RiskCounts'
   
   aws wellarchitected list-lens-review-improvements \
     --workload-id 0123456789abcdef0123456789abcdef --lens-alias wellarchitected \
     --pillar-id reliability \
     --query 'ImprovementSummaries[].{q:QuestionTitle,risk:Risk}'
   

   { "HIGH": 9, "MEDIUM": 14, "NONE": 31, "NOT_APPLICABLE": 2, "UNANSWERED": 1 }
   [ { "q": "How do you back up data?", "risk": "HIGH" },
     { "q": "How do you test reliability?", "risk": "HIGH" },
     { "q": "How do you design your workload to withstand component failures?", "risk": "MEDIUM" } ]
   

3. 3. Save a milestone, fix, compare

   aws wellarchitected create-milestone --workload-id 0123456789abcdef0123456789abcdef \
     --milestone-name "Before Eid review"
   
   # after the fixes and updated answers
   aws wellarchitected create-milestone --workload-id 0123456789abcdef0123456789abcdef \
     --milestone-name "Eid ready"
   aws wellarchitected list-milestones --workload-id 0123456789abcdef0123456789abcdef \
     --query 'MilestoneSummaries[].{n:MilestoneName,risk:WorkloadSummary.RiskCounts.HIGH}'
   

   [ { "n": "Eid ready", "risk": 3 }, { "n": "Before Eid review", "risk": 9 } ]
   

4. 4. List Trusted Advisor recommendations (Business Support+ or higher)

   aws trustedadvisor list-recommendations --status error --region us-east-1 \
     --query 'recommendationSummaries[].{name:name,pillars:pillars,status:status}'
   
   # the older Support API, us-east-1 only
   aws support describe-trusted-advisor-checks --language en --region us-east-1 \
     --query 'checks[?category==`cost_optimizing`].name' | head
   

   [ { "name": "Amazon S3 Bucket Permissions", "pillars": ["security"], "status": "error" } ]
   [ "Low Utilization Amazon EC2 Instances", "Unassociated Elastic IP Addresses",
     "Idle Load Balancers", "Underutilized Amazon EBS Volumes", ... ]
   

   On Basic Support these calls fail with a subscription error: that is the plan difference in practice.

5. 5. Get alerted when a check turns red

   aws events put-rule --region us-east-1 --name ta-red-security --event-pattern '{
     "source": ["aws.trustedadvisor"],
     "detail-type": ["Trusted Advisor Check Item Refresh Notification"],
     "detail": { "status": ["ERROR"] } }'
   
   aws events put-targets --region us-east-1 --rule ta-red-security \
     --targets Id=sec,Arn=arn:aws:sns:us-east-1:111122223333:security-alerts
   

   Trusted Advisor sends these events in us-east-1.

6. 6. Look at AWS Health events

   aws health describe-events --region us-east-1 \
     --filter eventStatusCodes=open,upcoming \
     --query 'events[].{svc:service,type:eventTypeCode,region:region,start:startTime}'
   

   [ { "svc": "EC2", "type": "AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED",
       "region": "ap-southeast-1", "start": "2026-11-12T03:00:00+06:00" } ]
   

   The dashboard itself and the EventBridge events are free for every account; the API needs Business Support+ or higher.

7. 7. Clean up

   aws events remove-targets --region us-east-1 --rule ta-red-security --ids sec
   aws events delete-rule --region us-east-1 --name ta-red-security
   aws wellarchitected delete-workload --workload-id 0123456789abcdef0123456789abcdef
   

#Summary

Key takeaways

• The Well-Architected Framework is AWS’s written best practice (design principles, six pillars, questions, best practices, lenses), not a service. “Where do I find best practices for cloud architecture?” → the framework. Never call it “WAF”: that is AWS WAF.
• General design principles: stop guessing capacity, test at production scale, automate with experimentation in mind, consider evolutionary architectures, drive architectures using data, improve through game days (rehearse the flash sale, kill an AZ on purpose, Fault Injection Service).
• Six pillars and their keywords: Operational excellence (automate, IaC, observe, small reversible changes, least overhead), Security (identity, traceability, all layers, data at rest and in transit), Reliability (recover automatically, test recovery, scale horizontally, Multi-AZ, DR), Performance efficiency (go global, serverless, right resource, mechanical sympathy), Cost optimization (consumption model, right-size, Savings Plans, Spot, storage classes), Sustainability (carbon footprint, maximise utilisation, Graviton, managed services). Security and Sustainability both have an “of the cloud / in the cloud” split.
• Pillars often reinforce each other, but real designs trade; honour the priority the question names (“most cost-effective” vs “highest availability regardless of cost”).
• Well-Architected Tool: free questionnaire for one workload; lenses (Lens Catalog, custom), HRIs and MRIs, improvement plan, milestones, profiles, review templates, sharing, reports, Trusted Advisor and Jira integrations. It only knows what you answer.
• Trusted Advisor: automatic account scan, nothing installed, six categories (cost, performance, security, fault tolerance, service limits, operational excellence; the notes’ five is outdated). Red / yellow / green. Basic and Developer: core security checks and service limits only; Business Support+ and higher: all checks, APIs, EventBridge, weekly refresh; Priority with Enterprise. Support plans changed in 2025–27.
• Contrast: Well-Architected Tool = you answer about a design; Trusted Advisor = AWS scans live resources; Config = every change against your rules; Compute Optimizer = right-sizing; Health Dashboard = AWS events affecting you (all accounts, EventBridge; the API needs Business Support+).
• Reference architectures: Architecture Center (diagrams), Solutions Library (deployable); Quick Starts became Partner Solutions (2023) and the program has ended.
• DR whitepaper: RPO, RTO, backup and restore → pilot light → warm standby → multi-site; hot standby is active/passive; details in 23.1.

Self-check: Well-Architected and Trusted Advisor30 questions