Should you turn on S3 Intelligent-Tiering, or just move to Wasabi

A platform engineer at a mid-sized SaaS reads the same AWS bill the CTO read last quarter, and the same line item still hurts. Someone in the room asks the obvious question: can't we just flip on Intelligent-Tiering and skip the whole vendor migration? It's a fair question. The answer depends on the shape of the workload, and it depends on a fee almost nobody notices until it shows up on the bill.

This post is the sibling piece to the leaving-the-hyperscaler math. Same three workload shapes, same list-price assumptions, but pitting AWS's internal optimization against leaving AWS entirely. Two real questions a buyer weighs side by side: do we turn on Intelligent-Tiering on our existing bucket? vs do we move the data to Wasabi or B2?

The math is different from the bare-Standard comparison because Intelligent-Tiering changes one variable (storage class auto-demotion) without changing the other one (egress). The shape of which option wins shifts accordingly.

What Intelligent-Tiering actually does

Intelligent-Tiering watches your objects' access patterns and demotes the cold ones into cheaper storage tiers automatically. Five tiers exist, each cheaper per GB-month than the one above it:

• Frequent Access — same price as S3 Standard, ~$0.023 per GB-month
• Infrequent Access — about half the cost, ~$0.0125 per GB-month
• Archive Instant Access — ~$0.004 per GB-month
• Archive Access — ~$0.0036 per GB-month, retrieval takes minutes to hours
• Deep Archive Access — ~$0.00099 per GB-month, retrieval takes hours

Objects move down the tiers automatically based on how often you read them. An object that hasn't been touched in 30 days drops to Infrequent. After 90 days, it drops to Archive Instant. With the optional opt-in tiers enabled, it can keep falling to Archive and Deep Archive after 180 and 730 days.

The catch is a fee Amazon prefers you read carefully: $0.0025 per 1,000 objects per month to monitor each object's access pattern. That's the line item that breaks the math on the wrong workload.

The monitoring fee, made concrete

A 50 TB bucket with an average object size of 1 MB is 50 million objects. Monitoring fee on that bucket: 50,000 thousand-object-units × $0.0025 = $125 per month, before any storage savings.

If your average object is 100 KB (think log lines, sensor data, small JSON payloads, image thumbnails), the same 50 TB is 500 million objects, and the monitoring fee is $1,250 per month. That's higher than the entire Wasabi bill for the same data.

The fee is per-object, not per-GB. Large-file workloads (video assets, ML checkpoints, full database backups, build artifacts) get away with it. Small-file workloads (logs, telemetry, document archives, thumbnails) get punished. The first thing to do before anyone touches the Intelligent-Tiering toggle is to ask the bucket how many objects it holds, divided by how many bytes. aws s3 ls --recursive --summarize will tell you. So will Mover's free dry run — counting objects and summing bytes is the first thing it does on the source bucket.

Three workloads, side by side

Workload 1 — storage-dominated, low egress

A research team holding 50 TB of archived experiment data on S3. Reads maybe 5 TB out per month. Mostly cold. Assume an average object size of 50 MB (this is research data — large parquet files, image stacks, model outputs). That's about 1 million objects.

S3 Standard, no Intelligent-Tiering:

• Storage: 50 TB × $0.023 ≈ $1,150
• Egress: 5 TB ≈ $450
• Monthly total: ~$1,600

S3 Intelligent-Tiering, assume 70% drops to Archive Instant after 90 days:

• Storage: 15 TB × $0.023 (Frequent) + 35 TB × $0.004 (Archive Instant) ≈ $345 + $140 ≈ $485
• Monitoring: 1M objects × $0.0025/1000 ≈ $2.50
• Egress: 5 TB ≈ $450 (unchanged — egress isn't a tier function)
• Monthly total: ~$940

Wasabi:

• Storage: 50 TB × $6.99/TB ≈ $350
• Egress: $0
• Monthly total: ~$350

Intelligent-Tiering saves ~$660/month vs Standard. Moving saves ~$1,250/month vs Standard, ~$590/month vs Tiering. Migration via Mover at $0.15/GB on a 50 TB pack: $7,499. Payback against the Tiering scenario: about 13 months.

Intelligent-Tiering is the right call if reversibility matters more than the extra savings. The move is the right call if you want to lock in the cheaper number permanently and you're willing to commit. Both beat doing nothing.

Workload 2 — moderate egress, the typical app

A SaaS team running 10 TB on S3 as application data, with 20 TB egress per month. Mixed access pattern — recent uploads get read often, older content rarely. Assume 5 million objects (typical for a customer-uploads bucket).

S3 Standard:

• Storage: 10 TB × $0.023 ≈ $230
• Egress: 20 TB ≈ $1,750
• Monthly total: ~$1,980

S3 Intelligent-Tiering, assume 50% in Frequent, 30% in Infrequent, 20% in Archive Instant:

• Storage: 5 TB × $0.023 + 3 TB × $0.0125 + 2 TB × $0.004 ≈ $115 + $37 + $8 ≈ $160
• Monitoring: 5M objects × $0.0025/1000 ≈ $12.50
• Egress: 20 TB ≈ $1,750 (still unchanged)
• Monthly total: ~$1,925

Wasabi:

• Storage: 10 TB × $6.99/TB ≈ $70
• Egress: $0
• Monthly total: ~$70

This is where the egress reality bites. Intelligent-Tiering shaved $55 off a $1,980 bill. Moving shaved $1,910. The storage line was never the problem on this workload; the egress line was. Tiering doesn't touch egress, so it doesn't move the bill.

Migration cost: 10 TB × $0.15/GB = $1,499. Payback against the Tiering scenario: under a month.

Workload 3 — heavy egress, the CDN origin

A media team holding 5 TB of source assets that get read constantly. 100 TB egressed per month — assets feeding a CDN, an inference cache, a download service. Assume large objects (average 100 MB — video, high-res images), so about 50,000 objects.

S3 Standard:

• Storage: 5 TB × $0.023 ≈ $115
• Egress: 100 TB ≈ $8,260
• Monthly total: ~$8,375

S3 Intelligent-Tiering: the data is read constantly. Nothing demotes. All 5 TB sits in Frequent Access at full Standard price. Plus the monitoring fee.

• Storage: 5 TB × $0.023 ≈ $115
• Monitoring: 50,000 objects × $0.0025/1000 ≈ $0.13
• Egress: 100 TB ≈ $8,260
• Monthly total: ~$8,375 (essentially identical to Standard)

Cloudflare R2:

• Storage: 5 TB × $0.015 ≈ $75
• Egress: $0
• Class A/B operations on this read pattern: ~$50–$200/month
• Monthly total: ~$150–$300

Intelligent-Tiering on this workload saves zero. The data is hot, so nothing demotes. The fee is small (large objects), so nothing is wasted — but nothing is gained either. Tiering is a no-op on hot data.

Moving saves ~$8,000/month. Migration cost: 5 TB × $0.15/GB = $749. Payback: three days.

Where Intelligent-Tiering wins

Three patterns where the in-place option is the right answer:

Large objects with a real cold tail. Video archives, ML training datasets, database backups, build artifacts older than a quarter. The monitoring fee per GB is negligible at large average object sizes, the access pattern has a clear bimodal distribution (recent stuff hot, old stuff cold), and the Archive tiers are genuinely cheap. This is the workload Intelligent-Tiering was designed for.

Deep AWS ecosystem lock-in. Athena queries on the bucket, Glue jobs, Lambda triggers on S3 events, SageMaker pipelines reading from S3 paths, Redshift Spectrum, any of the dozen integrations that assume the data lives in S3. Moving the data means re-pointing those integrations. Tiering keeps the data exactly where it is — same bucket, same ARN, same IAM policies — and just charges you less for the cold portion. The switching cost is zero.

Reversibility. Intelligent-Tiering is a toggle. You can flip it off tomorrow and you're back to bare Standard with no data movement. A migration is a real commitment — bytes physically move, integrations get re-pointed, the new provider becomes a vendor relationship to manage. Different risk profile. If the team is on the fence about whether the cheaper bill is worth the operational change, tiering buys time.

Where the move wins

Mirror image:

Egress-heavy workloads. Tiering doesn't touch egress. If your bill is dominated by data transfer out, no amount of storage-class optimization will help — only changing the egress equation will, which means leaving AWS.

Small-object workloads. The per-object monitoring fee scales with object count, not bytes. Logs, telemetry streams, image thumbnails, document archives with many tiny files — the fee can outpace any savings. Wasabi and B2 don't charge per object at rest. R2 charges per Class A/B operation but at a granularity that's almost always cheaper than the monitoring fee on the same workload.

You want flat predictable pricing. Tiering is dynamic — the bill shifts month to month as access patterns change, and it can go up unexpectedly when a cold-archive workload suddenly gets hot (an audit, an ML retraining run, a compliance discovery request). Wasabi at $6.99/TB-month with zero egress is the same number every month no matter what you do with the data.

You don't depend on AWS-internal services for the data. If the bucket is fed by external uploaders and consumed by external pipelines — partners, SFTP intake, customer-facing downloads — the AWS ecosystem isn't doing work for you. The lock-in cost of moving is small.

Edges worth naming

A few real edges worth naming:

Intelligent-Tiering monitoring fee waivers. Objects smaller than 128 KB aren't eligible for auto-tiering and aren't charged the monitoring fee. AWS quietly applies this to make small-object workloads less punitive than the raw arithmetic suggests. The fee still applies to anything above 128 KB. A bucket of 64 KB log lines won't pay the monitoring fee, but a bucket of 256 KB thumbnails will. Worth checking your object size distribution before you assume the worst case.

The Archive Access and Deep Archive Access tiers are opt-in. They're off by default. The Intelligent-Tiering you get out of the box only demotes to Archive Instant (~$0.004/GB-month), not the much cheaper Archive ($0.0036) or Deep Archive ($0.00099) tiers. To get those, you opt in per-bucket and accept that retrievals take minutes to hours. Most "I turned on Intelligent-Tiering and it didn't save me much" stories are accidentally describing the default config.

Reads count as access for tier-demotion purposes. A read on an Archive Instant object promotes it back to Frequent Access for the next monitoring cycle. Workloads with sporadic-but-real read patterns can ping-pong objects up and down the tiers in ways that erase the savings. The savings show up cleanly only on workloads where the cold tail is actually cold.

The cheapest option on a hot workload isn't either of these. The cheapest option is to put the data somewhere that doesn't charge egress at all. That's the leaving-the-hyperscaler post.

What about the orchestration layer

Most teams running this comparison aren't only choosing a storage backend — they're choosing where the file workflows around the storage live. SFTP intake from trading partners, AS2 exchanges with EDI counterparties, automation triggers when files land, audit logs for compliance teams, per-folder permissions for outside users. That layer doesn't change whether you stay in S3 or move to Wasabi. It runs on top of whichever storage backend wins the math.

If the file workflows around the bucket matter — and on most enterprise workloads they do — Files.com sits in front of whichever object store you land on and handles the protocol layer (SFTP, AS2, S3-API endpoint), the automation triggers, the audit logs, the access controls. Same external surface to your partners and customers regardless of whether the bytes live in S3 with Intelligent-Tiering enabled or in Wasabi with flat pricing. The storage decision and the orchestration decision are separable; this post is only about the storage half.

What to do next

Three steps, in order:

1. Get the real object count and average size on your bucket. aws s3 ls --recursive --summarize works for a quick sample. Mover's dry run is faster and free if the bucket is more than a few hundred thousand objects. The object-size distribution decides whether the monitoring fee is small or fatal.
2. Estimate the cold-tail percentage honestly. What fraction of the data hasn't been touched in 90 days? If it's most of the data and the average object is large, Intelligent-Tiering is probably the right move. If it's a small fraction or the objects are small, Tiering won't save much.
3. Run the leave-AWS numbers anyway. Even if Intelligent-Tiering looks good, the leave-AWS scenario is usually cheaper in absolute dollars and always cheaper on egress-heavy reads. The dry run gives you the exact migration cost and the exact destination bill so you can compare against the Tiering estimate with real numbers, not back-of-envelope ones.

If the answer comes out stay and tier, fine — you save money without moving bytes. If it comes out move, the dry run already told you the cost. Run the dry run, then decide.