AWS Config closed the previous lesson with an honest limitation: it checks the rules you have told it about. That is precise and it is powerful, but it cannot warn you about what you never thought to ask.

Nobody has written a rule saying "tell me if I have orphan EBS volumes costing money", because to write it you would first have to suspect that they exist. Nobody has written a rule about unassociated elastic IPs, which are billed precisely for not being used. And certainly nobody has written a rule about the account's vCPU limit, which —as we will see in this lesson— is the real reason why asg-mercadofresco-tienda cannot go beyond four instances.

AWS Trusted Advisor performs that review. It compares your account against a catalogue of best practices that AWS has distilled from millions of customers, and tells you what you had not thought to ask about. It is not a real-time detection tool nor a replacement for anything that came before: it is the automatic review, the equivalent of somebody very experienced looking at your account once a month and pointing out the obvious things you have not seen for months because you are too close.

This lesson closes module 5, and with it MercadoFresco's observability layer.

1. What Trusted Advisor is and how it differs from Config
2. And how it differs from Well-Architected
3. The five categories
4. What each category checks
5. What you see depending on your support plan
6. How to make up for what the Basic plan does not give you
7. An annotated walkthrough of a MercadoFresco report
8. Service quotas: the invisible limit
9. The case of the ASG that will not go beyond four instances
10. Requesting a quota increase
11. Alarming before you hit a quota
12. Automation: API, export and notifications
13. Integration with EventBridge
14. Compute Optimizer and Cost Optimization Hub
15. Marta's monthly review routine
16. Closing the module: the complete observability layer
17. The five questions from module 4, answered
18. Total cost added
19. What comes next: the bottleneck has moved

The underlying difference: Config answers questions; Trusted Advisor asks them.

An example that makes it clear. MercadoFresco has a Config rule that checks that all EBS volumes are encrypted. Perfect. But no rule checks whether a volume is of any use, because it occurred to nobody. Trusted Advisor points it out without being asked: "you have 3 volumes in the available state, attached to nothing, that have been costing 24 USD a month since March".

They do not compete. Trusted Advisor gives you the finding; Config turns it into a permanent rule. The natural flow is: Trusted Advisor discovers a problem you had not foreseen → you write a Config rule so it does not happen again → the remediation fixes it on its own. That is the complete cycle.

Trusted Advisor looks downwards, at the resources. Well-Architected looks upwards, at the decisions. Trusted Advisor tells you an instance is underutilised; Well-Architected asks you whether your scaling strategy suits your traffic pattern. Both use the same five or six pillars as their conceptual framework, and in fact the Trusted Advisor categories are almost the Well-Architected pillars, but they operate at different altitudes.

Well-Architected is covered in 11-01, opening the module on best practices and costs.

The three possible states of each check:

And a warning that saves a lot of frustration: amber is not always a problem. Trusted Advisor does not know your context. An instance at 5 % CPU may be a perfectly justified standby server. A bucket without versioning may be a bucket of temporary files. Findings are hypotheses that have to be evaluated, not orders.

Cost optimisation:

Performance:

Security:

Fault tolerance:

Service limits (quotas):

It checks usage against the quota for dozens of services and warns when 80 % is exceeded. It is the most underrated category and the one that has caused the most outages in the history of AWS. It has its own section further down.

This is where complete honesty is called for, because it is where the disappointment lies:

What MercadoFresco sees with the Basic plan (0 USD):

In other words: with the Basic plan, MercadoFresco sees basic security and service limits, which is no small thing —they are the two categories that prevent the most outages— but it sees nothing about cost, performance or fault tolerance, and it has no API to automate with.

Is it worth moving up to Business? The honest calculation for MercadoFresco:

With 600 USD of spend, paying 100 USD for Trusted Advisor does not pay for itself on the recommendations alone. But the Business plan includes far more than Trusted Advisor: 24×7 technical support with a one-hour response for production being down, access to solutions architects, and the ability to open technical cases. That is the real reason to buy it, and it has to be decided on that basis, not on the checks.

MercadoFresco's decision: stay on Basic for now and make up for what is missing with what has already been learned, revisiting the decision when spend goes above 2,000 USD a month or when the shop becomes critical enough to the business to need support with an SLA. It is written down in the decision log, with a date, just like the decision on Shield Advanced in 04-04.

This is where the whole module pays for itself. Every check that Trusted Advisor does not give you on Basic can be reproduced with what you already know:

The actual scripts. Orphan volumes, with Config:

Unassociated elastic IPs, which are billed for not being used:

Load balancers with no traffic in the last 7 days:

ACM certificates close to expiry (remember: the CloudFront ones are in us-east-1):

Certificates issued by ACM and validated by DNS renew themselves (03-03), but imported ones do not, and an expired certificate brings the whole shop down. This check deserves a place in the monthly routine.

The conclusion that matters: with Config, CloudWatch and a handful of scripts, MercadoFresco reproduces most of what the Business plan would give it, for free. What it cannot reproduce is technical support with an SLA, and that is the real product you are buying.

This is the full report, including the checks MercadoFresco does not see with Basic but which we have reproduced with the techniques from the previous section. Annotated finding by finding.

Comment. The red on port 22 is exactly the same finding as the one the mercadofresco-ssh-restringido Config rule gave in 05-04. Two independent tools pointing at the same thing is the best possible confirmation that it is real. The difference: Config remediates it on its own; Trusted Advisor only points at it.

The 412-day-old key belongs to the integracion-proveedor user from exercise 2 of 05-03. The real fix is not to rotate it: it is to replace it with an assumable role with sts:ExternalId (04-01).

Comment. The three ambers are perfect examples of findings that have to be evaluated, not obeyed:

• The 2 volumes without snapshots are the root volumes of the ASG instances. They do not need backups: they are ephemeral by design, they are recreated from lt-mercadofresco-tienda, and snapshotting them would mean paying to copy something that is already in the AMI. Marked as accepted and documented.
• The 2 buckets without versioning are mercadofresco-registros-web (ALB logs) and mercadofresco-catalogo-fotos. The first one is correct: logs are not overwritten. The second one is a real finding: if somebody uploads the wrong photo over a good one, there is no way back. Fixed.
• The Route 53 health checks are a real and valuable finding. MercadoFresco has an alias record pointing at CloudFront (03-05) with no health check. There is no failover configured towards anything. It is a pending decision that deserves discussion, not an immediate fix.

Comment. The amber on compression is money straight away: enabling automatic compression in CloudFront for the API responses reduces outbound transfer, which is the most expensive line item on CloudFront. It is a one-checkbox change. Fixed the same day.

Comment, finding by finding:

• The 3 orphan volumes were left over from instances terminated by hand during the tests in 02-01 and 02-02. Nobody deleted them because terminating an instance does not delete the additional volumes unless DeleteOnTermination is enabled. It is the most common cost finding in AWS. They are deleted, after checking that they contain nothing.
• The 2 elastic IPs are from the NAT tests and the initial instance. An elastic IP is free while it is associated with a running instance; when it is not, it is billed precisely to discourage hoarding. They are released.
• mercadofresco-tienda-01 at 4 % is a particularly interesting finding. That instance is the original one from 02-01, from before the ASG. It is no longer of any use: the traffic goes to the ALB and from there to the group. It has been running ever since because nobody remembered to switch it off. It is exactly the kind of thing only an automatic review picks up.
• The 4 manual snapshots more than 6 months old are from the tests in 02-04. Judgement is needed here: before deleting them it is worth checking there is no retention obligation, and that check is the custom rule from exercise 2 of 05-04.
• The Savings Plans recommendation is the highest-impact one in the whole report, and it is deliberately not dealt with here: analysing usage commitments is lesson 11-05. Trusted Advisor points at it; the decision is taken with Cost Explorer in front of you.

The red on elastic IPs at 100 % is the most urgent finding in the report, and it is doubly interesting: it has the same cause as the cost finding. The 2 unassociated IPs are taking up 2 of the 5 slots in the quota. If a third NAT gateway or an IP for something else were needed tomorrow, the API call would fail with AddressLimitExceeded and nobody would understand why. Releasing them solves both things at once.

And the vCPU row is what leads to the next case.

Every AWS account has quotas (formerly "service limits") on practically everything: how many vCPUs you can have running, how many VPCs, how many rules per security group, how much Lambda concurrency.

They exist to protect AWS from uncontrolled usage —accidental or malicious— and to protect you from a surprise bill. Most of them are adjustable; some are not.

What makes quotas dangerous is when you find out: once you have already hit one, at the worst possible moment. An account that works perfectly for months can fail all at once on the Friday when it needs to scale.

Service Quotas is the console where they are viewed and managed:

The quotas MercadoFresco keeps an eye on, and why:

Here is the specific case we promised, and it is a perfect example of why this category matters so much.

asg-mercadofresco-tienda is configured with a minimum of 2, desired 2, maximum 4. Marta had always assumed that 4 was a design decision. Looking at the quotas she finds out it is not quite so:

• The instances are t3.large: 2 vCPUs each.
• The account's standard on-demand vCPU quota is 16.
• Other workloads in the account consume 8 vCPUs.
• That leaves 8 vCPUs available = 4 t3.large instances.

The ASG maximum is not limited by design: it is limited by the quota. And that has a very specific and very ugly consequence.

On Friday at 19:00, with 900 orders an hour and a capacity of 600 orders an hour per instance, MercadoFresco needs at least 2 instances just for normal traffic. If a peak of twice that arrives —a campaign, a mention on social media, a bank holiday Friday— the ASG tries to scale. And if something else in the account had consumed vCPUs in the meantime:

The ASG does not scale. Customers see errors. And the cause is not in any CloudWatch alarm, nor in any Config rule, nor in any X-Ray trace. It is in an account quota that nobody has ever looked at.

Worse still: the failure happens at the worst possible moment, because hitting the limit is precisely what happens when you scale. It is the perfect latent failure.

The mercadofresco-asg-al-maximo alarm from 04-04 warns when the group reaches its maximum, which is a good sign that more capacity is needed. But it warns when you are already at the ceiling; it does not warn you that the ceiling is lower than you thought.

The possible states: PENDING, CASE_OPENED, APPROVED, DENIED, CASE_CLOSED.

Practical tips, learned the hard way:

1. Request in advance. Small increases are approved automatically in minutes; large ones go to a support case and can take days. Requesting on Friday afternoon because you are hitting the limit right now is exactly the scenario to avoid.
2. Ask for headroom, but be reasonable. Asking for 64 vCPUs when you use 8 is reasonable if you expect to grow. Asking for 10,000 with no justification gets denied.
3. Justify it. If the increase goes to support, explaining the use case —"an e-commerce grocery shop with Friday peaks, an ASG that needs to scale to 12 instances"— speeds things up a lot.
4. Quotas are per region. Raising it in eu-west-1 does not raise it in us-east-1. If you have a disaster recovery plan in another region, raise it there too, or you will discover the problem on the day of the disaster.
5. Some quotas are per account, not per region: IAM, S3, CloudFront.
6. Request through Organizations when you have several accounts (09-04): quota templates apply default values to new accounts.

And the arithmetic you have to do before deciding on the value:

Look at the fourth row: a blue/green deployment temporarily doubles the number of instances. It is a case that is systematically forgotten when calculating quotas, and it is why so many first zero-downtime deployments fail. It is covered in 08-03.

Service Quotas publishes usage metrics to CloudWatch in the AWS/Usage namespace. That lets you alarm before you reach the limit, which turns a quota from a trap into a managed number.

That threshold of 11 is 70 % of 16. The elegant way of expressing it, which adjusts itself if the quota changes, is a metric expression using the SERVICE_QUOTA() function:

SERVICE_QUOTA() is the function that makes this work properly: it returns the current value of the quota for that metric. If AWS approves the increase to 64 tomorrow, the alarm recalibrates itself without anybody touching anything. It is exactly the kind of detail that separates an alarm that ages well from one that has to be maintained.

The same technique for Lambda concurrency, which is the other quota that could bite MercadoFresco during the peak of photo uploads to the catalogue:

Cost: 0.10 USD per alarm. Two quota alarms, 0.20 USD a month, to avoid a scaling failure during a Friday peak. It is probably the best value-for-money decision in the entire module.

Important: the Trusted Advisor API (support and trustedadvisor) requires the Business plan or higher. On Basic, these commands return a subscription error. They are included because it is what you will use as soon as your organisation has that plan.

The support API is only in us-east-1. It is global and is served from there, just like ACM for CloudFront (03-04) or the CloudFront web ACLs (04-05). It is a recurring AWS pattern that you now recognise.

A script that exports the full report to CSV for the monthly review:

Weekly email notifications: with the Business or Enterprise plan, Trusted Advisor sends a weekly summary to the configured contacts. They are enabled in the console preferences, and the recipients are the account's alternate contacts —the operations one, the security one, the billing one— which we configured in 01-02. If you did not configure them then, now is the moment: aws-alertas@mercadofresco.example.

Trusted Advisor emits events when the status of a check changes. With EventBridge (07-03) you can react automatically:

Two details: Trusted Advisor events are emitted in us-east-1, so the rule goes there; and filtering by check-name is essential, because without it you would get a notification every time any of the ~115 checks changed.

What EventBridge enables, and this is the pattern to copy: not just notifying, but acting. A rule can invoke a Lambda that, faced with an "exposed access key" finding, disables the key immediately. When a key turns up in a public repository, every minute counts. The full detail of EventBridge —patterns, targets, buses, retries— is lesson 07-03.

Two complementary services that are mentioned here and developed in module 11:

AWS Compute Optimizer analyses the CloudWatch metrics of the last 14 days —more if you enable the agent's memory metrics that we installed in 05-01— and recommends the optimal instance type for each workload. It is free for the basic recommendations.

Typical output for MercadoFresco:

And here an important warning is in order: Compute Optimizer does not know that mercadofresco-tienda-01 should not exist. It recommends shrinking it to t3.small and saving 20 USD. The right answer is to switch it off, and save 60. Automatic tools optimise what is there; the question of whether it should be there is still asked by a person.

Compute Optimizer also analyses EBS volumes, Lambda functions —recommending the optimal memory, which in Lambda also determines the CPU— and ECS services on Fargate (module 10).

Cost Optimization Hub consolidates in a single place the cost recommendations from Compute Optimizer, Trusted Advisor, Cost Explorer and the reservation recommendations, with the estimated saving aggregated and without duplication. It is lesson 11-03.

This lesson does not go into costs. The whole of module 11 is devoted to it: tagging and allocation (11-02), Cost Explorer (11-03), Budgets (11-04) and Savings Plans (11-05).

This is the concrete checklist that Marta runs on the first Monday of every month, in an hour. It is the operational product of the whole of module 5.

Security (15 minutes)

• [ ] Trusted Advisor, security category: no reds.
• [ ] Config compliance dashboard: number of non-compliant rules against last month.
• [ ] aws cloudtrail validate-logs over the previous month; save the output.
• [ ] Athena query: unknown source IPs and AccessDenied grouped together (05-03).
• [ ] Review IAM users with keys more than 90 days old.
• [ ] Check that there is no root account activity.

Cost (10 minutes)

• [ ] available EBS volumes (Config query).
• [ ] Unassociated elastic IPs.
• [ ] Load balancers with no traffic in 7 days.
• [ ] Compute Optimizer recommendations.
• [ ] Compare this month's bill with the previous one; investigate any deviation greater than 20 %.
• [ ] Manual RDS and EBS snapshots more than 6 months old.

Reliability (10 minutes)

• [ ] Trusted Advisor, fault tolerance.
• [ ] Service quotas: nothing above 70 %.
• [ ] ACM certificates: none less than 60 days from expiry (in both regions).
• [ ] Check that the canario-mercadofresco-compra canary has not failed.
• [ ] Check that the DLM policies have created the expected snapshots (02-02).

Observability (15 minutes) — the most important one and the one most often skipped

• [ ] Quarterly drill: set-alarm-state on a critical alarm and confirm that the notice reaches the on-call phone.
• [ ] SNS subscriptions: none in PendingConfirmation.
• [ ] Log groups without retention (Config rule, should give zero).
• [ ] CloudWatch cost for the month: has it grown? why?
• [ ] Alarms that fired this month: was any of them a false positive? Adjust or delete it.
• [ ] Alarms that did not fire when they should have: add the missing one.

That penultimate point is what keeps the system alive. An alarm that produces repeated false positives ends up being ignored, and on the day it is real nobody will look at it. An alarm that gets ignored is worse than no alarm at all, because it gives a false sense of coverage. Deleting alarms is as important as creating them.

Technical debt (10 minutes)

• [ ] Review the decision log: any of them with an overdue review date? (Shield Advanced in 04-04, the support plan in this lesson, the migration to ADOT in 05-02).
• [ ] WAF rules marked as temporary during an incident (04-05).
• [ ] Accepted Config and Trusted Advisor exceptions: are they still valid?

The five pieces and what each one answers, which is the summary to take away:

And the connections between them, which are what turn five services into a system:

• CloudTrail triggers Config's recording: without CloudTrail, Config never sees the changes.
• CloudWatch receives CloudTrail's events and turns them into security alarms.
• ServiceLens joins the CloudWatch metrics to the X-Ray traces and the logs.
• Trusted Advisor discovers what you did not think of; Config turns it into a permanent rule.
• Config remediates; CloudTrail records the remediation; CloudWatch warns it happened.

The full path of an incident, which MercadoFresco now has end to end:

CloudWatch alarm → ServiceLens → X-Ray trace → the guilty subsegment → correlated log → CloudTrail if there was human intervention → a Config rule so that it does not happen again.

Module 4 closed with five open questions. These are the answers, with names and surnames:

1. "Nobody has checked that an SNS notice reaches a phone at 4 in the morning."

Answered in 05-01. The alertas-mercadofresco subscriptions were checked, looking for the dreaded PendingConfirmation, the aws-alertas@mercadofresco.example address and the on-call phone were subscribed, and the drill with set-alarm-state was run, which fires the real actions without touching the metric. It also emerged that the phone's "do not disturb" was silencing SMS from short numbers: the notification chain includes the phone, and the phone has to be tested too. It stays as a quarterly drill in the monthly routine.

2. "The WAF, VPC, ALB and Lambda logs pile up in five places without being correlated."

Answered in 05-01. Centralisation in CloudWatch Logs of what can be centralised —the application, nginx, the Lambdas, WAF (aws-waf-logs-mercadofresco), flow logs (flowlogs-mercadofresco) and PostgreSQL— with retention per group from day one, and with the honesty to acknowledge what does not go there: the ALB and CloudFront access logs live in S3 and are queried with Athena. Logs Insights queries up to 50 groups at a time, and that is what makes the correlation possible.

3. "If a customer says their order takes 8 seconds, Marta does not know whether the problem is in the shop, in the Lambda or in the database."

Answered twice. First in 05-01, with four Logs Insights queries over four groups and a timeline assembled by hand: 7,402 ms inside PostgreSQL. Then in 05-02, in a single search —annotation.pedido_id = "48213"— and a waterfall view where the problem reads in two seconds: 39 subsegments of 190 ms in series, 91 % of the time, an N+1 pattern. Fixed with WHERE id = ANY(...): p95 from 6.8 s to 0.44 s, and DatabaseConnections from 185 to 96 at the Friday peak.

4. "Nobody knows who decrypted the last backup."

Answered in 05-03. Three kms:Decrypt events on mercadofresco-pedidos: RDS encrypting its automatic backup, an ASG instance from 10.0.11.24, and rol-restauracion-copias at 03:42 from 198.51.100.77, without MFA, on snapshot-2026-07-27. The full investigation —freezing the evidence, finding the real AssumeRole, reconstructing the session by accessKeyId— led to Luis testing a restore in the middle of the night. Right intention, wrong procedure. With corrective actions and dates, and an alarm for next time.

5. "Nothing warns if somebody disables the encryption on a bucket or opens an SG to the world."

Answered in 05-04. And it does not just warn: it fixes it. Full timeline: T+0 somebody disables the encryption, T+3 min Config creates the CI and evaluates NON_COMPLIANT, T+4 min the remediation runs AWS-EnableS3BucketEncryption, T+8 min compliant again. No human intervention, with the full trail in CloudTrail. And the initial compliance dashboard found fourteen resources non-compliant for months with nothing detecting them, because they were not events: they were states.

And a sixth, which nobody had formulated and which appears in this lesson: the ASG cannot go beyond four instances because of an account vCPU quota that nobody had ever looked at. That is exactly the kind of problem that only an automatic review finds, and it is the best argument in favour of Trusted Advisor and Service Quotas.

Put in context:

Observability is 9.9 % of the total spend. It is a high proportion compared with security, and it is worth saying why it is reasonable: 70 % of that figure is CloudWatch and the canary, that is, log ingestion and the continuous check that people can buy. And against what it costs: the N+1 fix that X-Ray found, for 10.60 USD a month, halved the pressure on the database, avoiding an RDS instance upgrade that would have cost 80 USD a month. Observability paid for itself in the first month.

And the five decisions that keep that figure at 62 USD instead of 600:

1. Retention on every log group the day it is created (05-01).
2. No high-cardinality dimensions in custom metrics (05-01).
3. X-Ray sampling at 0 % on /salud and static files, 100 % on orders (05-02).
4. Data event selectors by prefix and readOnly: false (05-03).
5. recordingFrequency: DAILY for instances and volumes in Config (05-04).

Five lines of configuration that separate 62 USD from more than 600.

1. Expecting Trusted Advisor to see everything on the Basic plan. On Basic you see basic security and service limits. Nothing on cost, performance or fault tolerance, and no API.

2. Obeying the ambers without judgement. Trusted Advisor does not know your context. The root volume of an ephemeral instance does not need snapshots. Every finding is a hypothesis; document the ones you accept and why.

3. Ignoring the service limits category. It is the one that has caused the most outages, and it is one of the few available on the free plan. Always review it.

4. Requesting a quota increase when you are already hitting the limit. Large increases go to a support case and take days. Alarm at 70 % and ask in advance.

5. Forgetting that quotas are per region. Raising it in eu-west-1 does not raise it in eu-central-1. If you have a recovery plan in another region, raise it there too.

6. Not counting the blue/green deployment when calculating vCPUs. It temporarily doubles the instances. It is the most frequent cause of a first zero-downtime deployment failing (08-03).

7. Confusing Trusted Advisor with Config. Config checks your rules and remediates; Trusted Advisor checks AWS's and only points them out. The good cycle is: Trusted Advisor discovers → Config turns it into a rule → the remediation fixes it.

8. Refreshing checks by hand all the time. They refresh themselves every 24 hours. Refreshing manually before a particular review is fine; doing it every hour adds nothing.

9. Buying the Business plan just for Trusted Advisor. Do the sums: if the saving detected does not cover the cost, the reason to buy it is technical support with an SLA, not the checks. Decide it on that basis.

10. Letting findings pile up. A report with 40 permanent findings stops being read. Resolve them, formally accept them with a justification, or take them out of scope. A clean report is a report that somebody looks at.

11. Not reviewing the alarms that produce false positives. An ignored alarm is worse than no alarm. The monthly review includes deleting alarms, not just creating them.

12. Optimising an instance that should not exist. Compute Optimizer recommends shrinking mercadofresco-tienda-01 to t3.small. The right answer is to switch it off. Tools optimise what is there; the question of whether it should be there is asked by a person.

Final tip for the module: observability is never "finished". It is maintained. The system you have built over these five lessons degrades on its own if nobody looks after it: noisy alarms appear, logs without retention, non-compliant rules that get normalised, quotas creeping closer. Marta's monthly hour is what keeps everything else alive. Without it, in six months you have a dashboard nobody looks at and a pile of services billing away.

MercadoFresco is growing. Current data:

Available plans: Basic (0 USD), Developer (29 USD/month or 3 % of spend, whichever is greater), Business (100 USD/month or 3 to 10 % of spend depending on the band, whichever is greater).

Work out the real cost of each plan at that level of spend. Estimate the cost of a 95-minute outage on a Friday at peak time. Decide which plan you would buy, justifying it with numbers and not just with the Trusted Advisor checks. Say what you would do about what the chosen plan does not cover.

For Black Friday MercadoFresco expects a peak of 5 times the usual traffic for 6 hours. The current situation:

On top of that, the team wants to do a blue/green deployment the week before in order to publish the campaign.

Work out: how many instances are needed at the peak, how many vCPUs, which quotas fall short and by how much. Write the increase requests with the values you would ask for and their justification. Design the quota alarms you would set up. Say which other non-AWS limits you would review, and how far in advance you would do each thing.

It is the first Monday in October. Marta runs her routine and finds this:

Security

• Trusted Advisor: 1 red — "Security groups: specific ports unrestricted".
• Config: 3 non-compliant rules (last month there were 0).
• validate-logs: a digest file from 14 September is missing.
• Athena: 2,400 AccessDenied from rol-mercadofresco-tienda on s3:GetObject.

Cost

• CloudWatch bill: from 44 to 71 USD.
• 1 available EBS volume of 200 GiB, created on 22 September.
• Compute Optimizer: the ASG instances marked as under-provisioned.

Reliability

• vCPU quota at 75 %.
• The canario-mercadofresco-compra canary has failed 14 times, all between 03:00 and 03:20.

Observability

• The mercadofresco-pedidos-fallidos alarm has fired 23 times this month; 21 were false positives.
• One SNS subscription in PendingConfirmation: the new person's email address.

For each of the eleven findings: say what it most probably means, what priority you give it (critical, high, medium, low), what specific action you would take, and which lesson of the course the necessary knowledge comes from. Identify which of these findings are related to each other, which is the part that separates a mechanical review from a useful one.

Solution 1

Real cost of each plan with 2,400 USD of monthly spend:

Watch out for the Developer and Business calculation: it is the greater of the minimum and the percentage. With 2,400 USD of spend, Business costs 240 USD, not 100.

Cost of a 95-minute outage on a Friday at peak time:

Two outages a year ≈ 700-900 EUR of lost margin, plus the damage to the image of a fresh produce shop, where confidence in delivery within 24 h is the product.

The decision: Business, 240 USD/month. And the justification is not the Trusted Advisor checks:

The number that settles the decision: 240 USD/month is 2,880 USD a year. If support with an SLA cuts the duration of one single outage from 95 to 30 minutes, that saves around 240 EUR of margin. With two outages a year, it does not pay for itself on that alone.

But the team is three people, an informal on-call arrangement and no way of escalating to anybody at 4 in the morning. The real argument is one of risk, not of saving: with 185,000 EUR a month depending on the platform, having nobody to call when something serious breaks is a risk that is wholly disproportionate against 2,880 USD a year. It is the same kind of reasoning that in 04-04 led to not buying Shield Advanced —there the cost was 100 times higher and the risk far lower—, applied in the opposite direction. Reaching a different conclusion with the same method is what shows the method is a good one.

What Business does not cover and you have to keep doing:

And a condition for the decision to be a good one: buying Business and changing nothing else would be throwing money away. The decision includes setting up formal on-call rotas among the three people, with the set-alarm-state drill verified for every phone (05-01). AWS support answers within the hour; somebody at MercadoFresco has to be awake to read that answer.

Solution 2

Capacity calculation.

The 50 % margin is not paranoia: the figure of 600 orders/hour per instance was measured under normal conditions. On Black Friday the average basket is bigger, there are more searches per order and more abandonments with retries. Capacity per instance will go down, not up.

Quotas that fall short:

Increase requests:

Justification for the support case, if it escalates: "A grocery e-commerce shop. Black Friday campaign with an expected peak of 5× the usual traffic for 6 hours on 27 November. We need to scale the auto scaling group to 12 t3.large instances and to perform a prior blue/green deployment that temporarily doubles the capacity. We are requesting 64 vCPUs with headroom."

The most important row in the quota table is the one that is not an AWS quota: the RDS connections. With 12 instances × 40 pool connections = 480 connections, against a max_connections of 200. The database becomes the bottleneck before EC2 does. And that one is not fixed with a request to AWS: it is fixed with architecture.

Other limits that are not AWS quotas and have to be reviewed:

The fifth row is the one a technical profile forgets and the one that costs the most: scaling the shop to accept 4,500 orders an hour that the warehouse cannot prepare turns a commercial success into a customer service catastrophe. MercadoFresco's real limit may be in the warehouse, not in AWS.

Quota alarms to set up:

The third one is particularly clever: instances stuck in Pending for 15 minutes is exactly what you see when launches are failing because of a quota.

Timeline, with realistic notice:

The load test in the fourth row is what turns everything above it into a plan rather than a hope. If you have not tested it, you do not know whether it scales.

Solution 3

Findings, with priority and relationships.

Finding 3 is the most serious of all and it is worth saying why. A missing digest file means that CloudTrail's integrity chain is broken on 14 September. It may be an AWS delivery problem —it happens, rarely— or it may mean that somebody deleted log files to hide activity. You cannot tell the difference without investigating, and until it is ruled out it has to be treated as a possible security incident:

If the COMPLIANCE-mode Object Lock from 05-04 was enabled, nobody could have deleted anything and the explanation is an AWS delivery problem: you open a support case and document it. If it was not, there is serious investigating to do. This is the best practical demonstration of why Object Lock mattered.

Relationships between findings, which is the part that makes a review a useful one:

Group A: findings 1, 2 and 3 — probably the same incident.

Three Config rules that went from compliant to non-compliant, an open port, and a hole in the audit trail. That is too much of a coincidence. Config's timeline will say exactly when the rules became non-compliant, and if that date is 14 September, it is no longer a coincidence: it is an incident that has to be reconstructed in full.

Group B: findings 4 and 5 — the same deployment.

2,400 AccessDenied on s3:GetObject means there is a broken feature that no customer has reported. And every failure generates an error line in the log, which largely explains the CloudWatch increase from 44 to 71 USD. A permissions problem showed up as a cost problem. Fixing the permission fixes both.

Group C: findings 7 and 8 — the same capacity problem.

Compute Optimizer says the instances are falling short, and the vCPU quota is at 75 %. They are two sides of the same thing: MercadoFresco has grown and capacity has not followed. And there is a trap: if 7 is solved by scaling to more instances, 8 gets worse. The correct sequence is request the quota increase first, scale afterwards. The other way round, the ASG will try to launch and fail.

Group D: findings 9 and 6 — the maintenance window.

The canary fails between 03:00 and 03:20. What happens at that hour? The RDS maintenance window and the automatic backup window (02-04). During a Multi-AZ failover there are a few seconds of unavailability, and the canary detects it. And this is good news disguised as a problem: the canary is working and it is measuring a real impact that customers suffer too, even if in the small hours it affects few people. Actions: check whether the application retries lost connections properly (the pattern from 07-05), and consider moving the window to an even quieter hour.

The orphan volume from 22 September probably comes from an instance terminated during that same maintenance work.

Group E: findings 10 and 11 — the health of the notification system, and they are more urgent than they look.

• 21 false positives out of 23 means that nobody looks at mercadofresco-pedidos-fallidos any more. Its fixed threshold of 10 errors in 5 minutes does not survive the growth in traffic: with more orders there are more absolute errors even if the proportion is the same. The fix is the one from solution 1 of 05-01: alarm on the percentage, not on the absolute number, with a metric expression.
• The pending subscription means the new person has not had a single notice since they joined. If they were on call some night, nobody was on call. The confirmation is resent and a drill with set-alarm-state is run against their phone, exactly the onboarding protocol of 05-01.

Recommended order of action:

The lesson of the exercise: eleven isolated findings look like a to-do list. Grouped into five related groups, they are five real problems: a possible security incident, a deployment with incomplete permissions, a capacity problem with a trap in the order of operations, a maintenance window with measurable impact, and a notification system that has quietly degraded. That difference is exactly what you get from having the review done by a person with context rather than by an automatic report.

MercadoFresco has the last piece. You know what Trusted Advisor is and how it differs from everything that came before: Config checks your rules, Trusted Advisor checks AWS's; Config answers questions, Trusted Advisor asks them. And you know that the good cycle is to chain them: Trusted Advisor discovers what you had not foreseen, you write a Config rule so it does not come back, and the remediation fixes it on its own. Against Well-Architected (11-01), the distinction is one of altitude: Trusted Advisor looks down, at the resources; Well-Architected looks up, at the decisions.

You know the five categories —cost optimisation, performance, security, fault tolerance and service limits— and what each one checks, with the three states and the warning that an amber is a hypothesis, not an order: the root volumes of the ASG instances do not need snapshots, and formally accepting that finding with its justification is the right answer.

You have the honest table of what MercadoFresco sees with the Basic plan: basic security and service limits, which is no small thing, and nothing on cost, performance, fault tolerance or the API. And you know how to make up for what is missing with what you have already learned: the orphan volumes with an advanced Config query, the elastic IPs with describe-addresses, the idle load balancers with RequestCount, the underutilised instances with Compute Optimizer, Multi-AZ with a Config rule. Almost everything the Business plan would give you, for free. What cannot be reproduced is technical support with an SLA, and that is the real reason why it gets bought.

You have walked through a complete report of MercadoFresco's architecture and found what had been sitting there for months: 3 orphan EBS volumes from the 02-01 tests, 2 unassociated elastic IPs billed precisely for not being used and which were also taking up 2 of the 5 slots in the quota, mercadofresco-tienda-01 at 4 % CPU ever since we built the ASG and which nobody switched off, the same open port 22 that Config had already flagged —two independent tools confirming each other— and the CloudFront compression finding that is fixed with a checkbox.

And you have discovered the quota nobody had looked at: asg-mercadofresco-tienda cannot go beyond four instances because the account's vCPU quota is 16 and other workloads consume 8. The ASG's maximum was not a design decision: it was an invisible limit. A perfect latent failure, which would show up at exactly the worst moment —the Friday when scaling was needed— and would appear in no CloudWatch alarm, no Config rule and no X-Ray trace. You know how to manage Service Quotas: see the usage, request increases in advance because the big ones take days, remember that they are per region, count the blue/green deployment that doubles the instances, and above all alarm at 70 % with SERVICE_QUOTA(), the function that makes the alarm recalibrate itself when the quota changes. Two alarms, 0.20 USD a month, so that you are not left unable to scale on a Friday.

You know the Trusted Advisor API (Business, and only in us-east-1, the same pattern as ACM and the CloudFront web ACLs), exporting the recommendations to CSV, the weekly notifications to the alternate contacts from 01-02, and the integration with EventBridge (07-03) that lets you not just notify but act —automatically disabling an access key that has turned up in a public repository. And you know where Compute Optimizer and Cost Optimization Hub fit, with the warning that sums up the relationship between tools and people: Compute Optimizer recommends shrinking mercadofresco-tienda-01 to t3.small; the right answer is to switch it off. Tools optimise what is there; the question of whether it should be there is asked by a person.

And you have Marta's monthly routine: one hour, on the first Monday, with its checklist for security, cost, reliability, observability and technical debt. Including the point that is most often skipped and matters most: reviewing the alarms that produced false positives and deleting or recalibrating them, because an alarm that gets ignored is worse than no alarm at all.

This closes module 5. MercadoFresco's observability layer is complete: metrics and dashboards with mercadofresco-produccion, MercadoFresco/Tienda and thirteen alarms verified by drill; end-to-end traces with sampling at 100 % on orders and 0 % on the health check; unalterable auditing in trail-mercadofresco with seven years of retention and SQL queries over every API call; continuous compliance with 29 Config rules and automatic remediation that restores a bucket's encryption in eight minutes; and the automatic review that finds what nobody thought to ask about. The five questions from module 4 have answers —the notice arrives, the logs are correlated, the eight-second order was an N+1, the backup was decrypted by Luis testing a restore in the middle of the night, and the encryption restores itself— and all for 62.47 USD a month, 9.9 % of the bill, with five lines of configuration separating that figure from more than 600.

And now, with the house finally under watch, the watching starts to show something uncomfortable. Marta's dashboard has been saying it ever since we built it, and this module's data confirms it from three different angles: the next bottleneck is the database.

mercadofresco-pedidos is a single PostgreSQL instance that does everything, and it does it badly for different reasons in each case. The basket hammers a session table with constant writes of data that has no need whatsoever to be transactional or to live forever. Sara's reports, with their aggregations over months of history, block production when she runs them during working hours —and the read replica only moves the problem, it does not solve it. The catalogue is queried thousands of times a minute to return always the same thing: prices and descriptions that change once a day. And X-Ray itself showed that even after fixing the N+1, the shop's latency is still dominated by database queries.

All of that sits on a single instance because, when we started in 02-04, PostgreSQL was the obvious answer. And it was. But a relational database is not the right tool for every job, and forcing it to be is the most common cause of architectures that do not scale.

In module 6, "Databases", starting with 06-01, "How to choose the right database", we will look at the decision model: relational versus key-value, document, in-memory, time-series and graph, with the real criteria —access pattern, consistency, latency, volume and cost— for choosing between them. After that, DynamoDB for the session table and the basket, Aurora as the natural evolution of PostgreSQL when more is needed, Redshift so that Sara's reports stop touching production, and ElastiCache so that the catalogue is served from memory in microseconds. And all of it with the advantage that, for the first time in the course, every change we make can be measured: we have the metrics, the traces and the dashboards to prove whether a given architecture decision was a good one or not.