The previous module ended with MercadoFresco's architecture complete: elastic, secure, observable, deployable from a pipeline, described in code and spread across five working accounts. And with an uncomfortable question waiting for Monday morning. Before answering how much it costs, it is worth answering something that comes first: is it well built? Not "does it work?" — it works — but "would it survive an honest audit?".

This lesson introduces the method AWS publishes for running that audit: the Well-Architected Framework. You will see what it is and what it is not, the six pillars with their design principles and their key questions, the real review of MercadoFresco pillar by pillar with its findings and their risk, the trade-offs between pillars that nobody can avoid, the Well-Architected Tool for running the review with some method, and the conversation that almost never gets written down: RTO, RPO and the four disaster recovery strategies. At the end you will have a prioritised improvement plan, and the first item on that plan is the one that opens the next five lessons.

Cost warning. The AWS Well-Architected Tool is free: it charges nothing for workloads, reviews, milestones or lenses. What costs money are the actions that come out of the improvement plan — a replica in another region, a load test, a higher support plan — and that is exactly what this lesson teaches you to prioritise instead of buying the lot. Fictitious data, accounts and identifiers.

1. What the Well-Architected Framework is and what it is not
2. The anatomy of the framework: pillars, questions, best practices and improvement plan
3. Pillar 1: operational excellence
4. Pillar 2: security
5. Pillar 3: reliability
6. Pillar 4: performance efficiency
7. Pillar 5: cost optimisation
8. Pillar 6: sustainability
9. The trade-offs between pillars and how they are documented
10. The architecture decision record
11. RTO, RPO and the four disaster recovery strategies
12. MercadoFresco's recovery decision
13. The AWS Well-Architected Tool: workloads, milestones and lenses
14. The routine: who reviews, how often and what happens to the findings
15. Periodic review versus continuous checking: Trusted Advisor and Config
16. MercadoFresco's prioritised improvement plan
17. Common mistakes and tips
18. Exercises
19. Conclusion

The AWS Well-Architected Framework is a public document — a set of documents, in fact — that gathers what AWS has learned from reviewing tens of thousands of customer architectures. Its format is not a list of recommended services but a collection of questions grouped into six pillars, each one with its associated best practices.

The shape of the questions is always the same: "How do you do X?". Not "Do you use service Y?". That difference is the whole value of the framework:

• "How do you protect data at rest?" can be answered with KMS, with client-side encryption, or with a justification of why that data does not need encryption. All three are valid answers if they are reasoned.
• "Do you use KMS?" only admits yes or no, and turns the architecture into a shopping list.

It is worth stating clearly what it is not:

• It is not a certification. Nobody passes or fails. There is no "Well-Architected" badge to hang on your website.
• It is not a shopping list of AWS services. Many of the best answers cost no money at all: writing a procedure, running a drill, deleting a permission.
• It is not a compliance audit. It does not replace an ISO 27001, a national security scheme or the review of a data protection professional. There is overlap, but the goal is different.
• It is not an afternoon's work, nor a one-off. An architecture that was fine a year ago may not be fine today: it has grown, the business has changed and new services have appeared.
• It does not demand that you fix everything. The output is a prioritised list of consciously accepted risks and risks you are going to mitigate. Accepting a risk in writing is a professional answer; ignoring it is not.

What it is: a structured way of finding what you did not know you were missing, and of turning it into a conversation with the business that does not depend on the intuition of whoever speaks loudest.

The structure is hierarchical and it is worth having it clear before opening the tool:

The elements:

The six pillars — and their order matters little, because no pillar is more important than another in the abstract, only in your context — are:

One practical detail before starting: the review is done on a specific workload, not on "the company". MercadoFresco defines a workload called mercadofresco-tienda-produccion, covering the shop, the catalogue, orders and delivery in account 111122223333. Sara's analytics will be a second workload with its own review, because it has different requirements, different risk and a different owner.

This is about how the workload is run and improved: procedures, observability, incident response and learning.

Design principles:

• Perform operations as code: if it is done twice by hand, it gets automated.
• Make frequent, small, reversible changes.
• Refine procedures often, rather than leaving them fossilised in a two-year-old document.
• Anticipate failure: rehearse it before suffering it.
• Learn from all operational failures with blameless post mortems.
• Use observability to gain actionable insight, not pretty charts.

Key questions: how priorities are determined; how teams are structured to support the business outcome; how the workload is designed so it can be understood while running; how the risk of changes is reduced; how you know it is ready for production; how you know it is healthy; how operational events are managed; and how what you learn is turned into evolution.

MercadoFresco review:

A detail that usually goes unnoticed: MercadoFresco has excellent observability and weak operations. It knows perfectly well what is happening and has not written down what to do when it happens. It is the most common pattern among good technical teams.

This is about protecting information, systems and assets, with controls that detect and respond.

Design principles:

• A strong identity foundation: least privilege, separation of duties, no long-lived credentials.
• Traceability: log, monitor and audit every action.
• Apply security at all layers, not only at the perimeter.
• Automate security best practices.
• Protect data in transit and at rest, and classify it.
• Keep people away from the data: if nobody needs to get in, nobody gets in.
• Prepare for the incident: have a plan, tools and a rehearsal.

Key questions: how the account and identities are managed; how permissions for people and machines are managed; how security events are detected; how networks, compute and data are protected; and how you respond to an incident.

MercadoFresco review:

This is about the workload doing what it should when it should, and recovering from disruptions.

Design principles:

• Recover automatically from failure, detecting it through key indicators.
• Test the recovery procedures, not just write them.
• Scale horizontally to increase aggregate availability.
• Stop guessing capacity.
• Manage change through automation.

Key questions: how service quotas are managed; how the network topology is designed; how the service architecture is designed to withstand the failure of a dependency; how it is monitored; how reliability is tested; and how disaster recovery is planned.

MercadoFresco review:

This pillar comes off worst of the six, and not by accident: everything that is missing is a drill, and drills are the first thing to be postponed when features have to ship.

This is about using the right resources — not merely enough of them — and continuing to do so as the world changes.

Design principles:

• Democratise advanced technologies: consume them as a service instead of operating them.
• Go global in minutes.
• Use serverless architectures where they fit.
• Experiment more often, because in the cloud trying things is cheap.
• Have mechanical sympathy: choose the technology for how it works inside, not out of habit.

Key questions: how the architecture is selected; how compute, storage, database and network resources are selected and used; and how performance is monitored to make sure it is still what you expect.

MercadoFresco review:

This is about getting the maximum business value per dollar spent. It is not "spend little": it is "spend well and know it".

Design principles:

• Implement cloud financial management (FinOps) as a capability, not as an annual fright.
• Adopt a consumption model: pay for what you use.
• Measure overall efficiency: cost per business unit, not absolute cost.
• Stop spending on undifferentiated heavy lifting: data centres, patching hosts.
• Analyse and attribute spend: let every team see its own.

Key questions: how spend governance is implemented; how usage and cost are monitored; how you decommission what is no longer used; how purchase options and resource types are evaluated; how demand is planned; and how cost changes are evaluated over time.

MercadoFresco review:

Eight findings and five of them high risk. It is by far the worst governed pillar, and that is consistent with reality: it is the only one that does not throw an error in production when it is ignored. It simply charges you.

This is the most recent pillar and the least well understood. It is about the environmental impact of running the workload: energy, hardware and resources consumed.

Design principles:

• Understand the impact and measure it.
• Set sustainability targets per unit of work.
• Maximise utilisation: a server at 10 % consumes almost as much as at 60 %.
• Adopt more efficient hardware and software as soon as they are available.
• Use managed services, which aggregate the load of many customers.
• Reduce the downstream impact: less data transferred, fewer client devices forced to work.

Key questions: how regions are selected against the sustainability goal; how software patterns are aligned with demand; how data is exploited; how hardware and its lifecycle are managed; and how development and deployment processes are optimised.

MercadoFresco review:

An honest note: in 90 % of cases, the actions in the sustainability pillar coincide exactly with those in the cost pillar. Switching off what nobody uses saves money and energy. It is the pillar with the best effort-to-result ratio, precisely because it goes hand in hand with the next one.

This is where the framework stops being a list and starts being engineering. The six pillars cannot be maximised at once. Every decision raises one and lowers another. Real examples from MercadoFresco:

The lesson is not "choose well". It is more concrete than that: a trade-off is only defensible if it is written down, quantified and signed off by whoever takes the risk. Multi-AZ costs twice as much; if the manager understands that the extra buys not losing a Friday's orders, the decision is his and it has been made. If nobody has told him, the decision does not exist: there is only a bill.

The tool for not losing that reasoning is called an ADR (Architecture Decision Record): a short text file, versioned alongside the code, for each relevant decision. MercadoFresco keeps them in mercadofresco-infra under docs/adr/.

Minimum format, four sections:

Three rules that make ADRs worth something:

1. One file per decision, and it is never edited: if the decision changes, a new ADR is written that supersedes the previous one and the old one is marked superseded by ADR-027. The history is the value.
2. They are written when the decision is made, not when somebody asks six months later.
3. They always include the rejected alternatives and why. That is the part you are most grateful for when the context changes: it lets you know whether the reason for rejecting them still holds.

Of all the findings in the review, the one that makes Marta most uncomfortable is this: nobody has ever declared how long the shop may be down or how much data may be lost. Without those two numbers recovery cannot be designed, because there is no way of knowing whether what you have is enough.

The two definitions, which are constantly confused:

• RTO (Recovery Time Objective): how long the service may be down before the damage becomes unacceptable. It is measured from the start of the disruption until the service is working again. It is a business decision, not a technology one.
• RPO (Recovery Point Objective): how much data may be lost, measured in time. An RPO of 15 minutes means that, after the disaster, you accept having lost at most the last 15 minutes of transactions.

Put another way: the RPO looks backwards (what did I lose) and the RTO looks forwards (how long until I am back). And both cost money in a growing, non-linear way: bringing the RTO down from 8 hours to 4 is cheap; bringing it down from 30 minutes to 1 minute is extremely expensive.

The four canonical strategies, from least to most costly:

Applied to MercadoFresco's consolidated monthly bill, which is 2,237.60 USD (we will break it down in 11-03), the cost of each option is:

Note that these figures are for the secondary region, and that to all of them you have to add the cost that never appears in the table: the work of keeping that second region consistent with the first. A warm standby that has not been updated for four months is not a warm standby, it is a false sense of security.

Marta takes the conversation to the manager with two concrete questions, not with a table of services:

1. "If the whole Ireland region goes down — which happens very rarely, but it happens — how many hours can the shop stay shut before the damage is serious?"
2. "How many minutes of orders can we afford to lose?"

The answers, after discussing them: 8 hours of RTO and 15 minutes of RPO for the ordering system. The manager's reasoning is defensible: MercadoFresco delivers fresh produce within 24 hours; an 8-hour outage delays a day of deliveries, is annoying and costs money, but it does not close the company down. Losing orders that have already been confirmed and charged for, on the other hand, is serious, because it means charging without delivering.

Those two figures alone rule out two of the four strategies:

• Active-active and warm standby are oversized for an RTO of 8 hours. Nobody is asking to pay 780 or 2,200 USD a month to go from 8 hours down to 20 minutes.
• Backup and restore fits the RTO (8-24 h is right at the limit) but fails on the RPO if the backups are daily.

The resulting decision is a reasoned hybrid: reinforced backup and restore.

And here comes the part that separates a plan from a document: the real declared RPO is 6 hours in the event of a regional disaster, not 15 minutes. Marta writes it exactly like that, in those words, in ADR-021, and gets it signed. The option of bringing it down to 15 minutes exists — continuous replication to the other region — and costs about 200 USD more a month. Management decides to accept the residual risk for now and to revisit it when they open outside Spain.

Three additional commitments that close the finding:

1. A half-yearly full restore drill in eu-west-3, against the clock and minuted. If the measured RTO exceeds 8 hours, the strategy is reconsidered.
2. A quarterly AZ failure drill with AWS Fault Injection Service in pre-production, which is a far more likely risk than the regional one.
3. The first test happens before December, because running it during the Christmas season would be reckless.

The Well-Architected Tool is a free console service that turns the document into a workflow with state. The steps:

1. Define the workload. Name, description, environment (production or pre-production), regions, accounts involved, industry and owner. MercadoFresco defines:

A note on the options that matter:

• --environment PRODUCTION changes the weight of some recommendations: the tool is more demanding with a production workload.
• --account-ids includes the tooling account 555566667777 because the pipeline is part of the workload: there is no point reviewing operational excellence while ignoring who deploys.
• --lenses applies the base lens and the serverless one from the outset, because MercadoFresco has Lambda and Fargate on the critical path.
• --tags tags the review itself, consistent with the course convention. Yes: even the review gets tagged.

2. Answer the questionnaire. For each question you tick the best practices that are really in place and you can add a note. There are two classic traps:

• Ticking out of optimism. "Yes, we have backups" is not the same as "we successfully restored a backup last month". If it has not been tested, it is not ticked.
• Not using the notes. The note is where you write "we do this partially: production only". Without it, the review six months from now has no context.

There is also the "this question does not apply" option, with its justification. Using it is legitimate: questions about instance fleet management do not apply to an entirely serverless workload.

3. Get the improvement plan. The tool works out the risk per question (high, medium or none) and generates a list of improvement items with links to the documentation. The list can be exported and — this is the important part — turned into backlog tasks with an owner and a date. An improvement plan that lives inside the Well-Architected Tool and not on the team's board never gets executed.

4. Create a milestone. A milestone freezes the state of the answers on a date:

Six months later, after a new review, the tool shows the comparison between milestones: how many high risks there were, how many there are, which were resolved and which are new. That comparison is the only honest indicator of whether the team is improving or merely running.

5. Apply lenses. A lens adds domain-specific questions and moves the bar. The most useful ones:

One piece of advice about lenses: do not apply more than two. Each lens adds dozens of questions and the review stops getting finished. A complete review with two lenses beats an abandoned review with six.

6. Query the results through the API, which is how the follow-up gets automated:

What this script does, line by line:

• get_lens_review returns the state of the review for a given lens; PillarReviewSummaries carries the risk count per pillar, which is exactly the executive summary management asks for.
• list_lens_review_improvements returns the improvement items; they are filtered by Risk == "HIGH" because a 60-item plan does not get executed and a 12-item one does.
• The result can be dumped to a file, used to open issues automatically, or published as a CloudWatch metric to watch it evolve. MercadoFresco does the third: a RiesgosAltosWA metric in the MercadoFresco/Tienda namespace, reviewed in the monthly meeting.

A Well-Architected review done once is a report. One that is repeated is a process. The routine Marta puts in place:

Two rules that stop the process from dying:

1. No improvement item without an owner and a date. "We ought to do load tests" is not a task; "Luis runs a load test at 1,400 orders/hour in pre-production before 30 October" is.
2. A maximum of five improvements in flight at once. A plan with 40 open actions amounts to no action in progress.

The Well-Architected review is periodic, deep and human. It is no use for spotting that somebody opened a security group to the world on Tuesday afternoon. That is what the tools you already know from module 5 are for, and it is worth seeing how the three fit together:

The correct relationship is one of feedback in both directions:

A concrete example from MercadoFresco: the review discovers that there is no periodic permissions review. The action is not just "review the permissions this quarter" but turning the finding into a continuous check: a Config rule iam-user-unused-credentials-check and a monthly IAM Access Analyzer report. That way the finding does not come back in the review six months from now.

The general rule: every finding that can be turned into an automatic check gets turned into one. The human review should be reserved for what no tool can assess: whether the RTO suits the business, whether the team knows what to do at 3 in the morning, whether last year's decision still holds.

Adding up the six pillars, the initial review produces this balance:

Fourteen high risks are too many to tackle at once, so they are prioritised by crossing impact with effort:

Why the cost pillar comes first, even though reliability has the same number of high risks and sounds more important. Three concrete reasons:

1. It is the only pillar nobody has a single figure for. You cannot prioritise what you do not measure, and the reliability decisions that come next — pilot light or warm standby? — are cost decisions dressed up as technical ones.
2. The actions are low effort with immediate effect. Activating tags, deleting orphans and switching environments off at night are hours of work, not weeks, and they free up budget.
3. The budget freed up funds the rest of the plan. The money no longer thrown away on development at night is exactly what pays for the cross-region backups and the load tests.

That is the thread of the five remaining lessons. 11-02 makes the bill readable through tagging and allocation. 11-03 analyses it with Cost Explorer and executes the optimisations. 11-04 sets limits and alerts with Budgets. 11-05 commits capacity with Savings Plans and reservations. And 11-06 closes the course with the integrating project.

Mistake: treating the review as an exam you have to pass. The team ticks best practices it does not fully meet so that the report comes out green. Tip: nobody outside reads the report. The only thing you lose by over-ticking is the chance to find the problem before it finds you on a Friday at 19:00.

Mistake: reviewing "the whole company" as a single workload. You end up with a questionnaire that is impossible to answer because the right answer is "it depends on the system". Tip: a workload is a set of components that deliver business value together and share an owner. MercadoFresco has two: the shop and analytics.

Mistake: turning the improvement plan into a document and filing it. Six months later, the new review finds exactly the same things. Tip: improvement items come out of the tool the same day and go onto the team's board with an owner and a date, or they do not exist.

Mistake: confusing "we have backups" with "we know how to restore". It is the most repeated finding in the reliability pillar across the whole industry. Tip: an untested backup is a hypothesis. Restore once, against the clock and in a clean environment, and write down the real time: it is almost always triple the estimate.

Mistake: setting the RTO and the RPO from technology. The technical team decides "let's say 15 minutes" without asking anyone, and then designs an architecture that costs three times what it needs to. Tip: RTO and RPO are declared by the business answering two questions in plain language, and they are written into a signed ADR.

Mistake: buying the most expensive recovery strategy "just in case". An unnecessary active-active doubles the bill and, worse, doubles the maintenance work; it usually ends up out of sync and providing false security. Tip: start with the strategy that meets the declared RTO and RPO, and move up when the business raises its demands, not before.

Mistake: applying six lenses at once. The review goes from 60 questions to 300 and is abandoned in the second session. Tip: the base lens plus one or two specific ones. More can be added in the next review.

Tip: use the notes on each question as memory. "Met in production only, pending in pre-production, see ADR-018" turns the next review into half an hour of work instead of two hours of archaeology.

Tip: measure the process, not just the architecture. The useful indicator is not "we have 14 high risks" but "we had 14 and now we have 6". Milestones exist for exactly that.

Tip: accept risks in writing and with an expiry date. "We accept a regional RPO of 6 h until we open in Portugal, review in March" is a professional decision. "We'll look at it some time" is not.

A fictitious company, LibreríaAtlas, sells books online with a much simpler architecture than MercadoFresco's: two EC2 instances behind an ALB, a single-AZ RDS MySQL, S3 for the covers, no CDN, deployments over SSH and automatic daily RDS backups with 7 days of retention. They have never restored a backup. They have no tags. The team is two people.

1. Write five findings from the reliability pillar with their risk (high or medium).
2. State which one you would tackle first and why, knowing that the budget is limited.
3. Propose a reasonable RTO and RPO and say which recovery strategy would fit.

MercadoFresco is considering adding request body inspection in the ALB's WAF to detect injection attempts in the order form. Measured in pre-production: it adds between 4 and 9 ms of latency per request and about 12 USD a month. The shop has a TiempoConfirmacionPedido p99 target below 900 ms and is currently at 840 ms.

1. Identify which pillars go up and which go down.
2. Write the complete ADR with context, decision, consequences and rejected alternatives.
3. State which metric you would watch afterwards and what would make you reverse the decision.

MercadoFresco's manager changes his mind: after reading a news item about a competitor's regional outage, he asks for an RTO of 1 hour and an RPO of 10 minutes.

1. Which strategies in the table are still valid with those objectives?
2. Work out the impact on the monthly bill of 2,237.60 USD of the cheapest option that meets them, in absolute value and as a percentage.
3. Prepare three questions you would put to the manager before approving the spend.

Solution to exercise 1

(1) Five reliability findings in LibreríaAtlas:

(2) What to tackle first: the tested restore. It is not the intuitive answer — intuition says "Multi-AZ" — but it is the right one on a limited budget, for three reasons: it costs nothing (only time), it validates or invalidates the whole backup strategy in one go, and if it turns out the backups are no good, it completely changes the priority of everything else. Multi-AZ is second, and it already costs money: it roughly doubles the cost of the RDS instance.

(3) Reasonable RTO and RPO. An online bookshop is not a life-critical service: an RTO of 4 hours and an RPO of 24 hours are perfectly defensible if the business accepts them — with daily backups, the real RPO is already 24 h. With those objectives, the right strategy is backup and restore, reinforced with two cheap things: replicating the snapshots to another region and having the infrastructure described in CloudFormation so it can be rebuilt without depending on anyone's memory. If the business demanded an RPO of 1 hour, the answer would not be to change strategy but to enable more frequent backups or move to an engine with point-in-time recovery.

Solution to exercise 2

(1) Pillars affected:

• Security goes up: extra protection against injection at the exact point where user data comes in, in a layer separate from the application's validation (defence in depth).
• Performance efficiency goes down: between 4 and 9 ms per request. With the p99 at 840 ms and the target at 900, the remaining headroom goes from 60 ms to about 51 ms in the worst case. It still meets the target, but with less slack.
• Cost optimisation goes down: 12 USD a month, 0.5 % of the bill. Marginal.
• Neutral for reliability, with one nuance: a badly tuned WAF rule that blocks legitimate requests does affect perceived reliability. That is the real risk of this decision, not the latency.

(2) ADR:

(3) What to watch and what would reverse the decision. Three things are watched: the p99 of TiempoConfirmacionPedido on the mercadofresco-produccion dashboard, the rate of requests blocked by the WAF, and the number of orders confirmed per hour compared with the previous week. The decision is reversed if the p99 goes above 900 ms in a sustained way, or if PedidosConfirmados drops inexplicably, which would be the sign of false positives blocking real purchases. The reversal is cheap: putting the rule back into count mode is a one-field change.

Solution to exercise 3

(1) Strategies valid with RTO 1 h and RPO 10 min:

• Backup and restore: does not meet them. Typical RTO of 8-24 h and, with cross-region backups every 6 h, an RPO of 6 h.
• Pilot light: meets them, just. RTO of 1-4 h — you have to work at it to stay at the bottom of the band — and RPO of 5-15 min with continuous Aurora replication to the other region.
• Warm standby: meets them comfortably (RTO 10-30 min).
• Active-active: meets them with room to spare and is unnecessary for these objectives.

The honest answer is that pilot light meets the RPO for certain and the RTO only if it is rehearsed. An RTO of 1 hour with pilot light demands full automation of the start-up: no rebuilding by hand. It is the option to propose, on the explicit condition of a drill that proves it.

(2) Impact on the bill:

And there is a cost that is not in that figure and is worth putting on the table: the recurring work. Keeping the second region aligned, running the half-yearly drill and fixing whatever the drill breaks come to something like 6 to 10 days of work a year, which at internal cost exceeds the infrastructure cost.

(3) Three questions for the manager:

1. "Where does the requirement come from?" If it comes from a news item about a competitor, perhaps the real risk that worries him is not the regional one — which is rare — but something far more likely: a bad deployment, an accidental deletion or an attack. Those are mitigated with automatic rollback, deletion with retention and a WAF, all of which already exist and cost far less.
2. "How much does MercadoFresco bill in 8 hours?" That is the number that turns the conversation into an investment decision. If it is 4,000 USD and the probability of a regional outage is once every several years, spending 3,222 USD a year has to be discussed with those two numbers in front of you.
3. "Do we also take on the commitment to rehearse it twice a year?" Without that condition, the right answer is not to build it: an untested pilot light gives you the same availability as having nothing, but with a bill.

MercadoFresco no longer has just an architecture: it has an audit of that architecture, done with method rather than intuition.

You know what the Well-Architected Framework is and, above all, what it is not: not a certification, not a shopping list of services, not a compliance audit. It is a collection of questions of the form "how do you do X?", grouped into six pillars — operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability — each with best practices that are ticked only when they are genuinely met. And you know that the unit of review is the workload, not the company.

You have MercadoFresco's complete review pillar by pillar, with 14 high risks and 12 medium ones, and with a pattern that repeats in almost every good technical team: excellent observability alongside operations with no runbooks, an elastic architecture that has never been tested under load, backups that have never been restored and a cost pillar that literally nobody has a single figure for. With the findings written as findings — "there is no declared RTO", "the failure of an AZ has never been simulated", "the development account has no spending limit", "nobody has reviewed the permissions since they were created" — and with their risk and their action beside them.

You have the trade-offs between pillars quantified rather than guessed at: Multi-AZ triples Aurora's compute, the WAF with body inspection adds 4 to 9 ms, Spot swaps cost for interruptions, VPC endpoints buy security and come out dearer than the NAT. And the tool that lets that reasoning survive the passage of time: the architecture decision record, one file per decision, versioned, never edited, and always including the rejected alternatives and why.

You have RTO and RPO genuinely understood — one looks forwards, the other backwards — and the four recovery strategies with their real cost on the bill: backup and restore (+2-4 %), pilot light (+10-15 %), warm standby (+30-40 %) and active-active (+90-110 %). And MercadoFresco's decision, taken by the business and not by the technical team: an RTO of 8 hours and an RPO of 15 minutes, resolved with reinforced backup and restore, with the residual risk written down without adornment — the real regional RPO is 6 hours — and with two drills committed to the calendar.

And you have the routine: who convenes it, who takes part — the business included, because RTO, RPO and budget are not technical decisions — how often, how long it lasts and what comes out of it; the milestones for comparing today's review with the one six months from now, which is the only honest indicator of improvement; the specialised lenses with the advice not to apply more than two; and the division of roles between the half-yearly human review, the continuous checks of Config and the alerts of Trusted Advisor, with the rule that binds them: every finding that can be turned into an automatic check gets turned into one.

The result is a prioritised improvement plan of ten actions with an owner and a date. And its first item is neither the flashiest nor apparently the most urgent: it is the cost optimisation pillar, because it is the only one with not a single figure behind it, because its actions are low effort with immediate effect, and because the budget it frees up is exactly what funds the load tests and the cross-region backups in the rest of the plan.

So the manager's question is still on the table, now with a method behind it to answer it. How much does all this cost and is it money well spent? The trouble is that today the answer would be a single figure on a one-line bill, and you cannot decide anything with that: you do not know how much is production and how much is development, nor how much the catalogue costs against orders, nor how much of that figure belongs to Madrid and how much to Seville, nor what part could be cut without anyone noticing.

In 11-02, "Tagging and cost allocation", that problem is solved first: the five mandatory tags from the course stop being a convention written in a document and become activated dimensions, enforced by policy and audited, capable at last of answering who spends what. Without that step, everything that comes afterwards — analysing, budgeting and committing — is done blind.