Data gravity cost: why your data becomes expensive to move

Quick answer

Data gravity is the tendency for applications and services to migrate toward where the data already lives, because moving compute is cheap and moving data is not. The financial expression of it is egress pricing: moving 500 TB out of AWS at standard rates costs roughly 36,000 dollars in a single transfer, while moving the compute that reads it costs nothing. The practical consequences are that the first place a large dataset lands tends to become permanent, and that cross-cloud architectures pay a recurring tax. Planning where data lands is therefore a long-term cost decision, not an operational one.

Compute is fungible. You can move a service from one cloud to another in an afternoon, or run the same container in three places. Data is not. Once a few hundred terabytes accumulate in one provider's object store, that dataset exerts a pull: the analytics runs next to it because queries over the network are slow and expensive, the machine learning training runs next to it, the backup tooling is built around its APIs, and each new service that needs the data is deployed in the same region. This is data gravity, and the meter that makes it real is egress pricing.

The cost of escape velocity

Dataset size	AWS egress at blended rate	Days at 1 Gbps
10 TB	about 830 USD	1.0
100 TB	about 7,700 USD	9.9
500 TB	about 36,000 USD	49
1 PB	about 64,000 USD	99

The blended rate falls with volume: 0.09 dollars per GB for the first 10 TB, 0.085 for the next 40 TB, 0.07 for the next 100 TB, and 0.05 beyond 150 TB in US regions. Even at the cheapest tier, a petabyte costs tens of thousands of dollars to move once, and the time dimension matters as much as the money: at a sustained 1 Gbps, a petabyte takes about 99 days.

Gravity is recurring, not one-time

The escape cost is the dramatic number, but the ongoing cost is what actually shapes architecture. If your data lives in cloud A and you want to run a workload in cloud B, every query pays egress. A nightly analytics job reading 2 TB from cloud A into cloud B costs about 170 dollars per night, or roughly 5,100 dollars per month, forever. That recurring number is what pushes the analytics workload back next to the data, which is gravity doing its work. The cross-cloud version of this problem is analyzed in cross-cloud networking cost.

The exit waiver changes one thing, not everything

Since 2024 the major clouds waive egress charges for customers migrating off the platform entirely. That materially reduces the cost of a clean exit, which is a genuine improvement. But it applies to exit, not to operation. A multi-cloud architecture that reads data in one cloud from compute in another pays full rates every day it runs. The waiver removes the lock-in argument at the boundary while leaving the operational tax fully intact, which is why data gravity remains an architectural force even after the policy change.

Where gravity accumulates fastest

Three categories accumulate data gravity quickly. Log and telemetry archives grow monotonically and are rarely deleted, reaching hundreds of terabytes within a few years at modest ingest rates. Media catalogs grow with every asset and are almost never pruned. And analytical data lakes accumulate raw, cleaned, and aggregated copies of the same facts, often tripling the footprint of the original data. The common thread is that none of them have a natural deletion pressure, so they only grow.

Designing with gravity in mind

The practical responses are not exotic. First, decide deliberately where the large datasets land, because that choice is effectively permanent and should be made with the same seriousness as a database engine choice. Second, keep processing close to storage: a query engine reading from object storage in the same region pays nothing for transfer, while the same engine one region away pays 0.02 dollars per GB. Third, push aggregation to the data rather than pulling raw data to the compute. A job that filters and aggregates 2 TB down to 8 GB before transfer converts a 170 dollar nightly transfer into 0.68 dollars.

Fourth, use open formats. Parquet and Iceberg tables in object storage are portable in a way that a proprietary warehouse's internal format is not, so the gravity applies to the bytes rather than to the vendor. Fifth, apply lifecycle policies aggressively, since data you delete cannot exert gravity. A 90 day retention on raw logs with aggregated rollups kept indefinitely reduces the archive by an order of magnitude while preserving nearly all analytical value.

When gravity is the right answer

It is worth saying that gravity is not purely a problem. Co-locating compute with data is the correct engineering choice most of the time: it is faster, simpler, and cheaper. The failure mode is not acknowledging that the choice has been made. Teams get into trouble when they assume portability they have not designed for, then discover during a vendor negotiation or a regional outage that the data cannot move on any useful timescale. Know the number, keep the formats open, and keep the transfer volume small. Price your storage and transfer architecture against the resource catalog before the dataset gets heavy.

FAQ

What is data gravity?

The tendency for applications and services to cluster around where data already lives, because moving compute is cheap and moving data is not. As a dataset grows, analytics, machine learning, backup tooling, and new services all get deployed next to it. Egress pricing is the financial mechanism that makes this pull concrete rather than merely a matter of latency.

How much does it cost to move a large dataset out of a cloud?

AWS egress tiers from 0.09 dollars per GB for the first 10 TB down to 0.05 beyond 150 TB in US regions. Moving 100 TB costs roughly 7,700 dollars, 500 TB about 36,000 dollars, and a petabyte about 64,000 dollars. Time matters too: at a sustained 1 Gbps, a petabyte takes roughly 99 days to transfer.

Does the egress waiver eliminate data gravity?

No. The major clouds waive egress fees for customers migrating off the platform entirely, which reduces the cost of a clean exit. But it applies to exit, not to operation. A multi-cloud architecture reading data in one cloud from compute in another pays full rates every day it runs, so the operational tax that drives workloads back toward the data remains intact.

What kinds of data accumulate gravity fastest?

Log and telemetry archives, which grow monotonically and are rarely deleted, reaching hundreds of terabytes within a few years at modest ingest. Media catalogs, which grow with every asset and are almost never pruned. And analytical data lakes, which keep raw, cleaned, and aggregated copies of the same facts and often triple the footprint of the original data.

How do I design around data gravity?

Choose deliberately where large datasets land, since that choice is effectively permanent. Keep processing in the same region as storage, where transfer is free. Push filtering and aggregation to the data so a job reducing 2 TB to 8 GB before transfer turns a 170 dollar nightly cost into 0.68 dollars. Use open formats like Parquet and Iceberg. And apply lifecycle policies, because deleted data exerts no gravity.

How does C3X help here?

C3X prices infrastructure from Terraform before deployment, including storage placement, replication rules, and the network paths between compute and data. Because data gravity is created by decisions about where things live, seeing those decisions priced in the pull request is the moment when a placement can still be changed without moving any bytes.

What to do next

Decide where your data lives with the cost in view. C3X prices Terraform against a live resource catalog. Start with the quickstart.