SD-WAN

SD-WAN separates the logical network connecting sites from the transport networks carrying its packets. The transport, or underlay, provides IP reachability through services such as internet access, MPLS, or private cloud connectivity. The overlay connects SD-WAN edges using tunnels and applies centrally managed forwarding policies. Centralized management does not mean user traffic passes through a central controller; edge devices normally forward traffic locally according to distributed policy.

A practical deployment might connect a branch to both an MPLS circuit and broadband internet. The SD-WAN edges measure conditions such as latency, jitter, and packet loss, then select paths according to application requirements and configured policy. Voice traffic might prefer the lowest-jitter path while backups use a less expensive connection. Application classification, tunnel protocols, failover behavior, and session handling depend on the vendor. SD-WAN cannot create bandwidth or guarantee performance across an uncontrolled internet path.

In a cloud environment, engineers commonly deploy vendor virtual appliances in a connectivity VPC and connect them to the existing enterprise SD-WAN fabric. These appliances terminate branch overlays and exchange routes with cloud networking components. Before deployment, verify vendor support, licensing, appliance throughput, interface requirements, supported tunnel encapsulations, and high-availability behavior. The cloud side must also have routes back to branch prefixes; a healthy overlay alone does not provide complete bidirectional connectivity.

On AWS, Transit Gateway Connect integrates compatible third-party appliances with a transit gateway using Generic Routing Encapsulation, or GRE, for traffic and BGP for dynamic route exchange. A Connect attachment uses an existing VPC attachment or AWS Direct Connect attachment as its transport. A Connect peer defines the GRE connectivity and associated BGP peering. GRE does not encrypt traffic, so Connect is not an encrypted VPN replacement. If confidentiality is required, design encryption separately and verify that the chosen vendor and transport architecture support it.

For example, appliances in a shared networking account can terminate branch SD-WAN tunnels and advertise branch prefixes through Connect. Workload VPCs in other accounts attach to the shared transit gateway, with sharing managed through AWS Resource Access Manager. Configure VPC subnet routes, transit gateway route-table associations, and route propagation so the intended networks can communicate. Separate route tables can restrict which attachments exchange traffic, but segmentation must also remain consistent with appliance policies and security controls.

Multi-Region connectivity requires an explicit design rather than an assumption that the SD-WAN overlay or a transit gateway automatically connects every Region. Options include regional appliance deployments with transit gateway peering or a managed global network architecture. Transit gateway peering uses static routing rather than automatic propagation of routes across the peering attachment. VPC peering is nontransitive, so peering a workload VPC with an appliance VPC does not make that appliance VPC a general transit hub.

Design resilience across independent appliances, Availability Zones, and transport paths. The two BGP sessions associated with a Connect peer do not represent two independent GRE data paths. Test appliance failure, transport failure, route withdrawal, and return-path behavior, especially when stateful firewalls require symmetric traffic. Account for tunnel overhead, MTU, TCP MSS, appliance capacity, service quotas, and processing charges. SD-WAN complements routing and private connectivity; it is not synonymous with VPN encryption, MPLS, or a cloud transit router.