Hybrid connectivity is not just a network link between an office and a virtual network. It is the path that lets on-premises systems, branch locations, users, and cloud workloads behave as one operating environment. For AZ-305<\/a> architecture, the real design work is deciding which connectivity method fits the workload\u2019s bandwidth, latency, availability, security, routing, and operational requirements.<\/p>\n Azure supports several approaches, including site-to-site VPN, point-to-site VPN, ExpressRoute, Virtual WAN, and third-party SD-WAN or network virtual appliances. None is universally superior. Internet-based VPN is fast to deploy and widely available. ExpressRoute provides private connectivity with more predictable performance. Virtual WAN can simplify large distributed topologies. The architecture should choose the pattern that matches the business dependency instead of defaulting to the most expensive option.<\/p>\n Inventory the systems that must communicate across the hybrid boundary. Identify source and destination networks, application protocols, expected throughput, latency sensitivity, data classification, and whether the dependency is one-way or bidirectional. A few administrative connections have very different requirements from a database replication stream or a real-time factory workload.<\/p>\n Also identify which traffic can tolerate public-internet transport. A site-to-site IPsec VPN encrypts traffic across the internet and is often adequate for moderate workloads. A private ExpressRoute circuit may be justified when predictable bandwidth, routing integration, or business criticality makes internet variability unacceptable.<\/p>\n The broader ideas in cloud networking<\/a> matter because hybrid design is an application problem as much as a carrier problem. The path must support the service\u2019s latency, security, and availability objectives.<\/p>\n Document traffic direction and dependency ownership as part of discovery. A migration tool that pulls data from on-premises systems might need different firewall openings from an Azure application that serves requests back to a datacenter. When connectivity requirements are expressed as application flows instead of subnet pairs, security review and troubleshooting become much clearer.<\/p>\n Azure VPN Gateway provides encrypted IPsec\/IKE connectivity between Azure and compatible on-premises VPN devices. It is usually the easiest enterprise hybrid connection to establish because it does not require a private circuit provider. That makes it useful for branch sites, smaller datacenters, temporary migrations, and backup connectivity.<\/p>\n VPN performance depends on the gateway SKU, tunnel configuration, internet path, and on-premises device. It also depends on routing and encryption overhead. Architects should validate expected throughput rather than assuming the nominal gateway limit will be achieved for every traffic pattern.<\/p>\n VPN can also be part of a resilient design even when ExpressRoute is primary. Microsoft\u2019s architecture guidance describes site-to-site VPN as a possible failover path for ExpressRoute when the workload can tolerate the lower and less predictable performance of the internet path.<\/p>\n Gateway redundancy matters on both ends. Azure VPN Gateway provides platform redundancy options, but the on-premises side still needs resilient devices, power, carriers, and routing. If one physical router terminates every tunnel, the architecture has a single point of failure even when Azure itself is highly available.<\/p>\n ExpressRoute connects on-premises networks to Microsoft through a connectivity provider or direct cross-connect model rather than through the public internet. It is appropriate for workloads that need high bandwidth, predictable performance, or private enterprise routing. The architecture still needs redundancy because a private circuit is not the same as an infallible path.<\/p>\n ExpressRoute includes redundant Microsoft edge connectivity, but customer-side routers, provider facilities, circuits, and gateway design remain part of the end-to-end availability chain. Mission-critical workloads can require more than one circuit or more than one peering location. A single on-premises edge device can undermine an otherwise redundant Azure design.<\/p>\n The networking depth represented by AZ-700<\/a> is relevant here because BGP, route propagation, gateways, and connectivity topology determine whether the private path behaves as the architect expects.<\/p>\n ExpressRoute design also needs clear peering intent. Private peering carries traffic between private address spaces, while Microsoft peering serves supported Microsoft public services through BGP-advertised prefixes. The architecture should enable only the peering types required and should understand route filtering, provider responsibilities, and how traffic enters the Microsoft network.<\/p>\n Some organizations use ExpressRoute as the normal path and a site-to-site VPN as backup. This creates transport diversity and can allow continued connectivity if the private circuit is unavailable. The failover only works well when routing is configured intentionally and the application can tolerate the backup path\u2019s performance.<\/p>\n BGP attributes and local preferences should make the desired primary route clear. The failover path should be tested before production depends on it. It is not enough to see both routes in a diagram; operators need to know how long convergence takes and whether asymmetric routing or firewall state will break application sessions.<\/p>\n High-bandwidth or latency-sensitive workloads may need ExpressRoute-specific resilience rather than relying on VPN as the only backup. Design the secondary path from the workload\u2019s minimum acceptable service, not from a checkbox labeled \u201credundant.\u201d<\/p>\n Failover testing should include application behavior after route convergence. Existing TCP sessions may reset, latency may increase, and throughput may drop. An application that survives the route change but violates its response-time objective is operating in a degraded mode that the business should understand in advance.<\/p>\n Azure Virtual WAN provides a Microsoft-managed hub model for connecting branches, VPN sites, ExpressRoute, users, and virtual networks. It can reduce the amount of custom routing and peering infrastructure that a platform team has to operate, particularly when many sites and Azure regions are involved.<\/p>\n Virtual WAN is not automatically cheaper or simpler for every environment. A small deployment with a handful of virtual networks may be easier to manage with a conventional hub and gateways. At larger scale, the managed routing, hub-to-hub connectivity, and integrated security options can reduce operational complexity.<\/p>\nStart with the traffic, not the circuit<\/h3>\n
Site-to-site VPN is the flexible baseline<\/h3>\n
ExpressRoute is about predictable private connectivity<\/h3>\n
Use VPN and ExpressRoute together when the recovery model needs it<\/h3>\n
Virtual WAN changes the operating model at larger scale<\/h3>\n