AWS Outposts network components - AWS Outposts

AWS Outposts network components

An AWS Outposts extends an Amazon VPC from an AWS Region to an Outpost with the VPC components that are accessible in the Region, including internet gateways, virtual private gateways, Amazon VPC Transit Gateways, and VPC endpoints. An Outpost is homed to an Availability Zone in the Region and is an extension of that Availability Zone that you can use for resiliency.

The following diagram shows the network components for your Outpost.

  • VPCs and subnets

  • A local gateway

  • A customer-owned IP address pool

  • Route tables


        The VPC networking components for your Outpost.

VPCs and subnets

A virtual private cloud (VPC) spans all Availability Zones in its AWS Region. You can extend any VPC in the Region to your Outpost by adding an Outpost subnet. To add an Outpost subnet to a VPC, specify the Amazon Resource Name (ARN) of the Outpost when you create the subnet.

Outposts support multiple subnets. You can specify the EC2 instance subnet when you launch the EC2 instance in your Outpost. You cannot restrict the hardware server where the instance is deployed, because the Outpost is a pool of AWS compute and storage capacity.

Each Outpost can support multiple VPCs that can have one or more Outpost subnets. For information about VPC quotas, see Amazon VPC Quotas in the Amazon VPC User Guide.

You create Outpost subnets from the VPC CIDR range of the VPC where you created the Outpost. You can use the Outpost address ranges for resources, such as EC2 instances that reside in the Outpost subnet. AWS does not directly advertise the VPC CIDR, or the Outpost subnet range to your on-premises location.

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 public IPv4 addresses in your Outpost. 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 Outpost connectivity to the local network.

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 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.

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 an Elastic 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 a next-hop target for traffic to be routed to your on-premises network.

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 peering connection.

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 at the internet gateway 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 Elastic 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. If you do not want the instance to natively connect to the internet, create a NAT instance.

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.

DNS

By default, EC2 instances in Outposts subnets can use the Amazon Route 53 DNS Service to resolve domain names to IP addresses. Route 53 supports DNS features, such as domain registration, DNS routing, and health checks for instances running in your Outpost. Both public and private hosted Availability Zones are supported for routing traffic to specific domains. Route 53 resolvers are hosted in the AWS Region. Therefore, service link connectivity from the Outpost back to the AWS Region must be up and running for these DNS features to work.

You might encounter longer DNS resolution times with Route 53, depending on the path latency between your Outpost and the AWS Region. In such cases, you can use the DNS servers installed locally in your on-premises environment. To use your own DNS servers, you must create DHCP option sets for the servers and associate them with the VPC. You must also ensure that there is IP connectivity to these DNS servers. You might also need to add routes to the local gateway routing table for reachability. Because DHCP option sets have a VPC scope, instances in both the Outpost subnets and the Availability Zone subnets for the VPC will try to use the specified DNS servers for DNS name resolution.