Published: September 7, 2026 · Last updated: September 7, 2026 · Author: Softix
On August 31, 2026, AWS announced the public preview of AWS Interconnect – multicloud with Microsoft Azure. For US small and midsize businesses that already straddle AWS and Azure—because of identity, SaaS backends, acquisitions, or customer deployments—this is a managed private path between clouds, not a reason to “go multicloud” for branding.
Softix recommends Pilot–Prove–Prod. Use the preview to learn the provisioning and operations model. Prove latency, failure behavior, and ownership with one real workload. Promote only when preview limits, commercial terms, and your reliability bar line up—or wait for general availability if the job needs GA-grade certainty.
What AWS announced
AWS Interconnect – multicloud is described as a managed capability for private, high-speed connectivity between Amazon VPCs and other cloud providers. The product page lists Microsoft Azure in preview alongside Google Cloud and Oracle Cloud Infrastructure. Customers attach Interconnect to AWS networking constructs such as Transit Gateway, Cloud WAN, and VPC, using a Direct Connect gateway as the attach point described in the getting started guide.
The AWS What’s New post frames the problem Softix hears from dual-cloud teams: DIY multicloud networking meant stitching physical circuits, partners, and routing yourself. Interconnect aims to provision capacity from console, CLI, or API instead. AWS introduced the multicloud Interconnect concept in preview at re:Invent 2025 with an open interoperability specification; Azure adopting that path is the August 31, 2026 news.
The companion AWS networking blog describes a cloud-native create flow on both sides, private bandwidth without customer-managed physical cabling, MACsec between edge routers, and a multi-path resiliency design. Softix treats those as vendor architecture claims to verify in your pilot—not Softix-invented SLAs or guaranteed uptime for your product.
What “preview” means (quote the docs carefully)
Preview is not GA with a soft launch label. The AWS Interconnect getting started documentation states, for CSPs in Public Preview:
- Previews are limited to one Interconnect per customer per supported Region.
- The connection can be used at no cost for the duration of Preview.
- Bandwidth is limited to 1 Gbps with CSPs currently in Public Preview.
- As AWS approaches General Availability with a CSP, all Preview 1 Gbps connections will be removed from your account in preparation for launch, and during that period no Interconnects can be created to that CSP.
- Preview use is governed by the AWS Service Terms, including terms for Betas and Previews.
Those are the constraints Softix wants founders to read before attaching a revenue path. Separately, AWS documents a Free Tier for Generally Available CSPs (one free local 500 Mbps Interconnect per Region per GA provider on the AWS side). That Free Tier is not the same offer as the Azure preview 1 Gbps note above—confirm which flow you are in before budgeting.
Preview regions (from What’s New)
Per the August 31, 2026 What’s New announcement, Azure preview Interconnect is available in:
- US East (N. Virginia)
- US West (N. California)
- Asia Pacific (Sydney)
- Europe (Frankfurt)
If your workloads live outside those AWS Regions, either wait, redesign the attach Region (for example with Cloud WAN reachability as described in the docs), or keep your current DIY path.
Activation key flow (high level)
The getting started guide describes a create-from-AWS path: choose the other CSP (preview cards are tagged), pick source AWS Region and destination CSP region, name the interconnect, select bandwidth (1 Gbps in preview), attach a Direct Connect gateway, and supply your ID on the other CSP. AWS then requests creation and displays an activation key you complete on the other CSP’s side. For preview CSPs, AWS notes you might need the CLI to finish activation—follow current Azure Multicloud Interconnect instructions rather than assuming a polished portal every time.
You can also accept an Interconnect that started on the other CSP by pasting its activation key into the AWS console flow. Either way, treat activation as a two-sided change with two owners and a rollback plan.
Softix Pilot–Prove–Prod
1. Pilot: learn the path without betting the P&L
Pilot when you already have a real AWS↔Azure dependency: Entra ID or Microsoft 365 adjacent systems talking to AWS backends, a SaaS control plane on one cloud and data plane on the other, or an acquisition that left you dual-homed. Softix custom software development work often starts with that inventory—not with a greenfield “multicloud strategy.”
A good pilot workload is:
- Non-customer-facing or easily rolled back
- Sensitive enough to care about private paths (for example sync, admin APIs, or internal ETL)—but not your only payment or identity path
- Sized under the 1 Gbps preview cap with headroom for bursts you can measure
- Located in a supported preview Region pair
Write a one-page pilot charter: owners on AWS and Azure, CIDR conflict check, Direct Connect gateway choice, monitoring owner, success metrics, and the date you will tear the preview interconnect down if GA cutover forces it. Review IP overlap before you create anything—the docs explicitly call out address planning.
Do not pilot if you only have a public HTTPS integration that already meets latency and compliance needs, if you need bandwidth above 1 Gbps, if you need a contractual SLA Softix cannot invent from marketing copy, or if your team cannot staff two-cloud change windows.
2. Prove: measure the private path like a product dependency
Prove means evidence, not screenshots of a green console. Softix’s SLO and error-budget model for small SaaS teams applies here: define the user or system promise the interconnect supports, then measure it.
Minimum proof set:
| Proof item | What to capture |
|---|---|
| Provisioning | Time and steps from create to activation complete; who held the activation key |
| Throughput | Sustained and burst traffic vs 1 Gbps ceiling under your real payload mix |
| Latency / loss | Baseline vs prior VPN or internet path for the same job |
| Failure drills | What happens if one side deletes/accepts wrongly, or a path is disrupted—document observed behavior without claiming a Softix SLA |
| Security boundary | Encryption expectations (vendor materials describe MACsec between edge routers), IAM ownership, and who can create/accept interconnects |
| Cost | AWS says preview use is at no cost for the preview duration; confirm Azure-side charges and any related gateway costs independently |
| Exit | Steps to remove the preview interconnect and how you will rebuild after GA (docs say preview 1 Gbps links are removed approaching launch) |
Keep logs and a short incident tabletop. If you run Kubernetes on either side, remember that cloud interconnect is not a substitute for clear traffic ownership inside the cluster—see Softix’s Gateway API migration guidance for route-level discipline after the pipe exists.
3. Prod: promote only when preview limits match the job—or wait for GA
Prod-ready, for Softix, means:
- The workload fits 1 Gbps, one interconnect per customer per Region, and the preview Region list.
- You accept preview terms (Betas and Previews) and the documented risk that preview connections are removed before GA.
- Ownership, monitoring, and rollback are named people—not a shared Slack channel.
- You have a GA re-provision plan on the calendar.
If any of those fail, the honest Prod decision is wait for GA while keeping VPN, Direct Connect + ExpressRoute, or partner interconnect for the critical path. Managed convenience is valuable; preview churn on a revenue path is not.
For SaaS products that sell into customer AWS and Azure tenancies, Prod also means documenting which cloud pairings you support and what customers must supply (IDs, regions, change windows)—not promising “any region, any bandwidth” during Azure preview.
How this differs from DIY VPN / Direct Connect + ExpressRoute
| Approach | Typical SMB reality | Softix take |
|---|---|---|
| Site-to-site VPN over internet | Fast to stand up; shared internet path; ops know IPsec well | Fine for many admin and low-sensitivity sync jobs; measure jitter and failure modes |
| DIY Direct Connect + ExpressRoute (or partner fabrics) | Private capacity; weeks/months of physical and partner coordination; more moving parts | Still valid when you need GA maturity, custom topologies, or regions/bandwidth outside preview |
| AWS Interconnect – multicloud (Azure preview) | Managed private path; console/CLI create; activation key; 1 Gbps, one per customer per Region, preview terms | Best as a Pilot–Prove tool for dual-cloud SMBs in listed regions—not an automatic replacement for every circuit |
The product page’s three-step story—choose CSP, choose destination region, pick bandwidth—is the operational win: less physical provisioning theater. It does not remove routing design, overlapping CIDRs, identity, or application timeouts. Softix will still ask which system owns DNS, certificates, and authorization after packets can cross.
When to pilot vs wait for GA
Pilot now if: you already cross AWS and Azure daily; a supported Region pair matches; 1 Gbps is enough; you can run a non-critical path; and you will staff the GA cutover when preview links are removed.
Wait for GA if: you need multi-interconnect density per Region, higher bandwidth, contractual clarity beyond preview terms, regions not listed, or a production dependency you cannot rebuild on short notice.
Stay on DIY if: your current Direct Connect + ExpressRoute (or partner) design already meets compliance and ops needs, and Interconnect would only add a parallel learning curve without reducing risk.
FAQ
Is AWS Interconnect free with Azure forever?
No. AWS documentation says the preview connection can be used at no cost for the duration of Preview, and that preview 1 Gbps connections are removed as GA approaches. Confirm Azure-side pricing separately. Do not budget as if preview pricing equals GA pricing.
Does Softix guarantee four-nines or any SLA for this link?
No. Softix does not invent SLAs. AWS marketing materials discuss resiliency and availability goals; your contract and production bar must come from current AWS and Microsoft terms for the service stage you are on (preview vs GA), verified against your own measurements.
Can we use this instead of fixing overlapping IP ranges?
No. The getting started guide tells you to review IP allocations for conflicts before you create an Interconnect. Overlap remains your problem.
A practical next step
If your stack already spans AWS and Azure and you want a sober Pilot–Prove–Prod plan—not a multicloud slogan—Softix can map the dependency, Region fit, and rollback before anyone clicks Create. Start with custom software development or contact Softix for a scoped connectivity assessment.
Share
