Egress Is the Second Lock-In: Modeling the Real Cost of Leaving Your Cloud Provider
10 min read
The exit strategy works on paper. The workload is portable, the virtualization layer is identical on both sides, the runbook is signed off. Then somebody runs the egress estimate, and the project goes back to the steering committee for a re-scope.
Egress is the second lock-in. The first is the managed VM layer, covered in the previous post. The second is the network bill that arrives the day you actually try to leave. For EUC estates in particular, where the dataset that has to move includes FSLogix profile containers, MCS or PVS image stores, recording archives, and gold-image snapshots, the egress invoice is the line item that decides whether the exit strategy is real or aspirational.
What the EU Data Act actually changed
A note before the legal part: I’m an infrastructure architect, not a lawyer. What follows is my reading of the EU Data Act (Regulation (EU) 2023/2854) and DORA as they apply to cloud exit costs, not legal advice. Check the specifics of your contract and your regulatory obligations with your legal or compliance team.
If you have read a vendor blog in the last twelve months you will have seen the claim that egress fees are “gone” because of the EU Data Act. The position is more specific than that, and it has a date on it. Article 29 phases switching charges out in two steps. Since 11 January 2024, providers may charge only reduced fees capped at the costs directly linked to the switch. From 12 January 2027 they may not charge at all, and Article 2(36) puts data egress squarely inside the definition of a switching charge. Until that date, AWS, Azure and GCP all run their switching credits as a process you have to initiate, prove and complete, rather than as a default tariff change.
What Article 29 does not touch matters just as much, and it does not expire in January. The ban covers switching. It does not cover routine egress, multi-cloud architectures, BCDR replication, in-parallel use (where Article 34(2) explicitly allows providers to pass the cost on), or internal transfer such as cross-AZ traffic, NAT processing and inter-region replication. All of that is metered after January 2027 exactly as it is today.
Read the small print on each provider’s switching-credit page:
- AWS free data transfer for switching, requires application and approval, applies to customers leaving AWS for an alternative.
- Azure free egress for leaving, process initiated by support request, with documentation of the destination.
- GCP free network egress to migrate, similar mechanism, similar prerequisites.
In all three cases, the cost goes to zero only for a one-way, fully-documented exit. Anything short of that (a hybrid migration, a parallel run, a BCDR test, a rebalance) is still metered at standard egress rates.
The three tariffs that drive the bill
Standard egress pricing is tiered by volume and varies materially across providers and regions. The rates change often enough that anything quoted in a blog post is going to be slightly out of date by the time you read it, check the current pricing pages before you model, but the orders of magnitude are stable:
- AWS data transfer out to internet tiers from $0.090/GB for the first 10 TB down to $0.050/GB above 150 TB, and publishes no rate at all beyond 500 TB a month, where the page tells you to contact them. The brackets are also binary: AWS’s “first 10 TB” ends at 10,240 GB, not 10,000.
- Azure bandwidth out follows a similar curve in a similar range.
- GCP egress is the awkward one to quote. Google does not publish a flat internet-out tier table the way AWS and Azure do, and its network pricing pages will not render a figure you can cite, so price it per region-pair in the calculator for your own source and destination rather than trusting a number from a blog, this one included.
What matters less than the absolute number is the shape of the curve. The marginal rate keeps falling but does not approach zero. A 100 TB exit is not 10× the cost of a 10 TB exit. A 1 PB exit works out at about 61×, still expensive enough to derail a project plan that assumed the EU Data Act made it free.
What lives in an EUC egress bill
When the finance team models a cloud exit, they model the virtual machines. When the EUC team models it, they realise the VMs are nearly the smallest line item. The data that has to physically move is somewhere else.
For a representative 5,000-seat EUC estate, the categories worth costing are:
- FSLogix profile containers. An average profile in a real environment sits at 5 to 15 GB, with outliers significantly larger. At 10 GB per user and 5,000 users, that is 50 TB before anyone has touched anything else.
- App Layering ELM / image stores. Gold images, layers, and elastic layers. Tens to low hundreds of GB per image, dozens of images per environment. Add 1 to 5 TB depending on the layering strategy.
- Session recordings. Any environment with Citrix Session Recording, AVD recording, or a third-party tool will have an archive that grows linearly with usage. Multiple TB are common.
- MCS / PVS golden images and snapshots. Under MCSIO in particular, the snapshot chains are easy to underestimate, so inventory them rather than assuming the image size is the number.
- Object storage for telemetry, monitoring, and analytics. Smaller per-object, larger in aggregate over a multi-year retention window.
A 5,000-seat estate that looks like 1 PB in storage on the cloud provider’s invoice is rarely 1 PB of “things you need to move”, but it is also rarely the 50 TB the project plan assumes. The honest number for an exit-test or full exit usually sits in the 100 to 250 TB range, before deduplication and before the cleanup pass that nobody schedules.
Three scenarios for the 5,000-seat estate
Scenario 1: Full estate exit (one-way)
The full one-way exit is the one scenario the Data Act actually fixes. Today it runs on the provider’s switching credit: submit the request, document the destination, complete the move inside an agreed window, and prove the source environment is decommissioned. From 12 January 2027 the process argument falls away, because charging for the switch stops being permitted at all.
The cost line is small. The process line is the problem. The credit applies once; it does not cover a parallel-run period beyond what the provider judges reasonable.
Scenario 2: DORA exit test (round-trip)
DORA’s testing requirement is the scenario the switching credits do not cover. An exit test is a round-trip: extract the workload to an alternative environment, verify it operates within the required recovery window, and either decommission the test environment or fold it into BCDR. The egress on the way out is metered. The cost of a quarterly or annual exit test on 100 to 250 TB of EUC data is non-trivial and predictable, and it needs to be in the budget as a recurring line, not a one-time project cost.
Scenario 3: Partial rebalance
A partial rebalance, moving a subset of workloads to a different provider, or splitting an estate across two for redundancy, is the most common live scenario and the least covered by anything. Standard egress applies on every move, and because the volumes are smaller, the per-GB rate is higher (you do not reach the cheapest tier). The unit economics of a partial rebalance are materially worse than either of the other two scenarios.
The numbers are arithmetic, not a quote: the AWS EU (Ireland) list tiers from the table above, applied to the volumes in this post. Two things fall out of it. The round trip at 250 TB costs more than twice the 100 TB run, so the volumetric estimate is not a rounding detail, it is the budget. And the 20 TB rebalance has the worst unit rate of anything on the list, because it never leaves the first two tiers. Routing the same 250 TB over an interconnect takes the bill from $16,691 to $5,120, which is what “a fraction” means in practice.
Architectural mitigations that actually work
There are three lines worth pursuing before the next exit-test budget cycle:
- Dedicated interconnect from bare metal. AWS Direct Connect, Azure ExpressRoute, and GCP Cloud Interconnect all carry materially lower per-GB rates than internet-out. For an estate that already runs on bare metal under a unified virtualization layer, routing the exit-test path over interconnect is the simplest mitigation. It does not make the bill zero; it makes it a fraction.
- Tiered data retention with explicit lifecycle policies. An estate that does not aggressively tier and expire recordings, session logs, and stale profile data is paying egress on data that nobody intended to keep. Cleanup pays back twice: lower storage cost ongoing, lower egress cost on the way out.
- Image and profile boundaries that match the exit scenario. Keep the things that have to leave separable from the things that do not. If golden images and profile containers live in the same storage account as analytics and telemetry, the exit-test runbook becomes much larger than it needs to be.
The documentation line items DORA actually cares about
An exit plan that does not name the egress line is not an exit plan. The artefact an auditor expects to see contains, at minimum:
- A volumetric estimate of the data that has to physically move, broken down by category (profile, image, recording, telemetry).
- The egress tariff that applies, with the source page URL and the date checked.
- The mitigation path (interconnect, switching-credit application, or paid egress), with the assumed cost.
- The runbook for the exit test, including the egress cost line in the test budget.
- Evidence of at least one test execution within the regulator’s expected cadence.
Most exit plans I have seen contain the first item and skip directly to the fourth. The middle two are the ones a competent regulator will ask about, and the ones that fail under questioning.
The Bottom Line
Egress is the second lock-in, and most of it survives the EU Data Act.
From 12 January 2027, a one-way permanent exit is free by law, and until then it runs on a switching credit with full process compliance. Neither covers the round-trip you actually have to perform under DORA, the parallel run any honest migration requires, or the partial rebalance that is the most common live scenario.
For an EUC estate, the bill is dominated by data nobody put on the migration spreadsheet: FSLogix profile containers, layered images, session recordings, and the snapshot chains under them. A 5,000-seat estate is comfortably in the 100 to 250 TB range for an exit test. At standard egress, that is a budget line, not a footnote.
The mitigations are known: bare-metal interconnect to drive the per-GB rate down, lifecycle policies to keep the dataset honest, and storage layout that separates the things that must leave from the things that do not. None of them are technical breakthroughs. All of them are deliberate design decisions that an organisation either makes early or pays for later.
An exit plan that does not name the egress tariff, the volume estimate, and the mitigation path is documentation, not strategy. The next time the steering committee asks whether the exit is real, the answer is the egress number in the test budget.
If you have run an exit-test budget for an EUC estate, what landed on the egress line versus what the project plan estimated? Drop a comment below or find me on X at @kbaggerman.
Kees Baggerman
Latest posts by Kees Baggerman (see all)
- Cloud Desktop Density: Where the Maths Breaks Down - November 5, 2026
- Egress Is the Second Lock-In: Modeling the Real Cost of Leaving Your Cloud Provider - November 4, 2026
- Stop Renting Their VM Layer: The Case for Hybrid Multicloud Infrastructure - October 28, 2026
- The Cloud Desktop CPU Lottery, AMD Edition: Which Zen Are You Actually Running On? - October 23, 2026
- Citrix MCSIO on Nutanix AHV: A Solution to a Problem That Doesn’t Exist - June 10, 2026
