Eleven modules ago, MercadoFresco was an online shop with one server that fell over on Fridays, backups nobody had ever restored and a deployment that consisted of copying files over SSH on a Tuesday night. Today it has an architecture that is elastic, secure, observable, deployable from a pipeline, described in code, spread across five accounts, audited with a method, and with a bill that costs 24.8 % less than it did two months ago.

This lesson teaches no new service. It does five things: it walks through the complete architecture, linking each piece to the module where it was learned, and closes the balance on the five initial problems; it sets the final project, a real challenge with ten deliverables; it offers an annotated reference solution with its discarded alternatives; it maps out the paths for carrying on learning, with the certifications, the resources and what this course has not touched; and it closes the course with the clean-up list for everything created, so that nobody carries on paying for a finished laboratory.

Cost warning. This lesson includes the final clean-up of every resource in the course. If you have followed the exercises in a real account, that section is not optional: a forgotten EKS cluster costs 73 USD a month, an ElastiCache group more than 100, and seven VPC endpoints around 112. The order of deletion matters, because there are dependencies. Fictitious data, accounts and identifiers.

1. MercadoFresco's complete architecture
2. Each component and the module where it was learned
3. The five problems and their metrics
4. Common Mistakes and Tips
5. Exercises: the final project
6. Solutions: the annotated reference architecture
7. The AWS certification paths
8. Official resources for carrying on
9. What this course has not touched
10. What you can do now
11. The final clean-up, in the right order
12. Conclusion

The course began with five specific problems. This is the balance sheet, with numbers rather than adjectives:

Five problems, five solutions, and in all five cases a number you can show. That is the difference between having migrated to the cloud and having solved something.

Mistake: believing the final architecture was the goal from the start. Nobody designs this in one go. MercadoFresco got here in eleven steps, each one solving a specific problem that hurt. Tip: when you design, start from the problem, not from the diagram.

Mistake: copying this architecture as it stands. It makes sense for a shop with these volumes, these problems and this team. For 200 orders a month it is absurd, and for 200,000 a day it falls short. Tip: copy the decision method, not the boxes in the diagram.

Mistake: handing in an architecture project with no numbers. "We will use DynamoDB because it scales" is not a justification; "we will use DynamoDB because it is 400 writes per second with key-based access and single-digit millisecond latency, and the estimated cost is 22 USD a month" is. Tip: every decision, a number.

Mistake: not writing down the discarded alternatives. The assessor — and you in a year's time — needs to know what you considered and why you left it out. Tip: for every important decision, one discarded alternative with its reason.

Mistake: finishing the course without deleting the resources. It is the most expensive mistake of all and it happens to a lot of people. Tip: do the clean-up at the end of this lesson today, not "when I get a moment".

Tip: the best project is not the one that uses the most services, but the one that best justifies why it does not use some of them. Rejecting Shield Advanced, rejecting EKS and rejecting Beanstalk were three of the most valuable decisions in this course.

Tip: keep your solution to the project. In six months' time, rereading it will tell you more about what you have learned than any exam.

The brief. MercadoFresco is growing and the business puts forward three things at once for the coming year:

1. Opening in Portugal and France. Lisbon and Porto first, Paris and Lyon afterwards. Portuguese and French customers must have an experience equivalent to the Spanish one.
2. A mobile app for iOS and Android, with two new features: real-time delivery tracking — the customer watches the vehicle move on the map — and personalised product recommendations based on their purchase history.
3. Keeping the cost per order. The manager has been explicit: the bill may go up, but the cost per order must not.

The requirements, written down:

What has to be delivered. Ten sections:

(a) Architecture diagram. A diagram — mermaid, draw.io or a photographed sheet of paper — with the regions, the accounts, the components and the main flows. It must distinguish what already exists from what is being added.

(b) Region or regions and multi-region strategy. One region or several? Which ones? Active-active, active-passive, or a single region with edge distribution? Justify it against the latency, residency and availability requirements, and say explicitly what you are rejecting and why.

(c) Data engines for the two new features. What you would use for real-time tracking and what for the recommendations, with the access pattern, the estimated volume and the approximate cost of each.

(d) Security and compliance plan. Identities, encryption, secrets, perimeter protection, auditing, and specifically how you handle couriers' and customers' geolocation data under the GDPR.

(e) Observability plan with SLIs and SLOs. At least three indicators with their target, their window and their error budget; which alarm triggers what, and which dashboards each role needs.

(f) Pipeline and deployment strategy for the new multi-region scope and for the mobile app, which has a different release cycle from the web.

(g) Infrastructure as code and account structure. What changes in the current six-account organisation and how the same thing is deployed in several regions without duplicating code.

(h) Estimated monthly budget broken down by service and the resulting cost per order, compared with the target of 0.00934 USD.

(i) Well-Architected review of your own proposal: the three main risks you introduce, their pillar and their mitigation.

(j) Phased migration plan, with milestones, criteria for moving on and what you do if a phase fails.

Assessment rubric:

General criterion: a submission that justifies three discarded alternatives well is worth more than one that lists fifteen services. And any section without a number is an incomplete section.

A colleague proposes the simplest possible solution for the latency requirement: stay in eu-west-1 only and solve Portugal and France with CloudFront and AWS Global Accelerator, without deploying anything in another region.

1. Which requirements in the brief does that proposal solve and which does it not?
2. Estimate the network latency from Lisbon and from Paris to Ireland, and say whether the 200 ms requirement is achievable.
3. What would you tell them about 99.95 % availability?

With the current bill of 1,681.60 USD and 180,000 orders, the cost per order is 0.00934 USD. The volume is multiplied by four, up to 720,000 orders.

1. If the bill grew linearly, how much would it cost and what would the cost per order be?
2. Identify four items on the bill that do not grow with volume and estimate how much they weigh.
3. Estimate the real bill with 4× the orders and calculate the cost per order. Is the target met?

Solution to exercise 1: the annotated reference architecture

This is one valid solution, not the only one. Its value is in the reasons, not in the boxes.

(a) and (b) Regions and multi-region strategy.

The proposal: eu-west-1 (Ireland) remains the primary and only region for transactional state, reinforced with CloudFront across the whole European edge and AWS Global Accelerator for the mobile app's traffic. eu-west-3 (Paris) is added purely for two things: the disaster recovery target and, if measurements justify it, a read replica of the catalogue.

Why:

• Latency is solved at the edge, not by moving the database. The requirement is about first byte, and 90 % of a shop's content is static or cacheable: photos, catalogue, JavaScript. CloudFront already serves it from points of presence in Lisbon, Madrid, Paris and Marseille. For the dynamic API calls, Global Accelerator gets the traffic onto the AWS backbone at the nearest point of presence, which cuts between 20 and 40 % of the latency compared with the public internet.
• Data residency is already met: Ireland is the EU. The GDPR requires data to remain in the EU or in countries with an adequacy decision, not to sit in the customer's own country. This is the most common misunderstanding in projects of this kind.
• A second active region would double the complexity and almost double the bill, and the 99.95 % requirement does not need it: 99.95 % monthly is 21.9 minutes of downtime a month, perfectly achievable with Multi-AZ done properly inside a single region.

Discarded alternatives and why:

(c) Data engines for the new features.

Real-time delivery tracking. Two different problems that people tend to mix up:

• Ingesting the position: 200 couriers sending their position every 5 seconds is 40 messages/second, 3.5 million a day. It is a small, constant volume.
• Delivering it to the customer: every customer with an order in progress wants to see the vehicle move with less than 3 seconds of delay.

The proposal:

Estimated cost: around 95 USD a month at this volume, dominated by the WebSocket connections and the DynamoDB writes.

Discarded alternative: having the app poll over HTTP every 3 seconds. With 3,000 orders in progress that would be 1,000 requests per second against the API, in other words more traffic than the whole shop, and a phone battery drained in two hours.

Product recommendations. Here the key lies in a requirement the brief gives and many people overlook: "updated daily; not in real time". That changes the entire solution.

Estimated cost: around 40 USD a month.

Discarded alternative: Amazon Personalize. It is the purpose-built service for this and it would probably give better recommendations. It is rejected for the first version for three reasons: it costs considerably more, it adds a new service to maintain for a team of five, and there is not yet any measure of whether the recommendations work. The written decision: start with simple rules — "people who bought this also bought", "you will be needing this again" — over data that is already there, measure conversion for three months, and then decide whether Personalize is worth it. Introducing machine learning before you have a success metric is the most expensive way of not knowing whether something works.

(d) Security and compliance.

What exists is kept and extended: Identity Center, alias/mercadofresco-datos for everything new, secrets in Secrets Manager, WAF on CloudFront and on the ALB, Shield Standard, CloudTrail and Config centralised in 444455556666.

What is added because of the mobile app:

• Amazon Cognito for customer identity, with federated sign-in. Tokens expire; no keys in the app.
• Per-device certificates in IoT Core for the couriers, with a policy that only allows publishing to their own topic. One courier cannot publish another's position.
• Rate limiting and bot protection in the WAF for the mobile API, which is the obvious new target.

And the delicate part, geolocation:

And the warning that must appear in the submission and that forms part of the mark: this is a technical design, not a legal opinion. Handling workers' geolocation is one of the most sensitive points of the GDPR and of employment law, it requires a data protection impact assessment and it must be reviewed by a data protection professional before going into production. A proposal that solves geolocation without mentioning this is incomplete, however good it may be technically.

(e) Observability with SLIs and SLOs.

With three important decisions: alarms are set on the error budget burn rate, not on instantaneous thresholds, so that nobody is woken up by a 30-second spike; dashboards are separated by role — mercadofresco-produccion for the on-call shift, mercadofresco-negocio for Sara and management, and a new mercadofresco-movil — and the cost per order stays on the business dashboard, next to the orders, as established in 11-02.

(f) Pipeline and deployment. pipeline-mercadofresco-tienda is kept with blue/green and rollback, and three things are added: a stage per region for whatever is deployed in eu-west-3, always deploying to the secondary region first and only then to the primary; a dedicated pipeline for the mobile API, versioned independently because apps published in the stores cannot be rolled back — an old version can stay installed for months, so the API must maintain backwards compatibility for at least two versions — and feature flags to enable real-time tracking city by city, which makes it possible to open Lisbon without touching the code.

(g) IaC and account structure. The six-account organisation does not change: it is still the right one, and Entorno is still the best dimension of separation. What changes is the parameterisation: the red-mercadofresco.yaml and aplicacion-mercadofresco.yaml templates and the CDK stacks take the region as a parameter, with ss-mercadofresco-linea-base extended to the new region. A single repository, a single definition, two targets.

The only account being considered as an addition is a data account for analytics and recommendations, and it is rejected for now: with five people, one more account is more governance than it contributes. It will be revisited if the data team grows.

(h) Estimated budget.

The target is met with room to spare, and the reason is exactly the one 11-02 anticipated: there is a significant part of the bill — NAT, ALB, endpoints, governance, baseline observability — that does not grow with volume, and spreading it across four times as many orders drives the unit cost down. Multiplying the business by four multiplies the bill by 2.7.

(i) The three main risks of this proposal:

(j) Phased migration plan:

Two principles govern the plan: every phase is reversible without affecting what already works — feature flags, not irreversible deployments — and the load test is a requirement for opening the second country, not a task done if there is time left over. It is exactly the high risk finding that 11-01 left open.

Solution to exercise 2

(1) What it solves and what it does not. The single-region proposal solves: data residency, because Ireland is the EU; cost, because it is by far the cheapest option; operational simplicity, decisive with five people; and static content latency, which is the bulk of a shop. On its own it does not solve: the latency of dynamic requests unless Global Accelerator or some acceleration mechanism is added; and it contributes nothing against a complete regional outage, which remains the proposal's number one risk.

(2) Estimated latency. The network round trip from Lisbon to eu-west-1 is around 40-55 ms, and from Paris around 25-35 ms. On top of that you have to add TLS establishment — which with connection reuse and TLS 1.3 is amortised — and server processing time, which at MercadoFresco is under 900 ms at p99 but far lower at the median. The 200 ms first-byte requirement is perfectly achievable for content served from CloudFront — where latency is that of the local point of presence, on the order of 10-20 ms — and achievable for the dynamic API with Global Accelerator and reused connections. What would not be achievable is serving every dynamic request from Ireland with no cache, no acceleration and a slow query behind it.

(3) On the 99.95 %. Here you have to be precise with the numbers, because this is where the conversation usually goes wrong. 99.95 % monthly is 21.9 minutes of downtime a month. That is perfectly achievable in a single region with Multi-AZ done properly: an ALB in two zones, Aurora with failover in under 30 seconds, tasks spread out and deployments with no downtime. What a single region does not cover is a complete regional outage, which is a rare but real event.

The honest answer to the colleague is that they are right about the proposal and are missing one sentence: a single-region architecture meets the committed SLO, and the residual risk — a regional outage — must be written down, quantified and accepted by whoever signs the 99.95 % contract, exactly as was done in 11-01 with the 6-hour regional RPO. If the business does not accept that residual risk now that three countries are at stake, then the conversation changes and pilot light in eu-west-3 has to be budgeted for: +12 % on the bill, around 550 USD a month at the new size.

Solution to exercise 3

(1) Linear growth. It would be 1,681.60 × 4 = 6,726.40 USD, and the cost per order would stay exactly the same at 0.00934 USD, because linear growth is the definition of a constant unit cost.

(2) Four items that do not grow with volume:

To those four you would have to add CloudWatch's fixed base — dashboards, alarms, custom metrics — and the part of Redshift that depends on the number of reports rather than on order volume.

(3) Realistic estimate.

Which matches, within the margin of an estimate, the 4,600 USD in section (h) of the reference solution.

The target is met with a 31.6 % margin. And the underlying conclusion is the one that gives module 11 its point: the cost per order falls as you grow because 37 % of the bill is fixed infrastructure spread across more orders. It is the reason why presenting absolute cost at the monthly meeting leads to wrong decisions, and why the unit metric from 11-02 is the one to show the manager. With one caveat: this advantage only exists if the fixed part is kept under control. If growth brings accounts, regions, clusters and tools added without judgement, the fixed part grows with them and the economy of scale disappears.

This course does not prepare you for any certification in particular, but it covers a good part of the syllabus of several. The map:

Three pieces of advice on certifications, said without hedging:

1. The architect Associate has the best effort-to-usefulness ratio if you have already done this course. With two or three weeks of focused revision and practice exams, it is within reach.
2. A certification is no substitute for having built something. It opens doors in recruitment processes and it does not teach you to decide. The hard decisions in this course — rejecting EKS, rejecting Shield Advanced, choosing one year instead of three — appear in no exam.
3. If you are going to certify, do it for the syllabus, not for the badge. The real value is in the areas the exam forces you to study and that you would never have touched on your own.

And one piece of advice on how to read them: the AWS documentation is enormous and is designed to be consulted, not read. The productive way to use it is to have a specific problem, find the exact page and read it in full, including the quotas section and the pricing section, which are the two that prevent the most grief.

Eleven modules and some two hundred hours of AWS later, this is what is left out and is the natural next step:

And the order that makes most sense after this course: Resilience first, because it closes the most serious open risk; then Analytics, because that is where the immediate business value is; and after that, whatever the problem in front of you demands.

When you started this course you probably knew that AWS existed and that "it has a lot of services". Now you know how to do specific things:

• Design a three-tier architecture in the cloud, with an isolated network, elastic compute and managed data, and explain every decision.
• Choose the right data engine from the access pattern rather than out of habit: relational, key-value, in-memory, columnar.
• Put an application into containers without managing servers, with auto scaling, progressive deployment and automatic rollback.
• Isolate and protect: identities with no permanent credentials, encryption with your own keys, rotated secrets, WAF and security groups with least privilege.
• Know what is happening: metrics, logs, traces, alarms and dashboards that answer business questions and not only infrastructure ones.
• Decouple with queues, topics, buses and state machines, and do it properly: idempotency, retries, dead-letter queues and compensation.
• Build a pipeline that takes a commit to production with no manual intervention and knows how to roll itself back.
• Describe all the infrastructure in code and deploy it across several accounts and regions without copy and paste.
• Govern a multi-account organisation with organisational units, control policies and a common baseline.
• Audit what has been built with a method — six pillars, findings, risks and a prioritised plan — and document decisions with their discarded alternatives.
• Read an AWS bill, break it down by environment and component, find what is surplus and put limits on it.
• And above all: say no. Rejecting Shield Advanced with judgement, rejecting EKS with six written conditions, rejecting Beanstalk, rejecting Personalize until there is a metric. An architect is recognised by what they leave out.

If you have followed the exercises in a real account, this is not optional. The order matters, because many resources cannot be deleted while others depend on them.

Before you start, two checks: review Cost Explorer at daily granularity to know what is really costing money, and filter by the Proyecto=mercadofresco tag in Tag Editor to get the complete inventory. Switch region and repeat: what gets forgotten is usually in us-east-1.

Phase 1 — Stop what is consuming right now (minutes).

Phase 2 — Compute and containers. ECS services, then the cluster; Lambda functions; EC2 instances — terminate, do not stop, because a stopped instance still pays for its EBS volume; Auto Scaling groups; and the ECR images, which are charged per GB stored.

Phase 3 — Load balancing and delivery. ALB listeners, then the ALB, then the target groups. The CloudFront distribution has to be disabled first and you must wait for it to propagate before deleting it, which takes on the order of 15 minutes. Elastic IP addresses are released separately: an unassociated IP costs more than an associated one.

Phase 4 — Data. This is where it is worth stopping to think, because it is irreversible. Aurora and RDS clusters with --skip-final-snapshot only if you really do not want to keep anything; ElastiCache replication groups; DynamoDB tables; and the S3 buckets, which have to be emptied before deleting, including the old versions and delete markers if versioning is enabled, which is the number one cause of "I cannot delete this bucket".

Phase 5 — Network. The order is strict and allows no shortcuts:

Interface endpoints are the most silent leak: they cost around 0.011 USD per hour, per AZ and per endpoint, even if not a single byte goes through. Seven endpoints across two AZs are 112 USD a month for nothing.

Phase 6 — Observability and governance. CloudWatch alarms and dashboards; log groups, which carry on costing storage indefinitely; Synthetics canaries; the Config recorder, which charges per configuration item; CloudTrail trails beyond the first, which is free; and the EventBridge rules.

Phase 7 — Security and management. Schedule the deletion of the KMS keys, with a waiting period of between 7 and 30 days — they cost 1 USD a month in the meantime; Secrets Manager secrets, also with a recovery period; advanced Parameter Store parameters, which are the only ones that are charged; and the WAF Web ACLs, which cost 5 USD a month plus 1 per rule even when they are not associated with anything.

Phase 8 — Final check. Four steps nobody takes and that avoid next month's surprise:

1. Wait 48 hours and look at Cost Explorer again at daily granularity. Whatever still shows up is what you have forgotten.
2. Go through the regions, especially us-east-1, where CloudFront Web ACLs and a lot of experiments end up.
3. Check Trusted Advisor, which lists orphaned resources.
4. Leave a 1 USD budget active with a notification at 100 %. It is your permanent safety net and it costs nothing.

And what you should not delete: the account itself, if you want to carry on practising; the management trail, which is free; and the watchdog budget. Closing the account is the nuclear option and only makes sense if you are not coming back.

This is where the course ends, and it is worth looking at the whole journey before closing.

You started with an empty account and a shop that fell over on Fridays. You finish with an architecture that serves four cities at 900 orders per hour at peak, that is deployed almost five times a week during working hours, that is restored in four minutes, that is described entirely in code, governed across six accounts, audited against the six pillars of the Well-Architected Framework and budgeted down to the cent per order. The five problems that opened the course are solved and each one has a number beside it.

But what you take away is not the services. Services change: half the screens in this course will look different in three years and there will be new names that do not exist today. What does not change is the method, and that is what you have practised for eleven modules straight: start from the problem and not from the technology; choose the data engine by its access pattern; measure before optimising and optimise before committing; test recovery instead of assuming it; automate what you do twice; write decisions down with their discarded alternatives; and put a number beside every claim.

And with that method comes its least glamorous and most valuable part: the ability to say no. This course rejected Shield Advanced with judgement, rejected EKS with six written conditions that would change that, rejected Elastic Beanstalk, rejected a second active region, rejected Personalize until there was a success metric and rejected a three-year commitment that would have conditioned the architecture. None of those decisions shows up in a diagram and all of them are the real work of an architect. You will be recognised sooner for what you leave out with arguments than for what you manage to fit in.

One last piece of advice remains, and it is the only one that really matters from here on: build something of your own. Not another guided lab, not another tutorial. Something small and real, that solves a problem you care about: a club's website, a service to automate something tedious, a dashboard with data that interests you. Put it in your own account with MFA and a five-dollar budget. Break it. Fix it at eleven at night. Discover for yourself that the backups did not work, that that security group was wide open and that the endpoint you left switched on has cost you fourteen dollars. That day you will have learned more than in any module of this course, because your own mistakes stay with you and other people's do not.

MercadoFresco, meanwhile, carries on delivering fresh produce within twenty-four hours. On Friday afternoons, when nine hundred orders an hour come in, the tasks have already been up since 16:45 because somebody scheduled that scaling. Nobody notices. And that is exactly the sign that the job has been done well: the best architecture is the one nobody notices.

Thank you for making it this far. Now delete the resources and go and build something.