What happened
On 31 August 2026, AWS and Microsoft announced public-preview connectivity between AWS and Microsoft Azure through their managed interconnect services. AWS said Azure connectivity entered Public Preview for AWS Interconnect – multicloud. AWS positioned the capability as on-demand, private and high-speed connectivity between the two cloud environments, extending its existing multicloud interconnect model.
Microsoft described Azure Multicloud Interconnect as a provider-managed private intercloud service built on Azure ExpressRoute and AWS Direct Connect. Microsoft said the providers coordinate circuits, routing and encryption, allowing one managed interconnect resource to replace a customer-assembled stack of circuits, routers, BGP sessions and encryption components. Microsoft said the design is quad-redundant, 400G-class and uses MACsec encryption.
AWS Direct Connect exposes ConnectionState, VirtualInterfaceBgpStatus, VirtualInterfaceBgpPrefixesAccepted and VirtualInterfaceBgpPrefixesAdvertised metrics through Amazon CloudWatch. AWS documentation says Direct Connect metrics use five-minute aggregation by default. Those metrics provide useful component visibility, but the launch material does not establish that customers receive complete cross-provider control-plane telemetry or a unified forensic record during a joint incident.
The cited launch materials did not publish a fixed general-availability date or final performance targets. Microsoft said feature availability, performance targets and timelines may evolve during the preview. Attribution posture: No threat actor or malicious activity is alleged in the cited launch materials. This is an architecture and governance development rather than a disclosed security incident.
Why this matters now
The service removes customer-managed circuits, routers, BGP sessions and encryption components, reducing configuration burden but also changing the evidence and control boundary. Security architecture teams need to decide which responsibilities are genuinely transferred, which remain shared and which customer controls must continue independently for segmentation, route validation, telemetry and incident response.
A jointly managed path can become a concentration point for data movement and application dependency across two major clouds. The quad-redundant design and private connectivity are positive resilience properties, but they do not remove the need for application-level failover, regional diversity, route-policy controls or an alternative path when the interconnect or its management plane is unavailable.
Preview status matters. Microsoft states that feature availability, performance targets and timelines may evolve, and the launch materials do not provide a fixed general-availability date. Organisations should prevent convenience or AI-workload urgency from converting a preview network service into an undocumented production dependency without explicit exception governance.
The decision for security leaders
Cloud and network architecture owners should establish a formal control-plane threat model before adoption. Document route ownership, segmentation enforcement, encryption responsibility, administrative access, telemetry retention, support escalation and evidence availability across AWS, Microsoft and the customer. Marketing language about private connectivity should not substitute for a shared-responsibility matrix.
Resilience engineering should test application behaviour when the managed path, one cloud endpoint or provider management functions are unavailable. Critical services need an approved fallback route or a documented business decision to accept the concentration. The test must include route withdrawal, asymmetric-path handling, capacity constraints and restoration sequencing.
Governance teams should treat preview use as an explicit, time-bound exception for production workloads. Define entry criteria, permitted data classes, approved regions, service-level assumptions and an exit plan. Reassess the exception when AWS and Microsoft publish general-availability terms, performance commitments and fuller incident-response responsibilities.
Evidence of closure
- Approved architecture records the provider, customer and shared control responsibilities.
- Telemetry test verifies route, flow and application visibility from both cloud environments.
- Failover exercise demonstrates an approved alternative path or accepted business impact.
- Exception register records permitted workloads, data classes, expiry and accountable owner.
The Security.io assessment
The service can reduce multicloud integration error by removing customer-operated network components and presenting a consistent provisioning model. That is a legitimate security benefit, particularly where bespoke interconnects suffer configuration drift. The benefit is conditional on customers understanding the new abstraction and retaining enough independent evidence to identify routing, encryption or availability failures.
The same simplification increases provider concentration. A jointly operated intercloud path becomes part of the security and resilience boundary for applications distributed across AWS and Azure. Quad redundancy and MACsec address important design risks, but they do not establish application continuity, eliminate route-policy mistakes or guarantee visibility into every provider-side event.
High confidence applies to the announced architecture and preview status, not to production suitability for any specific organisation. Adoption should follow workload threat modelling, data-classification review and failure testing. Security.io would reassess the control posture when final service commitments, regional architecture, customer-visible logs and joint incident procedures are published.
Questions for the morning meeting
- Who owns security approval for the jointly managed intercloud control plane?
- What independent telemetry remains available during a provider-side routing or encryption event?
- Can critical cross-cloud workflows fail over without the managed interconnect?
- Which incident, support and evidence responsibilities belong to AWS, Microsoft and the customer?