Cost Optimization and Lifecycle: From Hot Prefixes to Glacier Deep Archive

Lessons 01 to 15 built a lakehouse that works: storage, formats, tables, ingestion, a catalog, transformation, querying, a warehouse, orchestration, governance, PII handling, security and observability. Every one of those decisions has a meter attached to it, and by now those meters run together into a single monthly bill that nobody can read line by line. The bad news: cost is the one lakehouse property that degrades silently, because the bill arrives a month after the decision that caused it. The good news: unlike correctness, cost has a ladder: a fixed order of operations that AWS's own Well-Architected guidance implies and that every published AWS cost case study follows.

This lesson teaches that ladder end to end: shape → temperature → accidental scale → unattributed spend → commitments, in that order, with the October 2026 us-east-1 rates that make each rung arithmetic instead of advice. The single rule that organises everything below: never buy a discount on the wrong size, and never move a byte to a colder class before you know when you will read it back.

In this lesson you will:

• read a per-service cost-shapes table that names the billable unit of every layer of the lakehouse before touching a single lever;
• walk the S3 lifecycle waterfall, every storage class, minimum duration, retrieval fee and restore path, and compute a three-to-five-year TCO for a 60 TB footprint;
• fall into the Intelligent-Tiering monitoring-fee trap on purpose, on paper, with eight million tiny objects, so you never do it in production;
• fence the Athena query layer with workgroup cutoffs, partition projection, column pruning and ZSTD, then compute a 500-analyst monthly bill twice: before and after the reducers;
• right-size Glue (DPU = 4 vCPU + 16 GB, $0.44/DPU-hour, 1-minute minimum, 48-hour default timeout on Glue 4.0 and earlier) and sketch EMR Serverless versus Glue in vCPU/GB-hours;
• apply the Redshift levers: pause/resume, Redshift Managed Storage at $0.024/GB-month, Concurrency Scaling credits and Serverless reservations;
• choose between QuickSight per-user pricing and reader session capacity with a break-even calculation, and stop SPICE capacity from ratcheting upward;
• price the streaming shapes (Kinesis shard-hours versus on-demand GB, Firehose's 5 KB increments, MSK Serverless's five line items) and the silent multipliers (KMS requests with and without bucket keys, CloudTrail data events, NAT versus free gateway endpoints);
• operate Cost Explorer, Budgets and Cost Anomaly Detection and tag the estate with CostCenter / Layer / Project so every later number is readable;
• study GE Aerospace (customer-estimated >$500,000 yearly saving on Redshift) and Transport for NSW (~80% data-integration cost cut on Glue), plus a sourced 2026 update box;
• practise with twelve exam-style questions and four interactive checks (a TCO plot, a lever-to-service match, a fee-name fill-in and a drag-and-drop of the ladder itself).

---

1. Cost anatomy: the meter of every layer before the lever

1.1 The five-rung ladder, and why the order is not negotiable

AWS's cost-optimization discipline, documented in the Well-Architected cost pillar and repeated in every cost case study AWS publishes, is a sequence, not a menu. Each rung is cheaper and safer than the one below it:

1. Shape: stop paying for the wrong shape of data. Columnar formats, compression and column projection make scanners read fewer bytes. On a per-scan meter this is the highest-leverage change that exists, and it costs nothing but a rewrite of the write path.
2. Temperature: stop paying for the wrong temperature. Lifecycle rules move aging data to cheaper storage classes for free configuration cost; you pay only the transition request.
3. Accidental scale, stop paying for accidental spend: workgroup scan cutoffs, job timeouts, Max RPU-hour budgets, budget actions. These are circuit breakers, not optimisations, they cap the tail.
4. Attribution: stop paying for unattributed spend. Cost allocation tags per pipeline turn one unread bill into N readable ones. Without this rung, every later measurement is guesswork.
5. Commitments, only now buy discounts: Redshift reserved nodes, Redshift Serverless Reservations, Savings Plans. A commitment lowers the unit price and does nothing about the quantity, which is why rung 5 on an unoptimised estate is how you lock in waste for one or three years.

1.2 Per-service cost shapes: the table that makes everything else readable

Every row names the billable unit first, the October 2026 us-east-1 rate anchor second, and the failure mode that inflates the bill third. A lever that does not attack the billable unit of its service is not a lever.

1.3 Tagging: the rung that makes every later number readable

Four tag keys carry almost all of a lakehouse's attribution needs, applied to every resource that can carry a tag: S3 buckets and prefixes (via object tags where the service supports them), Glue jobs, crawlers and connections, Athena workgroups, Redshift clusters and workgroups, QuickSight folders and datasets, Kinesis streams, MSK clusters, NAT gateways and VPC endpoints:

Three hard rules, all documented by AWS:

1. Tags must be activated as cost allocation tags before they appear in Cost Explorer or a cost allocation report, and activation can take up to 24 hours for the key to appear on the activation page plus another up to 24 hours to take effect.
2. Tags are not retrospective. They affect billing reporting only from the moment of activation. A tagging strategy rolled out in October 2026 tells you nothing about September.
3. In AWS Organizations, cost allocation tags are activated only from the management (payer) account, and AWS recommends a small number of consistent tag keys: sprawl is itself a cost, because every extra key is an extra axis to reconcile.

1.4 Visibility before optimization: Cost Explorer, Budgets, Anomaly Detection

You cannot optimise what you cannot see, and the three AWS cost-visibility services have three different jobs, and three different bills:

The operational shape AWS documents: Budgets for the real-time circuit breaker (threshold → SNS → Lambda action), Cost Anomaly Detection as the weekly safety net (it is slow by design), Cost Explorer for the investigation once either of them fires. None of the three can attribute spend to a pipeline without the tags from section 1.3.

• 📚 Did you know? The cheapest FinOps tool in your account is a budget action, not a dashboard: the first two action-enabled budgets are free, and an action can disable an Athena workgroup or detach an IAM policy the moment a threshold trips. Cost Anomaly Detection, however smart its models, cannot stop anything, and it may take up to 24 hours to notice a runaway that a budget action would have caught in minutes (AWS Budgets and Cost Anomaly Detection documentation, accessed 2026-10-11).

---

2. S3: the lifecycle waterfall, and the restore bill nobody models

2.1 Every class, every minimum duration, every retrieval fee

This is the single most valuable table in the lesson. Storage rates are the headline; minimum durations and retrieval fees are where the design lives.

Plus the request-side fees that complete the picture: lifecycle transition requests cost $0.01 per 1,000 to Standard-IA / One Zone-IA / Intelligent-Tiering, $0.02 per 1,000 to Glacier Instant Retrieval and $0.05 per 1,000 to Glacier Deep Archive; restore request fees are $0.01 / $0.05 / $0.00 per 1,000 requests for Expedited / Standard / Bulk; archived objects additionally bill 40 KB of metadata per object; and every archived class charges its minimum duration in full: an object deleted or re-transitioned out of Deep Archive on day 30 still bills 180 days.

2.2 Lifecycle rules versus Batch Operations versus manual moves

A lifecycle rule transitions or expires existing and new objects that match a filter, and the configuration itself is free; you pay only the transition request ($0.01 to$0.05 per 1,000). AWS charges nothing for the rule to keep matching tomorrow's objects. S3 Batch Operations is the retroactive, manifest-driven path: $0.25 per job plus $1.00 per million object operations, with a manifest usually produced by S3 Inventory at $0.0025 per million objects listed. Manual re-uploading or CopyObject-ing millions of objects burns PUT/COPY request fees, needs a compute fleet, and opens a window where two copies both bill.

The practical rule: age-based reclassification = lifecycle rule; tag- or manifest-driven reclassification = Batch Operations. You almost never need Batch Operations to re-tier ordinary aging objects, and paying for it to do a lifecycle rule's job is a self-inflicted bill.

Three more lifecycle actions belong in every production bucket, because versioning without them is a silent multiplier: expire noncurrent versions (NoncurrentDays), cap how many noncurrent versions are kept (MaxNoncurrentVersions, valid 1 to 100), and abort incomplete multipart uploads. With versioning enabled, every PUT creates a new current version while the prior version stays fully billed at its storage-class rate: a churning bucket can bill several times its "logical" size until these three rules exist.

2.3 Restore economics: the temporary copy is the real shock

Restoring an archived object bills two things, and only one of them is intuitive:

1. the per-GB retrieval fee of the chosen speed tier (table above), plus the restore request fee; and
2. a temporary restored copy, charged at S3 Standard storage rates, for the duration you choose to keep it: on top of the archive object you are still paying for.

So a Deep Archive restore is cheap in the retrieval line ($0.0025/GB Bulk) and expensive in the plan: 48 hours of latency, a temporary copy at $0.023/GB-month prorated, and no Expedited option at any price. Deep Archive restores must therefore be scheduled, never casual: Bulk for planned backfills, Standard only for genuine 12-hour emergencies. And remember the minimum-duration cliff the other way round: if your access pattern says "we might read this within 90 days", Deep Archive's 180-day minimum means the class is wrong, not that you should accept the risk.

• 📚 Did you know? Deep Archive has no Expedited retrieval tier: the speed options stop at Standard (within 12 hours) and Bulk (within 48 hours). Any architecture diagram that shows an "instant" path out of Deep Archive is inventing a tier AWS does not sell (Amazon S3 Glacier documentation, accessed 2026-10-11).

2.4 Worked example E1: a 60 TB lakehouse, three years, then five

The scenario: an operational lake of 50 TiB, 20 TiB hot curated in S3 Standard, 25 TiB warm in Standard-IA, 5 TiB cold in Glacier Instant Retrieval, plus 10 TiB of compliance history in Glacier Deep Archive. A 60 TiB footprint, held three years. AWS bills GB as 1,073,741,824 bytes, so TiB → GB is ×1,024.

The gap widens by $591.46 every month and is entirely a rung-2 decision: no code changed, no query was tuned, no commitment was purchased. Now the two events that make archive models break, reads and the one-time transition bill, which belong in the same spreadsheet as the storage.

2.5 Worked example E1b: restore scenarios and the one-time transition bill

Same 60 TiB estate. What does it cost to read 1 TiB back, by path, and what did it cost to reclassify an existing 45 TiB of it?

2.6 Intelligent-Tiering: the monitoring-fee trap on tiny objects

Intelligent-Tiering is the safest default when access patterns are genuinely unknown: no minimum duration, no retrieval fees, automatic movement between Frequent, Infrequent, Archive Instant, Archive and Deep Archive Access tiers based on observed access (objects idle 30 days move to the Infrequent tier, 90 days to Archive Instant, and Deep Archive Access requires a minimum of 180 consecutive idle days). But it is a monitoring business: it charges $0.0025 per 1,000 objects per month for monitoring and automation, and only objects at least 128 KB are eligible for auto-tiering at all. For large warm objects the fee is a rounding error; for millions of tiny objects it is the bill.

2.7 Worked example E2: eight million tiny objects "saved" by Intelligent-Tiering

An event lake lands tiny fragments in Intelligent-Tiering "to save money". Nothing about this design saves money.

The decision rule that falls out of E2: Intelligent-Tiering is for large, warm, unevenly accessed objects with unknown patterns; explicit lifecycle classes are for objects you understand; and neither belongs on objects smaller than 128 KB; those should be compacted on write, which is a cost fix and a query-performance fix in one move.

2.8 Replication can target a cheaper class, but it double-bills

Destination storage class is a first-class replication setting: you can replicate directly into Glacier Flexible Retrieval, Glacier Deep Archive, Intelligent-Tiering and the other classes (the CloudFormation destination StorageClass accepts DEEP_ARCHIVE, GLACIER, GLACIER_IR, INTELLIGENT_TIERING, ONEZONE_IA, STANDARD, STANDARD_IA; the default is to keep the source class). The DR region therefore never pays Standard rates for a copy nobody reads.

The catch is arithmetic, not capability: you pay for both copies, plus replication request costs, plus $0.015 per million objects per month in the source bucket for replication monitoring. Replication into a cheaper class is a disaster-recovery and compliance pattern, not a storage discount: model it as "the DR copy is cheap enough to keep forever", never as "this halves my S3 bill".

---

3. The query layer: Athena bills bytes scanned, so every scan is a design decision

3.1 The meter and the four multiplicative reducers

Athena SQL on S3 costs $5.00 per TB scanned in us-east-1: charged for successful and unsuccessful queries alike (federated queries add a 10 MB per-query minimum and aggregate across data sources), plus the ordinary S3 request charges for writing and reading results. In a per-scan pricing model, tuning is billing. Four independent reducers stack multiplicatively:

1. Partitioning and partition projection: only matching partitions are listed and read. Projection computes partition values from table properties instead of the catalog, which avoids the metadata lookup entirely; enable it and Athena ignores catalog partition metadata, so it needs predicates on all projected keys and degrades where more than half of projected partitions are empty. Athena can read at most 1 million partitions in a single scan (Glue tables support up to 10 million).
2. Column projection: Parquet and ORC read only the referenced columns.
3. Compression, you pay for bytes scanned before decompression, so ZSTD/GZIP reduces the query bill and the S3 bill together. ZSTD is the default compression for Iceberg tables in engine version 3 (level 3), and AWS recommends level 3 or 6 to 9 for Parquet/ORC writes; levels above 19 need serious memory. Keep Parquet row groups at the 128 MB default and ORC stripes at 64 MB, shrinking them below default is not recommended.
4. Result reuse, engine version 3 re-runs of an identical query in the same workgroup return the cached result with DataScannedInBytes: 0, up to a 60-minute default and a 7-day maximum age. Non-deterministic SQL (rand(), shuffle()) bypasses it, and so do Lake Formation row/column-level permissions and federated queries, which always re-execute.

AWS's own worked example of the mechanism: 3 TB of uncompressed text, one column selected, uncompressed = 3 × $5 = $15; with 3:1 compression = $5; as Parquet with 3:1 compression and 4:1 column selection = $1.25. Three levers, twelve times cheaper, same query.

3.2 Workgroup spend guards: circuit breakers for the query layer

Workgroups are simultaneously the isolation unit and the cost-control unit, and AWS documents a two-workgroup production pattern:

• Per-query cutoff, BytesScannedCutoffPerQuery (API minimum 10,000,000 bytes = 10 MB) cancels a runaway query the moment it crosses the threshold. The cancelled query still bills for everything scanned up to the kill, the cutoff caps the tail, it never discounts the head.
• Per-workgroup usage controls: raise an SNS alarm, and the documented escalation is a Lambda function that disables the workgroup when a high-water mark trips.
• Cost allocation tags on the workgroup: tag each workgroup (say, Name=ad-hoc-users, Dept=analytics) so Athena spend lands under the right CostCenter in the Cost and Usage Report.

Athena also sells Capacity Reservations at $0.30 per DPU-hour (a 160-DPU reservation for a 15-minute peak hour costs 160 × $0.30 × 0.25 = $12.00 on AWS's worked example) and Spark sessions at $0.35 per DPU-hour: the rung-5 option once rungs 1 to 3 have done their work. Up to 1,000 workgroups per Region exist as a ceiling, which is capacity for one workgroup per team or pipeline, not one per user.

3.3 Worked example E3: 500 analysts, 50 GB a day, before and after the reducers

This is the calculation every analytics team should be able to reproduce from memory, because it is the one that decides whether Athena is a line item or a rounding error.

The lesson of E3 is the ratio: the reducers took ~$2,563 down to ~$154, a 16× reduction, before anyone bought anything. A team that negotiates a commitment while still running SELECT * over text files has skipped rungs 1 and 2 to save pennies on rung 5.

---

4. Transformation: Glue DPU right-sizing, one-minute billing, and the EMR Serverless sketch

4.1 What Glue actually bills, and where the defaults bite

Glue ETL is $0.44 per DPU-hour, billed per second with a 1-minute minimum (crawlers carry a 10-minute minimum; Data Quality tasks a 1-minute minimum with a 2-DPU floor). A DPU is 4 vCPUs of compute and 16 GB of memory. Two capacity models exist, split by version:

• Glue 1.0-style jobs specify provisioned capacity via MaxCapacity in DPUs (2 minimum, 100 maximum, default 10).
• Glue 2.0 and later jobs cannot set a maximum capacity at all; they specify a worker type × number of workers: G.1X = 1 DPU, G.2X = 2 DPU, up to G.16X; G.025X is a quarter-DPU for low-volume streaming at one-fourth the cost; R.* workers are memory-optimized in M-DPUs (4 vCPU + 32 GB); Z.2X is the Ray worker (2 M-DPU, 8 Ray workers). Spark jobs allocate 2 to 100 DPUs, default 10; Python shell jobs use 0.0625 or 1 DPU. Jobs created without a version default to Glue 5.1.

Three defaults hide in that table: a 10-DPU default allocation, a default job timeout of 2,880 minutes (48 hours) on Glue 4.0 and earlier (480 minutes on Glue 5.0 and later; hard maximum just under 7 days), and Flex execution class at $0.29 per DPU-hour for interruptible capacity, billed per worker-time rather than max-capacity × wall-clock. Right-sizing is a measured activity: compare the maximum needed executors against the maximum allocated executors, and stop scaling when wall-clock stops improving: in AWS's own published example the job improves from 10 DPUs / 6 minutes to 55 DPUs / 3 minutes and 100 DPUs buys nothing further.

4.2 Worked example E4: a runaway job, a right-sized job, and the EMR Serverless alternative

• 📚 Did you know? Glue publishes a DPUHours CloudWatch metric per job run (dimensions include JobName, JobRunId, JobType, GlueVersion and ExecutionClass), so a budget alarm can fire on DPU-hours consumed, not on wall-clock: the only reliable way to catch the runaway in E4 before the timeout does. Turning on job metrics, application logs and continuous logging adds CloudWatch charges of its own, so enable them where the alarm value exceeds the log cost (AWS Big Data Blog, 2023-04-28).

---

5. Redshift: pause/resume, managed storage, concurrency credits, Serverless RPUs

The warehouse leg of the lakehouse has three meters, and most sticker-price arguments confuse them:

1. Compute, provisioned: RA3 and RG nodes bill hourly (AWS's own worked example prices ra3.4xlarge at $3.26 per node-hour on demand: 4 nodes × $3.26 × 730 hours = $9,519.20 per month). Reserved nodes discount this by roughly 20% (No Upfront) up to 42 to 76% (All Upfront).
2. Storage, always separated: Redshift Managed Storage bills $0.024 per GB-month whether the data sits on local SSDs or in S3. This is the RA3 design point: stop paying for local disk you were only filling with cold data. 10 TiB of managed storage = 10,240 GB × $0.024 = $245.76 per month.
3. Serverless compute, RPU-hours per second with a 60-second minimum at $0.375 per RPU-hour in us-east-1 (1 RPU ≈ 16 GB); the 4-RPU base is $1.50 per hour; there is no charge while no queries run, and Spectrum plus Concurrency Scaling are included. Cap it with Max RPU-hours and Max capacity settings; Serverless Reservations cut compute by up to 24% (1-year) or 45% (3-year), the rung-5 answer for a steady serverless workload.

Pause/resume suspends on-demand compute billing; while paused you pay only backup storage; which makes dev/test and batch-window clusters cheap. The trap: reserved-node charges keep billing during a pause, because you bought the node, not the uptime. Concurrency Scaling earns one free hour of transient-cluster credit every 24 hours per active cluster, bankable up to 30 hours (credits do not expire while the cluster lives), then bills per second with a one-minute minimum only while the transient cluster serves queries. And Spectrum on provisioned clusters bills $5.00 per TB scanned: the same meter as Athena, so rung 1 (pruning, columnar layout) discounts both engines at once.

5.1 Worked example E5: the warehouse that sleeps

---

6. The BI layer: QuickSight's two pricing axes and the SPICE pool

QuickSight prices two axes at once, and a dashboard estate can be optimised on either:

• Per-user (Enterprise): Author $24 per user-month, Reader $3 per user-month, plus SPICE at $0.38 per GB-month beyond the 10 GB included with every provisioned Author. Standard Edition is $9 per user-month annual (or $12 monthly) with 10 GB per user included and $0.25 per additional GB. Each SPICE dataset in Enterprise supports a maximum of 1 billion rows per 1 TB of size.
• Capacity: reader sessions sold in packs: 500 sessions per month for $250 ($0.50 per session), with annual tiers down to $0.40 at 50,000 sessions/year, $0.28 at 200,000, $0.24 at 400,000,$0.20 at 800,000 and $0.16 per session at 1.6 million sessions/year. A session is a 30-minute period, not a view, and capacity pricing is required for programmatic refresh of dashboards.

Per-user wins for a known, steady population; capacity wins for spiky, embedded or programmatic consumption. SPICE itself is a per-Region shared pool: capacity purchased in one Region cannot be used in another, datasets stay in SPICE until someone removes them, and auto-capacity-purchasing is on by default for console-created accounts, the classic silent ratchet that raises your pool and never lowers it (turning it off later leaves the current pool as your purchased capacity). Finally, the mode choice moves the meter: Import (SPICE) converts query cost into a fixed $/GB-month with refresh lag, while Direct Query pushes every visual interaction back into Athena/Redshift, the section 3 bytes-scanned economics, multiplied by dashboard view counts.

6.1 Worked example E6: 10 Authors, 400 Readers, 500 GB of SPICE

• 📚 Did you know? Reader pricing is written for manual session interactions only: AWS reserves the right to bill a reader at the higher Author rate if reader sessions are used for programmatic or automated queries. Embedded analytics that polls dashboards on a timer is the documented bill-shock path, and it is also exactly the usage that requires capacity pricing rather than per-user (Amazon QuickSight pricing and FAQs, accessed 2026-10-11).

---

7. Streaming shapes: shard-hours, GB-with-a-floor, 5 KB increments, cluster-hours

Streaming services look similar on an architecture diagram and bill four different units. The lakehouse-relevant summary: Firehose + Kinesis are cheap per GB; MSK is expensive per hour: choose MSK only when you need Kafka semantics the alternative cannot provide.

• Kinesis Data Streams, provisioned: shard-hours at $0.015 per shard-hour, PUT payload units counted in 25 KB chunks at $0.014 per million, optional extended retention at $0.020 per shard-hour, and enhanced fan-out at $0.015 per shard-hour per consumer-shard.
• Kinesis on-demand Standard: per GB, with an account-level floor of 25 MB/s ingested and 25 MB/s retrieved across all on-demand streams, small streams can pay for throughput they never send. On-demand Advantage (introduced 2025-11-04) removes the per-stream hour charge and cuts ingest to $0.032/GB, at a committed minimum of 25 MiB/s; AWS's published 48-hour side-by-side was $2,071.75 (Standard) versus $823.44 (Advantage), about 60% lower, roughly $228,125 annualised for that workload, and AWS's own caveat is that spiky sub-10-MiBps workloads should stay on Standard. Retention beyond 24 hours costs Standard +$0.10/GB up to 7 days, versus $0.023 per GB-month in Advantage beyond 24 hours up to 365 days.
• Firehose: bills GB ingested in 5 KB increments (first 500 TB at $0.029/GB), a 3 KB record is billed as 5 KB, with add-ons for format conversion, VPC delivery and dynamic partitioning, and $0.045/GB when delivering from Kinesis into Iceberg tables.
• MSK Serverless: five line items: cluster-hours $0.75, partition-hours $0.0015, data-in $0.10/GB, data-out $0.05/GB, storage $0.10/GB-month. AWS's official worked example (31 days, 100 partitions, 100 GB/day) totals $1,299.60: $558.00 + $111.60 + $310.00 + $310.00 + $10.00.

7.1 Worked example E7: three streaming shapes, three bills

---

8. The silent multipliers: KMS, CloudTrail data events, and the NAT tax

8.1 KMS request costs and the bucket-key lever

SSE-KMS on a lake bills $1.00 per customer managed key per month plus $0.03 per 10,000 requests above a 20,000-request monthly free tier. On a high-QPS lake, the request line routinely overtakes the S3 GET line; which is why S3 bucket keys, which AWS documents as reducing KMS costs by up to 99%, are mandatory hygiene rather than an optimisation. The companion lever is CloudTrail data events: management events' first copy is free (extra copies $2.00 per 100,000), but S3 data events cost $0.10 per 100,000 events delivered: full-bucket data-event logging on a busy lake is a five-figure line item, and the fix is advanced event selectors scoped to sensitive prefixes (data-event aggregation analysis is a cheaper $0.03 per 100,000). Advanced event selectors never mix with basic event selectors on the same trail, and each trail supports 500 of them.

8.2 NAT versus endpoints: the highest-confidence networking saving

Every GB through a NAT gateway costs $0.045, plus $0.045 per hour per AZ while provisioned and available. Gateway endpoints for S3 and DynamoDB are free, no data processing charge, no hourly charge, and are the correct path for any VPC-resident ETL fleet talking to S3. Interface endpoints bill roughly $0.01 per hour per AZ plus $0.01 per GB (first-PB tier, then $0.006 and $0.004), with each partial endpoint-hour billed as a full hour. A VPC fleet that pushes S3 traffic over NAT carries an unforced 3 to 5× markup on its data-path networking and loses the aws:SourceVpce condition key that lesson 14's network perimeter depends on.

8.3 Worked example E8: the encryption, audit and network side-quests

---

9. Putting the ladder to work: interactive checks on the levers themselves

9.1 Interactive check: match the lever to the meter it attacks

9.2 Interactive check: fill in the fees the design depends on

9.3 Interactive check: order the ladder before you touch a bill

• 📚 Did you know? Replication can be pointed at a cheaper destination storage class directly (DEEP_ARCHIVE, GLACIER, GLACIER_IR and friends are all legal replication destinations): a genuine DR design, since the copy lands cold without a lifecycle rule ever firing. What it is not is a discount: you pay for both copies plus replication requests plus $0.015 per million objects per month in monitoring (Amazon S3 replication documentation, accessed 2026-10-11).

---

2026 Updates (as of October 2026)

---

Real-World Case Studies

AWS publishes what this ladder looks like in production. Every figure below is customer- or AWS-claimed and unaudited, with the source named so you can check it: the examinable point is the pattern: which rung moved, and in which direction.

Case A, GE Aerospace: modernising an operational data store on Redshift

Read the $500,000 as GE's own estimate of its saving, never as an AWS guarantee or a rate you can apply to your estate. The transferable pattern is the sequence: PoC first, nine months of phased migration, compliance boundary (GovCloud) treated as an architecture input, and the cost win arriving as a by-product of modernising the workload, not as a purchased discount on an oversized system.

Case B, Transport for NSW: 400+ ETL workflows moved to Glue, ~80% cheaper

The lesson-16 reading of TfNSW is that the 80% came from the meter change and the operational change together: a licensed platform bills for existence, Glue bills for DPU-seconds actually used. But notice what made the migration possible: Python support and training for 30+ staff; which is a people lever, not a price lever. A third reference point from the same AWS corpus: Integral Ad Science ran one Athena workgroup per business unit with per-department billing tags and query limits (AWS Big Data Blog, 2021-09-23): the section 1.3 and 3.2 design, in production.

• 📚 Did you know? Both headline percentages are undated customer pages, so they carry "accessed October 2026" rather than a publication date, and both describe specific migrations, not service guarantees. GE Aerospace's >$500,000 is an estimate; TfNSW's ~80% covers data-integration costs specifically, not the whole analytics bill. Quoting either as "Redshift saves 70%" or "Glue is 80% cheaper" is the kind of drift this course's source discipline exists to prevent (AWS case studies, accessed 2026-10-11).

---

Practice Questions