practice

Switching Egress Waiver

also called Exit Transfer Credit, Egress Waiver on Exit

The provider programme that removes data-transfer-out charges for a customer leaving the platform, which deletes the headline number in most exit business cases and leaves engineering time and dual-running as the real cost of moving.

egressprocurementlock-inmigrationsustainability

A finance director is handed a migration plan with a $73000 line for moving 900 TB out of a cloud at list egress rates and refuses to approve it. The number is doing more work than it deserves: it is a one-off, it is roughly a fifth of what three months of dual-running the two platforms will cost, and since 2024 it is largely waivable.

Both of the largest providers now waive data-transfer-out charges for customers migrating off. Google Cloud announced it on 11 January 2024 and AWS followed on 5 March 2024, both driven by the switching provisions of the EU Data Act and both applied to customers globally. As reported at launch, each requires a request and provider approval, each gives 60 days after approval to complete the exit, Google's applied to customers moving their entire workload to another provider or on-premises, and AWS issued credits for the migrated data without requiring the account to be closed. Terms change, so the current ones are a procurement question before they are an architecture one.

Why it matters

Egress pricing has been the most cited form of cloud lock-in for a decade, and for a one-time exit it has largely stopped being a cost. That changes two conversations. The business case for leaving is now dominated by engineering months and dual-run overlap, which are the terms a technical team can actually estimate and reduce. And the negotiating position at renewal improves, because the cost of the threat to leave fell.

What did not change is everything that is not an exit: cross-region and cross-zone transfer inside a provider, delivery to end users through a CDN, and the steady-state traffic of a multi-cloud architecture. Those remain priced as before and remain the lines that shape architecture.

Implementation patterns

  • Shrink the payload first. Expire noncurrent versions, drop derived data the target can recompute, and compact small objects. A 900 TB estate is frequently 600 TB of data and 300 TB of history nobody would pay to move.
  • Request the waiver only when bulk movement is ready, because approval starts a 60-day window that should cover copying and nothing else.
  • Keep the exit claimable. Open formats, provider-neutral interfaces and continuous exports are what make a 60-day window realistic at all.
  • Model the dual-run overlap explicitly, because it is the number the waiver does not touch.

Industry example

The policy change itself is the case study. The European Data Act's switching provisions set an expectation that providers must not charge for the transfer involved in leaving, and the two largest providers moved within two months of each other in early 2024, ahead of the regulation's application dates. The lesson for architects is that a cost line treated as a law of physics was a commercial policy, and commercial policy responds to regulation faster than architecture responds to anything. The same reasoning applies to other "unavoidable" line items: ask who sets them and what would make them change.

Failure scenarios

  • Requesting the waiver too early, then spending 40 of the 60 days building the target environment.
  • Assuming it covers hybrid traffic, and discovering that an ongoing multi-cloud data flow is billed at full rate forever.
  • Planning around reported terms rather than the agreement in force, which may require full termination or exclude particular services.
  • Treating transfer as the project's cost and under-funding the dual-run period, which is where these migrations actually fail: three months of overlap on a $120000-a-month platform is $360000, about five times the transfer bill it replaced.

Trade-offs

The waiver removes a cost and adds a constraint: a fixed window, an approval, and in at least one provider's case an expectation that you are genuinely leaving. A migration that wants to proceed slowly, service by service over a year, may be better served by paying list egress and keeping its own schedule. Speed is the price of free transfer.

When not to use it

Do not build a migration around it if you intend to stay multi-cloud, since steady-state transfer is not covered and the waiver is for exits. And where exit cost is dominated by rewriting against proprietary services rather than by moving bytes, the waiver changes nothing that matters.

Interview question

Q: Your CTO wants to leave your cloud provider and asks what it will cost. The data is 900 TB. Give me the cost structure and the sequence, and tell me which number you would actually argue about.

What a strong answer covers: transfer as the smallest term, waivable since 2024 subject to request, approval and a 60-day window; payload reduction before any request; a paid rehearsal; the point of no return at write cutover and what rollback costs after it; and the dual-run overlap plus engineering months as the numbers that decide whether the project is affordable.

Quick check

Quiz: What does the 2024 switching waiver cover, and what does it not? Data transfer out for a one-time exit, on request and within about 60 days of approval. Not cross-region or cross-zone transfer, not CDN delivery, not ongoing multi-cloud traffic, and not dual-running.

Flashcard: Since 2024 what is the largest cost of leaving a cloud provider? — Engineering months and the dual-run overlap where both platforms are paid at once, because the transfer charge is waivable for a genuine exit.