AWS Outposts

(1)

AWS Outposts

User Guide

(2)

AWS Outposts: User Guide

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

What is AWS Outposts?

AWS Outposts is a fully managed service that extends AWS infrastructure, services, APIs, and tools to customer premises. By providing local access to AWS managed infrastructure, AWS Outposts enables customers to build and run applications on premises using the same programming interfaces as in AWS Regions, while using local compute and storage resources for lower latency and local data processing needs.

An Outpost is a pool of AWS compute and storage capacity deployed at a customer site. AWS operates, monitors, and manages this capacity as part of an AWS Region. You can create subnets on your Outpost and specify them when you create AWS resources such as EC2 instances, EBS volumes, ECS clusters, and RDS instances. Instances in Outpost subnets communicate with other instances in the AWS Region using private IP addresses, all within the same VPC.

For more information, see the AWS Outposts product page.

Key concepts

These are the key concepts for AWS Outposts.

• Outpost site – The customer-managed physical buildings where AWS will install your Outpost. A site must meet the facility, networking, and power requirements for your Outpost.

• Outpost configurations – Configurations of Amazon EC2 compute capacity, Amazon EBS storage capacity, and networking support. Each configuration has unique power, cooling, and weight support requirements.

• Outpost capacity – Compute and storage resources available on the Outpost. You can view and manage the capacity for your Outpost from the AWS Outposts console.

• Outpost equipment – Physical hardware that provides access to the AWS Outposts service. The hardware includes racks, servers, switches, and cabling owned and managed by AWS.

• Outpost racks – An Outpost form factor that is an industry-standard 42U rack. Outpost racks include rack-mountable servers, switches, a network patch panel, a power shelf and blank panels.

• Outpost servers – An Outpost form factor that is an industry-standard 1U or 2U server, which can be installed in a standard EIA-310D 19 compliant 4 post rack. Outpost servers provide local compute and networking services to sites that have limited space or smaller capacity requirements.

• Service link – Network route that enables communication between your Outpost and its associated AWS Region. Each Outpost is an extension of an Availability Zone and its associated Region.

• Local gateway – A logical interconnect virtual router that enables communication between an Outpost rack and your on-premises network.

• Local network interface – A network interface that enables communication from an Outpost server and your on-premises network.

AWS resources on Outposts

You can create the following resources on your Outpost to support low-latency workloads that must run in close proximity to on-premises data and applications:

(6)

AWS resources on Outposts

Resource type Racks Servers

Amazon EC2 instances – Launch an instance on your Outpost (p. 55)

Yes Yes

Amazon ECS clusters – Amazon Elastic Container Service on AWS Outposts

Yes Yes

Amazon EKS nodes – Amazon Elastic Kubernetes Service on AWS Outposts

Yes

AWS App Mesh Envoy proxy – AWS App Mesh on AWS Outposts

Yes Yes

Storage

Amazon EC2 instance block storage – Amazon EC2 instance store in the Amazon EC2 User Guide for Linux Instances and Amazon EC2 instance store in the Amazon EC2 User Guide for Windows Instances

Yes Yes

EBS volumes – Launch an instance on your Outpost (p. 55)

Yes

Amazon S3 buckets – Using

Amazon S3 on AWS Outposts Yes

Analytics and Database Amazon EMR clusters – EMR

Clusters on AWS Outposts Yes

Amazon ElastiCache instances – Using Outposts in the Amazon ElastiCache for Redis User Guide, Using Outposts in the Amazon ElastiCache for Memcached User Guide

Yes

Amazon RDS DB instances –

Amazon RDS on AWS Outposts Yes

Networking, AWS IoT, and Amazon Machine Learning Amazon VPC – Subnets in AWS

Outposts Yes Yes

Application Load Balancers –

Subnets for your load balancer Yes

AWS IoT Greengrass Yes Yes

(7)

Pricing

Resource type Racks Servers

Amazon SageMaker Neo Yes Yes

Pricing

You can choose from a variety of Outpost conﬁgurations, each providing a combination of EC2

instance types and storage options. The price for rack conﬁgurations includes installation, removal, and maintenance. For servers, you must install and maintain the equipment.

You purchase a conﬁguration for a 3-year term and can choose from three payment options: All Upfront, Partial Upfront, and No Upfront. If you choose the Partial option or the No Upfront payment option, monthly charges will apply. Any upfront charges apply 24 hours after your Outpost is installed and the compute and storage capacity is available for use. For more information, see the AWS Outposts pricing page.

(8)

Network components

How AWS Outposts works

AWS Outposts is designed to operate with a constant and consistent connection between your Outpost and an AWS Region. To achieve this connection to the Region, and to the local workloads in your on- premises environment, you must connect your Outpost to your on-premises network. Your on-premises network must provide wide area network (WAN) access back to the Region and to the internet. It must also provide LAN or WAN access to the local network where your on-premises workloads or applications reside.

The following diagram illustrates both Outpost form factors.

Contents

• Network components (p. 4)

• Outpost connectivity to AWS Regions (p. 6)

• How local gateways for racks work (p. 9)

• How local network interfaces for servers work (p. 21)

Network components

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.

• An AWS Region and an on-premises network

• A VPC with multiple subnets in the Region

• A customer-owned IP address pool

• An Outpost in the on-premises network

(9)

VPCs and subnets

• A local gateway for racks (p. 9), or a local network interface for servers (p. 21)

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 specify the underlying hardware 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.

DNS

For network interfaces connected to a VPC, 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 traﬃc to speciﬁc 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 your on-premises DNS 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 but this is only an option for Outpost racks with local gateway. Because DHCP option sets

(10)

Region connectivity

have a VPC scope, instances in both the Outpost subnets and the Availability Zone subnets for the VPC will try to use the speciﬁed DNS servers for DNS name resolution.

Outpost connectivity to AWS Regions

AWS Outposts supports wide area network (WAN) connectivity through the service link connection.

Contents

• Connectivity through service links (p. 6)

• Service link private connectivity using VPC (p. 8)

• Redundant internet connections (p. 9)

Connectivity through service links

During AWS Outposts provisioning, you or AWS creates a service link connection that connects your Outpost back to your chosen AWS Region or Outposts home Region. The service link is an encrypted set of VPN connections that are used whenever the Outpost communicates with your chosen home Region.

You use a virtual LAN (VLAN) to segment traﬃc on the service link. The service link VLAN enables communication between the Outpost and the AWS Region for both management of the Outpost and intra-VPC traﬃc between the AWS Region and Outpost.

If you select the private connectivity option for your Outpost, the service link VPN connection is established using an existing VPC and subnet that you specify. For more information, see Service link private connectivity using VPC (p. 8).

Alternatively, the Outpost is able to create the service link VPN back to the AWS Region through public Region connectivity. To do so, the Outpost needs connectivity to the AWS Region's public IP ranges, either through the public internet or AWS Direct Connect public virtual interface. This connectivity can be through speciﬁc routes in the service link VLAN, or through a default route of 0.0.0.0/0. For more information about the public ranges for AWS, see AWS IP Address Ranges.

After the service link is established, the Outpost is in service and managed by AWS. The service link is used for the following traﬃc:

• Management traﬃc to the Outpost through the service link

• Traﬃc between the Outpost and any associated VPCs

Service link maximum transmission unit (MTU) requirements

The maximum transmission unit (MTU) of a network connection is the size, in bytes, of the largest permissible packet that can be passed over the connection. AWS Outposts requires a minimum of 1500 bytes across your on-premises network. Outpost service links support a maximum packet size of 1300 bytes.

Service link bandwidth recommendations

For an optimal experience and resiliency, AWS recommends that you use redundant connectivity of at least 500 Mbps (1 Gbps is better) for the service link connection to the AWS Region. You can use AWS Direct Connect or an internet connection for the service link. For Outpost racks, the minimum 500 Mbps service link connection allows you to launch Amazon EC2 instances, attach Amazon EBS volumes, and access AWS services, such as Amazon EKS, Amazon EMR, and CloudWatch metrics. Outpost servers support a lower minimum. For more information, see the section called “Service link traﬃc for servers” (p. 25).

Your Outposts service link bandwidth requirements vary depending on the following characteristics:

(11)

Connectivity through service links

• Number of Outpost racks and Outpost capacity conﬁgurations

• Workload characteristics, such as AMI size, application elasticity, burst speed needs, and Amazon VPC traﬃc to the Region

To receive a custom recommendation about the service link bandwidth required for your needs, contact your AWS sales representative or APN partner.

Firewalls and the service link

This section discusses ﬁrewall conﬁgurations and the service link connection.

In the following diagram, the conﬁguration extends the Amazon VPC from the AWS Region to the Outpost. An AWS Direct Connect public virtual interface is the service link connection. The following traﬃc goes over the service link and the AWS Direct Connect connection:

• Management traﬃc to the Outpost through the service link

• Traﬃc between the Outpost and any associated VPCs

If you are using a stateful ﬁrewall with your internet connection to limit connectivity from the public internet to the service link VLAN, you can block all inbound connections that initiate from the internet.

This is because the service link VPN initiates only from the Outpost to the Region, not from the Region to the Outpost.

If you use a ﬁrewall to limit the connectivity from the service link VLAN, you can block all inbound connections. You must allow outbound connections back to the Outpost from the AWS Region as per

(12)

Service link private connectivity using VPC

the following table. If the ﬁrewall is stateful, outbound connections from the Outpost that are allowed, meaning that they were initiated from the Outpost, should be allowed back inbound.

Protocol Source Port Source Address Destination

Port Destination Address

UDP 443 Outpost service link /26 443 Outpost Region's public

routes

TCP 1025-65535 Outpost service link /26 443 Outpost Region's public routes

NoteInstances in an Outpost cannot use the service link to communicate with instances in another Outposts if both instances are in the same VPC. Use the local gateway or local network interface to communicate between Outposts in the same VPC. Outpost racks are also designed with redundant power and networking equipment, including local gateway components. For more information, see Resilience in AWS Outposts (p. 82).

Service link private connectivity using VPC

You can select the private connectivity option in the console when you create your Outpost. When you do so, a service link VPN connection is established after the Outpost is installed using a VPC and subnet that you specify. This allows private connectivity by way of the VPC and minimizes public internet exposure.

Note

• If you need to undo the private connectivity for your Outpost, you must contact AWS Enterprise Support.

• Outposts servers do not support private gateways for AWS Direct Connect connections. You can use AWS Direct Connect for the service link connection, but you cannot use a private gateway.

Prerequisites

The following prerequisites are required before you can conﬁgure private connectivity for your Outpost:

• You must conﬁgure permissions for an IAM entity (user or role) to allow the user or role to create the service-linked role for private connectivity. The IAM entity needs permission to access the following actions:

• iam:CreateServiceLinkedRole on arn:aws:iam::*:role/aws-service-role/

outposts.amazonaws.com/AWSServiceRoleForOutposts*

• iam:PutRolePolicy on arn:aws:iam::*:role/aws-service-role/

outposts.amazonaws.com/AWSServiceRoleForOutposts*

• ec2:DescribeVpcs

• ec2:DescribeSubnets

For more information, see Identity and Access Management (IAM) for AWS Outposts (p. 77) and Using service-linked roles for AWS Outposts (p. 79).

• In the same AWS account and Availability Zone as your Outpost, create a VPC for the sole purpose of Outpost private connectivity with a subnet /25 or larger that does not conﬂict with 10.1.0.0/16. For example, you might use 10.2.0.0/16.

(13)

Redundant internet connections

• For Outpost racks, create an AWS Direct Connect connection, private virtual interface, and virtual private gateway to allow your on-premises Outpost to access the VPC. If the AWS Direct Connect connection is in a diﬀerent AWS account from your VPC, see Associating a virtual private gateway across accounts in the AWS Direct Connect User Guide.

• Advertise the subnet CIDR to your on-premises network. You can use AWS Direct Connect to do so. For more information, see AWS Direct Connect virtual interfaces and Working with AWS Direct Connect gateways in the AWS Direct Connect User Guide. For other options besides AWS Direct Connect, see the Introduction to Amazon Virtual Private Cloud Connectivity Options.

You can select the private connectivity option when you create your Outpost in the AWS Outposts console. For instructions, see Create an Outpost and order Outpost capacity (p. 37).

NoteTo select the private connectivity option when your Outpost is in PENDING status, choose Outposts from the console and select your Outpost. Choose Actions, Add private connectivity and follow the steps.

After you select the private connectivity option for your Outpost, AWS Outposts automatically creates a service-linked role in your account that enables it to complete the following tasks on your behalf:

• Creates network interfaces in the subnet and VPC that you specify, and creates a security group for the network interfaces.

• Grants permission to the AWS Outposts service to attach the network interfaces to a service link endpoint instance in the account.

• Attaches the network interfaces to the service link endpoint instances from the account.

For more information about the service-linked role, see Using service-linked roles for AWS Outposts (p. 79).

Important

After your Outpost is installed, conﬁrm connectivity to the private IPs in your subnet from your Outpost.

Redundant internet connections

When you build connectivity from your Outpost to the AWS Region, we recommend that you create multiple connections for higher availability and resiliency. For more information, see AWS Direct Connect Resiliency Recommendations.

If you need connectivity to the public internet, you can use redundant internet connections and diverse internet providers, just as you would with your existing on-premises workloads.

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.

Contents

• Local gateway (p. 10)

• Customer-owned IP addresses (p. 10)

• Routing (p. 11)

• Local network connectivity for racks (p. 14)

(14)

Local gateway

A local gateway serves two purposes. It provides a target in your VPC route tables for on-premises destined traﬃc, 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 traﬃc. Each Outpost supports a single local gateway. You can associate multiple VPCs with the local gateway. For more information, see Working with local gateways (p. 66) and Local network connectivity for racks (p. 14).

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 (p. 6).

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 conﬁguration that uses an AWS Direct Connect connection, virtual interface, and virtual private gateway.

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.

(15)

Routing

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, the section called “Step 3: Allocate and associate a customer-owned IP address with the instance” (p. 57).

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 deﬁnes this at installation. This is the local route and applies to all VPC routing, including traﬃc between Outpost instances in the same VPC.

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

• AWS Region destinations – This includes preﬁx 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 traﬃc between the VPCs remains in the Outpost and does not use the service link back to the Region.

Consider a scenario with the following conﬁguration:

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

(16)

Routing

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

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

Destination Target Type Notes

10.0.0.0/16 Local Deﬁned 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 Deﬁned 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 Deﬁned by the user This route allows the instances in Subnet 3 to connect to the on-premises network though the local gateway.

(17)

Routing

Example: Local gateway routing

Consider a scenario with the following conﬁguration:

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

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

Destination Target Type Notes

10.0.0.0/16 Local Deﬁned by AWS This route allows for

intra-VPC connectivity, including subnets in the Region.

0.0.0.0/0 local-gateway-id Deﬁned 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 conﬁgure the route table so that the local gateway routes traﬃc to the public internet.

Traﬃc initiated from the EC2 instance for the internet uses the 0.0.0.0/0 route to route traﬃc to the local gateway. The local gateway maps the EC2 instance private IP address to the customer-owned IP

(18)

Rack local connectivity

address (10.1.0.2), and then sends the traﬃc 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 traﬃc to the destination.

Outbound instance traﬃc 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 traﬃc 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.

Topics

• Physical connectivity (p. 14)

• Link aggregation (p. 15)

• Virtual LANs (p. 16)

• Network layer connectivity (p. 17)

• Service link BGP connectivity (p. 18)

• Service link infrastructure subnet advertisement and IP range (p. 19)

• Local gateway BGP connectivity (p. 19)

• Local gateway customer-owned IP subnet advertisement (p. 20)

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.

(19)

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 conﬁgure 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 ﬁber patch panel in each Outpost. You provide the ﬁber cables that are required to connect the Outpost to the patch panel.

Link aggregation

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 conﬁgure 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.

(20)

Virtual LANs

Each LAG between an Outpost network device and a local network device must be conﬁgured 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 traﬃc 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 conﬁgured in the Availability Zone when your purchase the Outpost.

• Local gateway VLAN – Enables VPC traﬃc 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 conﬁgure 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.

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 the section called “Network readiness checklist” (p. 28).

(21)

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.

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

(22)

Service link BGP connectivity

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 conﬁgure 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.

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.

(23)

Service link infrastructure subnet advertisement and IP range

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 the section called “Network layer connectivity” (p. 17).

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 conﬁgure 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.

(24)

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 conﬁgured:

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

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

(25)

How local network interfaces work

How local network interfaces for servers work

Outpost servers include a local network interface to provide connectivity to your on-premises network. A local network interface is available only for Outposts servers running on an Outpost subnet. You cannot use a local network interface from an EC2 instance on an Outpost rack or in the AWS Region. The local network interface is meant only for on-premises locations.

Contents

• Local network interface (p. 22)

• Local network interfaces on your network (p. 22)

• Local network connectivity for servers (p. 24)

(26)

Local network interface

The local connection method your Outposts uses depends on the form factor at your site. Outpost servers use local network interfaces. A local network interface is a logical networking component that connects an EC2 instance to your on-premises network.

A local network interface runs directly on your local area network. With this type of local connectivity, you don't need routers or gateways to communicate with your on-premises equipment. Local network interfaces are named similarly to network interfaces or elastic network interfaces. In this section and throughout this guide, we distinguish between the two interfaces by always using local to refer to local network interfaces.

If you enable local network interfaces on an Outpost subnet, EC2 instances launched from an Outpost server include two network interfaces, one of which is a local network interface. The local network interface connects to the on-premises network while the other network interface connects to the VPC.

Conﬁgure the operating system to enable the local network interface to communicate on your local area network, as you would for any other on-premises equipment. You cannot use DHCP option sets in a VPC to conﬁgure a local network interface because a local network interface runs on your local area network. For more information about enabling local network interfaces, see Working with local network interfaces (p. 22).

A network interface, not the local network interface, connected to the VPC works exactly as it does in the parent Region. For example, you can use the VPC network connection to access 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 (p. 6).

Local network interfaces on your network

In AWS Outposts, a local network interface is a logical networking component that connects an EC2 instance to your on-premises network. For more information, see Local network interface (p. 22).

Topics

• Local network interface basics (p. 23)

• Enable local network interfaces for Outpost subnets (p. 23)

• Using local network interfaces (p. 24)

(27)

Local network interfaces on your network

Local network interface basics

Local network interfaces provide access to a physical layer-two network. VPC is a virtualized layer-three network. Local network interfaces do not support VPC networking components. These components include security groups, network access control lists, virtualized routers or route tables, flow logs, or other virtualized layer-three networking components. The local network interface does not give the Outpost server visibility into VPC layer-three flows. The host operating system of the instance does have full visibility into frames from the physical network. You can apply standard firewall logic to information within these frames. However, this communication happens inside the instance and outside the purview of virtualized constructs like EC2 and VPC.

Consider the following limitations for local network interfaces:

• Local network interfaces support ARP and DHCP protocols. They do not support general L2 broadcast messages.

• You can conﬁgure up to 100 local network interfaces for each AWS account. This limit is adjustable.

• One local network interface for each EC2 instance.

• Outposts servers can host multiple EC2 instances, each with a local network interface.

NoteEC2 instances within the same server can communicate directly without sending data outside the Outposts server. This communication includes traﬃc over a local network interface or elastic network interfaces.

• A local network interface is available only for instances running in an Outposts subnet on an Outpost server.

• Local network interfaces do not support promiscuous mode or MAC address spooﬁng.

Performance

Local network interfaces can provide the same level of bandwidth performance as network interfaces, but are limited by the uplink speed of the server. Any IP ﬂow-based limits for network interfaces are instead based on MAC address pairs for local network interfaces. For more information, see Monitor your instances using CloudWatch in the Amazon EC2 User Guide for Linux Instances. For Windows, see Monitor your instances using CloudWatch in the Amazon EC2 User Guide for Windows Instances.

Monitoring

CloudWatch metrics are produced for each local network interface just like network interfaces. For more information applicable to Linux, see Monitor network performance for your EC2 instance in the Amazon EC2 User Guide for Linux Instances. For more information applicable to Windows, see Monitor network performance for your EC2 instance in the Amazon EC2 User Guide for Windows Instances.

MAC addresses

AWS provides MAC addresses for the local network interface. Local network interfaces use locally administered addresses (LAA) for their MAC addresses. A local network interface uses the same MAC address until you delete the interface. After you delete the local network interface, remove the MAC address from your local conﬁgurations. AWS can reuse MAC addresses that are no longer in use.

Enable local network interfaces for Outpost subnets

Use the modify-subnet-attribute command from the AWS CLI to enable local network interfaces on an Outpost subnet. The modify subnet attribute allows you to specify the device position for local network interfaces. The device position is the position of the network interface on the device index

(28)

Server local connectivity

of the instance. All instances launched from Outpost servers on this subnet use the device position indicated by the subnet attribute. For example, 1 indicates local network interfaces in this subnet are the secondary network interface (eth1). A local network interface cannot be the primary network interface (eth0).

To make local network interfaces available on instances launched from Outpost server

• At a command prompt, issue the modify-subnet-attribute command to specify the device position for the local network interface.

$ aws ec2 modify-subnet-attribute --subnet-id subnet-1a2b3c4d \ --enable-lni-at-device-index 1

Using local network interfaces

EC2 instances that are launched on Outpost servers in an Outpost subnet automatically include a local network interface. Use this section to understand how to work with local network interfaces.

Operating system conﬁguration

By default, EC2 instances launched from an Outpost server include two network interfaces, one of which is a local network interface. Ensure that you conﬁgure the operating system of the EC2 instances that you launch to support a multi-homed networking conﬁguration.

Security groups and local network interfaces

By design, the local network interface does not use security groups in your VPC. A security group controls inbound and outbound VPC traffic. The local network interface is not attached to the VPC. The local network interface is attached to your local network. To control inbound and outbound traffic on the local network interface, use a firewall or similar strategy with the rest of your on-premises equipment.

Local network connectivity for servers

Use this topic to understand the network cabling and topology requirements for hosting an Outpost server. For more information, see the section called “Local network interface” (p. 22) and the section called “Local network interfaces on your network” (p. 22).

Topics

• Server topology on your network (p. 24)

• Server physical connectivity (p. 25)

• Service link traﬃc for servers (p. 25)

• Local network interface (LNI) link traﬃc (p. 26)

• Server IP address assignment (p. 26)

• Server registration (p. 26)

Server topology on your network

An Outpost server requires two distinct connections to your networking equipment. Each connection uses a different cable and carries a different type of traffic. The multiple cables are for traffic-class isolation only, and not for redundancy. The two cables do not need to connect to a common network.

The following table describes Outpost server traﬃc types and labels.

(29)

Traﬃc label Description

2 Service link traﬃc – This traﬃc enables

communication between the Outpost and the AWS Region for both management of the Outpost and intra-VPC traﬃc between the AWS Region and the Outpost. Service link traﬃc includes the service link connection from the Outpost to the Region. The service link is a custom VPN or VPNs from the Outpost to the Region. The Outpost connects to the Availability Zone in the Region that you chose at time of purchase.

1 Local network interface (LNI) link traﬃc –

This traffic enables communication from your VPC to your local LAN over the local network interface. Local link traffic includes instances running on the Outpost that communicate with your on-premises network. Local link traffic can also include instances communicating with the internet through your on-premises network.

Server physical connectivity

Each Outpost server includes non-redundant physical uplink ports. Ports have their own speed and connector requirements as follows:

• 10Gbe – connector type QSFP+

QSFP+ cable

The QSFP+ cable has a connector that you attach to port 3 on the Outpost server. The other end of the QSFP+ cable has four SFP+ interfaces that you connect to your switch. Two of the switch-side interfaces are labeled 1 and 2. Use the 2 interface for service link traﬃc and the 1 interface for LNI link traﬃc. The remaining interfaces are not used.

Service link traﬃc for servers

Conﬁgure the service link port on your switch as an untagged access port to a VLAN with a gateway and a route to the following Region endpoints:

• Service link endpoints

• Outposts registration endpoint

The service link connection must have public DNS available for the Outpost to discover its registration endpoint in the AWS Region. The connection can have a NAT device between the Outpost server and the registration endpoint. For more information about the public ranges for AWS, see AWS IP Address Ranges and AWS Outposts endpoints and quotas.

To register the server, open the following network ports:

• TCP 443

• UDP 443

• UDP 53

(30)

Uplink speed

Outpost servers support a minimum requirement for uplink speed to the Region that is lower than bandwidth recommendations:

• 20 Mbps

However, you may need a faster uplink depending on your LNI link and service link utilization. For more information, see Bandwidth recommendations for service links (p. 6).

Local network interface (LNI) link traﬃc

Configure the LNI link port on your upstream network device as a standard access port to a VLAN on your local network. If you have more than one VLAN, configure all the ports on the upstream network device as trunk ports. Configure the port on your upstream network device to expect multiple MAC addresses. Each instance launched on the server will use a MAC address. Some network devices offer port-security features that will shut down a port that reports multiple MAC addresses.

Server IP address assignment

You do not need public IP address assignments for Outpost servers.

Dynamic host control protocol (DHCP) is network management protocol used to automate the process of conﬁguring devices on IP networks. In the context of Outpost servers, you can use DHCP two ways:

• Network cards on the server

• Local network interfaces on instances

The information in this section is about using DHCP to configure your hardware connections on the server. To use DHCP to configure instances on your local network, see the section called “Operating system configuration” (p. 24).

By default, Outpost servers use DHCP to attach to the local network. DHCP must return DNS name servers and a default gateway. Ensure you use a stable IP address for the Outpost server. IP address changes can cause temporary service disruptions on the Outpost subnet. For more information, see the section called “Step 3: Connect network” (p. 43).

Server registration

When Outpost servers establish a connection on the local network, they use the service link connection to connect to Outpost registration endpoints and register themselves. Registration requires public DNS. When servers register, they create a secure tunnel to their service link endpoint in the Region.

Outpost servers use TCP port 443 to facilitate communication with the Region. Depending on the private connectivity option for your Outpost, the communication to the Region goes over the public internet or privately by way of a VPC. For more information, see the section called “Step 5: Authorize server” (p. 46).

(31)

Rack requirements

Outpost site requirements

An Outpost site is the physical location where your Outpost operates. Before you order an Outpost, consider the following information about the location of your site and its requirements:

• Outposts come in diﬀerent form factors, each with separate requirements. Verify that your site meets the requirements for the form factor that you're ordering.

• Outposts racks are available in select countries and territories. For more information, see the question, In which countries and territories are Outposts racks available?, in AWS Outposts rack FAQs.

• Outposts servers are available in select countries and territories. For more information, see the question, In which countries and territories are Outposts servers available?, in AWS Outposts servers FAQs.

Form factors

• Site requirements for Outpost racks (p. 27)

• Site requirements for Outpost servers (p. 33)

Site requirements for Outpost racks

These are the facility, networking, power, and rack order fulﬁllment requirements for Outposts racks.

Facility

These are the facility requirements for racks.

• Temperature and humidity – The ambient temperature must be between 41° F (5° C) and 95° F (35°

C). The relative humidity must be between 8 percent and 80 percent with no condensation.

• Airﬂow – Racks draw cold air from the front aisle and exhaust hot air to the back aisle. The rack position must provide at least 145.8 times the kVA of cubic feet per minute (CFM) airﬂow.

• Loading dock – Your loading dock must accommodate a rack crate that is 94 inches (239 cm) high by 54 inches (138 cm) wide by 51 inches (130 cm) deep.

• Weight support – Weight varies by configuration. You can find the weight for your configuration specified in the order summary at the rack point loads. The location where the rack is installed and the path to that location must support the specified weight. This includes any freight and standard elevators along the path.

• Clearance – The rack is 80 inches (203 cm) high by 24 inches (61 cm) wide by 48 inches (122 cm) deep.

Any doorways, hallways, turns, ramps, and elevators must provide suﬃcient clearance. At the ﬁnal resting position, there must be a 24 inch (61 cm) wide by 48 inch (122 cm) deep area for the Outpost, with an additional 48 inches (122 cm) of front clearance and 24 inches (61 cm) of rear clearance. The total minimum area required for the Outpost is 24 inch (61 cm) wide by 10 feet (305 cm) deep.

The following diagram shows the total minimum area required for the Outpost, including clearance.

(32)

Rack requirements

• Seismic bracing – To the extent required by regulation or code, you will install and maintain appropriate seismic anchorage and bracing for the rack while it is in your facility.

• Bonding point – We recommend that you provide a bonding wire / point at the rack position so that the AWS-certiﬁed technician can bond the racks during installation.

• Facility access – You will not change the facility in a way that negatively aﬀects the ability of AWS to access, service, or remove the Outpost.

• Elevation – The elevation of the room where the rack is installed must be below 10,005 feet (3,050 meters).

Networking

These are the networking requirements for racks.

• Provide uplinks with speeds of 1 Gbps, 10 Gbps, 40 Gbps, or 100 Gbps.

TipFor bandwidth recommendations for the service link connection, see Bandwidth recommendations (p. 6).

• Provide either single-mode ﬁber (SMF) with Lucent Connector (LC), multimode ﬁber (MMF), or MMF OM4 with LC.

• Provide one or two upstream devices, which can be switches or routers. We recommend two devices to provide high availability.

Network readiness checklist

Use this checklist when you are gathering the information for your Outpost conﬁguration. This includes the LAN, WAN, and any devices between the Outpost and local traﬃc destinations, and the destination in the AWS Region.

(33)

Rack requirements

Uplink speed, ports, and ﬁber Uplink speed and ports

An Outpost has two Outpost network devices that attach to your local network. The number of uplinks each device can support depends on your bandwidth needs and what your router can support. For more information, see Physical connectivity (p. 14).

The following list shows how many uplink ports are supported for each Outpost network device, based on the uplink speed.

1 Gbps

1, 2, 4, 6, or 8 uplinks 10 Gbps

1, 2, 4, 8, 12, or 16 uplinks 40 Gbps or 100 Gbps

1, 2, or 4 uplinks

Fiber

The following ﬁber types are supported:

• Single-mode ﬁber (SMF) with Lucent Connector (LC)

• Multi-mode ﬁber (MMF) or MMF OM4 with LC

Depending on the uplink speed and the type of ﬁber that you choose, the following optical standards are supported.

Uplink speed Fiber type Optical standard

1 Gbps SMF – 1000Base-LX

1 Gbps MMF – 1000Base-SX

10 Gbps SMF – 10GBASE-IR

– 10GBASE-LR

10 Gbps MMF – 10GBASE-SR

40 Gbps SMF – 40GBASE-IR4 (LR4L)

– 40GBASE-LR4

40 Gbps MMF – 40GBASE-ESR4

– 40GBASE-SR4

100 Gbps SMF – 100G PSM4 MSA

– 100GBASE-CWDM4 – 100GBASE-LR4

100 Gbps MMF – 100GBASE-SR4

(34)

Rack requirements

Outpost link aggregation and VLANs

Link aggregation control protocol (LACP) is required between the Outpost and your network.

The following VLANs are required for each Outpost network device. For more information, see Virtual LANs (p. 16).

Outpost network device Service link VLAN Local gateway VLAN

#1 Valid values: 1-4094 Valid values: 1-4094

#2 Valid values: 1-4094 Valid values: 1-4094

For each Outpost network device, you can choose whether to use the same VLANs or diﬀerent VLANs for the service link and local gateway. However, we recommend that each Outpost network device have a diﬀerent VLAN from the other Outpost network device.

We also recommend redundant layer 2 connectivity. LACP is used for link aggregation and is not used for high availability. LACP between the Outpost network devices is not supported.

Outpost network device IP connectivity

Each of the two Outpost network devices requires a CIDR and IP address for the service link and local gateway VLANs. We recommend allocating a dedicated subnet for each network device with a /30 or /31 CIDR. Specify a subnet and an IP address from the subnet for the Outpost to use. For more information, see Network layer connectivity (p. 17).

Outpost network device Service link requirements Local gateway requirements

#1 – Service link CIDR (/30 or /31)

– Service link IP address

– Local gateway CIDR (/30 or /31)

– Local gateway IP address

#2 – Service link CIDR (/30 or /31)

– Service link IP address

– Local gateway CIDR (/30 or /31)

– Local gateway IP address

Service link maximum transmission unit (MTU)

The maximum transmission unit (MTU) of a network connection is the size, in bytes, of the largest permissible packet that can be passed over the connection. AWS Outposts requires a minimum of 1500 bytes across your on-premises network. The Outpost service link supports a maximum packet size of 1300 bytes. For more information about the service link, see the section called “Region connectivity” (p. 6).

Service link Border Gateway Protocol

The Outpost establishes an external BGP (eBGP) peering session between each Outpost network device and your local network device for service link connectivity over the service link VLAN. For more information, see Service link BGP connectivity (p. 18).

Outpost Service link BGP requirements

Your Outpost – Outpost BGP Autonomous System Number

(ASN). 2-byte (16-bit) or 4-byte (32-bit). From

(35)

Rack requirements

Outpost Service link BGP requirements

your private ASN range (64512-65534 or 4200000000-4294967294).

– Infrastructure CIDR (/26 required, advertised as two contiguous /27s).

Local network device Service link BGP requirements

#1 – Service link BGP peer IP address.

– Service link BGP peer ASN. 2-byte (16-bit) or 4- byte (32-bit).

#2 – Service link BGP peer IP address.

– Service link BGP peer ASN. 2-byte (16-bit) or 4- byte (32-bit).

Service link ﬁrewall

UDP and TCP 443 must be statefully listed in the ﬁrewall.

Protocol Source Port Source Address Destination

Port Destination Address

UDP 443 Outpost service link /26 443 Outpost Region's public

routes

TCP 1025-65535 Outpost service link /26 443 Outpost Region's public routes

You can use an AWS Direct Connect connection or a public internet connection to connect the Outpost back to the AWS Region. For Outpost service link connectivity, you can use NAT or PAT at your ﬁrewall or edge router. Service link establishment is always initiated from the Outpost.

Local gateway Border Gateway Protocol

The Outpost establishes an eBGP peering session from each Outpost network device to a local network device for connectivity from your local network to the local gateway. For more information, see Local gateway BGP connectivity (p. 19).

Outpost Local gateway BGP requirements

Your Outpost – Outpost BGP Autonomous System Number

(ASN). 2-byte (16-bit) or 4-byte (32-bit). From your private ASN range (64512-65534 or 4200000000-4294967294).

– CoIP CIDR to advertise (public or private, /26 minimum).

AWS Outposts

AWS Outposts

User Guide

AWS Outposts: User Guide

Table of Contents

What is AWS Outposts?

Key concepts

AWS resources on Outposts

Pricing

How AWS Outposts works

Network components

VPCs and subnets

DNS

Outpost connectivity to AWS Regions

Connectivity through service links

Service link private connectivity using VPC

Prerequisites

Redundant internet connections

How local gateways for racks work

Local gateway

Connectivity through the local gateway

Customer-owned IP addresses

Routing

Example: Local gateway routing

Local gateway access to the internet

Outbound instance traﬃc to the on-premises network

Inbound traﬃc from the on-premises network to the instance

Local network connectivity for racks

Physical connectivity

Link aggregation

Virtual LANs

Network layer connectivity

Service link BGP connectivity

Service link infrastructure subnet advertisement and IP range

Local gateway BGP connectivity

Local gateway customer-owned IP subnet advertisement

How local network interfaces for servers work

Local network interface

Local network interfaces on your network

Local network interface basics

Performance

Monitoring

MAC addresses

Enable local network interfaces for Outpost subnets

Using local network interfaces

Operating system conﬁguration

Security groups and local network interfaces

Local network connectivity for servers

Server topology on your network

Server physical connectivity

Service link traﬃc for servers

Local network interface (LNI) link traﬃc

Server IP address assignment

Server registration

Outpost site requirements

Site requirements for Outpost racks

Facility

Networking

Network readiness checklist