Macro Lens published a useful video called The Cloud's Exit Tax: 80x Markup on Leaving. The argument is simple enough to make any cloud tenant uncomfortable: bringing data into a major cloud is usually free, but moving the same data back out can produce a serious bill.
That is easy to dismiss as a pricing complaint. I do not think it is.
For a business that cares about data sovereignty, egress fees are part of the control model. They decide how expensive it is to change providers, move workloads back on owned infrastructure, respond to a customer demand, recover from a strategic mistake, or leave a platform after the economics stop making sense.
If you already have years of customer data, backups, logs, analytics, documents, media, and AI training material sitting inside one cloud, the fee to move it is not theoretical. It is a barrier. If you are starting a new business now, it is a warning label.
The shock is not the price. The shock is the asymmetry
Cloud providers have real network costs. Routers, transit, peering, backbone capacity, data center links, and operations are not imaginary. Nobody serious should pretend data movement costs nothing.
But the asymmetry matters.
Inbound transfer is commonly free. Outbound transfer is metered once you pass the free tier. AWS's own S3 pricing examples include data transfer out to the internet at $0.09 per GB in a Europe region example. That is roughly $90 per terabyte before volume tiers and exceptions. A few petabytes can turn into a six-figure exit conversation before the destination platform is even paid for.
That is why the language of "bandwidth pricing" feels too small. The fee shows up most painfully at the exact moment the customer wants optionality.
Data gravity turns a normal choice into a trap
The video leans on Dave McCrory's old phrase: data gravity. The more data gathers in one place, the more systems gather around it. Applications move closer. Analytics move closer. Backups move closer. AI pipelines move closer. Then identity, logging, monitoring, secrets, and automation start to assume that the data will remain where it is.
Nobody plans to become trapped.
A founder starts with a reasonable choice: use the cloud, move fast, avoid buying servers too early. Three years later, the company has a data estate, service dependencies, managed databases, object storage, audit logs, application integrations, and staff habits built around one platform.
At that point the exit tax is not only the invoice. It is the coordination cost. It is the rewrite cost. It is the test cost. It is the risk of discovering that one critical export path does not work the way the sales page implied.
The 80x number should be handled carefully
The video's title uses the 80x claim. That number traces back to criticism from Cloudflare and other cloud egress critics. It is not an official cost disclosure from AWS, Google, or Microsoft, so I would not treat it as audited truth.
I would treat it as a pressure test.
If wholesale bandwidth has fallen for years while egress pricing remained sticky, customers are right to ask whether the charge reflects network cost or switching friction. Those are different things. One is infrastructure economics. The other is lock-in.
For business planning, the exact markup is less important than the behavior it creates. The fee makes staying feel normal and leaving feel exceptional. That is enough to matter.
The EU Data Act changed the conversation
The strongest part of the video is not the 80x claim. It is the regulatory receipt.
The European Commission's Data Act explainer says switching charges, including charges for data egress, are to be removed from 12 January 2027. During the transition, providers are pushed toward cost-based switching charges.
Then the providers moved. Google Cloud created an exit-cloud transfer request path. AWS announced free data transfer out to the internet when moving out of AWS and explicitly tied the waiver to the direction of the European Data Act. Azure's bandwidth pricing page now says Azure offers free egress for customers leaving Azure to switch to another cloud provider or an on-premises data center.
Those waivers matter. They also have conditions. They are about leaving a platform, not ordinary day-to-day outbound traffic. A customer still needs to qualify, plan the transfer, meet the provider's process, and avoid confusing an exit waiver with a sovereignty strategy.
The lesson is not "egress is solved."
The lesson is that exit became negotiable once regulators forced the issue.
Why this is a sovereignty issue for US cloud tenants
For US cloud customers, especially small and midsize businesses, the practical question is not whether AWS, Azure, or Google are bad. They are useful platforms. They are also commercial control planes for data, identity, services, logs, and automation.
When a business centralizes its data with a US hyperscaler, it gets speed, managed services, mature security tooling, and global infrastructure. It also accepts a dependency model. Pricing, export paths, identity integrations, AI service terms, retention behavior, regional availability, and legal exposure all become part of the operating risk.
Data sovereignty is not just "where is the server?"
It is whether the business can answer these questions:
- Can we get our data out without asking for a rescue project?
- Do we know what it would cost under normal pricing and under any exit waiver?
- Can we rebuild the core workload somewhere else?
- Are our backups stored in a form we can use outside the provider?
- Do our AI, analytics, and automation pipelines depend on proprietary services that make the data harder to move?
- Have we tested a restore or migration path recently?
If the answer is no, the business does not fully govern the data. It rents access to it inside someone else's operating model.
What current cloud tenants should do
Start with an exit inventory. Not a migration project. An inventory.
List the data stores that would hurt if they had to move: object storage, databases, logs, backups, file shares, media libraries, vector stores, data warehouses, and AI datasets. Estimate the transfer size. Check the provider's current data transfer pricing. Check whether an exit waiver exists and what it requires.
Then look for hidden gravity. Which applications assume the data is local to one cloud? Which managed services would need replacement? Which identities, roles, service accounts, and secrets would break? Which teams know how the system works well enough to rebuild it?
Most companies do not need to leave tomorrow. They need to know whether leaving would be a controlled project or a panic event.
What new businesses should do before choosing a cloud
The time to design an exit is before the first terabyte lands.
For a new business, I would put a few rules into the architecture decision:
- Classify data before choosing services. Customer records, contracts, regulated data, logs, AI training material, and internal documents deserve different treatment.
- Prefer portable data formats. Do not bury critical records in services that make clean export difficult.
- Keep a second copy of the most important data under a separate control boundary. That might be another provider, owned hardware, or a backup platform that is not tied to the same identity and billing account.
- Use open interfaces where possible. S3-compatible storage, Postgres, standard identity protocols, documented APIs, and ordinary file formats make future movement easier.
- Test export and restore early. A backup you have never restored is a wish, not a control.
- Write down the exit path. If the business cannot explain how it would leave, it has not finished the architecture.
This is also where free and open-source infrastructure matters. Not because every workload should run on owned hardware from day one. That would be overkill for many startups. The point is to keep enough of the operating model portable that the business can choose where sensitive data belongs as it grows.
AI makes the exit question bigger
AI raises the stakes because it pulls more data toward the platform.
Documents become embeddings. Support tickets become training examples. Logs become evaluation data. Internal notes become retrieval sources. Customer records become context. Once AI workflows depend on provider-native storage, search, model hosting, and automation, the exit path gets harder.
This is why I keep coming back to sovereignty by architecture. The question is not whether the cloud is useful. It is whether the business can still govern the data after AI systems start using it.
For a practical example of this operating model, see the self-hosted SMB infrastructure stack. The point is not to reject cloud services. The point is to make the boundary deliberate: identity, files, apps, automation, AI tooling, secrets, observability, documentation, and recovery should be understandable and movable where the business requires it.
The planning rule
Use the cloud when it helps. Pay for good infrastructure when it saves time and reduces risk. But do not confuse convenience with control.
The exit path is part of the architecture.
If you are already in the cloud, measure it. If you are choosing a provider now, design it. If you are building AI workflows on top of the data, treat portability and governance as first-class requirements.
The bill to leave is only one part of the problem. The deeper issue is discovering, too late, that the data you thought you owned can only move on someone else's terms.
Source notes
- Macro Lens: The Cloud's Exit Tax: 80x Markup on Leaving
- AWS: Amazon S3 pricing and free data transfer out when moving out of AWS
- Google Cloud: Exit cloud free data transfer request
- Microsoft Azure: Bandwidth pricing
- European Commission: Data Act explained
- Cloudflare: AWS's Egregious Egress