Database. Per gigabyte, this is the most expensive storage you own — replicated, backed up, on fast disks — which is the economic argument behind three earlier rules: do not put blobs in it (Module A-11), do not put logs in it, and partition old data so it can be dropped or tiered (Module P-9). Replicas cost full price, and analytics on the OLTP instance means paying OLTP prices for scan-heavy work (Module P-22).

And provisioned IOPS is a line item, which closes this course's first through-line. Module F-2 established that sequential access is dramatically cheaper than random. Module P-3 showed that random UUID primary keys destroy insert locality. Module F-13 showed that bloat multiplies the pages a query must touch. Every one of those is now literally an invoice: more IOPS provisioned, more I/O charged, a larger instance to hold a working set that should have been smaller. The physics from Phase 1 arrives as a monthly bill, and that is the most direct link between a low-level design decision and money in the entire curriculum.

Network. Load balancers charge per hour and per capacity unit, so a fleet of under-used balancers is pure overhead. And the item that is routinely large and rarely understood:

NAT gateway data processing. Traffic from a private subnet to the internet — including to object storage, to a managed service's public endpoint, and to a third-party API — is charged per gigabyte processed by the NAT gateway, on top of egress. A pipeline reading terabytes from S3 through a NAT gateway can produce a five-figure monthly charge that a VPC endpoint (gateway or interface) eliminates almost entirely. It is one configuration change, it is frequently one of the top five line items, and most teams have never looked at it.

Managed services and third parties. Per-request, per-seat, or per-token (Module A-12's LLM costs, where output tokens are several times input and an agentic loop is unbounded). The observability vendor belongs here too, priced on cardinality and volume (Module O-1). These are the line items that grow silently with usage and have no natural ceiling unless you impose one.

---

The Architectural Levers, Ordered by Size

Resource-level optimisation gets 20–50%. Design-level changes get 5–20×. In order:

1. Do not do the work at all. A cache hit is the cheapest possible request (Module F-12): no compute, no database, no egress if it is at a CDN. Everything in this category is the same idea — pre-aggregation instead of scanning (Module P-22), a CDN instead of origin serving (Module A-11), pagination limits instead of full result sets, conflation instead of every update (Module A-10), and a rollup table instead of a warehouse query per page load.

2. Do it later, and more cheaply. Asynchronous work on spot capacity, batch instead of streaming. And the question worth asking of every "real-time" requirement (Module P-22): what decision changes because this is fresh in seconds rather than in an hour? The honest answer is usually "none," and the cost difference between the two designs is large.

3. Do it once. Content-addressed storage deduplicates identical files (Module A-11); an embedding cache keyed on content hash removes repeated model calls (Module A-12); memoisation and request coalescing collapse a stampede into one fetch (Module P-12).

4. Do not store or ship what nobody reads. Unused metric series (Module O-1 notes most are never queried), logs at debug level in production, columns nobody selects, backups of derived data (Module O-7's tier 3), and traces retained for a year that nobody has ever opened past week two.

5. And the one this course has been building towards.

When scaling out is just buying your way past a design flaw

Each row is a real pattern, and in each the purchase works — capacity is genuinely added, the incident genuinely ends. That is what makes it seductive: buying capacity is fast, requires no code review, and can be done during an incident, while fixing the design takes a sprint and a migration.

The test that distinguishes them:

If cost per request rises as you scale, you are buying past something. Efficient scaling holds cost per unit roughly flat; paying to avoid a fix makes each unit more expensive, permanently.

That single metric, trended, is the most valuable thing in this module — because it turns an architectural judgement into an observation, and because the alternative is a bill that grows superlinearly with revenue while nobody can say why.

---

Governance That Actually Works

• Enforce tagging with policy as code (Module O-3), so an untagged resource cannot be created. Retrofitting tags is an archaeology project.
• Showback or chargeback per team, so the people who can change a design see its cost. Cost data that reaches only finance changes nothing.
• Anomaly detection on daily spend. The failure this catches is a runaway loop — an agent without a step cap (Module A-12), a retry storm against a metered API, a job stuck re-processing, a debug flag left on. These produce five-figure surprises within days, and a daily anomaly alert catches them while a monthly review does not.
• Budgets with alerts, per team and per service, so the conversation happens before the invoice.
• Cost estimates in pull requests. Tooling that annotates an infrastructure change with its projected monthly delta (Infracost and similar) makes cost a design-time decision reviewed alongside the code — which is where it is cheapest to change.
• A cost review on the same cadence as the capacity review (Module O-5), because they are the same conversation with different units: resource-per-request times traffic forecast, with prices attached.

---

The Trade-Offs, Honestly

Cost trades against things you also want, and pretending otherwise produces bad decisions in the other direction:

• Cost versus reliability. Module O-7's standby tiers and Module O-2's nines both cost money by design. The right response to "the hot standby is expensive" is a stated RTO for that data class, not a cheaper standby chosen quietly.
• Cost versus latency. Multi-region, CDNs and caches cost money to save milliseconds. The question is what those milliseconds are worth, which is a product question with a real answer.
• Cost versus velocity. This is the one engineers get wrong most often: premature cost optimisation has exactly the same shape as premature performance optimisation. A team of six spending three weeks to save £400 a month has spent far more than it saved, and has added complexity that will slow every subsequent change.

Two rules that keep this proportionate. Measure before optimising — most teams guess wrong about where the money goes, and the actual answer is frequently egress, NAT processing, logs, or idle capacity rather than the compute everyone assumed. And optimise the top two or three line items and ignore the rest, because a 30% saving on 40% of the bill dwarfs a 90% saving on 2% of it.

Why this matters in production: the cost failures that happen are quiet and cumulative. A NAT gateway processing a pipeline's terabytes for a year. Incomplete multipart uploads billed since 2024 (Module A-11). Orphaned volumes from a StatefulSet scale-down. A log level left at debug after an incident. An LLM agent loop without a step cap. Cross-region replication of data that was derivable. Three read replicas standing in for a JOIN. None of them pages anyone, none appears in an incident review, and together they are frequently a third of the bill — which is why the useful practice is a trended cost-per-request metric and a daily anomaly alert rather than an annual optimisation project.

---

Where This Shows Up in Your Stack

• PostgreSQL: the most expensive storage per gigabyte you operate, so keep blobs (Module A-11) and logs out of it, partition old data so it can be dropped or tiered (Module P-9), and keep scan-heavy analytics off the OLTP instance (Module P-22). Replicas cost full price. And provisioned IOPS is where Phase 1's physics becomes an invoice: random-insert keys (Module P-3) and table bloat (Module F-13) both raise the I/O you must pay for.
• Redis: memory is the cost, so TTLs, eviction policy and what you choose to cache are cost controls (Module P-12). Do not replicate a cache cross-region — give each region its own and avoid the egress entirely (Module A-9).
• Kafka: storage is retention × replication factor, so a 7-day retention at RF=3 is 21 days of disk; and cross-AZ replication traffic between brokers is billed, which is a known large and surprising line item. Decide retention per topic rather than globally (Module P-15).
• Object storage: lifecycle rules to abort incomplete multipart uploads, tiering for large cold objects only, and a CDN in front so you pay CDN egress rather than origin egress (Module A-11).
• NAT gateway and VPC endpoints: check the NAT data-processing line before anything else. A gateway endpoint for object storage and interface endpoints for the managed services you call heavily can remove a top-five line item with one change.
• Observability: cardinality and volume are the price (Module O-1) — cardinality limits at the collector, tail-based sampling, retention tiers, and deleting the majority of series nothing queries.
• LLM APIs: output tokens dominate, so cap max_tokens, trim context (which also improves quality), route easy requests to a small model, cache embeddings by content hash, and put hard step and token budgets on agentic loops (Module A-12).
• Spot capacity: transcoding (Module A-11), embedding backfills, batch pipelines and CI — with the checkpointing from Module P-19 that makes an interruption cost one chunk.

---

Summary

• The architecture determines the bill; finance can only report it. A system costing three times more per request than it needs to is a defect with the same standing as one that is three times slower — cheap to influence at design time, expensive to retrofit.
• Total spend is unactionable; unit economics is not. Cost per request, per tenant, per order. Cost per request rising means the system is getting less efficient, and a deploy that doubles it should be as visible as one that doubles p99. Per-tenant cost is what reveals that a plan is sold at a loss, and the distribution is usually extreme — Module P-8's noisy neighbour with prices attached, bounded by Module P-18's per-tenant limits.
• Attribution has to be set up in advance: tagging enforced by policy as code, per-tenant metering of the dominant units, and a shared-cost allocation rule based on measured usage — because an approximate measurement drives better decisions than an arbitrary split.
• Egress is priced by distance and ingress generally is not, which makes several architectural shortcuts permanently expensive: querying another region's database, replicating writes N−1 times, chatty cross-AZ service calls, serving object storage without a CDN, and shipping all telemetry to one region. Measure egress by source first — most teams cannot attribute their transfer charges, which makes the line item unattackable.
• Compute levers: right-sizing (most instances are over-provisioned), ARM families (20–40%), spot at 60–90% for interruptible work — which requires Module P-19's checkpointing and idempotency — reserved capacity for the baseline, and autoscaling to remove idle. Idle is its own problem: a GPU, a warm standby and an under-used replica all cost the same doing nothing, so utilisation is the only lever. Serverless-versus-provisioned has a computable crossover that moves as a workload matures.
• Storage: tier large cold objects only (retrieval charges, minimum durations, per-object fees and minimum billable sizes make small-object tiering a loss), and watch the three quiet accumulations — snapshot and orphaned-volume sprawl, log retention, and "keep everything forever" as a decision made by omission.
• The database is your most expensive storage per gigabyte, which is the economic argument behind keeping blobs and logs out of it, partitioning old data, and keeping analytics off the OLTP instance. Provisioned IOPS closes the course's first through-line: sequential-versus-random from Module F-2, random UUID keys from Module P-3, and bloat from Module F-13 all arrive here as a monthly bill.
• Check the NAT gateway data-processing charge. Traffic from a private subnet to object storage or a managed service is billed per gigabyte through the NAT, and a VPC endpoint removes it — frequently a top-five line item fixed by one configuration change that most teams have never examined.
• Design levers beat resource levers by an order of magnitude, in this order: do not do the work (a cache hit is the cheapest request; pre-aggregate, use a CDN, bound pagination, conflate); do it later and cheaper (async on spot, batch instead of streaming — and ask what decision actually changes if data is seconds fresh rather than an hour); do it once (content addressing, embedding caches, request coalescing); and do not store or ship what nobody reads.
• Know when scaling out is buying past a design flaw: replicas standing in for a fixed N+1, instances standing in for a hot-row counter, memory standing in for a key distribution, a bigger database standing in for reclaiming bloat, workers standing in for batching, and IOPS standing in for time-ordered keys. The purchase always works, which is what makes it seductive. The test: if cost per request rises as you scale, you are buying past something — efficient scaling holds cost per unit roughly flat.
• Governance that works: tagging enforced at creation, showback to the teams who can change designs, anomaly detection on daily spend (which catches the runaway agent loop, the retry storm against a metered API, and the debug flag left on — all of which produce five-figure surprises within days), budgets with alerts, cost estimates annotated on pull requests, and a cost review on the same cadence as the capacity review, since they are the same arithmetic with prices attached.
• Be honest about the trade-offs: reliability and latency cost money by design, and premature cost optimisation has the same shape as premature performance optimisation — three weeks to save £400 a month is a loss. Measure before optimising, because the answer is usually egress, NAT processing, logs or idle rather than the compute everyone assumed, and optimise the top two or three line items only.

The next module, Compliance, Privacy, and Data Sovereignty, is the last constraint layer. It treats GDPR, HIPAA, CCPA and DPDP as design inputs rather than legal paperwork, covers PII tokenisation and vaulting, and resolves the problem that six earlier modules deferred to it: how a deletion request reaches an immutable Kafka log, an object-storage backup and a warehouse — for which the answer is to delete a key rather than a record.

---