

# AWS Outposts connectivity to AWS Regions
<a name="region-connectivity"></a>

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

**Note**  
You can't use private connectivity for your service link connection that connects your Outposts server to your AWS Region or AWS Outposts home Region.

**Topics**
+ [Connectivity through service link](service-links.md)
+ [Updates and the service link](updates-service-link.md)
+ [Firewalls and the service link](firewalls-sl.md)
+ [Outposts server network troubleshooting](network-troubleshoot.md)

# Connectivity through service link
<a name="service-links"></a>

During AWS Outposts provisioning, you or AWS creates a service link connection that connects your Outposts server to your chosen AWS Region or 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 traffic 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 traffic between the AWS Region and Outpost.

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 specific 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](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) in the *Amazon VPC User Guide*.

After the service link is established, the Outpost is in service and managed by AWS. The service link is used for the following traffic:
+ Management traffic to the Outpost through the service link, including internal control plane traffic, internal resource monitoring, and updates to firmware and software.
+ Traffic between the Outpost and any associated VPCs, including customer data plane traffic.

## Service link maximum transmission unit (MTU) requirements
<a name="sl-max-mtu-requirements"></a>

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.

Note the following:
+ The network **must** support 1500-bytes MTU between the Outpost and the service link endpoints in the parent AWS Region.
+ The traffic that goes from an instance in Outposts to an instance in the Region has an MTU of 1300 bytes, which is lower than the required MTU of 1500 bytes due to packet overheads.

## Service link bandwidth recommendations
<a name="sl-bandwidth-recommendations"></a><a name="region-bw-rec"></a>

For an optimal experience and resiliency, AWS requires that you use redundant connectivity of at least 500 Mbps and a maximum of 175 ms round trip latency for the service link connection to the AWS Region. The maximum utilization for each Outposts server is 500 Mbps. To increase the connection speed, use multiple Outposts servers. For example, if you have three AWS Outposts servers, the maximum connection speed increases to 1.5 Gbps (1,500 Mbps). For more information, see [Service link traffic for servers](https://docs.aws.amazon.com/outposts/latest/server-userguide/local-server.html#lni-sl).

Your AWS Outposts service link bandwidth requirements vary depending on workload characteristics, such as AMI size, application elasticity, burst speed needs, and Amazon VPC traffic to the Region. Note that AWS Outposts servers do not cache AMIs. AMIs are downloaded from the Region with every instance launch.

We strongly recommend consulting with your AWS sales representative or APN partner to evaluate available home Region options in your geography and seek a custom recommendation about the service link bandwidth and latency requirements for your workloads. 

## Redundant internet connections
<a name="redundant-connections"></a>

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 [Direct Connect Resiliency Recommendations](https://aws.amazon.com/directconnect/resiliency-recommendation/).

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.

# Updates and the service link
<a name="updates-service-link"></a>

AWS maintains a secure network connection between your Outposts server and its parent AWS Region. This network connection, called the service link, is essential in managing the Outpost by providing intra-VPC traffic between the Outpost and AWS Region. [AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/) best practices recommend deploying applications across two Outposts parented to different Availability Zones with an active-active design. For more information, see [AWS Outposts High Availability Design and Architecture Considerations](https://docs.aws.amazon.com/whitepapers/latest/aws-outposts-high-availability-design/aws-outposts-high-availability-design.html).

The service link is regularly updated to maintain operational quality and performance. During maintenance, you might observe brief periods of latency and packet loss on this network resulting in impact on workloads that are dependent on VPC connectivity to resources hosted in-region. However, traffic traversing the [Local Network Interfaces (LNI)](https://docs.aws.amazon.com/outposts/latest/server-userguide/local-network-interface.html) will not be impacted. You can avoid impact to your application by following [AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/) best practices and by ensuring your applications are [resilient to failures](https://docs.aws.amazon.com/outposts/latest/server-userguide/disaster-recovery-resiliency.html) or maintenance activities affecting a single Outposts server.

# Firewalls and the service link
<a name="firewalls-sl"></a>

This section discusses firewall configurations and the service link connection.

In the following diagram, the configuration extends the Amazon VPC from the AWS Region to the Outpost. An Direct Connect public virtual interface is the service link connection. The following traffic goes over the service link and the Direct Connect connection:
+ Management traffic to the Outpost through the service link
+ Traffic between the Outpost and any associated VPCs

![\[Direct Connect connection to AWS\]](http://docs.aws.amazon.com/outposts/latest/server-userguide/images/intra-vpc-Nov-23.png)


If you are using a stateful firewall 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.

![\[Internet gateway connection to AWS\]](http://docs.aws.amazon.com/outposts/latest/server-userguide/images/igw-connection-Nov-23.png)


If you use a stateful firewall that is both UDP and TCP-aware to limit connectivity regarding the service link VLAN, you can deny all inbound connections. If the firewall is acting in a stateful manner, allowed outbound connections from the Outposts service link should automatically allow reply traffic back in without explicit rule configuration. Only outbound connections initiated from the Outpost service link need to be configured as allowed.


| Protocol | Source Port | Source Address | Destination Port | Destination Address | 
| --- | --- | --- | --- | --- | 
|  UDP  |  1024-65535  |  Service Link IP  |  53  |  DNS server  | 
|  UDP  |  443, 1024-65535  |  Service Link IP  |  443  |  AWS Outposts Service Link endpoints  | 
|  TCP  |  1024-65535  |  Service Link IP  |  443  |  AWS Outposts Registration endpoints  | 

If you use a non-stateful firewall to limit connectivity regarding the service link VLAN, you must allow outbound connections initiated from the Outposts service link to the AWS Outposts Region's public networks. You must also explicitly allow reply traffic in from the Outposts Region’s public networks inbound to the service link VLAN. Connectivity is always initiated outbound from the Outposts service link, but reply traffic must be allowed back into the service link VLAN.


| Protocol | Source Port | Source Address | Destination Port | Destination Address | 
| --- | --- | --- | --- | --- | 
| UDP | 1024-65535 | Service Link IP | 53 | DNS Server | 
| UDP | 443, 1024-65535 | Service Link IP | 443 | AWS Outposts Service Link endpoints | 
| TCP | 1025-65535 | Service Link IP | 443 | AWS Outposts Service Link endpoints | 
| UDP | 53 | DNS Server | 1025-65535 | Service Link IP | 
| UDP | 443 | AWS Outposts Service Link endpoints | 443, 1024-65535 | Service Link IP | 
| TCP | 443 | AWS Outposts Service Link endpoints | 1025-65535 | Service Link IP | 

**Note**  
Instances in an Outpost can't use the service link to communicate with instances in another Outposts. Leverage routing through the local gateway or local network interface to communicate between Outposts.

# Outposts server network troubleshooting
<a name="network-troubleshoot"></a>

Use this checklist to help troubleshoot a service link that has a status of `DOWN`.

## Initial assessment
<a name="initial-assessment"></a>

Verify the status of the service link through Amazon CloudWatch metrics:

1. Monitor the **ConnectedStatus** metric in the AWS Outposts namespace.

1. If the average value is less than 1, this confirms that the service link is impaired.

1. If the service link is impaired, complete the steps in the following sections to resolve and reestablish the connection.

## Step 1. Check physical connectivity
<a name="check-physical-connectivity"></a>

1. Verify you are using the provided QSFP breakout cable. If issues persist, test with a different QSFP breakout cable if available.

1. Verify that the QSFP breakout cable in the Outposts server is firmly seated.

1. Verify that **cable 1** (LNI) is firmly seated in the switch.

1. Verify that **cable 2** (service link) is firmly seated in the switch.

1. Complete a general switch-sanity check such as, checking link lights.

## Step 2. Test the Outposts server connection to AWS
<a name="test-connection"></a>

[Create a serial connection](https://docs.aws.amazon.com/outposts/latest/install-server/authorize-2.html) to the Outposts server and perform the following tests:

1. [Test the links](https://docs.aws.amazon.com/outposts/latest/install-server/authorize-3.html#w8aac17c15b7).

   1. If successful, proceed with the next test.

   1. If it fails, [Verify network configuration](#verify-network-configuration).

1. [Test for DNS resolution](https://docs.aws.amazon.com/outposts/latest/install-server/authorize-3.html#w8aac17c15b9).

   1. If successful, proceed with the next test.

   1. If it fails, [Check firewall rules](#check-firewall-rules).

1. [Test for access to the AWS Region](https://docs.aws.amazon.com/outposts/latest/install-server/authorize-3.html#w8aac17c15c11).

   1. If successful, proceed to reestablish the connection.

   1. If it fails, [Verify MTU](#verify-mtu).

### Verify network configuration
<a name="verify-network-configuration"></a>

Ensure that your switch meets the following specifications:
+ **Basic configuration** — The service link port must be an untagged access port to a VLAN with a gateway and a route to AWS endpoints.
+ **Link speed** — The switch port must have link speed set to 10 Gb and auto-negotiation must be turned off.

### Verify MTU
<a name="verify-mtu"></a>

The network must support 1500-bytes MTU between the Outpost and the service link endpoints in the parent AWS Region. For more information about the service link, see [AWS Outposts connectivity to AWS Regions](https://docs.aws.amazon.com/outposts/latest/server-userguide/region-connectivity.html).

### Check firewall rules
<a name="check-firewall-rules"></a>

If you use a firewall 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 the following table. If the firewall 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  |  1024-65535  |  Service Link IP  |  53  |  DNS server  | 
|  UDP  |  443, 1024-65535  |  Service Link IP  |  443  |  AWS Outposts Service Link endpoints  | 
|  TCP  |  1024-65535  |  Service Link IP  |  443  |  AWS Outposts Registration endpoints  | 

## Step 3. Reestablish connectivity
<a name="reestablish-connectivity"></a>

If the previous checks pass but the service link remains `DOWN` (**ConnectedStatus** is less than 1 in CloudWatch), then follow the steps in [Authorize the Outposts server using the Outpost Configuration Tool](https://docs.aws.amazon.com/outposts/latest/install-server/authorize-4.html) to reestablish the connection.

**Note**  
If the service link remains down, create a case at the [AWS Support Center](https://console.aws.amazon.com/support/home#/).