The decisive qualifier is Public Preview. The AWS–Azure offering is not yet a generally available multicloud backbone with a complete public feature, pricing, regional, and contractual picture. Its value today is as a tightly controlled evaluation path: one that can validate architecture and workload behaviour, but not justify production or regulated-workload assumptions.
What AWS and Azure have announced
AWS and Microsoft describe a managed private cloud-to-cloud connection delivered through AWS Interconnect – multicloud and Azure Multicloud Interconnect. The services are coordinated through an OpenAPI-based interoperability specification.
On the AWS side, the service is intended to remove customer configuration of routers, cross-connects, and BGP peering. Customers select a Region, capacity, and cloud provider, while the connection is represented as a single Interconnect object. That can substantially reduce the low-level assembly work required to start a multicloud connectivity project.
The practical gain should not be overstated. A managed connection does not turn AWS and Azure into a single operational environment, nor does it decide an enterprise’s routing, segmentation, DNS, firewall, identity, or incident-management design. It also does not establish which Azure networking models, services, address families, routing features, or attachment requirements are supported during Preview.
For Windows-oriented estates, likely evaluation scenarios include an AWS-hosted application that needs controlled access to an Azure-hosted service, a migration that temporarily spans both clouds, or a shared enterprise service whose dependent components are split between AWS and Azure. Whether a particular pattern is viable must be tested rather than inferred from the announcement. A successful route between two test subnets does not automatically validate access to a complex application dependency chain.
Preview capacity is deliberately narrow
AWS identifies the Azure connection as a Public Preview. The announced AWS-side locations are US East (N. Virginia), US West (N. California), Asia Pacific (Sydney), and Europe (Frankfurt).
The available launch material does not identify the Azure Region paired with each of those AWS locations. That is not a minor administrative detail: the pair determines the assumptions that teams can make about latency, resilience geography, data residency, and where a workload’s traffic may traverse. It should be established for the intended account and design before stakeholders are given performance or compliance expectations.
AWS also documents firm Preview limits for cloud service providers:
- Bandwidth is limited to 1 Gbps.
- Each customer can create only one Preview Interconnect per supported Region.
- The AWS-side Preview connection is free for the Preview period.
- AWS says the 1 Gbps Preview connections will be removed as the service approaches general availability.
These conditions define a proof-of-concept environment, not a capacity commitment. A 1 Gbps test can usefully establish reachability, route controls, application compatibility, and operational workflow. It cannot demonstrate that a future high-throughput replication, analytics, backup, or media pipeline will meet its production objectives.
Microsoft has said that connectivity can deploy at up to 100 Gbps from day one of general availability. That is a statement about the intended GA service, not evidence that the current Azure Preview offers 100 Gbps. It should not be used to size a current pilot, calculate present throughput, or promise a future deployment model before GA specifications are published.
The removal of Preview connections is equally important. A pilot should be built so that its routing changes, test configuration, access permissions, and documentation can be unwound cleanly. A free Preview path must not become an undocumented application dependency that is discovered only when the connection is retired ahead of GA.
Less physical network assembly, not less architecture
The principal attraction of the offering is the reduction in customer-managed interconnect setup. AWS says customers do not need to configure the routers, cross-connects, and BGP peering associated with the managed connection. That shifts effort away from one class of infrastructure work, but it does not eliminate the architecture decisions around it.
Network, cloud platform, and security teams still need to define reachable address ranges, routing expectations, route propagation boundaries, segmentation, firewall rules, DNS resolution, logging, operational ownership, and incident escalation. Those questions are particularly consequential where Windows workloads rely on shared services such as internal name resolution, certificate infrastructure, directory-integrated applications, management endpoints, or data services.
The connection itself does not determine whether a workload should be allowed to reach a service in the other cloud. Nor does it ensure that intended traffic is permitted while unintended paths remain blocked. A private path is a transport capability, not a replacement for least-privilege network design.
AWS’s documentation also creates a regional design constraint. An Interconnect attaches to a Direct Connect gateway. A virtual private gateway or Transit Gateway can reach only an Interconnect local to its AWS Region. AWS Cloud WAN can reach attached Interconnects globally when it is attached to the same Direct Connect gateway.
That distinction matters for distributed AWS estates. Teams using regional virtual private gateways or Transit Gateways must account for the Interconnect’s Region when designing access to Azure. Organisations using Cloud WAN may have a broader reachability model, subject to their own attachment and network design. Either way, “AWS-to-Azure connectivity” is not a sufficient architecture description; the regional path and attachment model need to be explicit.
Resilience claims need an end-to-end boundary
AWS describes an Interconnect design with multiple logical connections over redundant devices at two or more physically distinct facilities. Its documentation outlines a four-connection model using ECMP load balancing. At a high level, that is a more resilient design than a single connection with one physical dependency.
It does not, however, establish four-nines application availability across both clouds. AWS’s published 99.99% service-level agreement is a conditional service-credit framework for a Covered Interconnect. Its eligibility conditions include deployment of the accessed Endpoint across at least two Availability Zones, and its exclusions include problems beyond the AWS Interconnect demarcation point.
That SLA discussion is useful background for assessing a potential generally available deployment. It should not be treated as a commitment for the current Azure Public Preview. The supplied Preview information does not establish a contractual availability promise for this pairing, and it does not establish what commitment, if any, applies on Azure’s side.
A pilot should therefore test resilience only as observed behaviour, not as proof of a future contractual outcome. Teams can examine how their applications respond to route loss, dependency failure, name-resolution problems, and policy errors. They should not infer an end-to-end availability guarantee from AWS-side redundancy or from the existence of a general service-credit SLA.
Private transport is not a blanket encryption claim
Security descriptions for cloud interconnect services can become broader than the documented facts. AWS says MACsec encryption is automatically used on physical links between AWS networking devices and adjacent partner devices. That is a specific protection for those links.
AWS also directs customers to the partner’s documentation to determine the data-transit security provided on the partner network. The available material therefore does not establish one cryptographic control protecting every segment of traffic throughout both providers’ backbones. It would be inaccurate to call the service end-to-end encrypted solely because MACsec is used at the AWS-to-partner link boundary.
For security-sensitive designs, teams should document the protection applied to each relevant segment, identify where the vendors’ stated responsibilities end, and decide whether application- or workload-level controls remain required. The appropriate answer may vary by data classification, protocol, application behaviour, and organisational policy.
As a matter of prudent pilot design, use non-sensitive, bounded test data. The Preview’s limited capacity, planned connection removal, incomplete Azure-specific details, and unresolved end-to-end security and service-commitment questions make it unsuitable as a production or regulated-workload transport. That is a risk-management recommendation, not a claim that private connectivity alone is inherently insecure.
Pricing and support remain two-provider questions
AWS documents hourly billing for its side of Interconnect, based on provisioned bandwidth and geographic scope, with no separate AWS data-transfer charge for the Interconnect. The other cloud provider independently determines its prices and charges.
The AWS-side Preview connection being free does not establish that the Azure side, connected environments, or related services are free. Nor does it reveal the eventual price model once the CSP reaches general availability. Finance and platform teams should obtain Azure-side cost details and identify any associated networking or workload charges before treating the offering as a long-term economic alternative to existing connectivity.
Support is similarly split by the nature of the deployment. The joint launch shows technical coordination, but the reviewed information does not establish a single support queue, unified service-level commitment, or guaranteed one-vendor root-cause process. During a pilot, teams should explicitly exercise their escalation path, especially for faults that appear near the AWS–Azure boundary.
Region-pair detail is still missing
The launch announcements clearly identify Azure as being in Public Preview and name four AWS-side locations. What remains absent from the reviewed current launch information is the specific Azure Region associated with each AWS Preview location.
An earlier regional-availability crawl did not list Azure region pairs, but that pre-launch record cannot demonstrate a current operational contradiction after the launch. The useful conclusion is narrower: organisations need current, account-specific confirmation of the actual supported AWS–Azure pair before designing for latency, residency, or regional failover.
The same discipline applies to other unresolved Azure-side details, including onboarding requirements, subscription or tenant eligibility, bandwidth quotas, pricing, routing behaviour, and supported feature combinations. Marketing announcements can explain the direction of a service; implementation decisions require confirmation of what the intended account can actually provision.
A disciplined pilot for Windows and Azure estates
A worthwhile pilot should answer limited, measurable questions without implying production readiness.
Start by confirming that the selected AWS Region is one of the announced Preview locations and determining the associated Azure Region. Do not make latency, data-location, or resilience claims until that pairing is known. Then map the AWS network design to the Direct Connect gateway requirement and assess the regional implications for Transit Gateway, virtual private gateway, or Cloud WAN deployments.
Next, test actual application flows rather than stopping at basic IP reachability. For a Windows-focused estate, that may mean validating only the required ports, service dependencies, and name-resolution paths for a bounded test workload. The test should also confirm that segmentation remains intentional: expected traffic should work, while access outside the approved path should stay blocked.
Record observed throughput, latency, provisioning steps, failure behaviour, and support interactions. Those observations can inform an internal decision, but they are not promised service characteristics. No independently measured customer outcomes in the reviewed material establish real-world provisioning times, operational savings, outage handling, or delivered performance for this AWS–Azure pairing.
Finally, rehearse the exit. Remove test routes and permissions, document rollback steps, and verify that disconnecting the Preview link does not leave a hidden dependency. Since AWS says Preview connections will be removed as GA approaches, this is a core success criterion rather than an afterthought.
The bottom line
The AWS–Azure collaboration gives multicloud organisations a credible reason to evaluate managed private connectivity. It can reduce some of the manual network assembly associated with linking two hyperscale clouds, while AWS’s described redundant design and managed provisioning model make the Preview technically interesting.
But the service remains a 1 Gbps, one-per-Region Public Preview on the AWS side, available in four announced AWS locations. The future 100 Gbps figure belongs to general availability, not today’s test environment. Exact Azure region pairs and several Azure-side implementation, pricing, and contractual details remain unconfirmed in the reviewed material.
The sensible course is to run a non-sensitive, tightly bounded pilot that validates routing, workload behaviour, security boundaries, operational ownership, and clean removal. Production standardisation should wait for complete GA documentation, confirmed regional availability, commercial terms, and service commitments across the full AWS–Azure path.