AWS Interconnect multicloud in 2026: how a Singapore edge turns $9,000 a month into $37,799

Summary. AWS Interconnect - multicloud reached general availability on 14 April 2026, with Google Cloud as the first launch partner and Microsoft Azure and Oracle Cloud Infrastructure due later in 2026. It gives you a private, dedicated-bandwidth link between an Amazon VPC and another cloud, available in five AWS Regions, with no per-gigabyte data transfer charges. A 10 Gbps interconnect at Tier 1 costs $12.33 an hour, which AWS's own example works out to $9,000.90 a month over 730 hours. The number that should stop you: attach that same interconnect to a Cloud WAN Core Network that happens to include a Core Network Edge in Singapore and AWS assigns it Tier 4 long-haul pricing at $51.78 an hour, or $37,799.40 a month. That is 4.2x the bill, a $28,798.50 monthly swing, and it is triggered by your topology rather than by any traffic actually crossing the Pacific.

What AWS shipped

AWS announced general availability on 14 April 2026. Google Cloud is the first launch partner; Azure and OCI are stated as coming later in 2026.

The problem it addresses is real. Connecting workloads across two clouds previously meant a do-it-yourself build: your own routers in a colocation facility, cross-connects to both providers, BGP on both sides, and the ongoing job of operating a multi-layered global network. AWS describes Interconnect - multicloud as the first purpose-built product of its kind, and the pitch is that you can stand up private, secure, high-speed connectivity with dedicated bandwidth and built-in resiliency in minutes rather than the weeks or months a DIY build takes.

It composes with the networking services you already run. Attach a Direct Connect Gateway and you can use Virtual Private Gateways, Transit Gateways and Cloud WAN, which is how you scale one interconnect across many VPCs and Regions. You can drive it from the console, CLI or API, and other cloud providers can adopt it through a published open API package on GitHub.

There is also a genuine free tier: one Free Tier Interconnect at 500 Mbps per cloud service provider, per Region. For a control-plane link, a management path, or a proof of concept, that is enough to get real work done at zero cost.

How the pricing actually works

The model is refreshingly simple on the surface and has one sharp edge underneath.

You are charged hourly per interconnect, based on selected bandwidth and an automatically assigned pricing tier. Billing starts when you create the interconnect and stops when you delete it, in one-hour increments rounded up. There are no per-gigabyte data transfer charges, which is the headline improvement over egress-metered alternatives and the reason this changes the arithmetic for chatty cross-cloud workloads.

The tier is where it gets interesting. There are five tiers, Tier 1 cheapest and Tier 5 most expensive. Your tier is computed from where your VPC traffic originates, the source AWS Regions, relative to the interconnect's local AWS Region. Greater geographic path distance means a higher tier. Each interconnect gets a single tier based on the highest-tier path it uses, and higher tiers include all the connectivity paths of lower tiers.

Read that once more: the highest-tier path it uses. Not the average. Not the busiest. The highest.

Those are AWS's own worked examples, not our modelling. The interconnect is physically identical in both rows. Same endpoints, same bandwidth, same Region. The only difference is what the Direct Connect Gateway is associated with.

The Cloud WAN trap

This is the part worth the read, and AWS documents it plainly enough that nobody should be surprised, yet it is exactly the shape of thing that surprises people.

Cloud WAN is a global service spanning multiple AWS Regions through Core Network Edges. When your interconnect's Direct Connect Gateway is associated with a Cloud WAN Core Network, any CNE in that Core Network can send traffic through the interconnect. Because any of them can, AWS prices as though they will.

In AWS's example, an interconnect whose local Region is us-east-1, attached to a DXGW associated with a Core Network that has CNEs in us-east-1 and ap-southeast-1, is assigned Tier 4, not Tier 1. AWS's wording is that your tier is determined by the highest tier CNE in your topology, not the CNE in the interconnect's local AWS Region.

So the cost driver is reachability, not traffic. You do not need to send a single packet from Singapore. You need only to have a Singapore edge in the Core Network the interconnect is attached to. The bill goes from $9,000.90 to $37,799.40 a month, a difference of $28,798.50 a month or roughly $345,582 a year, for a topology change that looks like housekeeping in a pull request.

AWS's own guidance is the tell: it says Cloud WAN users should carefully review their network topology before attaching interconnects. That sentence is doing a lot of work.

The mitigation is architectural, not contractual. If you have a global Cloud WAN Core Network and a regional interconnect need, do not associate the interconnect's DXGW with the global core. Attach it through a Transit Gateway or a Virtual Private Gateway scoped to the Region, or segment your Core Network so the interconnect lives in a core whose CNEs are all local. Decide this before you build, because unwinding a Core Network association after the fact is the kind of change that needs a maintenance window.

Versus the DIY build

The comparison that matters is not Interconnect versus nothing. It is Interconnect versus the colocation build most multicloud shops already run.

Two honest caveats on that table.

First, $9,000.90 a month for 10 Gbps is not cheap in absolute terms. A DIY build at steady state and real scale can beat it on unit cost, which is exactly why large networks were built that way. What you are buying is the removal of a function, not a discount. If you already run a network team and a colo presence, do the sums properly rather than assuming the managed option wins.

Second, and this catches finance teams: AWS bills only its side. The other cloud service provider sets and charges its own prices for its half of the infrastructure, independently. AWS says so explicitly and tells you to review the other CSP's pricing before creating your interconnect. Your $9,000.90 is not the all-in number. Google Cloud will invoice you separately, and any model that omits that is wrong by construction.

The DIY column's real advantage is that its long-haul costs are explicit. You bought a circuit to Singapore or you did not. With Interconnect, long-haul exposure arrives through a topology attribute, which is cheaper to acquire and much easier to acquire accidentally.

Where this genuinely wins

The no-per-GB-charge model is the structural change, and it points at a specific workload: high-volume, chatty, cross-cloud traffic. Data pipelines that land in one cloud and process in another. Inference that lives next to a model in one cloud and a feature store in the other. Anything where egress metering has been quietly setting your architecture for you. We have written about how badly egress fees distort AI inference bills; a flat hourly link with unmetered bytes removes that distortion inside the link.

At 10 Gbps and Tier 1, $9,000.90 a month buys up to about 3.2 petabytes of transfer if you saturated it for the month. Per-gigabyte egress pricing at that volume is not close. The break-even is far lower than saturation, which is the point.

It also wins where the DIY build never made sense: a five-Region availability footprint you do not want to staff, or a proof of concept that needs to be real. Start on the free 500 Mbps interconnect per CSP per Region, prove the pattern, then buy bandwidth once the workload justifies it.

Where it does not win: low-volume, latency-tolerant, occasional transfer. The hourly charge runs whether you use the link or not. Billing starts at creation and stops at deletion, so an idle interconnect is pure cost. For a nightly batch, the public internet or metered egress is probably still right.

What to do before you create one

Four things, in order.

Check your Cloud WAN topology first, before you attach anything. Enumerate the CNEs in the Core Network you are about to associate. The furthest one sets your tier and therefore your bill. This is the single highest-use five minutes in the whole exercise.

Confirm the other cloud's charges. Get Google Cloud's number for its side of the link and add it to yours. Present one figure to finance, not AWS's half.

Start on the free tier. One 500 Mbps interconnect per CSP per Region costs nothing and will tell you more about your actual requirement than a capacity plan will.

Model against idle, not peak. The charge is hourly from creation to deletion regardless of bytes. If the workload is bursty, the interconnect is a subscription, and the relevant comparison is subscription versus metered egress, not peak-rate versus peak-rate. Our FinOps comparison across AWS, Azure and GCP covers how to frame that trade for Indian teams.

The engineering judgement, plainly: this is a good product with one pricing edge sharp enough to cut. The edge is that cost follows topology rather than traffic. Design for that and it is excellent. Ignore it and you will explain a 4.2x variance to someone who does not want to hear about Core Network Edges.

India-specific considerations

Interconnect - multicloud is available in five AWS Regions at GA, and AWS has not published that list on the What's New announcement, so Indian teams should confirm Mumbai (ap-south-1) or Hyderabad (ap-south-2) availability with their account team before planning around it rather than assuming.

The tier mechanic deserves particular attention from Indian platform teams, because the topologies here are frequently long-haul by default. A Core Network with edges in Mumbai and a US or European Region is a normal shape for an Indian company serving global customers. Under this pricing, that normal shape is precisely what pushes an otherwise-local interconnect into a high tier. AWS's Singapore example is not exotic; it is the Asian equivalent of a topology many teams in Gurugram and Bengaluru already run.

The practical advice is the same as everywhere, with more urgency: segment the Core Network, keep the interconnect's association local, and do not let a global core and a regional link share a DXGW.

FAQ

How eCorpIT can help

eCorpIT is a CMMI Level 5 certified, MSME-registered technology organisation in Gurugram, founded in 2021, and an AWS and Google partner. Our senior engineering teams review multicloud network designs before they are built: mapping Cloud WAN topologies against interconnect tier assignment, modelling the hourly-plus-remote-CSP cost properly, and finding the segmentation that keeps a regional link on regional pricing. If you are planning AWS to Google Cloud connectivity and want the tier maths done against your actual Core Network before you sign, talk to our cloud team.

References

1. AWS announces general availability of AWS Interconnect - multicloud - AWS What's New, 14 April 2026.

1. AWS Interconnect - multicloud pricing - Amazon Web Services, rates and worked examples retrieved 17 July 2026.

1. AWS Interconnect documentation - AWS.

1. AWS Interconnect open API package - GitHub.

1. AWS Direct Connect gateways - AWS documentation.

1. AWS Cloud WAN - Amazon Web Services.

1. AWS Transit Gateway - Amazon Web Services.

1. AWS finally moves to simplify multicloud operations with Google - Network World.

1. AWS, Google link up to ease multicloud deployments - CIO Dive.

1. AWS, Google Cloud Unveil New Multicloud Service - TechRepublic.

1. Google Cloud Next 2026 wrap up - Google Cloud Blog.

1. Amazon S3 pricing - Amazon Web Services, for comparison of metered data charges.

Last updated: 17 July 2026.