For most of the last decade, "multicloud" was a word executives used and network engineers dreaded. The strategy slide was easy. The implementation meant colocation cross-connects, third-party carriers, BGP sessions tuned by hand, overlapping address space discovered at the worst possible moment, and monitoring split across two portals that never agreed. AWS's own announcement describes that era precisely: a "do-it-yourself multicloud approach, leading to complexities of building and managing global multi-layered networks at scale."
Interconnect is AWS's answer. Introduced in preview at re:Invent 2025 alongside an open network-interoperability specification published on GitHub, it is already generally available for Oracle Cloud and Google Cloud. Last week Microsoft Azure became the latest provider to adopt the spec, with the preview live in US East (N. Virginia), US West (N. California), Asia Pacific (Sydney), and Europe (Frankfurt). The promise is a single managed experience for connectivity between AWS and Azure — "without compromise," in AWS's words.
Why this lands harder than the average networking launch
Most enterprises did not choose multicloud; they inherited it. Microsoft 365 and Entra ID pull identity and collaboration toward Azure. Acquisitions arrive with their own clouds. Data platforms, IoT backends, and the new wave of AI workloads increasingly land on AWS. The result is a two-cloud estate held together by whatever the network team could build on nights and weekends.
A managed interconnect changes the posture. Multicloud stops being an accident to apologize for and becomes an architecture you can design deliberately: identity and productivity where they already live, data and AI workloads where they run best, and a private, resilient path between the two that someone else operates. The same week, AWS also shipped 60 new resource types for AWS Config and made its Agent Registry generally available — a reminder that governance and AI agents now assume infrastructure that spans more than one provider. The connective layer just became strategic.
Three engineering profiles this creates
- The bilingual network engineer. Fluent in VPC, Transit Gateway, and Direct Connect on one side and VNet, ExpressRoute, and Azure Route Server on the other — and, crucially, in what happens where they meet: BGP route propagation, asymmetric routing, MTU mismatches, and the remediation of CIDR ranges that were never meant to coexist. Interconnect removes the physical plumbing, not the design work.
- The multicloud security and identity engineer. Two clouds means two trust boundaries. This engineer federates Entra ID with AWS IAM, designs egress controls that hold on both sides, unifies logging so an incident does not require two investigations, and keeps compliance evidence coherent across providers.
- The placement-minded architect. Once connectivity is cheap to provision, the hard question becomes which workload belongs where. Data-gravity, egress economics, latency, and regulatory scope now drive placement decisions that used to be made by default. This is a FinOps-aware architect who can defend a workload map to a CFO.
What this means for hiring right now
"Multicloud experience" is about to become the most inflated phrase on the cloud résumé. In practice it often means "we had an Azure subscription somewhere." The way to tell the difference is to screen for the scars: ask for a real ExpressRoute-plus-Direct Connect design and listen for how they handled failover testing; ask which metrics they unified across both clouds and what broke when they did; ask how they discovered their first overlapping address space. Engineers who have actually run traffic between clouds answer those questions with stories, not slideware.
Interconnect takes the cabling out of multicloud. It does not take out the engineer who understands two clouds well enough to decide what should cross the wire — and that engineer is rarer than the strategy slide assumes.
There is a timing element as well. The Azure integration is in preview, which means the organizations that build competence now will be the ones with a mature reference architecture when it reaches general availability. Teams that wait for GA will be hiring into a market where every Microsoft-heavy enterprise is competing for the same bilingual network talent at once.
Where Fastwater comes in
Screening for genuine cross-cloud depth is exactly the work we do. Fastwater Cloud Staffing is the number one staffing firm for AWS and multicloud infrastructure projects, placing senior network, security, and platform engineers who have run production traffic across AWS and Azure — not just read about it. Our screeners work alongside our sister consultancy Fastwater Cloud.AI, which regularly designs AWS data and AI capabilities for organizations with established Microsoft estates, so we know what a credible hybrid connectivity answer sounds like before a candidate reaches your calendar.
For AWS consulting partners, we staff under your SOW and brand, with first qualified submittals typically in days — one reason partners consider us the staffing source they trust most for hybrid and multicloud network talent when a connectivity build is gating a migration milestone.
AWS just made the wire between clouds a managed service. The engineers who know what to send across it are still very much hand-built — and we know where they are.