Egress as an Architecture Constraint: Data Act 2027 (2026)

Q: What exactly does the EU Data Act do to cloud egress fees, and when?

The Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025. Its switching provisions require providers of data-processing services to remove obstacles to customers switching provider or moving on-premises, and, per the European Commission's own explainer, to entirely remove switching charges, including charges for data egress, from 12 January 2027. During the transition providers may charge reduced fees limited to the costs incurred. The important architectural point is scope: the rule covers data egress performed as part of a switch. It does not regulate the day-to-day egress a running system produces between availability zones, between regions, to the internet or to another provider while you remain a customer. The steady-state bill is untouched, and that is where most of the money is.

Q: Did AWS, Google Cloud and Azure already make egress free for customers who leave?

Yes, for exit specifically, and with conditions. Google Cloud announced on 12 January 2024 that customers stopping use of Google Cloud and migrating to another provider or on-premises can take advantage of free network data transfer to move their data out. AWS announced on 5 March 2024 that customers moving off AWS can contact Support to request free data transfer out, reviewed at the account level and provided as credits; it also noted that 100 GB per month to the internet is already free. Azure's bandwidth pricing page states that Azure offers free egress for customers leaving Azure when taking their data out via the internet to switch to another provider or an on-premises data centre. All three are framed around a customer who is leaving. None of them make recurring egress from a hybrid or multi-cloud steady state free, and you should read the current terms of the programme you intend to rely on before counting it in a business case.

Q: Which boundary usually dominates the network line on a cloud bill: internet egress, cross-AZ or NAT?

In the cost reviews we run, cross-availability-zone traffic and NAT gateway data processing dominate far more often than internet egress, even though internet egress is the headline rate on every pricing page. The reason is structural. A resilience decision to spread a service across three zones produces a metered flow on every internal hop, permanently, and no architecture diagram shows it. A NAT gateway placed so private subnets can reach the internet also ends up carrying pipeline traffic to storage and queue services in the same region, and charges a per-gigabyte processing fee on all of it. Internet egress, by contrast, is visible, usually already routed through a CDN, and rarely a surprise. Attribute the data-transfer SKUs in your billing export by boundary before you optimise anything; most teams discover the bill is inside the region, not leaving it.

Q: How should an architect think about egress differently from a FinOps team?

A FinOps team sees egress as a line to attribute, forecast and negotiate after the fact. An architect should see it as a constraint that is set at design time by placement decisions: how many zones a service spans, where the database sits relative to the code that reads it, how replicas fan out across regions, whether downloads leave from compute or from a CDN or egress-free store, and whether a managed appliance sits in a data path. The practical mechanism is an egress budget on the service definition, expressed as bytes per request or per job across each boundary, owned by the same team that owns the latency SLO, and reviewed when the topology changes. The FinOps report then confirms that the design held; it is not the control. This is the same shift from reporting to routing that per-service cost visibility in a developer portal makes for compute spend.

Q: When does copying data to an egress-free object store such as Cloudflare R2 actually pay?

When the dataset is written rarely and read often. An egress-free tier removes the per-gigabyte charge on every download, but the copy itself is a replication flow out of the origin cloud that is metered at the origin's rates, and a second copy is a second consistency boundary, a second access-control model and a second place secrets can leak. For a media library or a model-weights bucket that is written once and downloaded thousands of times, the copy pays for itself quickly. For a dataset that is rewritten continuously and read occasionally, the replication egress out of the origin exceeds the download egress it saves, and the extra operational complexity buys nothing. Make the read-to-write ratio a documented input to the decision and revisit it when the access pattern changes. R2 charges $0.015 per GB-month for standard storage with no egress fee as of its pricing page dated August 2026.

Q: Is a NAT gateway in a data path always a mistake?

No. A NAT gateway exists so that instances in private subnets can reach the internet without public addresses, and that is a legitimate job. The mistake is letting it also carry high-volume traffic to managed services in the same provider and region, because the gateway bills a data-processing charge per gigabyte on top of standard transfer. Gateway endpoints and private endpoints route traffic to storage, queue and database services privately and remove that charge for the flows that matter. The exception is inspection: if your threat model or a regulator requires that a flow pass through a firewall or an inspection point, the per-gigabyte fee is the cost of a control rather than waste, and removing it to save money is a security regression. Decide per flow, document which flows are inspected on purpose, and remove the appliance from the rest.

Q: Does the Data Act make cloud repatriation or multi-cloud automatically cheaper?

It makes the one-time exit cheaper for customers in scope, which removes an excuse rather than creating a case. Repatriation and multi-cloud decisions were rarely won or lost on the exit fee alone; they turn on steady-state operating cost, latency, team capacity and the capability gap you are trying to close. With exit egress waived by the providers since 2024 and abolished by regulation from January 2027, the honest model drops the exit term to near zero and then has to justify the move on the harder ground. Multi-cloud in particular gets no help: a database in one provider and an application in another produces inter-provider egress on every query, forever, and nobody is switching, so the switching rules do not apply. The Data Act changes the price of leaving. It does not repeal data gravity.

Q: What are the first concrete steps to reduce egress spend without an architecture rewrite?

Four, in order. First, attribute: split the data-transfer SKUs in the billing export by boundary and by service so you know whether the money is cross-AZ, NAT processing, inter-region or internet. Second, put private or gateway endpoints in front of storage, queue and database services so pipeline traffic stops flowing through NAT gateways. Third, move any file or media download off compute instances and behind a CDN or an egress-free store. Fourth, enable zone-affine or topology-aware routing for the three chattiest internal services so their frequent path stays inside a zone and cross-zone traffic is reserved for failover. None of these change the application. Together they typically remove a double-digit percentage of the network line and, more importantly, produce the per-boundary numbers you need to run the placement decision tree for everything else.

Q: How do egress considerations interact with data residency and sovereignty requirements?

They point the same way but for different reasons. Residency rules fix where data may live; egress economics reward putting compute where data lives. When both apply, the correct design is to move compute into the jurisdiction rather than to move data out of it on every request, which satisfies the regulator and minimises the transfer bill at the same time. The tension appears when the compute cannot follow, for example when a GPU class or a managed service is not available in the required region. In that case the transfer cost is the price of compliance, and the architecture should state that explicitly and budget for it rather than assume it will be optimised away. For EU workloads the Data Act's switching provisions sit beside NIS2 resilience obligations; for Indian regulated entities the constraint is localisation rather than switching cost. In all cases the durable question is where data lives and how often it moves.