Multiprotocol Label Switching (MPLS)

Multiprotocol Label Switching (MPLS) forwards packets using short labels within an MPLS-enabled network. An ingress router classifies traffic into a forwarding equivalence class and applies a label. Intermediate label-switching routers use their forwarding tables to swap labels and select the next hop, while labels are removed before traffic leaves the MPLS domain. Labels have local significance rather than acting as globally unique destination addresses. Label-switched paths can follow routing-derived paths or paths selected through traffic-engineering mechanisms.

A common enterprise application is a carrier-managed MPLS Layer 3 VPN. Customer edge routers connect to provider edge routers, which maintain separate virtual routing and forwarding instances for different customers or routing domains. In a typical BGP/MPLS Layer 3 VPN, provider edge routers exchange VPN routes using multiprotocol BGP, and label stacks distinguish transport through the provider network from the destination VPN context. This supports separation over shared infrastructure, but the separation is not encryption.

In a cloud deployment, an organization might connect branches and data centers through a carrier MPLS WAN, then have that carrier deliver connectivity to AWS Direct Connect. The carrier terminates the MPLS service and presents the appropriate Ethernet and IP connectivity toward AWS. AWS Direct Connect is not itself an MPLS VPN service, and engineers do not configure MPLS labels on VPC route tables. The cloud-facing connection uses VLANs and BGP sessions on virtual interfaces, while the provider manages its own MPLS forwarding.

For example, a company with branches in several countries can use its MPLS WAN to reach a Direct Connect transit virtual interface, a Direct Connect gateway, and regional Transit Gateways. Each Transit Gateway can connect VPCs belonging to multiple AWS accounts. Transit Gateway route-table associations and propagation control which attachments can communicate. Transit Gateway peering can provide inter-Region connectivity, with routes configured for the peering path; attaching gateways to the same Direct Connect gateway does not itself create transit connectivity between them.

The routing design must work across every boundary. Branch routers need routes toward cloud prefixes, and AWS needs valid return routes toward branch prefixes. Engineers must coordinate BGP advertisements, route filtering, address allocation, and failover policy with the carrier. Overlapping address ranges can remain isolated in separate MPLS VPNs, but connecting those networks to shared cloud resources still requires address translation, renumbering, or another deliberate overlap-handling design. MPLS does not automatically solve overlapping VPC CIDRs.

MPLS services can offer managed quality-of-service classes and contractual performance targets, but these depend on the provider and purchased service. Provider QoS markings do not establish an end-to-end priority guarantee across AWS networking. Costs, provisioning lead times, carrier dependencies, and limited visibility into the provider core are important trade-offs. Private connectivity also does not imply confidentiality: use IPsec or application-layer encryption when required, and account for tunnel overhead and path MTU.

For resilience, use genuinely diverse access circuits, devices, and connection locations, rather than assuming two logical connections have independent physical paths. An internet-based Site-to-Site VPN can provide a separate backup path, subject to available bandwidth and routing policy. SD-WAN can select paths across MPLS and internet transports; it is not synonymous with MPLS. Likewise, VPC peering and Transit Gateway provide cloud routing connectivity, not an extension of the carrier's MPLS control plane.