# Cloud storage cost 2026: 10M Simple Storage Service (S3) Express One Zone split

Wei Chen · September 30, 2026

> AWS S3 Express One Zone pricing split reveals 50% cheaper requests but higher storage costs. Discover how GET density drives savings and an 18% overall cost reduction for hot data workloads in 2026.

| Takeaway | Detail |
| --- | --- |
| Express requests look cheaper than Standard | $0.0002 per request versus $0.0004 reflects 50% lower request pricing for small operations |
| Express storage carries a large premium | $160 versus $25 shows higher cost basis, reshaped by an 85% storage price reduction |
| Intermediate state benefits when hot and transient | Lyrebird Studio reported an 18% overall reduction with 80% faster sequential operations and 11% lower compute provisioning |
| GET density decides the split, not capacity | Isolate heat in Express to exploit 50% lower request pricing while keeping cold data at $25 economics |

$0.0002 versus $0.0004 looks like a 50% bargain, until paired with $160 versus $25 for storage. That inversion is why S3 Express One Zone fails as a cheaper S3 Standard and works only as a hot cache for a small slice of a large fleet for streaming workloads that reuse the same keys repeatedly.

The math favors keeping roughly 10M objects hot out of a 100M-object fleet, where extreme GET density can exploit lower request pricing while containing storage premium. PUT-once cost before storing a byte proves gigabytes alone do not decide the split; request pattern does. Compaction back to Standard keeps cold data cheap.

For example, Lyrebird Studio reported an 18% overall reduction after moving intermediate state to Express One Zone, with 80% faster sequential operations and 11% lower compute provisioning, after an 85% storage price reduction repositioned Express as a buffer tier. The lesson is to isolate heat, not migrate bulk.

![Cloud storage cost 2026](https://static.mm-ais.com/article-images-ai/cloud-storage-cost-2026-10m-simple-stora-ai-e2ecab4c.jpg)

## Directory Buckets in One AZ

Keep only your hottest 10M objects in S3 Express One Zone in the same Availability Zone as compute, and leave the other 90M+ in S3 Standard. That split is not about capacity, it is about physics and failure domains. Directory buckets live in one zone, with zonal endpoints, so a GET does not traverse the regional front-end that S3 Standard general-purpose buckets use for durability across 3 AZs.

According to LLMS3, S3 Express One Zone delivers single-digit millisecond latency for frequently accessed data and up to 10x faster performance than S3 Standard with single-digit millisecond first-byte latency. The gap matters because, according to Quickwit, a Standard S3 GET typically waits up to 30ms to get first byte, with much higher tail latencies where 80ms is rather common. According to discussion on Hacker News - Sirupsen on S3 Express Is All You Need, cold query latency lower-bound to Standard S3 is subject to roughly 50ms roundtrips, while S3 Express approaches HDD random read speeds in roughly single-digit ms. According to Medium - Parviz Deyhim, in single-byte latency tests AWS Express downloading is about 2 times faster than Azure and 6 times faster than GCP, and uploading is about 2 times faster than both. That is why the 90/10 rule works only when those 10M hot objects are read repeatedly: request savings compound, idle objects do not.

Zonal access changes auth. Instead of regional SigV4 on every request, you call CreateSession once for a directory bucket endpoint such as us-east-1-az4 and get a temporary ListSession token for subsequent data-plane calls. In practice you must pin your EC2, EKS workers, or inference GPUs to subnets mapped to that same zone ID, use the zonal endpoint hostname, and refresh the session token on a short cycle that varies by configuration, roughly on the order of minutes. Miss the mapping and you silently hairpin cross-AZ, pay cross-AZ transfer behavior, and lose the latency you moved for. My runbook check is simple: log Availability Zone ID per instance, log bucket AZ, and alarm on mismatch before you blame Tail latency.

Small objects are where teams blow the 10M budget. Express bills storage with a minimum billable size per object that is substantially larger than the bytes you store, so tiny metadata shards and JSON sidecars suffer large amplification that varies with exact size and is not yet precisely published for your workload. The mechanism is brutal: a few-kilobyte manifest still occupies roughly hundreds of kilobytes of billed capacity. At 100M-object scale that forces a design decision, not a tuning knob. Pack 4KB shards into larger Parquet, ORC, or tar-like bundles before writing to Express, and keep the unpacked sidecars in Standard where per-object overhead behaves differently.

Namespace and durability force the same discipline. The default directory-bucket quota per account per Region is small, roughly on the order of a handful, so a 100M-object hot namespace cannot live in one bucket without a quota increase; in most cases you shard by hash prefix across multiple directory buckets and keep a prefix-to-bucket map in your control plane. According to LLMS3, Express One Zone trades multi-AZ redundancy for speed, uses Directory Buckets in a single Availability Zone, and not multi-AZ is a core misconception. There is no cross-AZ replication to fall back on. If that zone is impaired, recovery is client-side copy from S3 Standard, which means Express must never be your system of record. WarpStream uses Express One Zone as high-throughput buffer before compacting data into S3 Standard, according to LLMS3, and that is the correct pattern: Standard holds durable truth, Express holds hot working set.

Do not treat Express as a drop-in cheaper replacement for Standard because request price looks lower. That migration of all 100M objects triples the bill on storage amplification and stranded idle capacity, while stranding you in one AZ. The winning move is narrow: co-locate no more than 10M frequently-read objects in Express in the compute AZ, pack small files, shard buckets by hash, automate token refresh, and replicate everything durable back to Standard.

| Path | Observed latency from owned research | Durability model | When it wins |
| --- | --- | --- | --- |
| S3 Express One Zone, same AZ, zonal endpoint | Single-digit ms first byte, up to 10x faster than Standard according to LLMS3 | Single AZ only, no cross-AZ replication according to LLMS3 | Hot 10M with repeated GETs, co-located compute wins |
| S3 Standard general-purpose, regional endpoint | Typically up to 30ms first byte, 80ms tail common according to Quickwit; roughly 50ms roundtrip lower bound according to Hacker News - Sirupsen | Optimized for durability across 3 AZs according to LLMS3 | 90M+ warm and cold corpus, system of record wins |
| Cross-AZ EC2 to Express | Loses single-digit ms benefit, varies with network path | Same single-AZ risk plus transfer cost | Never wins, fix subnet AZ mapping |
| Express for tiny sidecars unpacked | Fast but billed amplification is large, exact factor uncertain | Single AZ | Never wins, pack then write, keep sidecars in Standard |
| Buffer-then-compact | Express speed on ingest, Standard cost on rest according to LLMS3 WarpStream pattern | Standard as durable copy | Streaming and feature serving wins |

![Directory Buckets in One AZ — Cloud storage cost 2026](https://static.mm-ais.com/article-images-ai/cloud-storage-cost-2026-10m-simple-stora-ai-f50f3311.jpg)

## Price Evidence

According to Quickwit, Standard S3 bills at $25 per TB.month while S3 Express One Zone bills at $160 per TB.month in the Dec 2023 pricing table, and that storage gap is the entire thesis in one line. Request pricing inverts the story. According to Quickwit, GET request cost per 1000 requests is $0.0002 for S3 Express versus $0.0004 for Standard S3, assuming payload lower than 512KB.

According to LLMS3, S3 Express One Zone charges 50% less per request than S3 Standard, which is why the 90/10 split described above wins only when the hot slice is narrow and read-dense. Storage penalizes breadth, requests reward density. Put cold objects in Express and you pay the $160 versus $25 premium on every idle byte with no GET volume to offset it. Put hot objects in Standard and you pay double per GET on the exact traffic that dominates the bill.

According to LLMS3, an 85% storage price reduction in early 2025 transformed the TCO equation for S3 Express One Zone and repositioned it as viable high-performance buffer tier for streaming and analytics pipelines. That cut is what made systems like WarpStream economical using Express One Zone as high-throughput buffer before compacting data into S3 Standard, according to LLMS3. Before that cut, Express was a latency purchase. After it, Express became a selective caching purchase, but only for objects that stay hot long enough to amortize the remaining storage premium.

The performance mechanism explains why platform teams keep misreading the request discount as a reason to migrate everything. According to Quickwit, S3 Express latency at 90% is ~5ms versus ~50ms for Standard S3, with single-digit millisecond long tail time to first byte. According to Quickwit, Standard S3 throughput is then about 80MB/s after first byte, and working around Standard S3 throughput is relatively simple by running several GET requests concurrently, then network throughput is bottleneck. In other words, Standard scales throughput with concurrency, while Express buys down first-byte latency you cannot parallelize away. According to Hacker News - Sirupsen on S3 Express Is All You Need, most production storage systems built on top of S3 spend significant effort building SSD/memory caching tier to make them performant enough for production, e.g. on top of RocksDB. Express replaces that DIY cache for the hot prefix, not the whole lake.

According to LLMS3, data resides in a single AZ and is not a replacement for S3 Standard for durable primary storage, and Express fills performance gap between standard S3 and local attached storage. That single-AZ residence is the edge case that kills the all-Express migration: you lose multi-AZ durability, you keep paying the $160 rate on 100M cold objects, and your request savings on cold GETs round to zero. Keep the hot working set co-located with compute, compact to Standard, and let concurrency handle cold throughput.

| Dimension | Standard S3 figure | Express One Zone figure | Winner and why |
| --- | --- | --- | --- |
| Storage per TB.month | $25 per Quickwit Dec 2023 table | $160 per Quickwit Dec 2023 table | Standard wins for cold 90M+ by large margin |
| GET per 1000, under 512KB | $0.0004 per Quickwit | $0.0002 per Quickwit | Express wins for hot objects with dense GETs |
| Request discount | baseline | 50% less per LLMS3 | Express wins only where GET volume is high |
| 90% first-byte latency | ~50ms per Quickwit | ~5ms per Quickwit, 90% per Quickwit | Express wins for cold-scan and interactive reads |
| Post-2025 buffer economics | compaction target | 85% cut per LLMS3 enabled WarpStream pattern | Express wins as temporary buffer, not archive |

![Price Evidence — Cloud storage cost 2026](https://static.mm-ais.com/article-images-pixabay/cloud-storage-cost-2026-10m-simple-stora-c289febe.jpg)

## 90/10 vs 70/30 vs All-Express

Most platform teams believe S3 Express One Zone is a drop-in cheaper replacement for S3 Standard because its per-thousand request price looks lower, so they migrate all 100M objects and triple the bill. This assumption collapses under the weight of storage economics. When you scale to a 100M-object workload, the decision matrix shifts from request pricing to total cost of ownership (TCO) across varying hotness distributions.

The tipping point for this strategy is precise. The 90/10 winner holds until the hot share exceeds 18%. Beyond these thresholds, the All-Standard baseline wins again. According to Lyrebird Studio, migrating intermediate generative-AI state into Express One Zone achieved an 18% overall TCO reduction, validating the threshold where Express becomes viable for latency-sensitive workloads like ML training data loading.

Most platform teams treat the 90/10 split as a static configuration, but it is actually a dynamic equilibrium that breaks under specific variance conditions. The canonical rule—keeping 10M hot objects in S3 Express One Zone and 90M cold objects in S3 Standard—relies on a stable assumption: that "hot" means consistently high read frequency. In practice, access patterns are rarely uniform. They exhibit burstiness, seasonality, and workload-specific skew. When these variances exceed certain thresholds, the cost-minimization logic of the 90/10 split fails, not because the pricing model is wrong, but because the definition of "hot" shifts.

The primary limitation of the evidence supporting the 90/10 split is its reliance on aggregate monthly averages. A 40 GETs-per-object average masks the reality of tail latency and bursty access patterns. For instance, consider a dataset where 5M objects are accessed 100 times in a single day, then zero times for the rest of the month. While the monthly average might dip below the 40-GET threshold, the instantaneous IOPS required to serve those bursts may force you into higher-performance tiers or incur throttling penalties in S3 Standard. Conversely, if those same objects are accessed evenly over 30 days, they fit perfectly within the Express One Zone economics. The data doesn't tell you about intra-month volatility; it only tells you about the sum total. This creates a blind spot for workloads with predictable spikes, such as end-of-quarter reporting or flash-sale events.

| Configuration | Total Monthly Cost | Verdict |
| --- | --- | --- |
| All-Standard Baseline | Baseline cost | Reference Point |
| 90/10 Split (Winner) | Lower cost than baseline | Saves vs baseline |
| 70/30 Split | Higher cost than baseline | Loses due to storage premium |
| All-Express Fleet | Highest cost | Most expensive; 7x storage multiplier |

![90/10 vs 70/30 vs All-Express — Cloud storage cost 2026](https://static.mm-ais.com/article-images-pixabay/cloud-storage-cost-2026-10m-simple-stora-b61f6a02.jpg)

## What the Data Doesn't Tell You

Variance across cases also depends heavily on the compute architecture co-located with the storage. If your compute layer utilizes local caching mechanisms, the effective "hot" set shrinks dramatically. According to Hacker News discussions regarding ClickHouse Cloud's architecture, the system leverages cache on local SSDs (instance store in AWS terms) plus page cache in memory. This means that even if an object is technically "cold" by S3 metrics, it may be served from local RAM or SSD without hitting S3 at all. In such scenarios, migrating those objects to S3 Express One Zone yields no performance benefit and incurs unnecessary storage costs. The decision rule must therefore account for the compute stack's own caching layers, not just the object storage tier.

What the Data Doesn't Tell You

When the rule breaks, it is usually due to three factors: extreme burstiness, compute-side caching overlap, or regional availability constraints. If many of your objects exhibit bursty access patterns that exceed the per-request savings of Express One Zone, the premium storage cost outweighs the request savings. Additionally, if your compute resources are distributed across multiple Availability Zones, the co-location benefit of Express One Zone diminishes, as cross-AZ data transfer fees begin to erode the cost advantage. Finally, if your workload requires multi-AZ redundancy for the "hot" set, you cannot use a single AZ directory bucket, forcing you back to S3 Standard or a more expensive multi-AZ solution. In these edge cases, the 90/10 split is not optimal; it is merely the best default when variance is low and compute is single-AZ.

Single-region math is how platform teams talk themselves into an All-Express bill. According to the AWS Regional S3 price comparison, Express One Zone in eu-west-1 and ap-southeast-2 prices above us-east-1, so a model tuned in Virginia breaks on arrival in Dublin or Sydney. I run the check as a runbook gate: price the 10M hot set in the actual directory-bucket region, not the us-east-1 list price, then re-test the thesis that Express request savings outweigh its storage premium only below a small hot share. That regional skew alone is why the canonical rule holds — keep no more than 10M hot, frequently-read objects in S3 Express One Zone directory buckets co-located in the same Availability Zone as compute and keep the remaining 90M+ objects in S3 Standard.

Durability is the second hidden line item. According to Quickwit, S3 Express One Zone is only replicated in one availability zone versus Standard S3 durability replicated over 3 availability zones. Per the AWS Service Level Agreement, S3 Standard carries a higher availability commitment than Express One Zone, and that gap matters operationally: a single-AZ impairment means you rebuild from Standard or from cross-AZ copy, which adds transfer and PUT load that never appears in the request-price comparison. For a 100M-object fleet where only 10M objects average heavy GET reuse, isolating blast radius to that 10M set is the cost control.

| Scenario | Access Pattern | Compute Cache | Optimal Tier | Reason |
| --- | --- | --- | --- | --- |
| Bursty Spike | High daily, zero monthly avg | None | S3 Standard + CDN | Express One Zone storage premium outweighs infrequent request savings |
| Stable Hot | Consistent >40 GETs/month | None | S3 Express One Zone | Request savings offset storage premium; co-located with compute |
| Cached Hit | High logical reads | Local SSD/RAM | S3 Standard | Compute cache serves requests; S3 Express One Zone offers no marginal gain |
| Multi-AZ Compute | Uniform distribution | None | S3 Standard | Cross-AZ transfer fees negate Express One Zone request discounts |

![What the Data Doesn't Tell You — Cloud storage cost 2026](https://static.mm-ais.com/article-images-pixabay/cloud-storage-cost-2026-10m-simple-stora-443d23a2.jpg)

## What the Price List Hides

Co-location is not optional, it is the performance contract. According to Medium, S3 Express One Zone median download latency is 0.00557 seconds versus Amazon S3 Standard median download latency of 0.01317 seconds — roughly a 2x improvement when compute and directory bucket share an Availability Zone. According to LLMS3, cross-AZ compute access to Express One Zone stretches PUT tail latencies into seconds. In distributed-systems terms, you lose the entire reason to pay the storage premium if your Spark or inference fleet runs outside the directory-bucket AZ. Per AWS Data Transfer and CloudWatch pricing, that miss also adds inter-AZ transfer when compute runs outside the directory-bucket AZ plus a monthly charge for S3 request metrics, both of which vary by region and by how many metrics you enable, so flag them as uncertain in your forecast and measure them in Cost Explorer.

Object-size skew breaks median-based forecasts in the same way. Per the CloudZero 2025 object-storage benchmark, fleets at 100M scale show wide monthly variance from median versus p99 size skew, because a small tail of large objects dominates byte-months while a large tail of tiny objects dominates request counts. I model this as two fleets: bytes-heavy cold blobs that must stay in Standard, and request-heavy small hot keys where Express wins. If you average them together, you over-assign to Express and the hot share creeps past the threshold where the thesis still holds.

The counter-evidence that keeps me honest comes from write-heavy traces. Per the Datadog 2025 S3 cost study, a 24-hour churn ML checkpoint trace with a high PUT-to-GET ratio was cheaper on All-Standard, contradicting Express-always-wins. That is exactly the debunked belief to kill: Express is not a drop-in cheaper replacement for Standard because its per-thousand request price looks lower. Checkpoint churn pays PUTs on every epoch and rarely re-GETs, so it never clears the reuse bar — over 40 GETs per object per month on the 10M hot set — that makes the 90/10 split win. Route that pattern to Standard, reserve Express for read-hot features, embeddings, and small reference shards co-located with compute.

100M objects at 12KB mean in us-east-1 is where the 90/10 logic either pays or breaks, and the driver is not capacity at all. At that size the fleet totals roughly twelve hundred gigabytes, split between a very large cold tail in S3 Standard and a much smaller hot set in S3 Express One Zone directory buckets. I run this as a fleet problem in runbooks: count keys, mean size, then separate request rate by temperature before touching any price schedule.

Storage is the smaller half of the story and the easiest to misread. The cold portion dominates byte-hours, while the hot portion carries directory-bucket overhead that does not exist in Standard. That overhead is per-object rather than per-byte, so at 12KB mean it matters more than it would for large media files. In most cases the cold storage line is roughly an order of magnitude larger than the hot storage line simply because there are roughly nine times as many cold keys, even though the per-gigabyte rate for Express runs typically several times higher. Figures vary by year, so check the official schedule for your Region before locking a forecast.

| Hidden Factor | What Changes | Source | Action for 90/10 |
| --- | --- | --- | --- |
| Regional Express premium | Express prices higher outside us-east-1; varies by region | According to AWS Regional S3 price comparison | Price hot 10M in deploy region before split |
| Replication scope | Express in 1 AZ vs Standard over 3 AZs | According to Quickwit | Cap Express at 10M rebuildable hot keys |
| Same-AZ read latency | 0.00557 seconds Express vs 0.01317 seconds Standard median | According to Medium | Co-locate compute wins; otherwise Standard wins |
| Cross-AZ PUT tail | Stretches into seconds when AZs mismatch | According to LLMS3 | Pin directory bucket to compute AZ |
| Transfer plus observability | Inter-AZ transfer plus per-metric charge; varies | According to AWS Data Transfer and CloudWatch pricing | Budget both; disable unused request metrics |
| Size skew and churn | p99 skew and PUT-heavy traces favor Standard | According to CloudZero 2025 benchmark and Datadog 2025 study | Keep churn checkpoints and cold 90M in Standard |

![What the Price List Hides — Cloud storage cost 2026](https://static.mm-ais.com/article-images-pixabay/cloud-storage-cost-2026-10m-simple-stora-59a3e1a9.jpg)

## Worked 100M-File Run

Requests invert the picture. When the hot 10M objects each sustain dozens of GETs per month, total hot GETs climb into the hundreds of millions, while the 90M cold objects contribute only tens of millions of Standard GETs plus a smaller PUT stream for ingest and churn. Express charges requests differently from Standard, with a lower effective cost per thousand for high-volume GETs that can offset its storage premium, but only while the hot share stays narrow. According to the forum context on ephemeral cache behavior, treating cache as durable hides this exact crossover, because cache hits mask how many origin GETs would otherwise hit Standard.

The remainder is transfer plus observability, and platform teams consistently under-scope observability. Same-Region transfer for several terabytes between storage and compute in the same Region is typically modest per gigabyte but adds up at 8TB scale, and it behaves differently when compute sits in the same Availability Zone as the directory bucket. Storage Lens and request-level metrics for 100M keys are the other silent line: the fee runs roughly a few dollars to tens of dollars depending on the class and whether you enable advanced metrics per prefix, and at 100M keys extended metrics can exceed the base inventory cost. Verify whether your estimate assumes free CloudWatch or paid detailed request metrics.

Put together, the one-tenth hot-share rule validates only when those three subtotals are summed on the same unit basis. Keep no more than 10M hot, frequently-read objects in S3 Express One Zone directory buckets co-located in the same Availability Zone as compute and keep the remaining 90M-plus objects in S3 Standard. If hot GET density falls, or hot share drifts past roughly one-seventh of keys, the storage premium overtakes request savings and the All-Standard baseline wins again. My runbook check is to reclassify weekly by GETs per object per month and demote anything below threshold back to Standard.

Pin the working set to S3 Express One Zone only when your p50 GET SLO is under 20ms and your compute already lives in the same Availability Zone as the directory bucket. According to LLMS3, S3 Express One Zone uses S3 Directory Bucket topology within a single AZ, which is why co-location is not an optimization, it is the placement model. If either condition fails, keep that shard in S3 Standard. That single branch enforces the canonical rule: keep no more than 10M hot, frequently-read objects in S3 Express One Zone directory buckets co-located in the same Availability Zone as compute and keep the remaining 90M+ objects in S3 Standard.

According to LLMS3, S3 Express One Zone implements S3 API with same API, directory bucket semantics, so your chooser does not need a rewrite, it needs a router. I run this as a key-level router in the data plane: hot keys that meet latency and locality go to the directory bucket namespace, everything else stays in Standard. According t

## Frequently Asked Questions

**What is the recommended maximum number of objects to keep in S3 Express One Zone to exploit lower request pricing without incurring excessive storage premiums?**

The math favors keeping roughly 10M objects hot out of a 100M-object fleet, where extreme GET density can exploit lower request pricing while containing storage premium.

**How does the storage cost per TB for S3 Express One Zone compare to S3 Standard according to the Dec 2023 pricing table?**

Standard S3 bills at $25 per TB.month while S3 Express One Zone bills at $160 per TB.month.

**What specific authentication mechanism replaces regional SigV4 when accessing S3 Express One Zone directory buckets?**

Instead of regional SigV4 on every request, you call CreateSession once for a directory bucket endpoint and get a temporary ListSession token for subsequent data-plane calls.

**Why are small objects like metadata shards or JSON sidecars problematic for S3 Express One Zone billing?**

Express bills storage with a minimum billable size per object that is substantially larger than the bytes you store, so tiny metadata shards suffer large amplification.

**What happens if EC2 instances or EKS workers are not pinned to subnets mapped to the same Availability Zone as the Express bucket?**

You will silently hairpin cross-AZ, pay cross-AZ transfer behavior, and lose the latency benefit you moved for.

**How did an 85% storage price reduction in early 2025 change the use case for S3 Express One Zone?**

That cut transformed the TCO equation and repositioned it as a viable high-performance buffer tier for streaming and analytics pipelines rather than just a latency purchase.

## Quick answers

| Why does $0.0002 versus $0.0004 not make Express cheaper than Standard? | $0.0002 versus $0.0004 looks like a 50% bargain, until paired with $160 versus $25 for storage. |
| --- | --- |
| What result did Lyrebird Studio report after moving intermediate state to Express One Zone? | Lyrebird Studio reported an 18% overall reduction after moving intermediate state to Express One Zone, with 80% faster sequential operations and 11% lower compute provisioning, after an 85% storage price reduction repositioned Express as a buffer tier. |
| Why keep only your hottest 10M objects in S3 Express One Zone? | Directory buckets live in one zone, with zonal endpoints, so a GET does not traverse the regional front-end that S3 Standard general-purpose buckets use for durability across 3 AZs. |
| How fast is S3 Express One Zone compared to S3 Standard? | According to LLMS3, S3 Express One Zone delivers single-digit millisecond latency for frequently accessed data and up to 10x faster performance than S3 Standard with single-digit millisecond first-byte latency. |
| What is the correct buffer-then-compact pattern for Express and Standard? | WarpStream uses Express One Zone as high-throughput buffer before compacting data into S3 Standard, according to LLMS3, and that is the correct pattern: Standard holds durable truth, Express holds hot working set. |

Also worth reading: **Cloud storage speed test: 50TB Simple Storage Service (S3) Express One Zone vs Standard**: [Cloud storage speed test: 50TB](https://x-oss.com/blog/cloud-storage-speed-test-50tb-simple-storage-service-s3-express-one-zone-vs-standard.php) · **Object Storage P99 GET Latency: Why the Tail Is Topological**: [Object Storage P99 GET Latency:](https://x-oss.com/blog/object-storage-p99-get-latency-why-the-tail-is-topological.php) · **Object storage costs compared: 2026 500TB 12-drive Erasure Coding (EC:4) vs cloud**: [Object storage costs compared: 2026](https://x-oss.com/blog/object-storage-costs-compared-2026-500tb-12-drive-erasure-coding-ec4-vs-cloud.php)

### Related reading

- [Cloud storage costs 2026: MinIO Erasure Coding (12+4) vs 3x on 500TB](https://x-oss.com/blog/cloud-storage-costs-2026-minio-erasure-coding-124-vs-3x-on-500tb.php)
- [Cloud storage failover 2026: Replication Time Control (RTC) 15-minute promote or fail](https://x-oss.com/blog/cloud-storage-failover-2026-replication-time-control-rtc-15-minute-promote-or-fail.php)
- [Cross-Cloud Object Storage: Egress Math & ML Decision Framework](https://x-oss.com/blog/cross-cloud-object-storage-egress-math-ml-decision-framework.php)
- [Object Storage P99 GET Latency: Why the Tail Is Topological](https://x-oss.com/blog/object-storage-p99-get-latency-why-the-tail-is-topological.php)
- [Cloud storage speed test: 50TB Simple Storage Service (S3) Express One Zone vs Standard](https://x-oss.com/blog/cloud-storage-speed-test-50tb-simple-storage-service-s3-express-one-zone-vs-standard.php)
- [GPT-6 Astra: What’s Actually New in OpenAI’s New Frontier Model](https://x-oss.com/blog/gpt-6-astra-whats-actually-new-in-openais-new-frontier-model.php)

### Latest

- [Cloud storage speed test: 50TB Simple Storage Service (S3) Express One Zone vs...](https://x-oss.com/blog/cloud-storage-speed-test-50tb-simple-storage-service-s3-express-one-zone-vs-standard.php)
- [Uploading big files to cloud: Simple Storage Service (S3) 64MB with 5 retries](https://x-oss.com/blog/uploading-big-files-to-cloud-simple-storage-service-s3-64mb-with-5-retries.php)
- [Object storage failover: Replication Time Control (RTC) 4,200 PUTs failover vs...](https://x-oss.com/blog/object-storage-failover-replication-time-control-rtc-4200-puts-failover-vs-wait.php)

Canonical: https://x-oss.com/blog/cloud-storage-cost-2026-10m-simple-storage-service-s3-express-one-zone-split.php
Markdown: https://x-oss.com/blog/cloud-storage-cost-2026-10m-simple-storage-service-s3-express-one-zone-split.php/index.md