# How AWS Site-to-Site VPN works How Site-to-Site VPN works A Site-to-Site VPN connection consists of the following components: + A [virtual private gateway](#VPNGateway) or a [transit gateway](#Transit-Gateway) + A [customer gateway device](#CustomerGatewayDevice) + A [customer gateway](#CustomerGateway) The VPN connection offers two VPN tunnels between a virtual private gateway or transit gateway on the AWS side, and a customer gateway on the on-premises side. For more information about Site-to-Site VPN quotas, see [AWS Site-to-Site VPN quotas](vpn-limits.md). ## Virtual private gateway Virtual private gateway A *virtual private gateway* is the Site-to-Site VPN Concentrator on the Amazon side of the Site-to-Site VPN connection. You create a virtual private gateway and attach it to a virtual private cloud (VPC) with resources that must access the Site-to-Site VPN connection. The following diagram shows a VPN connection between a VPC and your on-premises network using a virtual private gateway. ![\[A VPC with an attached virtual private gateway and a VPN connection to your on-premises network.\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/vpn-how-it-works-vgw.png) When you create a virtual private gateway, you can specify the private Autonomous System Number (ASN) for the Amazon side of the gateway. If you don't specify an ASN, the virtual private gateway is created with the default ASN (64512). You cannot change the ASN after you've created the virtual private gateway. To check the ASN for your virtual private gateway, view its details in the **Virtual private gateways** page in the Amazon VPC console, or use the [describe-vpn-gateways](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpn-gateways.html) AWS CLI command. **Note** Virtual private gateways do not support IPv6 for Site-to-Site VPN connections. If you need IPv6 support, use a transit gateway or Cloud WAN for your VPN connection. ## Transit gateway Transit gateway A transit gateway is a transit hub that you can use to interconnect your VPCs and your on-premises networks. For more information, see [Amazon VPC Transit Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/). You can create a Site-to-Site VPN connection as an attachment on a transit gateway. The following diagram shows a VPN connection between multiple VPCs and your on-premises network using a transit gateway. The transit gateway has three VPC attachments and a VPN attachment. ![\[A transit gateway with three VPC attachments and one VPN attachment.\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/vpn-how-it-works-tgw.png) Your Site-to-Site VPN connection on a transit gateway can support IPv4 or IPv6 traffic inside the VPN tunnels (inner IP addresses). Additionally, transit gateways support IPv6 addresses for the outer tunnel IP addresses. For more information, see [IPv4 and IPv6 traffic in AWS Site-to-Site VPN](ipv4-ipv6.md). You can modify the target gateway of a Site-to-Site VPN connection from a virtual private gateway to a transit gateway. For more information, see [Modify the target gateway of an AWS Site-to-Site VPN connection](modify-vpn-target.md). ## Customer gateway device Customer gateway device A *customer gateway device* is a physical device or software application on your side of the Site-to-Site VPN connection. You configure the device to work with the Site-to-Site VPN connection. For more information, see [AWS Site-to-Site VPN customer gateway devices](your-cgw.md). By default, your customer gateway device must bring up the tunnels for your Site-to-Site VPN connection by generating traffic and initiating the Internet Key Exchange (IKE) negotiation process. You can configure your Site-to-Site VPN connection to specify that AWS must initiate the IKE negotiation process instead. For more information, see [AWS Site-to-Site VPN tunnel initiation options](initiate-vpn-tunnels.md). If you're using IPv6 for the outer tunnel IP addresses, your customer gateway device must support IPv6 addressing and be able to establish IPsec tunnels with IPv6 endpoints. ## Customer gateway Customer gateway A *customer gateway* is a resource that you create in AWS that represents the customer gateway device in your on-premises network. When you create a customer gateway, you provide information about your device to AWS. For more information, see [Customer gateway options for your AWS Site-to-Site VPN connection](cgw-options.md). ![\[A customer gateway and customer gateway device.\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/vpn-how-it-works-cgw.png) To use Amazon VPC with a Site-to-Site VPN connection, you or your network administrator must also configure the customer gateway device or application in your remote network. When you create the Site-to-Site VPN connection, we provide you with the required configuration information and your network administrator typically performs this configuration. For information about the customer gateway requirements and configuration, see [AWS Site-to-Site VPN customer gateway devices](your-cgw.md). ### IPv6 customer gateway When creating a customer gateway for use with IPv6 outer tunnel IPs, you specify an IPv6 address instead of an IPv4 address. You can create an IPv6 customer gateway using the AWS Management Console or the AWS CLI. To create an IPv6 customer gateway using the AWS CLI, use the following command: ``` aws ec2 create-customer-gateway --Ipv6-address 2001:0db8:85a3:0000:0000:8a2e:0370:7334 --bgp-asn 65051 --type ipsec.1 --region us-west-1 ``` The IPv6 address must be a valid, internet-routable IPv6 address for your customer gateway device. ## IPv6 VPN connections Site-to-Site VPN VPN connections support the following IPv6 configurations: + *IPv4 outer tunnel with IPv4 inner packets* - The basic IPv4 VPN capability supported on Virtual Private Gateway (VGW), Transit Gateway (TGW), and Cloud WAN. + *IPv4 outer tunnel with IPv6 inner packets* - Allows IPv6 applications/transport within the VPN tunnel. Supported on TGW and Cloud WAN (not supported on VGW). + *IPv6 outer tunnel with IPv6 inner packets* - Allows full IPv6 migration with IPv6 addresses for both outer tunnel IPs and inner packet IPs. Supported on TGW and Cloud WAN. + *IPv6 outer tunnel with IPv4 inner packets* - Allows IPv6 outer tunnel addressing while supporting legacy IPv4 applications within the tunnel. Supported on TGW and Cloud WAN. To create a VPN connection with IPv6 outer tunnel IPs, you specify `OutsideIPAddressType=Ipv6` when creating the VPN connection. AWS automatically configures the outside tunnel IPv6 addresses for the AWS side of the VPN tunnels. Example CLI command to create a VPN connection with IPv6 outer tunnel IPs and IPv6 inner tunnel IPs: ``` aws ec2 create-vpn-connection --type ipsec.1 --transit-gateway-id tgw-12312312312312312 --customer-gateway-id cgw-001122334455aabbc --options OutsideIPAddressType=Ipv6,TunnelInsideIpVersion=ipv6,TunnelOptions=[{StartupAction=start},{StartupAction=start}] ``` You can view the IPv6 addresses assigned to your VPN connection using the `describe-vpn-connection` CLI command. # Tunnel options for your AWS Site-to-Site VPN connection VPN tunnel options You use a Site-to-Site VPN connection to connect your remote network to a VPC. Each Site-to-Site VPN connection has two tunnels, with each tunnel using a unique public IP address. It is important to configure both tunnels for redundancy. When one tunnel becomes unavailable (for example, down for maintenance), network traffic is automatically routed to the available tunnel for that specific Site-to-Site VPN connection. The following diagram shows the two tunnels of a VPN connection. Each tunnel terminates in a different Availability Zone to provide increased availability. Traffic from the on-premises network to AWS uses both tunnels. Traffic from AWS to the on-premises network prefers one of the tunnels, but can automatically fail over to the other tunnel if there is a failure on the AWS side. ![\[The two tunnels of a VPN connection between a virtual private gateway and a customer gateway.\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/Multiple_VPN_Tunnels_diagram.png) When you create a Site-to-Site VPN connection, you download a configuration file specific to your customer gateway device that contains information for configuring the device, including information for configuring each tunnel. You can optionally specify some of the tunnel options yourself when you create the Site-to-Site VPN connection. Otherwise, AWS provides default values. ## Tunnel bandwidth options You can configure the bandwidth capacity for your VPN tunnels: + **Standard bandwidth**: Up to 1.25 Gbps per tunnel (default) + **Large Bandwidth Tunnel (LBT)**: Up to 5 Gbps per tunnel Large Bandwidth Tunnels are available only for VPN connections attached to Transit Gateway or Cloud WAN. For more information, see [Large Bandwidth Tunnels](#large-bandwidth-tunnels). **Note** Site-to-Site VPN tunnel endpoints evaluate proposals from your customer gateway starting with the lowest configured value from the list below, regardless of the proposal order from the customer gateway. You can use the `modify-vpn-connection-options` command to restrict the list of options AWS endpoints will accept. For more information, see [modify-vpn-connection-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-vpn-connection-options.html) in *Amazon EC2 Command Line Reference*. ## Large Bandwidth Tunnels Large Bandwidth Tunnels Large Bandwidth Tunnels allow you to configure Site-to-Site VPN tunnels that support up to 5 Gbps bandwidth per tunnel, compared to the standard 1.25 Gbps. Large Bandwidth Tunnels are available for VPN connections attached to Transit Gateway or Cloud WAN. This eliminates or reduces the need to deploy complex protocols such as ECMP (Equal Cost Multi Path) to achieve higher bandwidth and ensures a consistent tunnel bandwidth of 5 Gbps per tunnel. Large Bandwidth Tunnels is designed to be used in the following use cases: + **Data center connectivity**: Support bandwidth-intensive hybrid applications, big data migrations, or disaster recovery architectures that require high-capacity connectivity between AWS workloads and on-premises data centers. + **Direct Connect backup**: Provide backup or overlay connectivity for high-capacity Direct Connect circuits (10 Gbps\$1) to on-premises data centers or colocation facilities. ### Region availability Large Bandwidth Tunnels are available in all Regions except the following: **Unavailable AWS Regions** | AWS Region | Description | | --- | --- | | ap-southeast-4 | Asia Pacific (Melbourne) | | ca-west-1 | Canada West (Calgary) | | eu-central-2 | Europe (Zurich) | | il-central-1 | Israel (Tel Aviv) | | me-central-1 | Middle East (UAE) | ### Requirements and limitations + Available only for VPN connections attached to a transit gateway or to Cloud WAN. Not supported for Virtual Private Gateway attachments. + Both tunnels of a VPN connection must use the same bandwidth configuration (both 1.25 Gbps or both 5 Gbps). + Accelerated VPN is not supported. + All other core VPN features such as private IP VPN, routing, and tunnel maintenance work the same with Large Bandwidth Tunnel. + MTU limit remains 1500 bytes. [ Learn More ](https://docs.aws.amazon.com/vpn/latest/s2svpn/cgw-best-practice.html) on how to adjust MTU and MSS sizes according to the algorithms in use. + You can't modify an existing tunnel to use Large Bandwidth Tunnels. You'll need to first delete the tunnel, and then create a new tunnel and setting the tunnel bandwidth to **Large**. + Customer Gateways (CGWs) only with a fixed IP can be used with Large Bandwidth Tunnels. + Customer Gateways (CGWs) without an IP address cannot be used with Large Bandwidth Tunnels. + Large Bandwidth Tunnels do not support changes to the NAT-T port while the tunnel is established. + Packets requiring fragmentation may experience lower performance. [ Learn More ](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-limits.html#vpn-quotas-mtu). ### Pricing for Large Bandwidth Tunnels Information about pricing for Large Bandwidth VPN connections can be found on the [AWS VPN pricing](https://aws.amazon.com/vpn/pricing/#AWS_Site-to-Site_VPN_and_Accelerated_Site-to-Site_VPN_Connection_Pricing) page. ### Scaling beyond 5 Gbps For bandwidth requirements exceeding 5 Gbps per tunnel, you can use ECMP across multiple VPN connections. For example, you can achieve 20 Gbps bandwidth by deploying two VPN connections with Large Bandwidth Tunnels and using ECMP across all four tunnels. # Configure tunnel options for AWS Site-to-Site VPN Configure tunnel options This section provides comprehensive guidance on configuring tunnel options for AWS Site-to-Site VPN connections, covering essential parameters such as dead peer detection, IKE versions, and encryption settings. You can customize these tunnel options to optimize your VPN connection's security, performance, and compatibility with your on-premises network infrastructure. The following are the tunnel options that you can configure. **Note** Some tunnel options have multiple default values. For example, **IKE versions** has two default tunnel option values: `ikev1` and `ikev2`. All default values will be associated with that tunnel option if you don't choose specific values. Click to remove any default value that you don't want associated with the tunnel option. For example, if you only want to use `ikev1` for the IKE version, click `ikev2` to remove it. **Dead peer detection (DPD) timeout** The number of seconds after which a DPD timeout occurs. A DPD timeout of 30 seconds means that the VPN endpoint will consider the peer dead 30 seconds after the first failed keep-alive. You can specify 30 or higher. Default: 40 **DPD timeout action** The action to take after dead peer detection (DPD) timeout occurs. You can specify the following: + `Clear`: End the IKE session when DPD timeout occurs (stop the tunnel and clear the routes) + `None`: Take no action when DPD timeout occurs + `Restart`: Restart the IKE session when DPD timeout occurs For more information, see [AWS Site-to-Site VPN tunnel initiation options](initiate-vpn-tunnels.md). Default: `Clear` **VPN logging options** With Site-to-Site VPN logs, you can gain access to details on IP Security (IPsec) tunnel establishment, Internet Key Exchange (IKE) negotiations, and dead peer detection (DPD) protocol messages. For more information, see [AWS Site-to-Site VPN logs](monitoring-logs.md). Available log formats: `json`, `text` **IKE versions** The IKE versions that are permitted for the VPN tunnel. You can specify one or more of the default values. Defaults: `ikev1`, `ikev2` **Inside tunnel IPv4 CIDR** The range of inside (internal) IPv4 addresses for the VPN tunnel. You can specify a size /30 CIDR block from the `169.254.0.0/16` range. The CIDR block must be unique across all Site-to-Site VPN connections that use the same virtual private gateway. The CIDR block does not need to be unique across all connections on a transit gateway. However, if they are not unique, it can create a conflict on your customer gateway. Proceed carefully when re-using the same CIDR block on multiple Site-to-Site VPN connections on a transit gateway. The following CIDR blocks are reserved and cannot be used: + `169.254.0.0/30` + `169.254.1.0/30` + `169.254.2.0/30` + `169.254.3.0/30` + `169.254.4.0/30` + `169.254.5.0/30` + `169.254.169.252/30` Default: A size /30 IPv4 CIDR block from the `169.254.0.0/16` range. **Pre-shared key storage** The type of storage for the pre-shared key: + **Standard** — The pre-shared key is stored directly in the Site-to-Site VPN service. + **Secrets Manager ** — The pre-shared key is stored using AWS Secrets Manager. For more information about Secrets Manager, see [Enhanced security features using Secrets Manager](enhanced-security.md). **Tunnel bandwidth** The bandwidth supported for the tunnel. + **Standard** — The tunnel bandwidth is set to a maximum of up to 1.25 Gbps per tunnel (default). + **Large** — The tunnel bandwidth to a maximum of up to 5 Gbps per tunnel. **Note** **Large** is only available only for VPN connections attached to a transit gateway or to Cloud WAN. It is not supported for Virtual Private Gateway connections. **Inside tunnel IPv6 CIDR** (IPv6 VPN connections only) The range of inside (internal) IPv6 addresses for the VPN tunnel. You can specify a size /126 CIDR block from the local `fd00::/8` range. The CIDR block must be unique across all Site-to-Site VPN connections that use the same transit gateway. If you don't specify an IPv6 subnet, Amazon automatically selects a /128 subnet from this range. Regardless of whether you specify the subnet or Amazon selects it, Amazon uses the first usable IPv6 address in the subnet for its side of the connection, and your side uses the second usable IPv6 address. Default: A size /126 IPv6 CIDR block from the local `fd00::/8` range. **Outside tunnel IP address type** The IP address type for the outside (external) tunnel IP addresses. You can specify one of the following: + `PrivateIpv4`: Use private IPv4 address to deploy Site-to-Site VPN connections over Direct Connect. + `PublicIpv4`: (Default) Use IPv4 addresses for the outer tunnel IPs. + `Ipv6`: Use IPv6 addresses for the outer tunnel IPs. This option is only available for VPN connections on a transit gateway or Cloud WAN. When you select `Ipv6`, AWS automatically configures the outside tunnel IPv6 addresses for the AWS side of the VPN tunnels. Your customer gateway device must support IPv6 addressing and be able to establish IPsec tunnels with IPv6 endpoints. Default: `PublicIpv4` **Local IPv4 Network CIDR** (IPv4 VPN connection only) The CIDR range used during IKE phase 2 negotiation for the customer (on-premises) side of the VPN tunnel. This range is used to propose routes but does not enforce traffic restrictions since AWS uses route-based VPNs exclusively. Policy-based VPNs are not supported as they would limit AWS' ability to support dynamic routing protocols and multi-region architectures. This should include the IP ranges from your on-premises network that need to communicate over the VPN tunnel. Proper route table configurations, NACLs, and security groups should be used to control actual traffic flow. Default: 0.0.0.0/0 **Remote IPv4 Network CIDR** (IPv4 VPN connection only) The CIDR range used during IKE phase 2 negotiation for the AWS side of the VPN tunnel. This range is used to propose routes but does not enforce traffic restrictions since AWS uses route-based VPNs exclusively. AWS does not support policy-based VPNs because they lack the flexibility required for complex routing scenarios and are incompatible with features like transit gateways and VPN Equal Cost Multi-Path (ECMP). For VPCs, this is typically the CIDR range of your VPC. For transit gateways, this could include multiple CIDR ranges from attached VPCs or other network. Default: 0.0.0.0/0 **Local IPv6 Network CIDR** (IPv6 VPN connection only) The IPv6 CIDR range on the customer gateway (on-premises) side that is allowed to communicate over the VPN tunnels. Default: ::/0 **Remote IPv6 Network CIDR** (IPv6 VPN connection only) The IPv6 CIDR range on the AWS side that is allowed to communicate over the VPN tunnels. Default: ::/0 **Phase 1 Diffie-Hellman (DH) group numbers** The DH group numbers that are permitted for the VPN tunnel for phase 1 of the IKE negotiations. You can specify one or more of the default values. Defaults: 2, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24 **Phase 2 Diffie-Hellman (DH) group numbers** The DH group numbers that are permitted for the VPN tunnel for phase 2 of the IKE negotiations. You can specify one or more of the default values. Defaults: 2, 5, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24 **Phase 1 encryption algorithms** The encryption algorithms that are permitted for the VPN tunnel for phase 1 of the IKE negotiations. You can specify one or more of the default values. Defaults: AES128, AES256, AES128-GCM-16, AES256-GCM-16 **Phase 2 encryption algorithms** The encryption algorithms that are permitted for the VPN tunnel for phase 2 IKE negotiations. You can specify one or more of the default values. Defaults: AES128, AES256, AES128-GCM-16, AES256-GCM-16 **Phase 1 integrity algorithms** The integrity algorithms that are permitted for the VPN tunnel for phase 1 of the IKE negotiations. You can specify one or more of the default values. Defaults: SHA1, SHA2-256, SHA2-384, SHA2-512 **Phase 2 integrity algorithms** The integrity algorithms that are permitted for the VPN tunnel for phase 2 of the IKE negotiations. You can specify one or more of the default values. Defaults: SHA1, SHA2-256, SHA2-384, SHA2-512 **Phase 1 lifetime** AWS initiate re-keys with the timing values set in the Phase 1 lifetime and Phase 2 lifetime fields. If such lifetimes are different than the negotiated handshake values, this may interrupt tunnel connectivity. The lifetime in seconds for phase 1 of the IKE negotiations. You can specify a number between 900 and 28,800. Default: 28,800 (8 hours) **Phase 2 lifetime** AWS initiate re-keys with the timing values set in the Phase 1 lifetime and Phase 2 lifetime fields. If such lifetimes are different than the negotiated handshake values, this may interrupt tunnel connectivity. The lifetime in seconds for phase 2 of the IKE negotiations. You can specify a number between 900 and 3,600. The number that you specify must be less than the number of seconds for the phase 1 lifetime. Default: 3,600 (1 hour) **Pre-shared key (PSK)** The pre-shared key (PSK) to establish the initial internet key exchange (IKE) security association between the target gateway and customer gateway. The PSK must be between 8 and 64 characters in length and cannot start with zero (0). Allowed characters are alphanumeric characters, periods (.), and underscores (\$1). Default: A 32-character alphanumeric string. **Rekey fuzz** The percentage of the rekey window (determined by the rekey margin time) within which the rekey time is randomly selected. You can specify a percentage value between 0 and 100. Default: 100 **Rekey margin time** The margin time in seconds before the phase 1 and phase 2 lifetime expires, during which the AWS side of the VPN connection performs an IKE rekey. You can specify a number between 60 and half of the value of the phase 2 lifetime. The exact time of the rekey is randomly selected based on the value for rekey fuzz. Default: 270 (4.5 minutes) **Replay window size packets** The number of packets in an IKE replay window. You can specify a value between 64 and 2048. Default: 1024 **Startup action** The action to take when establishing the tunnel for a VPN connection. You can specify the following: + `Start`: AWS initiates the IKE negotiation to bring the tunnel up. Only supported if your customer gateway is configured with an IP address. + `Add`: Your customer gateway device must initiate the IKE negotiation to bring the tunnel up. For more information, see [AWS Site-to-Site VPN tunnel initiation options](initiate-vpn-tunnels.md). Default: `Add` **Tunnel endpoint lifecycle control** Tunnel endpoint lifecycle control provides control over the schedule of endpoint replacements. For more information, see [AWS Site-to-Site VPN tunnel endpoint lifecycle control](tunnel-endpoint-lifecycle.md). Default: `Off` You can specify the tunnel options when you create a Site-to-Site VPN connection, or you can modify the tunnel options for an existing VPN connection. For more information, see the following topics: + [Step 5: Create a VPN connection](SetUpVPNConnections.md#vpn-create-vpn-connection) + [Modify AWS Site-to-Site VPN tunnel options](modify-vpn-tunnel-options.md) # AWS Site-to-Site VPN tunnel authentication options VPN tunnel authentication options You can use pre-shared keys, or certificates to authenticate your Site-to-Site VPN tunnel endpoints. ## Pre-shared keys A pre-shared key (PSK) is the default authentication option for Site-to-Site VPN tunnels. When creating a tunnel, you can either specify your own PSK or allow AWS to auto-generate one for you. The PSK is stored using one of the following methods: + Directly in the Site-to-Site VPN service. For more information, see [AWS Site-to-Site VPN customer gateway devices](your-cgw.md). + In AWS Secrets Manager for enhanced security. For more information about using Secrets Manager to store a PSK, see [Enhanced security features using Secrets Manager](enhanced-security.md). The PSK string is then used when configuring your customer gateway device. ## Private certificate from AWS Private Certificate Authority If you do not want to use pre-shared keys, you can use a private certificate from AWS Private Certificate Authority to authenticate your VPN. You must create a private certificate from a subordinate CA using AWS Private Certificate Authority (AWS Private CA). To sign the ACM subordinate CA, you can use an ACM Root CA or an external CA. For more information about creating a private certificate, see [Creating and Managing a Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/creating-managing.html) in the *AWS Private Certificate Authority User Guide*. You must create a service-linked role to generate and use the certificate for the AWS side of the Site-to-Site VPN tunnel endpoint. For more information, see [Service-linked roles for Site-to-Site VPN](security_iam_service-with-iam.md#security_iam_service-with-iam-roles-service-linked). **Note** To facilitate seamless certification rotations, any certificate with the same certificate authority chain as the one originally specified in the `CreateCustomerGateway` API call is sufficient to establish a VPN Connection. If you do not specify the IP address of your customer gateway device, we do not check the IP address. This operation allows you to move the customer gateway device to a different IP address without having to re-configure the VPN connection. Site-to-Site VPN performs certificate chain verification on the customer gateway certificate when you create a certificate VPN. In addition to the basic CA and validity checks, Site-to-Site VPN checks whether the X.509 extensions are present, including Authority Key Identifier, Subject Key Identifier, and Basic Constraints. # AWS Site-to-Site VPN tunnel initiation options VPN tunnel initiation options By default, your customer gateway device must bring up the tunnels for your Site-to-Site VPN connection by generating traffic and initiating the Internet Key Exchange (IKE) negotiation process. You can configure your VPN tunnels to specify that AWS must initiate or restart the IKE negotiation process instead. ## VPN tunnel IKE initiation options The following IKE initiation options are available. You can implement either or both options, for one or both of the tunnels in your Site-to-Site VPN connection. See [VPN tunnel options](VPNTunnels.md) for more details on these and other tunnel option settings. + **Startup action**: The action to take when establishing the VPN tunnel for a new or modified VPN connection. By default, your customer gateway device initiates the IKE negotiation process to bring the tunnel up. You can specify that AWS must initiate the IKE negotiation process instead. + **DPD timeout action**: The action to take after dead peer detection (DPD) timeout occurs. By default, the IKE session is stopped, the tunnel goes down, and the routes are removed. You can specify that AWS must restart the IKE session when DPD timeout occurs, or you can specify that AWS must take no action when DPD timeout occurs. ## Rules and limitations The following rules and limitations apply: + To initiate IKE negotiation, AWS requires the public IP address of your customer gateway device. If you configured certificate-based authentication for your VPN connection and you did not specify an IP address when you created the customer gateway resource in AWS, you must create a new customer gateway and specify the IP address. Then, modify the VPN connection and specify the new customer gateway. For more information, see [Change the customer gateway for an AWS Site-to-Site VPN connection](change-vpn-cgw.md). + IKE initiation (startup action) from the AWS side of the VPN connection is supported for IKEv2 only. + If using IKE initiation from the AWS side of the VPN connection, it does not include a timeout setting. It will continuously try to establish a connection until one is made. Additionally, the AWS side of VPN connection will re-initiate IKE negotiation when it receives a delete SA message from your customer gateway. + If your customer gateway device is behind a firewall or other device using Network Address Translation (NAT), it must have an identity (IDr) configured. For more information about IDr, see [RFC 7296](https://datatracker.ietf.org/doc/html/rfc7296). If you do not configure IKE initiation from the AWS side for your VPN tunnel and the VPN connection experiences a period of idle time (usually 10 seconds, depending on your configuration), the tunnel might go down. To prevent this, you can use a network monitoring tool to generate keepalive pings. ## Working with VPN tunnel initiation options For more information about working with VPN tunnel initiation options, see the following topics: + To create a new VPN connection and specify the VPN tunnel initiation options: [Step 5: Create a VPN connection](SetUpVPNConnections.md#vpn-create-vpn-connection) + To modify the VPN tunnel initiation options for an existing VPN connection: [Modify AWS Site-to-Site VPN tunnel options](modify-vpn-tunnel-options.md) # AWS Site-to-Site VPN tunnel endpoint replacements Endpoint replacements Your Site-to-Site VPN connection consists of two VPN tunnels for redundancy. Sometimes, one or both of the VPN tunnel endpoints is replaced when AWS performs tunnel updates, or when you modify your VPN connection. During a tunnel endpoint replacement, connectivity over the tunnel might be interrupted while the new tunnel endpoint is provisioned. **Topics** + [ ## Customer initiated endpoint replacements ](#endpoint-replacements-for-vpn-modifications) + [ ## AWS managed endpoint replacements ](#endpoint-replacements-for-aws-updates) + [ # AWS Site-to-Site VPN tunnel endpoint lifecycle control ](tunnel-endpoint-lifecycle.md) ## Customer initiated endpoint replacements When you modify the following components of your VPN connection, one or both of your tunnel endpoints is replaced. | Modification | API action | Tunnel impact | | --- | --- | --- | | [Modify the target gateway for the VPN connection](modify-vpn-target.md) | [ModifyVpnConnection](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpnConnection.html) | Both tunnels are unavailable while new tunnel endpoints are provisioned. | | [Change the customer gateway for the VPN connection](change-vpn-cgw.md) | [ModifyVpnConnection](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpnConnection.html) | Both tunnels are unavailable while new tunnel endpoints are provisioned. | | [Modify the VPN connection options](modify-vpn-connection-options.md) | [ModifyVpnConnectionOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpnConnectionOptions.html) | Both tunnels are unavailable while new tunnel endpoints are provisioned. | | [Modify the VPN tunnel options](modify-vpn-tunnel-options.md) | [ModifyVpnTunnelOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpnTunnelOptions.html) | The modified tunnel is unavailable during the update. | ## AWS managed endpoint replacements AWS Site-to-Site VPN is a managed service, and periodically applies updates to your VPN tunnel endpoints. These updates happen for a variety of reasons, including the following: + To apply general upgrades, such as patches, resiliency improvements, and other enhancements + To retire underlying hardware + When automated monitoring determines that a VPN tunnel endpoint is unhealthy AWS applies tunnel endpoint updates to one tunnel of your VPN connection at a time. During a tunnel endpoint update, your VPN connection might experience a brief loss of redundancy. It’s therefore important to configure both tunnels in your VPN connection for high availability. # AWS Site-to-Site VPN tunnel endpoint lifecycle control Tunnel endpoint lifecycle Tunnel endpoint lifecycle control provides control over the schedule of endpoint replacements, and can help minimize connectivity disruptions during AWS managed tunnel endpoint replacements. With this feature, you can choose to accept AWS managed updates to tunnel endpoints at a time that works best for your business. Use this feature if you have short-term business needs or can only support a single tunnel per VPN connection. **Note** In rare circumstances, AWS might apply critical updates to tunnel endpoints immediately, even if the tunnel endpoint lifecycle control feature is enabled. **Topics** + [ ## How tunnel endpoint lifecycle control works ](#how-elc-works) + [Enable tunnel endpoint lifecycle control](enable-elc.md) + [Verify if tunnel endpoint lifecycle control is enabled](view-elc-status.md) + [Check for available updates](view-elc-updates.md) + [Accept a maintenance update](accept-update.md) + [Turn tunnel endpoint lifecycle control off](turn-elc-off.md) ## How tunnel endpoint lifecycle control works Turn on the tunnel endpoint lifecycle control feature for individual tunnels within a VPN connection. It can be enabled at the time of VPN creation or by modifying tunnel options for an existing VPN connection. After tunnel endpoint lifecycle control is enabled, you will gain additional visibility into upcoming tunnel maintenance events in two ways: + You will receive AWS Health notifications for upcoming tunnel endpoint replacements. + The status of pending maintenance, along with the **Maintenance auto applied after** and **Last maintenance applied** timestamps, can be seen in the AWS Management Console or by using the [get-vpn-tunnel-replacement-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-vpn-tunnel-replacement-status.html) AWS CLI command. When a tunnel endpoint maintenance is available, you will have the opportunity to accept the update at a time that is convenient for you, before the given **Maintenance auto applied after** timestamp. If you do not apply updates before the **Maintenance auto applied after** date, AWS will automatically perform the tunnel endpoint replacement soon after, as part of the regular maintenance update cycle. # Enable AWS Site-to-Site VPN tunnel endpoint lifecycle control Enable tunnel endpoint lifecycle control Endpoint lifecycle control can be enabled on an existing or new VPN connection. This can be done using either the AWS Management Console or AWS CLI. **Note** By default when you turn on the feature for an existing VPN connection, a tunnel endpoint replacement will be initiated at the same time. If you want to turn the feature on, but not initiate an tunnel endpoint replacement immediately, you can use the **skip tunnel replacement** option. ------ #### [ Existing VPN connection ] The following steps demonstrate how to enable tunnel endpoint lifecycle control on an existing VPN connection. **To enable tunnel endpoint lifecycle control using the AWS Management Console** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the left-side navigation pane, choose **Site-to-Site VPN Connections**. 1. Select the appropriate connection under **VPN connections**. 1. Choose **Actions**, then **Modify VPN tunnel options**. 1. Select the specific tunnel that you want to modify by choosing the appropriate **VPN tunnel outside IP address**. 1. Under **Tunnel Endpoint Lifecycle Control**, select the **Enable** check box. 1. (Optional) Select **Skip tunnel replacement**. 1. Choose **Save changes**. **To enable tunnel endpoint lifecycle control using the AWS CLI** Use the [modify-vpn-tunnel-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-vpn-tunnel-options.html) command to turn on tunnel endpoint lifecycle control. ------ #### [ New VPN connection ] The following steps demonstrate how to enable tunnel endpoint lifecycle control during creation of a new VPN connection. **To enable tunnel endpoint lifecycle control during creation of a new VPN connection using the AWS Management Console** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, choose **Site-to-Site VPN Connections**. 1. Choose **Create VPN connection**. 1. In the sections for **Tunnel 1 options** and **Tunnel 2 options**, under **Tunnel Endpoint Lifecycle Control**, select **Enable**. 1. Choose **Create VPN Connection**. **To enable tunnel endpoint lifecycle control during creation of a new VPN connection using the AWS CLI** Use the [create-vpn-connection](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpn-connection.html) command to turn on tunnel endpoint lifecycle control. ------ # Verify if AWS Site-to-Site VPN tunnel endpoint lifecycle control is enabled Verify if tunnel endpoint lifecycle control is enabled You can verify whether tunnel endpoint lifecycle control is enabled on an existing VPN tunnel by using the AWS Management Console or CLI. + If tunnel endpoint lifecycle control is disabled, and you want to enable it see [Enable tunnel endpoint lifecycle control](enable-elc.md). + If tunnel endpoint lifecycle control is enabled, and you want to disable it, see [Turn tunnel endpoint lifecycle control off](turn-elc-off.md). **To verify if tunnel endpoint lifecycle control is enabled using the AWS Management Console** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the left-side navigation pane, choose **Site-to-Site VPN Connections**. 1. Select the appropriate connection under **VPN connections**. 1. Select the **Tunnel details** tab. 1. In the tunnel details, look for **Tunnel Endpoint Lifecycle Control**, which will report whether the feature is **Enabled** or **Disabled**. **To verify if tunnel endpoint lifecycle control is enabled using the AWS CLI** Use the [describe-vpn-connections](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpn-connections.html) command to verify if tunnel endpoint lifecycle control is enabled. # Check for available AWS Site-to-Site VPN tunnel updates Check for available updates After you enable the tunnel endpoint lifecycle control feature, you can view whether a maintenance update is available for your VPN connection by using the AWS Management Console or CLI. Checking for an available Site-to-Site VPN tunnel update does not automatically download and deploy the update. You can choose when you want to deploy it. For the steps to download and deploy an update, see [Accept a maintenance update](accept-update.md). **To check for available updates using the AWS Management Console** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the left-side navigation pane, choose **Site-to-Site VPN Connections**. 1. Select the appropriate connection under **VPN connections**. 1. Select the **Tunnel details** tab. 1. Check the **Pending maintenance** column. The status will be either **Available** or **None**. **To check for available updates using the AWS CLI** Use the [get-vpn-tunnel-replacement-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-vpn-tunnel-replacement-status.html) command to check for available updates. # Accept an AWS Site-to-Site VPN tunnel maintenance update Accept a maintenance update When a maintenance update is available, you can accept it using the AWS Management Console or CLI. You can choose to accept the Site-to-Site VPN tunnel maintenance update at a time that's convenient for you. Once you accept the maintenance update it will be deployed. **Note** If you don't accept the maintenance update, AWS will automatically deploy it during a regular maintenance update cycle. **To accept an available maintenance update using the AWS Management Console** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the left-side navigation pane, choose **Site-to-Site VPN Connections**. 1. Select the appropriate connection under **VPN connections**. 1. Choose **Actions**, then **Replace VPN Tunnel**. 1. Select the specific tunnel that you want to replace by choosing the appropriate **VPN tunnel outside IP address**. 1. Choose **Replace**. **To accept an available maintenance update using the AWS CLI** Use the [replace-vpn-tunnel](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-vpn-tunnel.html) command to accept an available maintenance update. # Turn AWS Site-to-Site VPN tunnel endpoint lifecycle control off Turn tunnel endpoint lifecycle control off If you no longer want to use the tunnel endpoint lifecycle control feature, you can turn it off using the AWS Management Console or the AWS CLI. When you turn off this feature, AWS will automatically deploy maintenance updates periodically, and these updates might happen during your business hours. To avoid any business impact, we highly recommend that you configure both tunnels in your VPN connection for high availability. **Note** While there is an available pending maintenance, you cannot specify the **skip tunnel replacement** option while turning the feature off. You can always turn the feature off without using the **skip tunnel replacement** option, but AWS will automatically deploy the available pending maintenance updates by initiating a tunnel endpoint replacement immediately. **To turn off tunnel endpoint lifecycle control using the AWS Management Console** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the left-side navigation pane, choose **Site-to-Site VPN Connections**. 1. Select the appropriate connection under **VPN connections**. 1. Choose **Actions**, then **Modify VPN tunnel options**. 1. Select the specific tunnel that you want to modify by choosing the appropriate **VPN tunnel outside IP address**. 1. To turn off tunnel endpoint lifecycle control, under **Tunnel Endpoint Lifecycle Control**, clear the **Enable** check box. 1. (Optional) Select **Skip tunnel replacement**. 1. Choose **Save changes**. **To turn off tunnel endpoint lifecycle control using the AWS CLI** Use the [modify-vpn-tunnel-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-vpn-tunnel-options.html) command to turn off tunnel endpoint lifecycle control. # Customer gateway options for your AWS Site-to-Site VPN connection Customer gateway options The following table describes the information you'll need to create a customer gateway resource in AWS. | Item | Description | | --- | --- | | (Optional) Name tag. | Creates a tag with a key of 'Name' and a value that you specify. | | (Dynamic routing only) Border Gateway Protocol (BGP) Autonomous System Number (ASN) of the customer gateway. | ASN in the range of 1–4,294,967,295 is supported. You can use an existing public ASN assigned to your network, with the exception of the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/cgw-options.html) If you don't have a public ASN, you can use a private ASN in the range of 64,512–65,534 or 4,200,000,000–4,294,967,294. The default ASN is 64512. For more information about routing, see [AWS Site-to-Site VPN routing options](VPNRoutingTypes.md). | | The IP address of the customer gateway device's external interface. | The IP address must be static and can be either IPv4 or IPv6. For IPv4 addresses: If your customer gateway device is behind a network address translation (NAT) device, use the IP address of your NAT device. Also, ensure that UDP packets on port 500 (and port 4500, if NAT traversal is being used) are allowed to pass between your network and the AWS Site-to-Site VPN endpoints. See [Firewall rules](FirewallRules.md) for more info. For IPv6 addresses: The address must be a valid, internet-routable IPv6 address. IPv6 addresses are only supported for VPN connections on a transit gateway or Cloud WAN. An IP address is not required when you are using a private certificate from AWS Private Certificate Authority and a public VPN. | | (Optional) Private certificate from a subordinate CA using AWS Certificate Manager (ACM). | If you want to use certificate based authentication, provide the ARN of an ACM private certificate that will be used on your customer gateway device. When you create a customer gateway, you can configure the customer gateway to use AWS Private Certificate Authority private certificates to authenticate the Site-to-Site VPN. When you choose to use this option, you create an entirely AWS-hosted private certificate authority (CA) for internal use by your organization. Both the root CA certificate and subordinate CA certificates are stored and managed by AWS Private CA. Before you create the customer gateway, you create a private certificate from a subordinate CA using AWS Private Certificate Authority, and then specify the certificate when you configure the customer gateway. For information about creating a private certificate, see [Creating and managing a private CA](https://docs.aws.amazon.com/privateca/latest/userguide/creating-managing.html) in the *AWS Private Certificate Authority User Guide*. | | (Optional) Device. | A name for the customer gateway device associated with this customer gateway. | ## IPv6 customer gateway options When creating a customer gateway with an IPv6 address, consider the following: + IPv6 customer gateways are only supported for VPN connections on a transit gateway or Cloud WAN. + The IPv6 address must be a valid, internet-routable IPv6 address. + Your customer gateway device must support IPv6 addressing and be able to establish IPsec tunnels with IPv6 endpoints. + To create an IPv6 customer gateway using the AWS CLI, use an IPv6 address for the `--ip-address` parameter: ``` aws ec2 create-customer-gateway --ip-address 2001:0db8:85a3:0000:0000:8a2e:0370:7334 --bgp-asn 65051 --type ipsec.1 --region us-west-1 ``` # Accelerated AWS Site-to-Site VPN connections Accelerated VPN connections You can optionally enable acceleration for your Site-to-Site VPN connection. An accelerated Site-to-Site VPN connection (accelerated VPN connection) uses AWS Global Accelerator to route traffic from your on-premises network to an AWS edge location that is closest to your customer gateway device. AWS Global Accelerator optimizes the network path, using the congestion-free AWS global network to route traffic to the endpoint that provides the best application performance (for more information, see [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)). You can use an accelerated VPN connection to avoid network disruptions that might occur when traffic is routed over the public internet. When you create an accelerated VPN connection, we create and manage two accelerators on your behalf, one for each VPN tunnel. You cannot view or manage these accelerators yourself by using the AWS Global Accelerator console or APIs. For information about the AWS Regions that support Accelerated VPN connections, see the [AWS Accelerated Site-to-Site VPN FAQs](https://aws.amazon.com/vpn/faqs/). ## Enabling acceleration By default, when you create a Site-to-Site VPN connection, acceleration is disabled. You can optionally enable acceleration when you create a new Site-to-Site VPN attachment on a transit gateway. For more information and steps, see [Create an AWS Site-to-Site VPN connection](create-vpn-connection.md). Accelerated VPN connections use a separate pool of IP addresses for the tunnel endpoint IP addresses. The IP addresses for the two VPN tunnels are selected from two separate [network zones](https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-components.html). ## Rules and restrictions To use an accelerated VPN connection, the following rules apply: + Acceleration is only supported for Site-to-Site VPN connections that are attached to a transit gateway. Virtual private gateways do not support accelerated VPN connections. + An Accelerated Site-to-Site VPN connection cannot be used with an AWS Direct Connect public virtual interface. + You cannot turn on or turn off acceleration for an existing Site-to-Site VPN connection. Instead, you can create a new Site-to-Site VPN connection with acceleration on or off as needed. Then, configure your customer gateway device to use the new Site-to-Site VPN connection and delete the old Site-to-Site VPN connection. + NAT-traversal (NAT-T) is required for an accelerated VPN connection and is enabled by default. If you downloaded a [configuration file](SetUpVPNConnections.md#vpn-download-config) from the Amazon VPC console, check the NAT-T setting and adjust it if necessary. + IKE negotiation for accelerated VPN tunnels must be initiated from the customer gateway device. The two tunnel options that effect this behavior are `Startup Action` and `DPD Timeout Action`. See [VPN tunnel options](VPNTunnels.md) and [VPN tunnel initiation options](initiate-vpn-tunnels.md) for more information. + Site-to-Site VPN connections that use certificate-based authentication might not be compatible with AWS Global Accelerator, due to limited support for packet fragmentation in Global Accelerator. For more information, see [How AWS Global Accelerator works](https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-how-it-works.html). If you require an accelerated VPN connection that uses certificate-based authentication, then your customer gateway device must support IKE fragmentation. Otherwise, do not enable your VPN for acceleration. # AWS Site-to-Site VPN routing options Site-to-Site VPN routing options AWS recommends advertising specific BGP routes to influence routing decisions in the virtual private gateway. Check your vendor documentation for the commands that are specific to your device. When you create multiple VPN connections, the virtual private gateway sends network traffic to the appropriate VPN connection using statically assigned routes or BGP route advertisements. Which route depends on how the VPN connection was configured. Statically assigned routes are preferred over BGP advertised routes in cases where identical routes exist in the virtual private gateway. If you select the option to use BGP advertisement, then you cannot specify static routes. For more information about route priority, see [Route tables and route priority](vpn-route-priority.md). When you create a Site-to-Site VPN connection, you must do the following: + Specify the type of routing that you plan to use (static or dynamic) + Update the [route table](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) for your subnet There are quotas on the number of routes that you can add to a route table. For more information, see the Route Tables section in [Amazon VPC quotas](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html) in the *Amazon VPC User Guide*. **Topics** + [Static and dynamic routing](vpn-static-dynamic.md) + [Route tables and route priority](vpn-route-priority.md) + [Routing during VPN tunnel endpoint updates](routing-vpn-tunnel-updates.md) + [IPv4 and IPv6 traffic](ipv4-ipv6.md) # Static and dynamic routing in AWS Site-to-Site VPN Static and dynamic routing The type of routing that you select can depend on the make and model of your customer gateway device. If your customer gateway device supports Border Gateway Protocol (BGP), specify dynamic routing when you configure your Site-to-Site VPN connection. If your customer gateway device does not support BGP, specify static routing. **Note** Site-to-Site VPN Concentrators only support BGP routing. Static routing is not supported for VPN connections that use a Site-to-Site VPN Concentrator. If you use a device that supports BGP advertising, you don't specify static routes to the Site-to-Site VPN connection because the device uses BGP to advertise its routes to the virtual private gateway. If you use a device that doesn't support BGP advertising, you must select static routing and enter the routes (IP prefixes) for your network that should be communicated to the virtual private gateway. We recommend that you use BGP-capable devices, when available, because the BGP protocol offers robust liveness detection checks that can assist failover to the second VPN tunnel if the first tunnel goes down. Devices that don't support BGP may also perform health checks to assist failover to the second tunnel when needed. You must configure your customer gateway device to route traffic from your on-premises network to the Site-to-Site VPN connection. The configuration depends on the make and model of your device. For more information, see [AWS Site-to-Site VPN customer gateway devices](your-cgw.md). # Route tables and AWS Site-to-Site VPN route priority Route tables and route priority [Route tables](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) determine where network traffic from your VPC is directed. In your VPC route table, you must add a route for your remote network and specify the virtual private gateway as the target. This enables traffic from your VPC that's destined for your remote network to route via the virtual private gateway and over one of the VPN tunnels. You can enable route propagation for your route table to automatically propagate your network routes to the table for you. We use the most specific route in your route table that matches the traffic to determine how to route the traffic (longest prefix match). If your route table has overlapping or matching routes, the following rules apply: + If propagated routes from a Site-to-Site VPN connection or Direct Connect connection overlap with the local route for your VPC, the local route is most preferred even if the propagated routes are more specific. + If propagated routes from a Site-to-Site VPN connection or Direct Connect connection have the same destination CIDR block as other existing static routes (longest prefix match cannot be applied), we prioritize the static routes whose targets are an internet gateway, a virtual private gateway, a network interface, an instance ID, a VPC peering connection, a NAT gateway, a transit gateway, or a gateway VPC endpoint. For example, the following route table has a static route to an internet gateway, and a propagated route to a virtual private gateway. Both routes have a destination of `172.31.0.0/24`. In this case, all traffic destined for `172.31.0.0/24` is routed to the internet gateway — it is a static route and therefore takes priority over the propagated route. | Destination | Target | | --- | --- | | 10.0.0.0/16 | Local | | 172.31.0.0/24 | vgw-11223344556677889 (propagated) | | 172.31.0.0/24 | igw-12345678901234567 (static) | Only IP prefixes that are known to the virtual private gateway, whether through BGP advertisements or a static route entry, can receive traffic from your VPC. The virtual private gateway does not route any other traffic destined outside of received BGP advertisements, static route entries, or its attached VPC CIDR. Virtual private gateways do not support IPv6 traffic. When a virtual private gateway receives routing information, it uses path selection to determine how to route traffic. Longest prefix match applies, if all endpoints are healthy. The health of a tunnel endpoint takes precedence over other routing attributes. This precedence applies to VPNs on virtual private gateways and Transit Gateways. If the prefixes are the same, then the virtual private gateway prioritizes routes as follows, from most preferred to least preferred: + BGP propagated routes from an Direct Connect connection Blackhole routes are not propagated to a Site-to-Site VPN customer gateway via BGP. + Manually added static routes for a Site-to-Site VPN connection + BGP propagated routes from a Site-to-Site VPN connection + For matching prefixes where each Site-to-Site VPN connection uses BGP, the AS PATH is compared and the prefix with the shortest AS PATH is preferred. **Note** AWS strongly recommends using customer gateway devices that support asymmetric routing. For customer gateway devices that support asymmetric routing, we *do not* recommend using AS PATH prepending, to ensure that both tunnels have equal AS PATH. This helps to ensure that the multi-exit discriminator (MED) value that we set on a tunnel during [VPN tunnel endpoint updates](routing-vpn-tunnel-updates.md) is used to determine tunnel priority. For customer gateway devices that do not support asymmetric routing, you can use AS PATH prepending and Local Preference to prefer one tunnel over the other. However, when the egress path changes, this may cause traffic to drop. + When the AS PATHs are the same length and if the first AS in the AS\$1SEQUENCE is the same across multiple paths, multi-exit discriminators (MEDs) are compared. The path with the lowest MED value is preferred. Route priority is affected during [VPN tunnel endpoint updates](routing-vpn-tunnel-updates.md). On a Site-to-Site VPN connection, AWS selects one of the two redundant tunnels as the primary egress path. This selection may change at times, and we strongly recommend that you configure both tunnels for high availability, and allow asymmetric routing. The health of a tunnel endpoint takes precedence over other routing attributes. This precedence applies to VPNs on virtual private gateways and Transit Gateways. For a virtual private gateway, one tunnel across all Site-to-Site VPN connections on the gateway will be selected. To use more than one tunnel, we recommend exploring Equal Cost Multipath (ECMP), which is supported for Site-to-Site VPN connections on a transit gateway. For more information, see [Transit gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html) in *Amazon VPC Transit Gateways*. ECMP is not supported for Site-to-Site VPN connections on a virtual private gateway. For Site-to-Site VPN connections that use BGP, the primary tunnel can be identified by the multi-exit discriminator (MED) value. We recommend advertising more specific BGP routes to influence routing decisions. For Site-to-Site VPN connections that use static routing, the primary tunnel can be identified by traffic statistics or metrics. # Routing during VPN tunnel endpoint updates Routing during VPN tunnel endpoint updates A Site-to-Site VPN connection consists of two VPN tunnels between a customer gateway device and a virtual private gateway or a transit gateway. We recommend that you configure both tunnels for redundancy. From time to time, AWS also performs routine maintenance on your VPN connection, which might briefly disable one of the two tunnels of your VPN connection. For more information, see [Tunnel endpoint replacement notifications](monitoring-vpn-health-events.md#tunnel-replacement-notifications). When we perform updates on one VPN tunnel, we set a lower outbound multi-exit discriminator (MED) value on the other tunnel. If you have configured your customer gateway device to use both tunnels, your VPN connection uses the other (up) tunnel during the tunnel endpoint update process. **Note** To ensure that the up tunnel with the lower MED is preferred, ensure that your customer gateway device uses the same Weight and Local Preference values for both tunnels (Weight and Local Preference have higher priority than MED). # IPv4 and IPv6 traffic in AWS Site-to-Site VPN IPv4 and IPv6 traffic Your Site-to-Site VPN connection on a transit gateway can support either IPv4 traffic or IPv6 traffic inside the VPN tunnels. By default, a Site-to-Site VPN connection supports IPv4 traffic inside the VPN tunnels. You can configure a new Site-to-Site VPN connection to support IPv6 traffic inside the VPN tunnels. Then, if your VPC and your on-premises network are configured for IPv6 addressing, you can send IPv6 traffic over the VPN connection. If you enable IPv6 for the VPN tunnels for your Site-to-Site VPN connection, each tunnel has two CIDR blocks. One is a size /30 IPv4 CIDR block, and the other is a size /126 IPv6 CIDR block. ## IPv4 and IPv6 support Site-to-Site VPN VPN connections support the following IP configurations: + **IPv4 outer tunnel with IPv4 inner packets** - The basic IPv4 VPN capability supported on virtual private gateways, transit gateways, and Cloud WAN. + **IPv4 outer tunnel with IPv6 inner packets** - Allows IPv6 applications/transport within the VPN tunnel. Supported on transit gateways and Cloud WAN. This is not supported for virtual private gateways. + **IPv6 outer tunnel with IPv6 inner packets** - Allows full IPv6 migration with IPv6 addresses for both outer tunnel IPs and inner packet IPs. Supported for both transit gateways and Cloud WAN. + **IPv6 outer tunnel with IPv4 inner packets** - Allows IPv6 outer tunnel addressing while supporting legacy IPv4 applications within the tunnel. Supported for both transit gateways and Cloud WAN. The following rules apply: + IPv6 addresses for outer tunnel IPs are supported only on Site-to-Site VPN connections that are terminated on a transit gateway or Cloud WAN. Site-to-Site VPN connections on a virtual private gateways do not support IPv6 for outer tunnel IPs. + When using IPv6 for outer tunnel IPs, you must assign IPv6 addresses on both the AWS side of the VPN connection and your customer gateway for both VPN tunnels. + You cannot enable IPv6 support for an existing Site-to-Site VPN connection. You must delete the existing connection and create a new one. + A Site-to-Site VPN connection cannot support both IPv4 and IPv6 traffic simultaneously. The inner encapsulated packets can be either IPv6 or IPv4, but not both. You need separate Site-to-Site VPN connections to transport IPv4 and IPv6 packets. + Private IP VPNs do not support IPv6 addresses for outer tunnel IPs. They use either RFC 1918 or CGNAT addresses. For more information about RFC 1918, see [RFC 1918 - Address Allocation for Private Internets](https://datatracker.ietf.org/doc/html/rfc1918). + IPv6 VPNs support the same throughput (Gbps and PPS), MTU, and route limits as IPv4 VPNs. + The IPSec encryption and key exchange work the same way for both IPv4 and IPv6 VPNs. For more information about creating a VPN connection with IPv6 support, see [Create a VPN connection](SetUpVPNConnections.md#vpn-create-vpn-connection) in Get Started with Site-to-Site VPN. # AWS Site-to-Site VPN Concentrators VPN Concentrators AWS Site-to-Site VPN Concentrator is a new feature that simplifies multi-site connectivity for distributed enterprises. VPN Concentrator is suitable for customers who need to connect 25\$1 remote sites to AWS, with each site needing low bandwidth (under 100 Mbps). ## Supported gateway services and features VPN Concentrators are only supported with Transit Gateway. This feature is not supported with Cloud WAN or Virtual Private Gateway. The following table describes Site-to-Site VPN Concentrator supported features: | Feature | Supported? | | --- | --- | | IPv6 | Yes | | Private Direct Connect VPN connections | No | | Accelerated VPN | Yes | | Multiple customer gateway devices from the same site | Yes. However, each customer gateway device must have a unique IP address. | | Geographical restrictions | No. You can attach a site located in any region to a Concentrator in any AWS Region. | | Site-to-Site VPN logs | Yes. You can generate VPN logs for all sites connected to the Concentrator or individually. | | Transit Gateway Encryption Support | No | ## Bandwidth Currently, Site-to-Site VPN Concentrators support 5 Gbps aggregate bandwidth. Each site can support a maximum of 100 Mbps bandwidth. However, if you need higher bandwidth, reach out to AWS Support. ## Routing Site-to-Site VPN Concentrators support BGP (Border Gateway Protocol) routing only. Static routing is not supported. All customer gateways connected to the Site-to-Site VPNConcentrator use the same Site-to-Site VPN Concentrator attachment to the transit gateway for routing. Each site connecting to the Site-to-Site VPN Concentrator can send a maximum of 5,000 routes from the transit gateway to a customer gateway and 1,000 routes from the customer gateway to the transit gateway. ## IP address allocation Each VPN connection through the Site-to-Site VPN Concentrator will still have a unique AWS IP address (one per tunnel). ## Monitoring VPN connections via Site-to-Site VPN Concentrators support the same metrics as regular VPN connections. When you enable Transit gateway flow logs on the VPN Concentrator attachment, you will see flow logs for all the traffic coming in and going out of all the remote sites connected to the concentrator. ## Tunnel maintenance The tunnel maintenance works the same way as existing standard Site-to-Site VPN tunnels for both endpoints when using a Site-to-Site VPN Concentrator. See [Endpoint replacements](endpoint-replacements.md) for more information. ## Pricing Information about pricing for Site-to-Site VPN Concentrator can be found on the [ AWS VPN pricing ](http://aws.amazon.com/vpn/pricing/) page.