With the tags activated and the cost and usage report landing every day in mercadofresco-informes-analitica, MercadoFresco can already share out its bill. What is missing is the other half: actually looking at it. Not the total, not a summary table, but the full breakdown by service, going into the three or four lines almost nobody understands, and coming out of there with a list of concrete actions and their calculated savings.

This lesson makes that journey. You will see what Cost Explorer is and what data it works with, the billing concepts you have to understand before looking at a chart — because otherwise the numbers do not add up and you lose confidence in the tool — MercadoFresco's real bill service by service up to 2,237.60 USD, the three surprises that turn up almost every time, anomaly detection, the automatic recommendations and how they relate to Compute Optimizer and Trusted Advisor, the query from boto3 that publishes spend alongside the business figures, and the ten optimisations MercadoFresco carries out, with their savings one by one.

Cost warning. The Cost Explorer interface is free. What does cost money is the API: each paginated call to GetCostAndUsage and friends is billed at 0.01 USD. A dashboard that queries the API every five minutes comes to around 90 USD a month, an expensive and surprisingly common mistake. Anomaly detection is free. Fictitious data, accounts and identifiers; prices are indicative and vary by region and date.

1. What Cost Explorer is and what data it works with
2. Billing concepts: unblended, amortised and net
3. Charges, credits, refunds and taxes: why the total does not add up
4. Consolidated billing across the six accounts
5. MercadoFresco's bill, service by service
6. Surprise 1: the NAT Gateways
7. Surprise 2: cross-AZ data transfer
8. Surprise 3: CloudWatch
9. Filters, groupings and saved reports
10. The cost dashboard Marta reviews every month
11. Cost anomaly detection
12. The case of the nightly Redshift load
13. Reduction recommendations and orphan resources
14. Compute Optimizer and Trusted Advisor
15. Spend forecasting and how to read it
16. Querying Cost Explorer from boto3
17. Publishing daily spend as a business metric
18. MercadoFresco's ten optimisations
19. Common mistakes and tips
20. Exercises
21. Conclusion

AWS Cost Explorer is the interactive analysis tool for the bill: charts, filters, groupings and forecasts over spend and usage. You enable it once from the management account and, from that moment on, it starts preparing the data.

What you need to know before trusting a number:

The first operational rule that saves you grief: never draw conclusions from the current day. With the refresh delay, today's spend always looks lower than it will be, and more than one team has celebrated a saving that was simply incomplete data.

Before looking at a chart you have to understand what it is measuring, because Cost Explorer offers several cost metrics and they give different results for the same month. It is the number one cause of distrust in the tool.

The difference is clearest with an example MercadoFresco will live through in 11-05. Suppose a 1-year Savings Plan with an all upfront payment of 1,200 USD taken out on 1 March:

With unblended cost, the chart shows an enormous spike in March and a drop to zero afterwards, which is true for the cash flow and utterly useless for analysing efficiency. With amortised cost, each month carries the 100 USD that belong to it and the chart reflects the real cost of operating.

The practical recommendation: use unblended to reconcile with the bill and net amortised to analyse. And always say which one you are using when you present a number, because two people looking at the same screen with different metrics will argue for half an hour without realising they are both right.

MercadoFresco, which has no commitments purchased yet, sees exactly the same number in all four metrics. That changes in 11-05, and it is worth knowing in advance.

The second source of distrust is that the Cost Explorer total does not match the amount charged to the card. It is not an error: the bill contains line types that Cost Explorer, by default, filters out or shows separately.

MercadoFresco's August bill, in full:

Two rules come out of that which are worth fixing in the team's head:

1. The working number is the service cost: 2,237.60 USD. That is the one you can reduce with engineering decisions. Taxes are not optimised, they are paid.
2. Credits deceive. While they last, spend looks lower than it is, and the day they run out a jump appears that nobody caused. MercadoFresco excludes them from the analysis and treats them as what they are: a temporary discount.

The organisation o-a1b2c3d4e5 has consolidated billing enabled, which is the default behaviour of AWS Organizations (09-04). That implies three things which bear directly on this analysis:

• A single bill and a single payment method, issued from the management account 999988887777. Member accounts do not receive their own bill.
• Usage aggregation for volume tiers. The 40 GB of S3 in production, the 12 in pre-production and the 8 in development count as 60 GB for pricing tiers. At small volumes the saving is symbolic, but with data transfer or S3 at scale it becomes relevant.
• Commitments are shared. A Savings Plan bought in any account covers usage in all the others, unless sharing is turned off. It is a central point of 11-05.

In Cost Explorer, the management account sees everything; a member account only sees itself, and only if access is enabled. Marta always works from the management account with the billing read-only role, and Luis and Sara see their own account.

This is the full breakdown for the month of August, grouped by service, with unblended cost and the six accounts consolidated:

The first thing to do with a table like this is read it the opposite way round from how everyone looks at it. The typical reaction is to fix on Aurora, which is the biggest line, and start arguing about whether two readers are needed. But Aurora is there because of a conscious decision, documented and signed off by management (ADR-014 in 11-01). What is interesting are the lines nobody decided: the NAT, cross-AZ transfer, CloudWatch and the residual EC2. Together they come to 611.20 USD a month, 27.3 % of the bill, and not one of them has ever been the subject of an explicit decision.

243.80 USD a month, the third line of the bill, for a component nobody remembers choosing. It is the most repeated finding in every cost review in the industry.

The NAT Gateway is billed on two counts:

MercadoFresco's breakdown:

Two observations that change the conversation:

1. 81 % of the cost is the fixed hourly charge, not the traffic. Optimising traffic does not fix the problem; reducing the number of NATs does.
2. Pre-production and development pay 143.80 USD a month to reach the internet, in environments where there is not a single customer and where an hour without internet access bothers nobody. Two NATs in development is high availability for an environment nobody considers critical.

And there is a third observation that connects with 10-02: a good part of production's 756 GB is image pulls from ECR, S3 API calls and log delivery to CloudWatch, that is, traffic towards AWS services that could bypass the NAT if there were endpoints. MercadoFresco already put four endpoints on the critical path; the analysis still pending is whether more are worth it, and the answer — as seen in 10-02 — is that seven endpoints across two AZs work out dearer than the NAT.

Inside the 118.60 USD of the VPC line there are two very different things:

Cross-zone transfer is the most invisible cost in AWS, because there is no resource to blame: it does not appear under any tag, there is no dashboard that shows it and you cannot switch it off. It appears all by itself as soon as an architecture is Multi-AZ, which is exactly what is recommended for reliability.

Where those 54.40 USD come from at MercadoFresco:

• The ALB spreads traffic across two AZs. With cross-zone load balancing enabled — which on an ALB is always on and free for ALB, but not for NLB — a request arriving in AZ a can end up on a task in AZ b.
• Aurora replicates from the writer to both readers, and one of them is in the other zone. Every byte written crosses the zone.
• ElastiCache replicates from the primary to the replica, which is in the other AZ.
• Fargate tasks read from the Aurora writer, which sits in one specific zone; half the tasks cross.

And here comes the important part: nearly all of that cost is the price of high availability, and it should not be removed. This is the textbook case of the trade-off between pillars from 11-01: you could save by concentrating everything in one zone, and you would lose exactly the property Multi-AZ was built for. What does make sense is reducing unnecessary crossing: routing reads to the reader in the same zone where possible, and not shifting large volumes of data between zones out of habit.

The right action on this line is not to cut it, but to know it exists, understand it and not discover it the day the bill goes up 40 % because of a topology change.

214.90 USD, the fourth line of the bill. It is the most uncomfortable surprise, because observability is a virtue and here it shows up as a considerable expense. The breakdown:

The two dominant lines are log ingestion and log storage, and both have the same root: nobody ever decided how much to keep or what to log. Specifically:

• The applications log at DEBUG level in pre-production and in production, because it was turned on to debug an incident in April and never turned back down.
• The ALB access logs and the WAF logs go to CloudWatch Logs as well as to S3, doubling the cost.
• No log group has retentionInDays configured, which means indefinite retention. A group created a year ago is still keeping everything.

This is the item with the best effort-to-saving ratio in the whole bill, and it appears in the list of optimisations further down.

The value of Cost Explorer lies in crossing dimensions. The available groupings and what each one is for:

Usage type is the most underrated dimension and the one that solves the most mysteries. "Amazon Virtual Private Cloud: 362.40 USD" tells you nothing; grouped by usage type you get EUW1-NatGateway-Hours: 198.00, EUW1-NatGateway-Bytes: 45.80, EUW1-VpcEndpoint-Hours: 64.20 and EUW1-DataTransfer-Regional-Bytes: 54.40, and suddenly you know exactly what to do.

Saved reports are queries with their filters and groupings, given a name and shared within the management account. MercadoFresco's five:

The last one is the most useful of the five: in a daily view of development, a resource left on over a Saturday is visible at a glance.

Marta blocks out 45 minutes on the 5th of each month — when the previous month's data is already closed — and always follows the same script. The discipline of always looking at the same things, in the same order, is what turns noise into a trend:

1. Month total against the previous month and against the same month last year. If the variation exceeds ±10 %, it gets explained before moving on.
2. Cost per order. It is the first number said out loud, before the total (11-02).
3. The five lines that have risen most in absolute value, not in percentage. A service going from 0.40 to 1.20 USD has risen 200 % and does not matter.
4. Split by environment. Stated target: the non-production side must not exceed 25 % of the total.
5. Untagged cost. It should tend to zero; if it rises, there are new resources created outside the pipeline.
6. Anomalies detected since the last review and what was done about each one.
7. Forecast for the current month and comparison with the budget (11-04).
8. One concrete action with an owner and a date. Only one. A monthly meeting that produces twelve actions a year that get done is worth more than one that produces forty that get abandoned.

Looking at the bill once a month has an obvious problem: a mistake made on the 6th is discovered on the 5th of the following month, with thirty days of accumulated spend. AWS Cost Anomaly Detection covers that gap with machine learning over the historical spend pattern, and it is free.

The concepts:

• A monitor defines what is watched: all services, an account, a tag or a cost category.
• A subscription defines who is notified, with what threshold and how often.
• Thresholds can be absolute (more than X USD of impact) or percentage-based (more than X % above expected). They can be combined with AND/OR.

MercadoFresco's three monitors:

Notes on the decisions taken here:

• MonitorType: DIMENSIONAL with SERVICE automatically creates a monitor for every service in use. It is the sensible default and it needs no maintenance.
• The second monitor exists because the non-production environments have a much flatter pattern: any rise is suspicious, whereas in production a rise may simply be a good Friday.
• Frequency: IMMEDIATE only works with SNS; email supports DAILY or WEEKLY. For immediate notification you have to go via SNS, which is also already integrated with Chatbot and reaches the team channel.
• Thresholds combined with Or avoid the two classic failures: a percentage-only threshold fires constantly on cheap services, and an absolute-only one fails to spot that a small service has multiplied tenfold.

A calibration tip: start with high thresholds and lower them. An anomaly detector that fires three times a week gets muted within a fortnight and is no use to anyone.

On 14 August at 09:12, alertas-mercadofresco receives this notification:

Sara's investigation follows three steps that serve as a template for any cost anomaly:

The three steps, with their concrete result:

1. Group by usage type in Cost Explorer, filtered to Redshift and the last 14 days. The result points at RPU-Hours, not storage: the problem is compute, not data.
2. Hourly view of those days. The pattern is unmistakable: before, a 40-minute peak at 02:00; now, continuous activity from 02:00 until 08:00.
3. CloudTrail and the query logs. On 7 August a new report was deployed with a query that produces a cartesian product through a JOIN with no condition. The query does not fail: it simply takes six hours, and meanwhile the Serverless workgroup never pauses.

The real cost of the incident: 68.40 USD in seven days, which at that rate would be around 340 USD a month, 15 % of the bill, for a badly written JOIN.

The three actions taken, and none of them is just "fix the query":

The general lesson: a cost anomaly is almost always a technical error, not a money problem. The billing alert was, in this case, the most effective error-detection system the team had.

Cost Explorer includes a Rightsizing recommendations section that analyses CPU and memory usage over the last 14 days and proposes downsizing or shutting down. Its limits are worth knowing: it only covers EC2 (not Fargate, not Lambda, not Aurora) and it assumes the pattern of the last two weeks will repeat.

For MercadoFresco, whose compute is now almost all on Fargate, that section contributes little. What does contribute a lot is hunting orphan resources, which needs no special tooling:

They add up to 114.30 USD a month on things nobody uses, that is, 5.1 % of the bill thrown away. And they are, without exception, leftovers from legitimate work: a test that was run, an environment that was brought up, an instance that was stopped instead of terminated.

The script MercadoFresco runs every Monday to find them:

Two design decisions in this script deserve a comment. It reports only, it never deletes: an available volume may be the copy someone deliberately detached before a migration, and an automatic deletion would destroy data. And it runs weekly, not daily, because orphans appear slowly and a daily report that is almost always empty stops being read.

Three tools overlap here and it is worth knowing which to use for what:

For MercadoFresco, the most useful of the three is Compute Optimizer, precisely because it covers what Cost Explorer cannot see:

• Lambda: it recommends memory per function. The mercadofresco-generar-miniaturas function is at 1,024 MB and peaks at 340 MB; dropping it to 512 MB saves little money but also reduces the runtime, because CPU scales with memory. Care is needed here: lowering a Lambda's memory can make it slower and more expensive, and that has to be measured with power tuning, not assumed.
• ECS on Fargate: it validates the percentile-based sizing done in 10-02, and flags that svc-mercadofresco-trabajadores is oversized on memory.
• EBS: it proposes moving the remaining gp2 volumes to gp3, 20 % cheaper with the same baseline performance.

The division of labour that works: Trusted Advisor for the obvious and cross-cutting, Compute Optimizer for fine sizing, Cost Explorer to understand the money and decide. None of the three replaces the monthly review with human judgement, because none of them knows that a pre-production environment has to resemble production even if it is underutilised.

Cost Explorer projects future spend with a confidence interval. For MercadoFresco, the mid-month forecast for August was 2,180 USD with an 80 % interval between 2,050 and 2,310; the actual close was 2,237.60 USD, inside the interval.

Three warnings about the forecast, in order of importance:

1. It extrapolates the past. It does not know that on 1 September the development environment starts shutting down overnight, nor that there is a campaign in December. Any decision already taken invalidates the forecast.
2. The confidence interval is part of the number. Presenting "2,180 USD" without saying "between 2,050 and 2,310" turns an estimate into a promise, and somebody will treat it as one.
3. It is very poor at the start of the month. With three days of data, MercadoFresco's forecast swung between 1,900 and 2,600 USD. From about the 10th it settles down.

Its legitimate use is as input to the budgets with a forecasted-cost threshold in 11-04: finding out on the 8th that you are going to blow the budget is far more useful than finding out on the 30th that you did.

Everything above can be automated with the API. The complete example MercadoFresco runs every day:

The details you need for this to work and not turn out expensive:

• The client is created in us-east-1. The Cost Explorer endpoint is global and lives there; creating it in eu-west-1 produces a connection error that throws people off for a while.
• RECORD_TYPE = Usage excludes taxes, credits and fees, so that the total matches the service cost and not the total billed.
• Each call costs 0.01 USD. This script runs once a day: 0.30 USD a month. Run every five minutes from a dashboard it would be 87 USD a month, more than ElastiCache costs in pre-production.
• GroupBy accepts a maximum of two dimensions. For richer cross-sections, the route is the CUR with Athena from 11-02.
• The response comes paginated with NextPageToken when there are many groups; in production you have to walk through it, and each page is another billed request.

The step that turns the analysis into something people look at without meaning to: bringing spend to the dashboard where the business already lives.

Why this matters more than it looks:

• It uses the figure from two days ago, not yesterday's, because of the refresh delay. Publishing yesterday's produces a series with false troughs that confuse more than they inform.
• It publishes one series per environment and one total, which lets you put a chart on the mercadofresco-negocio dashboard with CosteDiario next to PedidosConfirmados. Seeing the two lines together is the most direct way to understand unit cost without calculating anything.
• It enables CloudWatch alarms on cost, with all the machinery from module 5: thresholds, missing data, actions and suppression. An alarm on CosteDiario in development above 10 USD warns you in hours, not weeks.
• This script lives in a Lambda with EventBridge Scheduler running at 06:00, and its total cost is pennies.

With all the analysis done, Marta and Luis spend two days executing. These are the ten actions, ordered by saving:

The detail of the first three, which are the ones that contribute most.

1. Nightly shutdown (118.00 USD). Pre-production and development run 24×7 for a team that works from 8 to 19 Monday to Friday. Switched on from 07:30 to 20:30 on working days is 65 of the 168 hours in a week: a 61 % reduction in what can be switched off. With EventBridge Scheduler:

The explicit Europe/Madrid time zone is no small detail: without it, daylight saving shifts the shutdown by an hour and, twice a year, somebody finds the environment down at 19:30. What gets switched off: Fargate tasks to zero, Aurora instances stopped — remembering that RDS and Aurora start themselves up again after 7 days stopped, so you need a scheduler to stop them again — and the Redshift workgroup, which pauses by itself.

2. Log retention (74.00 USD). Two independent changes. The first, setting retention on the 84 log groups:

The second, dropping the log level from DEBUG to INFO in production, which cuts ingestion from 61 to about 38 GB a month. And an architectural decision taken along the way: the ALB and WAF access logs stop being duplicated in CloudWatch Logs and stay only in S3, where they are already queried with Athena and cost twenty times less.

3. From 2 NATs to 1 (66.00 USD). In pre-production and development one NAT per environment is removed and the traffic from both private subnets is routed through the surviving one. The real consequence, written down so nobody is surprised: if the AZ of the surviving NAT goes down, that environment loses its internet access. In development, that means Luis cannot download dependencies for a while. In production it is left alone, and that asymmetry is exactly what it means to treat environments according to their criticality rather than out of habit.

The overall result:

And an honest observation about this list: none of the ten actions has degraded production. No Aurora reader has been removed at peak, production observability has not been cut below what is needed, and internet egress redundancy has not been touched where there are customers. A 22 % saving without touching service quality is normal on the first optimisation pass over an architecture that has never been reviewed. The second pass costs a great deal more work per dollar.

Mistake: comparing the current month with the full previous month. On the 12th it looks like you have saved 60 %. Tip: compare equivalent periods — day 1 to 12 against day 1 to 12 — or use the forecast, never a partial month against a closed one.

Mistake: drawing conclusions from today's spend. With up to 24 hours of delay, the current day always looks cheap. Tip: work with data from at least two days ago, and publish your metrics with that lag.

Mistake: mixing unblended and amortised cost in the same conversation. Two people see different numbers and argue for half an hour. Tip: always say which metric you are using. Unblended to reconcile with the bill, net amortised to analyse.

Mistake: chasing the biggest line on the bill. Aurora is the largest and it is a conscious, signed-off decision; the badly spent money is in the mid-sized lines nobody decided. Tip: sort by "cost nobody has decided", not by amount.

Mistake: querying the Cost Explorer API from a dashboard that refreshes every minute. At 0.01 USD per request, cost analysis ends up as a line on the bill. Tip: query once a day and publish the result as a CloudWatch metric; the dashboards read the metric, not the API.

Mistake: enabling hourly granularity and forgetting about it. It costs money per record queried and you pay even if you barely use it. Tip: enable it for the specific analysis that needs it — the Friday peak, the stable baseline in 11-05 — and check whether it is still needed.

Mistake: anomaly thresholds that are too sensitive. Three alerts a week and the channel gets muted. Tip: start high — 25 USD or 40 % — and lower them based on real experience, with combined absolute and percentage thresholds.

Mistake: deleting orphans automatically. An available volume may be the copy someone set aside before a migration. Tip: the detector reports, the person decides. And before deleting, tag with FechaBaja and wait a week.

Mistake: shutting environments down without warning. The team finds the environment down at 20:31 in the middle of a test. Tip: announce it, leave a documented manual start-up procedure and begin with development before pre-production.

Tip: the first analysis of a bill that has never been reviewed yields between 15 and 30 %. You do not need to be brilliant, you need to look. The hard part is the second pass.

Tip: turn every finding into a permanent check. Log retention is not a task, it is a Config rule; the ECR lifecycle is not a deletion, it is a policy; the nightly shutdown is not a reminder, it is a scheduler.

On 3 October, alertas-mercadofresco receives an alert: Amazon S3 in account 111122223333 has gone from 4.20 to 19.80 USD a day since 28 September. Accumulated impact: 78.00 USD.

1. List four hypotheses ordered from most to least likely.
2. State which grouping and which filter you would use in Cost Explorer to rule them out.
3. If the cause turns out to be that access logging was enabled on the mercadofresco-catalogo-fotos bucket and those logs are written to the same bucket, which three actions would you take?

You have a single day of work and this list of possible actions on MercadoFresco's bill:

1. Choose what you would do in that day and justify it.
2. Why is F dangerous right now, if it has the largest saving and the lowest effort?
3. Calculate the saving achieved and the percentage against the 2,237.60 USD.

Cost Explorer, filtered to Amazon CloudWatch and grouped by usage type, returns this for a month:

1. Translate each line into what it means in practice.
2. Which would you tackle first and with which concrete action?
3. Estimate the saving if ingestion drops from 61 to 38 GB a month and retention goes from indefinite to 30/90 days, knowing that storage would settle at around 130 GB.

Solution to exercise 1

(1) Four hypotheses, from most to least likely:

1. A log that writes to S3 has been enabled — bucket access, ALB logs, WAF logs, the CUR or VPC flow logs — and the volume of PUT requests has shot up. It is the most frequent cause of an abrupt jump in S3, because the cost is not in the bytes but in the requests.
2. A large volume of data has been uploaded: an initial load, a manual backup, a database export.
3. A process in a loop rewriting the same objects, or versioning enabled with no lifecycle so every old version is kept.
4. Egress transfer to the internet or to another region, if some external consumer started reading directly from the bucket, bypassing CloudFront.

(2) How to rule them out. Filter: service = Amazon S3, account = 111122223333, last 30 days, daily granularity. Grouping: usage type. That single view discriminates between the four hypotheses at a glance, because the usage types are different: Requests-Tier1 (PUT requests) points to the first or the third; TimedStorage-ByteHrs points to the second; DataTransfer-Out-Bytes points to the fourth. If Requests-Tier1 dominates, a second step with the CUR grouping by line_item_resource_id gives you the exact bucket.

(3) Three actions if it is access logging writing to the same bucket:

1. Move the log destination to mercadofresco-registros-web, never to the same bucket being logged. Writing access logs into the bucket itself creates a loop: every log write generates an access, which generates a log. It is a classic mistake and it can grow without limit.
2. Put a lifecycle on those logs: 30 days in Standard, then Glacier Instant Retrieval, deletion at 180. Access logs are almost never consulted after the first month.
3. Ask whether they are needed at all. If the aim was auditing, CloudTrail data events (05-03) already cover S3 access with a better format and better integration, and they are probably already on. A duplicated log is paid for twice.

Solution to exercise 2

(1) What I would do in one day (8 hours): B (1 h) + D (2 h) + E (2 h) = 5 hours, and with the remaining 3 hours start A, leaving the scheduler written and tested in development but not yet applied to pre-production.

The reasoning: B, D and E are low risk, low effort and immediate effect, and together they come to 181 USD a month for five hours of work. A has the largest saving but needs six hours on the clock plus a heads-up to the team, so splitting it is the sensible move. C waits for another week: eight hours for 27 USD a month is the worst ratio on the list, and it also carries medium risk because it requires testing the arm64 image in pre-production first.

(2) Why F is dangerous. For a reason of sequencing that 11-05 develops and that is worth internalising now: committing capacity before optimising is buying what you are about to stop using. If you buy a three-year Savings Plan sized on current consumption and the following week you carry out actions A to E, consumption drops 22 % and the surplus commitment is still paid for over three years. Two aggravating factors pile on top: three years is a horizon over which the architecture will almost certainly change, and a Savings Plan cannot be cancelled. The right order is always: first switch off what is spare, then size what is left, and only then commit.

(3) Saving achieved:

Eight per cent of the bill for five hours of work. It is a return no other technical activity matches, and it is exactly why the improvement plan in 11-01 started with the cost pillar.

Solution to exercise 3

(1) Translation of each line:

(2) What to tackle first. The two log lines, which are 71 % of the total, and in this order:

1. Retention (TimedStorage), because it is the lowest-risk change: one command per group, no effect on the application and the saving starts the following month. All you have to decide with judgement is the audit groups, which must be kept longer.
2. Ingestion (DataProcessing), dropping the level to INFO in production and stopping the duplication of ALB and WAF logs into CloudWatch when they are already in S3.
3. Further back, reviewing the 90 custom metrics and the 84 alarms: there are almost always metrics nobody charts and alarms nobody attends to. That is 35 USD a month and, more importantly, every alarm nobody looks at degrades the credibility of the ones that do matter.

(3) Estimated saving:

It matches the 74 USD of action 2 on the optimisation list. Two caveats so as not to over-promise: the storage saving is not immediate, because the existing logs expire over the following weeks according to their age, so the full effect shows in the second or third month; and dropping from DEBUG to INFO has a real cost that has to be accepted in writing, which is having less detail available the day you have to investigate an odd incident in production. The mitigation is to leave DEBUG level switchable on demand through a parameter in /mercadofresco/produccion/... with no need to deploy.

MercadoFresco has opened up its bill and come out of it with 22 % less spend and no degradation of service.

You know what Cost Explorer is and what data it works with: 13 months of history, free daily granularity and paid hourly granularity, up to 24 hours of delay — hence the rule of never drawing conclusions from the current day — and a free interface with an API that costs 0.01 USD per request, which is the expensive mistake that turns a cost dashboard into a line on the bill.

You have the billing concepts you need to understand before looking at a chart: unblended to reconcile with the bill, amortised to analyse once there are commitments — with the example of the 1,200 USD Savings Plan that shows up as a March spike or as 100 USD a month depending on the metric — and the net variants that deduct credits. Plus the reason the total never matches what was charged: the Tax, Credit and Refund line types and the fees, with the rule of always working on the service cost, which is the only one engineering can optimise. And consolidated billing across the six accounts, with its three consequences: a single bill, volume tier aggregation and shared commitments.

You have MercadoFresco's complete bill: 27 lines up to 2,237.60 USD, headed by Aurora (342.60), Fargate (262.40), NAT Gateway (243.80) and CloudWatch (214.90). And the right way to read it, which is not from largest to smallest amount but by separating what was decided from what was not: Aurora is there because of a signed ADR, whereas the 611.20 USD of NAT, cross-AZ transfer, CloudWatch and residual EC2 — 27.3 % of the bill — were never decided by anyone.

You have the three surprises taken apart with their specific origin. The NAT Gateway, 81 % of which is the fixed hourly charge and not traffic, with 143.80 USD a month paid by environments without a single customer. Cross-AZ transfer, the most invisible cost in AWS because there is no resource to blame, which comes from the ALB spreading traffic across AZs, from Aurora's replication and from ElastiCache's, and which must not be removed because it is the price of high availability. And CloudWatch, where 71 % is logs and the root cause is the same in both lines: nobody ever decided what to log or how long to keep it.

You have the monitoring tools: filters and groupings — with usage type as the most underrated dimension, the one that turns "VPC: 362.40 USD" into four actionable lines — the five saved reports, the eight-step script for Marta's monthly review that always ends with a single action with an owner and a date, and anomaly detection with dimensional monitors, combined absolute and percentage thresholds, and immediate notification over SNS. Along with the real case of the nightly Redshift load — a JOIN with no condition that cost 340 USD a month and was caught by the bill — and its lesson: a cost anomaly is almost always a technical error, not a money problem.

You have the hunt for orphan resources, 114.30 USD a month on things nobody uses, with the weekly script that reports and never deletes; the division of labour between Cost Explorer, Compute Optimizer and Trusted Advisor, knowing that only Compute Optimizer sees Fargate and Lambda; the forecast with its three warnings, starting with the fact that it extrapolates the past and therefore any decision already taken invalidates it; and the query from boto3 with get_cost_and_usage, the client in us-east-1, the RECORD_TYPE=Usage filter and the script that publishes CosteDiario in MercadoFresco/Tienda with a two-day lag, so that spend finally lives on the same dashboard as the orders.

And you have the ten optimisations carried out with their savings: nightly shutdown (118), log retention (74), from two NATs to one in non-production (66), Aurora reader auto scaling (54), S3 lifecycle (38), orphans (41), pre-production endpoints (32), arm64 on the workers (27), Redshift limits (27) and ECR lifecycle (11). 488.00 USD a month, 21.8 %, which leaves the bill at 1,749.60 USD and the cost per order at 0.00972 USD. With the honest observation that none of the ten has degraded production, and with the warning about what comes next: the first optimisation pass over an architecture that has never been reviewed yields between 15 and 30 % without any brilliance; the second costs a great deal more work per dollar.

There is one problem this analysis does not solve. Everything above is looking backwards: you discover what has already been spent. The anomaly detector warns you within a day or two, which is fine, but nobody has yet put a limit in place. If tomorrow Luis brings up a test EKS cluster in the development account and forgets about it, or if a new query takes off on a Friday night, the bill will grow with nothing standing in its way. And the 10 USD presupuesto-mensual-mercadofresco created in 01-02 has been firing on the 2nd of every month for twenty-odd months, to the point where nobody reads its emails any more.

In 11-04, "AWS Budgets", you move from analysing to controlling: budgets by account, by service, by tag and by cost category, with thresholds on actual and forecasted cost, with escalating notifications and with automatic actions capable of freezing the development account when it reaches its limit. Plus the FinOps routine that sustains the whole cycle.