900 TB of 38 KB Objects and a Three-Year Commitment Ban
A media archive holds 900 TB in S3 Standard in us-east-1: 24 million objects averaging 38 KB. S3 Storage Lens over 90 days shows 62% of bytes are never read after day 30, 30% are read a few times a year at unpredictable times, and 8% are read daily. The same team runs 220 EC2 instances: 46 are steady-state production m6i.2xlarge running 24x7 at an average 22% CPU, and 174 are batch workers running 6–9 hours per weekday, already on Spot. Production moves to m7g Graviton in 7 months. Finance has ruled out any 3-year commitment but will consider 1-year terms, and has asked for the decision in terms of monthly savings, not percentages.
1. Evaluate S3 Intelligent-Tiering for this bucket. Show the arithmetic that decides it, and state what you would do instead.
Read the worked answer
Do the arithmetic before the architecture. Intelligent-Tiering charges a monitoring fee of $0.0025 per 1,000 objects per month: 24,000 thousand-objects x $0.0025 = $60/month of pure overhead. That is small against a Standard bill of 921,600 GB x $0.023 = $21,197/month - which is exactly why the fee is a distraction and the real number is the one nobody checks.
The disqualifier is the 128 KB floor. Intelligent-Tiering does not move objects smaller than 128 KB out of the Frequent Access tier, and S3 Lifecycle will not transition sub-128 KB objects to Glacier Flexible Retrieval or Deep Archive either. At a 38 KB average, the majority of these 24 million objects are permanently ineligible for every tiering mechanism you have. The design would pay $60/month and save approximately nothing on the cold 62%.
What to do instead, in order:
- Get the object-size distribution, not the average. Run S3 Inventory and bucket by size decade. If the median is under 128 KB, tiering is a dead end and every further storage-class discussion is wasted until step 2.
- Repack the cold cohort. Aggregate the 62% never-read bytes into ~100 MB archive objects with a manifest index, then Deep Archive the archives: 571,392 GB x $0.00099 = $566/month against $13,142 today. Trade-off to state explicitly: retrieving a single document now means restoring a 100 MB archive, so the manifest must map document to archive and you should expect per-retrieval restore cost.
- Glacier Instant Retrieval for the 30% unpredictable cohort: 276,480 GB x $0.004 = $1,106/month versus $6,359 - millisecond retrieval, and unpredictable access patterns are precisely what Deep Archive's 12-hour retrieval punishes.
- Keep the 8% hot in Standard or Standard-IA based on real access frequency.
Also check for free money first: noncurrent versions, incomplete multipart uploads, and abandoned delete markers typically account for 3–8% of a bucket like this.
2. Recommend the compute purchasing strategy for the 46 production instances and the 174 batch workers, given the Graviton migration and the ban on 3-year terms.
Read the worked answer
Commit to the baseline, never to the peak. The 46 production instances are the only predictable load: 46 x 730 hours = 33,580 instance-hours/month, roughly $12,900/month on-demand at m6i.2xlarge list rates. Buy Compute Savings Plans, 1-year, no upfront, sized to that steady baseline and no more.
Why Compute and not EC2 Instance Savings Plans or Convertible RIs:
- Instance Savings Plans are priced against a specific family in a specific region. In 7 months those 46 instances become m7g, and an m6i-scoped commitment becomes a discount you cannot use while still paying for it.
- Compute Savings Plans apply to any family, size, region, and to Fargate and Lambda, so the Graviton move carries the discount across automatically - that flexibility is the entire reason to accept the slightly smaller headline rate.
- Convertible RIs would work but add exchange mechanics and account-level bookkeeping for no benefit over Compute Savings Plans at 1-year.
Size it to the floor, not the average. A Savings Plan commits to dollars per hour. If you cover the average rather than the minimum, the excess is wasted whenever the fleet shrinks, and the Graviton move will shrink it - m7g is typically better price-performance, so fewer or smaller instances do the same work. Commit to roughly the 24x7 minimum and let the remainder float at on-demand.
Leave the 174 batch workers alone. They are already on Spot and run 6–9 hours on weekdays; a Savings Plan hour is spent whether or not a batch job runs. If batch becomes less spot-interruptible later, cover it with a separate, smaller plan rather than folding it into production's.
Show finance the deltas, not the discounts: model three line items - production baseline under a 1-year no-upfront Compute Savings Plan, production after the m7g move, and batch unchanged on Spot - and present the 7-month transition explicitly, because that is the month the numbers change and the month they will ask about.