Data Gravity

Cloud pricing is asymmetric: ingress is typically free, egress is expensive, and cross-region and cross-zone transfer sit between. Physics is asymmetric too — bandwidth and latency across a wide area are far worse than within a rack.

The consequence is that a large body of data exerts a pull on everything that uses it. New services are built where the data is, analytics runs where the data is, and moving the data becomes progressively less feasible as it grows — which is why data gravity is also the strongest form of cloud lock-in, and a far more durable one than any API dependency.

Why it matters

It reverses the naive design instinct. The intuitive approach is to move data to the service that needs it; the economical approach is to move the computation to the data and return only the result. The most common expensive mistake in cloud architecture is exporting raw data across a boundary in order to compute a small answer.

It also means early data placement decisions have long lifetimes. The region a dataset lands in, the cloud it lives on, and the format it is stored in constrain everything built around it for years — and the cost of revisiting grows with the dataset, so the window in which the decision is reversible closes early.

Implementation patterns

• Push computation to the data: aggregation, filtering and projection at the source, transferring results rather than inputs.
• Open storage formats on object storage, so multiple engines can read the same data in place. This is the main defence against the lock-in dimension — the data does not move, but the choice of what reads it stays open.
• Zone-aware routing for chatty internal traffic, preferring a same-zone instance while retaining cross-zone capability for failover.
• Edge caching, treating cache hit ratio as a cost metric.
• Compression on every boundary crossing, which is the cheapest available reduction.
• Replicate deliberately, not by default — replicating a dataset to a region that never reads it is pure transfer and storage cost.
• Attribute transfer by source, destination and workload, since the distribution is usually extreme and a handful of flows dominate.
• Locate new compute near the data it will use most, which is a design-review question rather than an operational one.

Industry example

The phenomenon shapes every large data platform's architecture. Analytics engines that separate storage and compute — Snowflake's model, and the lakehouse pattern generally — exist partly because keeping one copy of the data and bringing varying compute to it is far cheaper than maintaining copies per workload.

It also explains a persistent commercial pattern: egress pricing is a strategic instrument, not merely a recovered cost. The asymmetry between free ingress and expensive egress makes data easy to move in and expensive to move out, which is precisely why regulatory attention in the 2023–2025 period focused on it and why several providers reduced or removed egress fees for customers leaving.

Failure scenarios

• Exporting raw data to compute a small result, repeatedly, on a schedule.
• A multi-cloud architecture with data flowing between clouds, incurring the highest available transfer prices on every interaction.
• Cross-zone chatter by default in a multi-AZ deployment, with no zone affinity.
• Replicating everything everywhere on the assumption that storage is cheap, ignoring transfer.
• Analytics reading from a production database across a region boundary, which is both slow and billed.
• Proprietary storage formats, which convert data gravity into a genuine inability to change engines.
• Discovering the constraint at migration time, when the dataset is large enough that the transfer cost alone blocks the move.

Trade-offs

Designing around data gravity means accepting locality constraints: services placed near their data rather than where it would otherwise be convenient, and workloads that would benefit from a different region or provider staying where the data is. That is a real limit on architectural freedom, and it can mean running compute on a platform that is not the best fit because the data lives there.

Countering it — keeping data portable, in open formats, replicated where needed — costs storage, complexity and consistency management. Maintaining genuine portability is an ongoing tax paid against an optional future move.

The trade is architectural flexibility against transfer cost and latency, and the honest position is that gravity usually wins: the practical response is not to fight it but to choose the data's location deliberately and early, keep the format open so the compute layer stays replaceable, and avoid designs that move large data routinely.

Interview question

"Our analytics team wants to run their jobs in a different cloud from where our production data lives, because the tooling is better there. Tell me what that costs, what you would propose instead, and what would have to be true for their plan to be correct."