The Egress Tax That Defined a Decade of Cloud Lock-In
For the better part of a decade, cloud egress fees — charges for transferring data out of a cloud provider’s network — functioned as an invisible but powerful lock-in mechanism. Moving 100 TB of data from AWS to Google Cloud in 2024 cost approximately $9,000 in data transfer fees at standard rates. Running a hybrid architecture that required regular cross-cloud data synchronization could add $50,000-500,000 annually to cloud bills for mid-size enterprises. These fees were not accidental: they were a structural feature of the business model, transforming data gravity (the tendency for applications to colocate near their data) into financial inertia (the tendency for enterprises to stay where they started because moving is expensive).
The economics created predictable enterprise behaviors. Architects chose their primary cloud provider early, built applications using that provider’s proprietary managed services, and found that every service they adopted deepened the integration — and the financial exit cost. Multicloud in practice often meant “one hyperscaler for everything except a few workloads on the secondary for regulatory or risk reasons,” not the genuine workload portability that multicloud advocates described.
AWS Interconnect — multicloud’s general availability on April 14, 2026, with its single-fee flat-rate bandwidth model, directly attacks this structure. The service provides Layer 3 private connections between AWS VPCs and other cloud providers — starting with Google Cloud, with Microsoft Azure and Oracle Cloud Infrastructure (OCI) coming later in 2026. The pricing innovation: no per-gigabyte data transfer charges. Instead, customers pay an hourly fee based on selected bandwidth. Within that bandwidth allocation, data transfer between clouds is unlimited.
What the Pricing Model Actually Changes
The shift from per-gigabyte to flat-rate bandwidth pricing is not merely an accounting change — it is a behavioral incentive redesign at the infrastructure layer.
Under the old model, every architectural decision that moved data across cloud boundaries had a dollar cost attached. Architects learned to minimize cross-cloud data movement: replicate data unnecessarily, maintain redundant copies on multiple providers, accept latency penalties rather than pay transfer fees. These workarounds consumed engineering time and introduced data consistency risks.
Under the flat-rate model, cross-cloud data movement within contracted bandwidth becomes effectively free at the margin. An enterprise paying for a 500 Mbps interconnect can move as much data as that pipe allows without per-gigabyte charges. At 500 Mbps continuous utilization, that represents approximately 5.4 TB per day — enough for most enterprise cross-cloud synchronization workloads — for a single fixed hourly fee.
The complementary AWS FinOps improvements announced alongside Interconnect GA reinforce the transparency theme. S3 server access logs now include source AWS Region data, enabling teams to detect cross-region access patterns that drive egress costs. S3 Files eliminates the need for separate object and file storage by caching hot data, reducing egress tied to duplicate datasets. Natural language cost analysis via Amazon Q democratizes cost visibility across non-technical stakeholders.
Separately, AWS also announced that AWS Direct Connect now offers one complimentary local 500 Mbps interconnect per Region starting May 2026 — directly reducing the cost of entry for smaller enterprises exploring multicloud connectivity.
Advertisement
The Data Gravity Problem the Flat Rate Doesn’t Fully Solve
The enthusiastic reception of AWS Interconnect’s flat-rate pricing deserves a counterpoint: changing the pricing model for network transport does not automatically solve the data gravity problem. Data gravity is fundamentally an architectural phenomenon — applications become coupled to data stores, and moving data without moving the application creates latency penalties.
A manufacturing company with its ERP on AWS and its ML training pipeline on Google Cloud can now synchronize training data between clouds without per-GB fees. But if the ERP application makes hundreds of database calls per second to an RDS instance in us-east-1, the application cannot simply be “moved” to Google Cloud to co-locate with the ML pipeline without significant refactoring. The egress fee was one lock-in mechanism; the application architecture coupling is another, and it survives the pricing change.
The genuinely important shift is at the margin: for workloads that are already container-native and cloud-agnostic (microservices on Kubernetes, stateless APIs, analytics pipelines), flat-rate cross-cloud connectivity makes genuine multicloud deployment economically viable for the first time. For legacy monolithic applications deeply integrated with AWS proprietary services (DynamoDB, SageMaker, Lambda), the architectural coupling remains the primary constraint, and the pricing change is secondary.
Enterprise architects should not overinterpret the AWS announcement as “multicloud is now free.” It is more accurately: “the network transport tax on cloud-agnostic workloads has been eliminated.”
What Enterprise CTOs and Architects Should Do
1. Audit Your Current Egress Bill Before Redesigning Architecture
The first step is quantification, not redesign. Pull 90 days of AWS data transfer charges from Cost Explorer with service-level breakdowns. Identify the top three sources of cross-region and cross-provider egress by dollar value. For each source, determine whether the egress is: (a) cross-cloud (AWS to another provider — directly addressed by Interconnect), (b) cross-region within AWS (not addressed by Interconnect — separate pricing), or (c) egress to the public internet (addressed by separate AWS data transfer pricing changes). The audit typically reveals that 60-80% of egress cost is concentrated in 2-3 specific data transfer patterns, which are the correct targets for architectural remediation.
2. Evaluate Interconnect for Your Highest-Volume Cross-Cloud Flows First
AWS Interconnect GA supports Google Cloud connections now, with Azure and OCI “coming later in 2026.” If your multicloud architecture primarily involves AWS-Google Cloud data flows (common for enterprises using Google BigQuery for analytics with AWS as the operational cloud), the GA release is immediately actionable. Calculate your current monthly egress cost on that flow, model the Interconnect hourly fee at the bandwidth tier that matches your average throughput, and compare. For flows above approximately 1-2 TB per day, the flat-rate model is typically cheaper. For lower-volume flows, standard data transfer pricing may remain lower — the break-even varies by bandwidth tier and usage pattern.
3. Use This Moment to Establish a Multicloud Governance Framework
The reduction in economic friction for multicloud creates a governance risk that organizations should address proactively: without egress costs as an implicit constraint on cross-cloud proliferation, engineering teams may adopt additional cloud services more freely, creating hidden complexity, security boundary confusion, and uncontrolled sprawl. Before enabling Interconnect broadly, establish a multicloud governance framework: an approved set of workload patterns for each cloud provider, a cloud network topology that enforces security boundaries between environments, a shared tagging and cost attribution standard that works across providers, and a platform engineering team with ownership of the cross-cloud connectivity layer. The technical capability to move data freely between clouds should follow the governance capability to manage it — not precede it.
Where the Multicloud Market Goes Next
AWS Interconnect GA is one signal in a broader market restructuring. The EU Data Act (Article 23-29) mandates that cloud providers allow customer data portability and remove “obstacles to switching,” including excessive egress fees — with compliance deadlines in 2027. The EU’s regulatory pressure was clearly a factor in the direction cloud providers are moving on egress pricing, and it will accelerate further reduction of switching costs in the European market.
Google Cloud’s Partner Cross-Cloud Interconnect provides a corresponding mechanism from the Google side. Microsoft Azure has its own ExpressRoute connectivity options. The convergence of AWS, Google, and Microsoft toward flat-rate or reduced-fee cross-cloud connectivity signals that the industry recognizes the lock-in moat is becoming politically and commercially untenable.
For enterprise architects, the multicloud landscape in 2026-2027 will increasingly reward organizations that made the investment in cloud-agnostic architectural patterns early: containerization, infrastructure-as-code with multi-provider Terraform modules, standard database interfaces over proprietary managed services. Those organizations will be positioned to leverage reduced egress costs as a genuine capability. Organizations that deferred that investment will find that flat-rate connectivity alone does not deliver the promised multicloud flexibility — because their applications remain coupled to provider-specific services in ways that no pricing change can unwind.
Frequently Asked Questions
What exactly is AWS Interconnect — multicloud and how does its pricing work?
AWS Interconnect — multicloud is a Layer 3 private networking service that connects AWS VPCs (Virtual Private Clouds) directly to other cloud providers’ networks — starting with Google Cloud at GA on April 14, 2026, with Azure and OCI coming later in 2026. The key pricing innovation: instead of charging per gigabyte of transferred data (the standard egress model), AWS charges a flat hourly fee based on the bandwidth tier selected. Within the contracted bandwidth, customers can transfer unlimited data between clouds without additional per-GB charges. AWS also offers one complimentary local 500 Mbps interconnect per Region starting May 2026.
How significant is the egress cost problem for enterprises with multicloud architectures?
For enterprises with high-volume cross-cloud data flows, egress fees have historically added $50,000-500,000 annually to cloud costs, depending on data volumes and provider rates. Moving 100 TB from AWS to Google Cloud at standard AWS egress rates cost approximately $9,000 in 2024. These fees created strong financial incentives to keep all workloads on a single provider even when splitting workloads across providers would have been architecturally superior. The flat-rate Interconnect model eliminates this cost for AWS-Google Cloud flows, making genuine multicloud architectures economically viable for cloud-agnostic workloads for the first time.
Does AWS Interconnect eliminate cloud lock-in entirely?
No. AWS Interconnect removes the network transport cost as a lock-in mechanism, but the deeper lock-in — application coupling to proprietary managed services (DynamoDB, BigQuery, Azure Cosmos DB, SageMaker, Vertex AI) — remains. Applications built on provider-specific services require significant refactoring to move to another provider, regardless of network transfer costs. Genuine multicloud portability requires both flat-rate connectivity (now available via Interconnect) AND cloud-agnostic application architecture (Kubernetes, standard databases, IaC with multi-provider modules). Organizations that invested in cloud-agnostic design early will benefit most from the Interconnect pricing change; those deeply coupled to proprietary services will see limited practical benefit.
Sources & Further Reading
- AWS Announces General Availability of AWS Interconnect — Multicloud — AWS What’s New
- AWS Interconnect Reaches General Availability with Managed Multicloud Connectivity — InfoQ
- Could AWS’ Multi-Cloud Interconnect Spell the End of Egress Fees? — Fierce Network
- AWS Interconnect — Multicloud Pricing — aws.amazon.com
- 3 FinOps Trends to Look Out for in 2026 — TechTarget
- AWS Weekly Roundup: Claude Opus 4.7 in Bedrock, AWS Interconnect GA — AWS Blog
