Multi-Region Object Storage

Resilient in two regions. Priced like one.

Your applications need to survive a region going down. They shouldn't pay a premium on every byte stored, every byte read, and every operation to get there. Eon gives you two copies in two regions you choose: reads are served locally, and the second copy sits on archive pricing. Up to 35% lower total cost of ownership, and about 25% in a modeled petabyte-scale deployment.

The Problem

The bill for surviving a region failure scales with every object you store

Every serious object-storage workload eventually needs to survive the loss of a region. The cloud products built for this do their job well, but they were priced for a bucket, not for a petabyte-scale estate built from billions of small objects. Storage carries a premium on every byte, reads are billed as cross-location transfer, operations bill at double, and every write adds a replication fee. Three of these four cost vectors scale with object count rather than data volume, which is why estates full of small objects get hit hardest.

Your data, autonomously protected & ready for AI.

See what a single read-only role can do for your entire cloud estate.

How It Works

A storage layer that packs, replicates, tiers and fails over

Eon sits between your application and cloud storage as a client library. When your application writes an object, Eon bundles the DR copy with other objects heading the same way, and stores it in the region your application runs in. A second copy travels to the region you picked for disaster recovery, where it falls into archive pricing. Reads come back from whichever copy is local. If a region goes down, the SDK fails over to the other one.

Architecture diagram: an application using the Eon SDK in place of its cloud storage client library writes into Eon. Eon holds a production copy in a primary region you choose, intelligently tiered from Standard through Nearline to Coldline, serving all reads in-region with no cross-region transfer charges. It replicates asynchronously to a DR copy in a second region you choose, which sits on Standard for a configurable window and then moves to Archive while still reading back directly with no rehydration job. On a regional outage, reads fail over to the paired region.

Write: through a drop-in SDK

Your application calls Eon's SDK exactly as it calls the cloud provider's, with the same object types and the same create, read, delete, and list semantics. Eon writes the object into the production vault in your region. The object is readable locally the moment the write returns.

Replicate: batched and packed

Eon batches pending objects by destination region and ships them to the DR vault as bundles, each member with its own key. Bundling is what makes small objects economic, because you pay for one operation per bundle instead of one per object. Replication respects your RPO target first and optimizes bundle size second.

Tier: each copy at its own price point

The production copy moves down through Standard, Nearline, and Coldline based on access patterns, object age, and your per-prefix configuration. The DR copy storage is completely decoupled and its tiering is flexible based on access pattern and needs, with costs that are a fraction of the multi-region rate.
Economic Proof

Where the savings actually come from

A modeled petabyte-scale production estate on Google Cloud, running multi-region buckets with Autoclass, against the same estate on Eon. Both columns are full five-year cost of ownership including Eon's own charges, so they compare directly. The multi-region bill is indexed to 100.

Five-year cost of ownershipGCS Multi-RegionEonChange
Storing the dataBoth copies. On GCS they share one storage class; on Eon each copy is tiered on its own.51.339.922% less
Moving the dataReads billed as cross-region transfer, plus replication on writes30.49.768% less
Operations and feesTiering fees, retrieval, and per-request charges18.316.112% less
Total1006634% less

Indexed figures. Modeled at petabyte scale on Google Cloud list prices before negotiated discounts, with applications reading in their own region.

Storing the data costs less for three reasons. The DR copy is decoupled from the production copy, so it can sit in archive from the start while the copy your application reads stays warm. A geo-redundant bucket applies one storage class to both copies, so the redundant one is priced the same as the copy you actually read. Objects under 128 KiB tier down instead of sitting in Standard indefinitely. And the tiering policy is yours to shape per prefix, rather than one setting for the whole bucket.

Moving the data costs a fraction of what it did, because every read is served from a copy in the same region as the application, rather than billed as cross-location traffic.

A single read of the cold copy can cost you a year of Standard-rate storage on Autoclass. A read promotes the object back to Standard, and it takes a year of inactivity to move back down to archive, so pulling a large slice of cold data during an incident re-warms it at Standard rates for the next twelve months. Eon reads the object from archive and serves it from a cache that is discarded once the incident is over. The copy stays cold, and the cost stays bounded to the event.

FAQs

How is Eon cheaper than a multi-region or dual-region bucket?
Geo-redundant buckets apply a storage premium to every byte, bill reads as cross-location data transfer, charge double for Class A operations, and add a per-GB replication fee on writes. Eon replaces that with one intelligently tiered production copy in your region and one DR copy on archive pricing in a region you choose, and reads are served locally. In a modeled petabyte-scale deployment against GCS multi-region with Autoclass, that came out at roughly 25% lower five-year cost of ownership. Savings run higher against dual-region buckets, which bill two full-price copies, and higher again on estates with many small objects. We will model your actual footprint before you commit to anything.
Do we qualify for this? What does a good fit look like?
The hard requirement is that your applications can adopt the Eon SDK in place of your cloud provider's client library, so you need to own and be able to ship the code that reads and writes objects. If objects are written by a third-party appliance or a SaaS product you cannot modify, this is not the right fit and we will say so on the first call. Beyond that, the economics get stronger the more small objects you have, the more read-heavy your workload is, and the larger your footprint. The savings are a percentage of a geo-redundancy premium, so they matter most at roughly a petabyte and above.
Does moving the DR copy to Archive slow down recovery?
No rehydration job is required, because GCS Archive is online storage and Eon reads from it directly, and subsequent reads of that object come from a hot cache. Archive reads carry a retrieval charge, so the DR vault's tiering policy is tuned to your access and retention patterns. Some estates go straight to archive; others hold newer objects warmer first.
How does this compare on AWS, where there is no multi-region bucket?
Correct: S3 has no geo-redundant bucket type, so cross-region resilience is assembled from Cross-Region Replication plus, usually, a Multi-Region Access Point. That means paying for two full copies rather than a premium on one, plus a replication PUT per object, inter-region transfer, $0.015/GB for Replication Time Control if you want a 15-minute RPO, and $0.0033/GB for MRAP routing. You can cut the replica cost by landing it in Glacier Instant Retrieval, but then it is no longer serving reads. Small objects are hit hardest, because Standard-IA and Glacier Instant Retrieval enforce a 128 KiB minimum billable object size, so a 32 KiB object is billed as 128 KiB.
What replication RPO can I get, and is this active-active?
RPO is configurable from 15 minutes up to one hour, traded off against cost. Replication is asynchronous, and within a single region Eon provides strong read-after-write consistency: an object is readable immediately after the write returns. On active-active, every region serves reads from a local copy, and every region keeps serving if its neighbour fails, so from the application's point of view, yes. It is not architecturally identical to a GCS dual-region bucket, which presents a single strongly consistent namespace with both copies in the same storage class. Eon gives each region its own production copy plus a local archive-tier copy of its partner's data, and that difference is what makes the economics work.
Do I need to rewrite my application?
No. Eon's SDK is a drop-in replacement for the cloud provider's client library, with matching types and object operations, so integration is a dependency change and a client initialization rather than an application redesign. Create and streaming upload, read and streaming download, delete, prefix listing, metadata, conditional create, and retention and storage-tier hints are all supported. During a migration, reads fall back to your original bucket for objects not yet moved, so you can move a workload progressively rather than in a single cutover.

Bring us your bill

Send us your object-storage footprint, access pattern, and region layout. We'll model it line by line against what you're paying now (storage, transfer, operations, replication) and show you the delta before you commit to anything.