Multi-Region Object Storage at Petabyte Scale

Regional Resilience for Object Storage, Without Multi-Region Cost

Your applications need to survive a region going down. They shouldn't pay a premium on every byte stored, every byte read and every API operation. Eon keeps two copies in two regions you choose, serves every read locally, and puts the second copy on archive pricing. That cuts total cost of ownership by up to 35%.

Model my GCS savings
The Problem

Geo-redundant storage gets expensive and hard to navigate at scale

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. Cost is not the only thing that scales: at billions of objects, listing the bucket stops being a practical way to find anything, and knowing what is stored or whether any of it is sensitive gets harder as the estate grows.

See the cost model

How Eon lowers the cost of multi-region storage

  • The DR copy is decoupled and tiered for recovery, not production. It can sit in archive from the start, instead of being locked to the same storage class as the copy you read.
  • Small objects are bundled before replication. You pay for one operation per bundle instead of one per object.
  • The production copy stays in the region your applications run in. A multi-region bucket bills your everyday reads as cross-region transfer. Eon keeps a copy where the application already is, so those reads never cross a region boundary and there is nothing to charge for.
How It Works

How Eon handles writes, replication, and tiering

Eon sits between your application and cloud storage as a client library. A write goes into the region your application runs in and is readable there immediately. A second copy is bundled with other objects heading to the same place and replicated to the DR region you picked, where it falls into archive pricing. This is built for petabyte scale and billions of objects, where cost tracks object count as much as data volume. Reads come back from whichever copy is local, and 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. Eon replicates data within the configured RPO while batching small objects to reduce GCS operation costs.

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.

An index, not just a bucket

Every object written through Eon is recorded in a metadata index that sits beside the data. Listing and lookups are answered from that index rather than from the bucket, which is what keeps them fast and inexpensive when the namespace runs to billions of objects. It is also the same foundation Eon’s discovery, sensitive-data classification, and search are built on across protected AWS, Azure, and GCS estates.

Economic Proof

Five-year cost comparison

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 DR copy remains in a lower-cost storage tier and is accessed primarily during recovery.

Explore more from Eon

Eon Cost Explorer: Instant Visibility Into Backup Spend Across Clouds

Easily view backup spend across AWS, Azure, and Google Cloud so you can charge it back, fix anomalies, and optimize costs in minutes.

Read Article

How to Cut Cloud Backup Retention Costs Without Risking Data

Learn how to slash AWS backup costs without leaving critical data unprotected.

Read Article

Innago Simplifies Backup on AWS and Saves 40% with Eon

Learn how Eon’s first-of-its-kind autonomous backup platform helped Innago streamline backups and turn them into an easy-to-use asset that delivers ongoing business value and peace of mind.

Read Article

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. That is worth up to 35% lower five-year cost of ownership, with Eon's own charges included. 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.
Can Eon search or classify the data I store here?
Eon maintains a metadata index over every object written through the gateway, which is what makes listing and lookups fast and inexpensive at scale. That index is the same foundation Eon's discovery, sensitive-data classification, and search are built on across protected AWS, Azure, and GCS estates. Talk to us about bringing them to your object storage estate.

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.

Request a cost model