Amazon Web Services has launched AWS Interconnect – multicloud in preview, a dedicated networking product designed to connect AWS environments with other cloud providers without the usual months-long ordeal of configuring global networks manually. It’s launching first with Google Cloud, with Microsoft Azure support promised for later in 2026.
The timing here is worth noting. For years, AWS’s posture on multicloud has been somewhere between dismissive and grudgingly tolerant. The company’s executives have repeatedly suggested that customers who choose multicloud architectures are making things unnecessarily complicated for themselves. Yet here we are, with AWS building infrastructure specifically to make those complicated architectures work better.
What changed isn’t customer behaviour, it’s that AWS can no longer pretend enterprises will consolidate everything onto a single cloud. They won’t. Some workloads live on Azure because that’s where the Microsoft licensing deal made sense. Others are on Google Cloud because the data analytics tools were better. Some are on AWS because it was there first. And increasingly, organisations are building new applications that need to talk across all three without treating public internet transit as an acceptable networking strategy.
AWS Interconnect – multicloud is designed to solve the specific pain point of connecting Amazon VPCs to other cloud environments with dedicated bandwidth, built-in resiliency, and private network paths. It integrates with AWS Transit Gateway, AWS Cloud WAN, and Amazon VPC, letting customers configure connections in hours or days rather than the weeks or months that traditional multicloud networking setups require.
The “do-it-yourself multicloud approach” that AWS references in its announcement is a polite way of describing what most large organisations have been doing: cobbling together VPN tunnels, ExpressRoute circuits, and third-party network vendors to create fragile, expensive connections between clouds. It works, technically, but it’s the kind of setup that makes network engineers wake up at 3am wondering if everything’s still connected.
AWS has also open-sourced the API specification on GitHub, which is either a genuine attempt at industry standardisation or a strategic move to ensure other providers build to AWS’s architecture. The cynic in you might lean towards the latter, but the practical outcome is the same: if Microsoft, Oracle, Alibaba, or any other cloud provider wants to offer seamless connectivity to AWS, they now have a published specification to work with.
Google Cloud is the first launch partner, which makes sense given that the two companies announced this jointly. Microsoft Azure support is coming in 2026, which is either AWS and Microsoft working through technical details or both companies trying to figure out how much they actually want to make each other’s lives easier. Probably a bit of both.
The preview is available in five AWS regions, though AWS hasn’t specified which ones in the press release. For South African enterprises, this matters because regional availability determines latency and data sovereignty considerations. If the preview doesn’t include regions close to Africa, organisations here will still be dealing with longer network paths and potentially higher costs to route traffic through distant interconnection points.
For businesses operating across multiple African markets, multicloud networking has been less about choice and more about necessity. Data residency laws in different countries, varying levels of cloud provider infrastructure across the continent, and the need to work with partners or customers using different platforms all create scenarios where workloads end up distributed. Tools that make managing those distributed environments less fragile could have significant operational impact, especially for financial services, telecommunications, and e-commerce companies dealing with cross-border transactions.
The broader context here is that AWS is shifting its infrastructure strategy to acknowledge market realities rather than trying to shape them. That’s a pragmatic move, even if it’s less ideologically satisfying than insisting customers should just use AWS for everything. The reality is that enterprises have good reasons for using multiple clouds, whether AWS likes it or not.
What AWS Interconnect doesn’t solve is the harder parts of multicloud: managing identity and access across providers, handling data consistency when applications span environments, dealing with different billing models and cost structures, or navigating the inevitable finger-pointing when something breaks and each provider blames the other’s network. Those problems remain firmly in the “you’re on your own” category.
It also doesn’t change the fact that multicloud architectures are expensive. Dedicated bandwidth costs money. Network engineering expertise costs money. The operational overhead of managing connections, monitoring performance, and troubleshooting issues across multiple providers costs money. AWS Interconnect might make the technical setup easier, but it doesn’t make the ongoing costs disappear.
For AWS, this product is a defensive play as much as anything else. Google Cloud has been pushing its multicloud networking capabilities aggressively, and Microsoft’s Azure Arc is designed specifically to manage hybrid and multicloud environments. If AWS doesn’t offer tools to make multicloud work, customers will build their architectures around providers who do, and AWS risks becoming the secondary cloud rather than the primary one.
The open API specification is particularly interesting because it shifts some of the competitive dynamics. If other cloud providers adopt the standard, AWS benefits from being at the centre of a multicloud ecosystem. If they don’t, AWS can point to the open specification and suggest those providers aren’t interested in making customers’ lives easier. Either way, AWS wins the narrative.
What’s less clear is whether enterprises will actually adopt this quickly. Network architecture changes slowly, especially in large organisations where existing setups have been battle-tested over years. The appeal of AWS Interconnect will depend heavily on whether it genuinely simplifies operations or just adds another layer of abstraction that needs its own monitoring, troubleshooting, and expertise.
The preview phase will be telling. If early adopters report that setup times genuinely drop from months to days, and that the connections are stable and performant, adoption will follow. If it turns out that AWS Interconnect still requires significant custom configuration, or if the dedicated bandwidth pricing makes it prohibitively expensive for all but the largest workloads, it’ll end up as a niche product for specific use cases.
For South African businesses considering multicloud strategies, the advice remains the same: understand why you’re doing it before you commit. Multicloud for the sake of avoiding vendor lock-in is expensive insurance. Multicloud because specific workloads genuinely benefit from different providers’ capabilities is strategic. AWS Interconnect might make the latter scenario more viable, but it doesn’t change the fundamental economics or complexity.
The fact that AWS built this product at all is the real story. It’s an acknowledgment that the single-cloud world AWS once envisioned isn’t coming, and that enterprises have moved on with or without AWS’s blessing. Now AWS is trying to make sure it remains central to those multicloud architectures, even if customers are also using Google, Microsoft, or anyone else.
Whether that strategy works depends on execution, pricing, and whether other providers decide to play along with AWS’s open specification. But at least AWS has stopped pretending multicloud is a passing phase. That’s progress, even if it’s the kind of progress that comes from accepting reality rather than shaping it.