How local gateways for racks work - AWS Outposts

How local gateways for racks work

Outpost racks include a local gateway to provide connectivity to your on-premises network. If you have an Outpost rack, you can include a local gateway as target where the destination is your on-premises network. Local gateways are only available for Outpost racks and can only be used in VPC and subnet route tables that are associated with an Outpost rack.

Local gateway

A local gateway serves two purposes. It provides a target in your VPC route tables for on-premises destined traffic, and performs network address translation (NAT) for instances that have been assigned addresses from your customer-owned IP pool. You can also use the local gateway for communication for internet-bound traffic. Each Outpost supports a single local gateway. You can associate multiple VPCs with the local gateway. For more information, see Working with local gateways and Local network connectivity for racks.

You can attach the local gateway to a VPC to connect to your on-premises network. The local gateway provides connectivity between your local network, or your local gateway VLAN, and the VPC. The local gateway performs NAT of the Outpost instances' IP addresses to Elastic IP addresses from a pool that is assigned to the local gateway. The local gateway NAT function is similar to how an internet gateway functions in an AWS Region.

The local gateway for your Outpost rack enables connectivity from your Outpost subnets to all AWS services that are available in the parent Region, in the same way that you access them from an Availability Zone subnet. For example, you can access the Regional service endpoints over the public internet, or you can use interface VPC endpoints (AWS PrivateLink) to access them without going over the public internet. For more information, see Outpost connectivity to AWS Regions.

Connectivity through the local gateway

The primary role of a local gateway is to provide connectivity from an Outpost to your local on-premises LAN. It also provides connectivity to the internet through your on-premises network. The local gateway can also provide a data plane path back to the AWS Region. If you already have connectivity between your LAN and the Region through AWS Site-to-Site VPN or AWS Direct Connect, you can use the same path to connect from the Outpost to the AWS Region privately.

The data plane path for the local gateway traverses from the Outpost, through the local gateway, and to your private local gateway LAN segment. It would then follow a private path back to the AWS service endpoints in the Region.

The following diagram shows a private connectivity configuration that uses an AWS Direct Connect connection, virtual interface, and virtual private gateway.


            Architectural diagram for an Outpost private connectivity configuration.

Customer-owned IP addresses

During the installation process, AWS uses information that you provide about your on-premises network to create an address pool, known as a customer-owned IP address pool (CoIP pool). AWS then assigns it to the local gateway for use and advertisement back to your customer network through BGP.

Customer-owned IP addresses provide local or external connectivity to resources in your Outpost subnets through your on-premises network. You can assign these IP addresses to resources on your Outpost, such as EC2 instances, by allocating a new Elastic IP from the customer-owned IP pool, and then assigning this new Elastic IP to your EC2 instance. The following requirements apply to the customer-owned IP address pool:

  • You must be able to route the address in your network

  • The CIDR block must be a minimum of /26

When you allocate an Elastic IP address from your customer-owned IP address pool, you continue to own the IP addresses in your customer-owned IP address pool. You are responsible for advertising them as needed on your internal networks or WAN.

You can optionally share your customer-owned pool with multiple AWS accounts in your AWS Organizations using the AWS Resource Access Manager. After you share the pool, participants can allocate and associate Elastic IPs from the customer owned IP pool. For more information see, Step 3: Allocate and associate a customer-owned IP address with the instance. For information about how to share a customer-owned IPv4 addresses, see Sharing Your Resources in the AWS RAM User Guide. You use the customer-owned pool after you launch the Outpost instance.

Routing

By default, every Outpost subnet inherits the main route table from its VPC. You can create a custom route table and associate it with an Outpost subnet. You can include a local gateway as target when the destination is your on-premises network. A local gateway can only be used in VPC and subnet route tables that are associated with an Outpost.

The route tables for Outpost subnets work as they do for Availability Zone subnets. You can specify IP addresses, internet gateways, local gateways, virtual private gateways, and peering connections as destinations. For example, each Outpost subnet, either through the inherited main route table, or a custom table, inherits the VPC local route. This means that all traffic in the VPC, including the Outpost subnet with a destination in the VPC CIDR remains routed in the VPC. You cannot configure a more specific range than the VPC CIDR local route on the Outpost for Outpost subnets.

Outpost subnet route tables can include the following destinations:

  • VPC CIDR range – AWS defines this at installation. This is the local route and applies to all VPC routing, including traffic between Outpost instances in the same VPC.

  • Customer on-premises network – The local gateway routes this traffic for low latency routing to the on-premises network.

  • AWS Region destinations – This includes prefix lists for Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB gateway endpoint, AWS Transit Gateways, virtual private gateways, internet gateways, and VPC peering.

    If you have a peering connection with multiple VPCs on the same Outpost, the traffic between the VPCs remains in the Outpost and does not use the service link back to the Region.

Consider a scenario with the following configuration:

  • A VPC with a CIDR block 10.0.0.0/16 that spans Availability Zone 1 and Availability Zone 2

  • Three subnets in the VPC, Subnet 1 in Availability Zone 1 (10.0.1.0/24), Subnet 2 in Availability Zone 2 (10.0.2.0/24), and Subnet 3 in the Outpost (10.0.3.0/24). The Outpost is homed to Availability Zone 2.

  • An EC2 instance in Subnet 1 with an IP address of 10.0.1.25.

  • An EC2 instance in Subnet 2 with an IP address of 10.0.2.34.

  • Two EC2 instance in Subnet 3 with private IP addresses 10.0.3.112 and 10.0.3.113.

  • An on-premises network CIDR of 172.16.0.0/24.

  • A customer-owned IP pool (10.1.0.0/26).

  • A local gateway that uses BGP advertisement (10.1.0.0/26) to advertise the customer-owned IP pool to the on-premises network.

  • An Elastic IP address association that maps 10.0.3.112 to 10.1.0.2 and 10.0.3.113 to 10.1.0.3.


            Routing overview

You need the following entries in the Outpost subnet route table.

Destination Target Type Notes
10.0.0.0/16 Local Defined by AWS The local VPC route. This route allows for intra-VPC connectivity, including subnets in the AWS Region.
0.0.0.0 internet-gateway-id Defined by the user This route allows instances to connect to the public internet. Instances in Subnet 3 need an Elastic IP address assigned to allow for internet connectivity.
172.16.0.0/24 local-gateway-id Defined by the user This route allows the instances in Subnet 3 to connect to the on-premises network though the local gateway.

Example: Local gateway routing

Consider a scenario with the following configuration:

  • A VPC with a CIDR block 10.0.0.0/16.

  • A subnet in the VPC with a CIDR block 10.0.3.0/24.

  • An EC2 instance in the subnet with a private IP address 10.0.3.112.

  • A customer-owned IP pool (10.1.0.0/26).

  • A local gateway that uses BGP advertisement (10.1.0.0/26) to advertise the customer-owned IP pool to the on-premises network.

  • An Elastic IP address association that maps 10.0.3.112 to 10.1.0.2.

  • A router on the customer on-premises network that performs NAT.


              Local gateway access to on-premises

You need the following entries in the Outpost subnet route table.

Destination Target Type Notes
10.0.0.0/16 Local Defined by AWS This route allows for intra-VPC connectivity, including subnets in the Region.
0.0.0.0/0 local-gateway-id Defined by the user Instances in the subnet need an Elastic IP address assigned to allow for internet connectivity.

Local gateway access to the internet

The local gateway can provide access to the internet to your Outpost subnets. You configure the route table so that the local gateway routes traffic to the public internet.

Traffic initiated from the EC2 instance for the internet uses the 0.0.0.0/0 route to route traffic to the local gateway. The local gateway maps the EC2 instance private IP address to the customer-owned IP address (10.1.0.2), and then sends the traffic to the customer router. The router uses NAT to translate the customer-owned IP address to a public IP address on the router, and then sends the traffic to the destination.

Outbound instance traffic to the on-premises network

Traffic initiated from the EC2 instance with a destination of the on-premises network uses the Outpost subnet route table. The traffic routes to the local gateway, where the local gateway translates the EC2 instance IP address to the customer-owned IP address (Elastic IP address), and then sends the traffic to the destination.

Inbound traffic from the on-premises network to the instance

Traffic from the on-premises network with the EC2 instance as the destination uses the customer-owned IP address (Elastic IP address). When the traffic reaches the local gateway, the local gateway maps the customer-owned IP address (Elastic IP address) to the EC2 instance IP address, and then sends the traffic to the VPC.

Local network connectivity for racks

You need the following components to connect your Outpost rack to your on-premises network:

  • Physical connectivity from the Outpost patch panel to your customer local network devices.

  • Link Aggregation Control Protocol (LACP) to establish two link aggregation group (LAG) connections to your Outpost network devices and to your local network devices.

  • Virtual LAN (VLAN) connectivity between the Outpost and your customer local network devices.

  • Layer 3 point-to-point connectivity for each VLAN.

  • Border Gateway Protocol (BGP) for the route advertisement between the Outpost and your on-premises service link.

  • BGP for the route advertisement between the Outpost and your on-premises local network device for connectivity to the local gateway.

Physical connectivity

An Outpost rack has two physical network devices that attach to your local network.

An Outpost requires a minimum of two physical links between these Outpost network devices and your local network devices. An Outpost supports the following uplink speeds and quantities for each Outpost network device.

Uplink speed Number of uplinks

1 Gbps

1, 2, 4, 6, or 8

10 Gbps

1, 2, 4, 8, 12, or 16

40 Gbps or 100 Gbps

1, 2, or 4

The uplink speed and quantity are symmetrical on each Outpost network device. If you use 100 Gbps as the uplink speed, you must configure the link with forward error correction (FEC CL91).

Outpost racks can support single-mode fiber (SMF) with Lucent Connector (LC), multimode fiber (MMF), or MMF OM4 with LC. AWS provides the optics that are compatible with the fiber that you provide at the rack position.

In the following diagram, the physical demarcation is the fiber patch panel in each Outpost. You provide the fiber cables that are required to connect the Outpost to the patch panel.


            Outpost physical demarcation

AWS Outposts uses the Link Aggregation Control Protocol (LACP) to establish two link aggregation group (LAG) connections, one from each Outpost network device to each local network device. The links from each Outpost network device are aggregated into an Ethernet LAG to represent a single network connection. These LAGs use LACP with standard fast timers.

To enable an Outpost installation at your site, you must configure your side of the LAG connections on your network devices.

From a logical perspective, ignore the Outpost patch panels as the demarcation point and use the Outpost networking devices.

For deployments that have multiple racks, an Outpost must have four LAGs between the aggregation layer of the Outpost network devices and your local network devices.

The following diagram shows four physical connections between each Outpost network device and its connected local network device. We use Ethernet LAGs to aggregate the physical links connecting the Outpost network devices and the customer local network devices.


            Using link aggregation to connect devices.

Virtual LANs

Each LAG between an Outpost network device and a local network device must be configured as an IEEE 802.1q Ethernet trunk. This enables the use of multiple VLANs for network segregation between data paths.

Each Outpost has the following data paths between the on-premises network and its network:

  • Service link VLAN – Enables communication between the Outpost and the AWS Region for both management of the Outpost and intra-VPC traffic between the AWS Region and Outpost. This VLAN provides access to the AWS Region, which enables the service link connection from the Outpost to be established back to the Region. The service link is a custom VPN or VPNs from the Outpost to the Region. It is connected to the Outpost that is configured in the Availability Zone when your purchase the Outpost.

  • Local gateway VLAN – Enables VPC traffic from your VPC to your local LAN. This VLAN enables instances running on the Outpost to communicate with your on-premises network. It also enables them to communicate with the internet through your on-premises network.

You can configure the service link VLAN and local gateway VLAN only between the Outpost and your customer local network devices.

An Outpost is designed to separate the service link and local gateway data paths into two isolated networks. This enables you to choose which of your networks can communicate with services running on the Outpost. It also enables you to make the service link an isolated network from the local gateway network by using multiple route table on your customer local network device, commonly known as Virtual Routing and Forwarding instances (VRF). The demarcation line exists at the port of the Outpost network devices. AWS manages any infrastructure on the AWS side of the connection, and you manage any infrastructure on your side of the line.


            Virtual LANs.

To integrate your Outpost with your on-premises network during the installation and on-going operation, you must allocate the VLANs used between the Outpost network devices and the customer local network devices. You need to provide this information to AWS before the installation. For more information, see Network readiness checklist.

Network layer connectivity

Each Outpost network device requires an IP address on each VLAN so they can communicate with the customer local network devices to establish a BGP session. We recommend that you use a dedicated subnet, with a /30 or /31 CIDR, to represent this logical point-to-point connectivity. We recommend that you do not bridge the VLANs between your customer local network devices.

You need to establish two paths:

  • Service link path - To establish this path, specify a VLAN subnet with a range of /30 or /31 and an IP address for the service link VLAN on the Outpost network device.

  • Local gateway path - To establish this path, specify a VLAN subnet with a range of /30 or /31 and an IP address for the local gateway VLAN on the Outpost network device.

The following diagram shows the connections from each Outpost network device to the customer local network device for the service link path and the local gateway path. There are four VLANs for this example:

  • VLAN A is for the service link path that connects the Outpost network device 1 with the customer local network device 1.

  • VLAN B is for the local gateway path that connects the Outpost network device 1 with the customer local network device 1.

  • VLAN C is for the service link path that connects the Outpost network device 2 with the customer local network device 2.

  • VLAN D is for the local gateway path that connects the Outpost network device 2 with the customer local network device 2.


            Service link path and local gateway path

The following table shows example values for the subnets that connect the Outpost network device 1 with the customer local network device 1.

VLAN Subnet Customer Device 1 IP AWS OND 1 IP
A

10.0.0.0/30

10.0.0.2 10.0.0.1
B 172.16.0.0/30

172.16.0.2

172.16.0.1

The following table shows example values for the subnets that connect the Outpost network device 2 with the customer local network device 2.

VLAN Subnet Customer Device 2 IP AWS OND 2 IP
C

10.0.0.4/30

10.0.0.6 10.0.0.5
D 172.16.0.4/30

172.16.0.6

172.16.0.5

The Outpost establishes an external BGP peering session between each Outpost network device and the customer local network device for service link connectivity over the service link VLAN. The BGP peering session is established between the /30 or /31 IP addresses provided for the point-to-point VLAN. Each BGP peering session uses a private Autonomous System Number (ASN) on the Outpost network device and an ASN that you choose for your customer local network devices. AWS provides the attributes as part of the installation process.

Consider the scenario where you have an Outpost with two Outpost network devices connected by a service link VLAN to two customer local network devices. You configure the following infrastructure, and customer local network device BGP ASN attributes for each service link:

  • The service link BGP ASN. 2-byte (16-bit) or 4-byte (32-bit). The valid values are 64512-65535 or 4200000000-4294967294.

  • The infrastructure CIDR. This must be a /26 CIDR per rack.

  • The customer local network device 1 service link BGP peer IP address.

  • The customer local network device 1 service link BGP peer ASN. The valid values are 1-4294967294.

  • The customer local network device 2 service link BGP peer IP address.

  • The customer local network device 2 service link BGP peer ASN. The valid values are 1-4294967294. For more information, see RFC4893.


            Service link BGP advertisement

The Outpost establishes an external BGP peering session over the service link VLAN using the following process:

  1. Each Outpost network device uses the ASN to establish a BGP peering session with its connected local network device.

  2. Outpost network devices advertise the /26 CIDR range as two /27 CIDR blocks to support link and device failures.

  3. The subnet is used for connectivity from the Outpost to the AWS Region.

You provide a /26 CIDR range during the pre-installation process for the service link infrastructure subnet. The Outpost infrastructure uses this range to establish connectivity to the Region through the service link. The service link subnet is the Outpost source, which initiates the connectivity.

Outpost network devices advertise the /26 CIDR range as two /27 CIDR blocks to support link and device failures.

You must provide a service link BGP ASN and an infrastructure subnet CIDR (/26) for the Outpost. For each Outpost network device, provide the BGP peering IP address on the VLAN of the local network device and the BGP ASN of the local network device.

If you have a multiple rack deployment, you must have one /26 subnet per rack.

Local gateway BGP connectivity

The Outpost establishes an external BGP peering from each Outpost network device to a local network device for connectivity to the local gateway. It uses a private Autonomous System Number (ASN) that you assign in order to establish the external BGP sessions. Each Outpost network device has a single external BGP peering to a local network device using its local gateway VLAN.

The Outpost establishes an external BGP peering session over the local gateway VLAN between each Outpost network device and its connected customer local network device. The peering session is established between the /30 or /31 IPs that you provided when you set up network connectivity and uses point-to-point connectivity between the Outpost network devices and customer local network devices. For more information, see Network layer connectivity.

Each BGP session uses the private ASN on the Outpost network device side, and an ASN that you choose on the customer local network device side. AWS provides the attributes as part of the pre-installation process.

Consider the scenario where you have an Outpost with two Outpost network devices connected by a service link VLAN to two customer local network devices. You configure the following local gateway and customer local network device BGP ASN attributes for each service link:

  • AWS provides the local gateway BGP ASN. 2-byte (16-bit) or 4-byte (32-bit). The valid values are 64512-65535 or 4200000000-4294967294.

  • You provide the customer owned CIDR that gets advertised (public or private, /26 minimum).

  • You provide the customer local network device 1 local gateway BGP peer IP address.

  • You provide the customer local network device 1 local gateway BGP peer ASN. The valid values are 1-4294967294. For more information, see RFC4893.

  • You provide the customer local network device 2 local gateway BGP peer IP address.

  • You provide the customer local network device 2 local gateway BGP peer ASN. The valid values are 1-4294967294. For more information, see RFC4893.


            Local gateway BGP advertisement

Local gateway customer-owned IP subnet advertisement

During the pre-installation process, AWS creates an address pool, known as a customer-owned IP address pool. It is created based on information that you provide about your on-premises network. You can create Elastic IP addresses from this pool, and then assign the addresses to resources on your Outpost, such as EC2 instances.

The local gateway translates the Elastic IP address to an address in the customer-owned pool. The local gateway advertises the translated address to your on-premises network, and any other network that communicates with the Outpost. The addresses are advertised on both local gateway BGP sessions to the local network devices.

Consider the scenario where you have an Outpost with two Outpost network devices connected by a service link VLAN to two customer local network devices. The following is configured:

  • A VPC with a CIDR block 10.0.0.0/16.

  • A subnet in the VPC with a CIDR block 10.0.3.0/24.

  • An EC2 instance in the subnet with a private IP address 10.0.3.112.

  • A customer-owned IP pool (10.1.0.0/26).

  • An Elastic IP address association that associates 10.0.3.112 to 10.1.0.2.

  • A local gateway that uses BGP to advertise 10.1.0.0/26 to the on-premises network through the local devices.

  • Communication between your Outpost and on-premises network will use the CoIP Elastic IPs to address instances in the Outpost, the VPC CIDR range is not used.


            Local gateway subnet advertisement