TL
The short answer

Data gravity is the principle that as a dataset grows, the cost and latency of moving it rise, so it becomes cheaper to bring compute and services to the data than to move the data to them. The cost consequence in a multicloud estate is concrete: every time a workload in one cloud reads from a dataset in another, you pay egress on the source side, and every time you copy the dataset to avoid that, you pay for duplicated storage and the pipelines that keep copies in sync. The buyer takeaway is that placement is an economic decision, not a technical afterthought, and the cheapest architecture is usually the one that keeps heavy compute next to the data it reads most.

Below is how data gravity shows up on the bill, the three levers that control it, and a worked example you can act on this week.

How does data gravity show up on the cloud bill?

It rarely appears as a line called data gravity. It hides inside three categories. The first is egress: AWS, Azure, and GCP all meter data leaving a region or the cloud, typically in the range of a few cents per gigabyte that looks trivial until a daily analytics job moves terabytes. OCI is materially cheaper on egress, which is itself a placement signal. The second is duplication: teams copy a dataset into a second cloud to keep compute local, then pay twice for storage plus the transfer to seed and refresh the copy. The third is the architecture tax: services chosen because they sit next to the data, not because they are the best fit, which quietly raises the run rate for years.

Why does moving compute to the data usually win?

Compute is portable and cheap to relocate; petabytes are neither. If an analytics workload needs to read a 40 terabyte dataset every day, running that workload in the same region as the data costs nothing in transfer, while running it one cloud over could move 40 terabytes a day across a metered boundary. At a representative egress rate, that single design choice can swing five figures a month. The discipline is to identify the authoritative dataset, treat its location as fixed, and place the compute that reads it most heavily right beside it. Lighter consumers that need only summaries can live elsewhere and pull aggregates rather than raw data.

What does deliberate placement look like?

Three levers control data gravity cost. Place the authoritative copy where the heaviest readers live and treat other clouds as consumers of derived data, not raw. Push aggregation to the source so you transfer summaries measured in gigabytes rather than raw events measured in terabytes. And price egress into every cross cloud design before it ships, because the cheapest time to avoid a transfer charge is at the whiteboard, not after the first bill. Where a second copy is genuinely required for resilience or locality, size it against the recovery and latency benefit it buys rather than copying by reflex.

A worked example

Worked example

A European SaaS company ran its event store in one cloud and its analytics stack in another because two teams had chosen independently. A daily pipeline moved roughly 30 terabytes across the boundary, and the cross cloud transfer alone ran into the tens of thousands of dollars a month. Moving the analytics compute into the same region as the event store, and shipping only daily aggregates to the second cloud for the business intelligence layer, cut the transferred volume by more than 90 percent and removed the duplicated raw copy entirely. The change touched placement and pipelines, not the application, so engineering risk stayed low. Figures are verified against billing data and anonymised.

PatternWhat movesCost driver
Data to computeRaw dataset, dailyHigh egress plus duplicated storage
Compute to dataNothing across the boundaryRegion local, no transfer charge
Aggregate then shipSummaries onlySmall transfer, single source of truth

Talk it through with us

If your multicloud bill is heavier than the architecture should justify, data gravity is often the reason, and placement is the fix. We take zero provider commissions and answer only to you, across AWS, Azure, GCP, and OCI. Our guarantee is plain: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee scoped up front or a no risk Gainshare share of verified savings. Book a strategy call to scope it for your estate, and follow more analysis in The Cloud Spend Navigator.

Frequently asked questions

What is data gravity in cloud computing?
Data gravity is the tendency of a large dataset to attract compute, analytics, and services toward it, because moving the data is slower and more expensive than moving the workloads that use it. In multicloud estates it drives egress charges and duplicated storage.
How does data gravity increase cloud costs?
It increases costs three ways: egress charges when a workload in one cloud reads data in another, duplicated storage when teams copy datasets to keep compute local, and an architecture tax when services are chosen for proximity to the data rather than fit.
How do you reduce the cost of data gravity?
Place the authoritative dataset where its heaviest readers live, move compute to the data rather than data to the compute, and ship aggregates instead of raw events across cloud boundaries. Price egress into every cross cloud design before it ships.
Independent · buyer-side

Put a defensible number on your cloud spend.

No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.

Buyer-side intelligence, monthly.

The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.