# Subnets for your VPC
<a name="configure-subnets"></a>

A *subnet* is a range of IP addresses in your VPC. You can create AWS resources, such as EC2 instances, in specific subnets.

**Topics**
+ [

## Subnet basics
](#subnet-basics)
+ [

## Subnet security
](#subnet-security)
+ [

# Create a subnet
](create-subnets.md)
+ [

# Add or remove an IPv6 CIDR block from your subnet
](subnet-associate-ipv6-cidr.md)
+ [

# Modify the IP addressing attributes of your subnet
](subnet-public-ip.md)
+ [Subnet CIDR reservations](subnet-cidr-reservation.md)
+ [Route tables](VPC_Route_Tables.md)
+ [

# Middlebox routing wizard
](middlebox-routing-console.md)
+ [

# Delete a subnet
](subnet-deleting.md)

## Subnet basics
<a name="subnet-basics"></a>

Each subnet must reside entirely within one Availability Zone and cannot span zones. By launching AWS resources in separate Availability Zones, you can protect your applications from the failure of a single Availability Zone.

**Topics**
+ [

### Subnet IP address range
](#subnet-ip-address-range)
+ [

### Subnet types
](#subnet-types)
+ [

### Subnet diagram
](#subnet-diagram)
+ [

### Subnet routing
](#subnet-routing)
+ [

### Subnet settings
](#subnet-settings)

### Subnet IP address range
<a name="subnet-ip-address-range"></a>

When you create a subnet, you specify its IP addresses, depending on the configuration of the VPC:
+ **IPv4 only** – The subnet has an IPv4 CIDR block but does not have an IPv6 CIDR block. Resources in an IPv4-only subnet must communicate over IPv4.
+ **Dual stack** – The subnet has both an IPv4 CIDR block and an IPv6 CIDR block. The VPC must have both an IPv4 CIDR block and an IPv6 CIDR block. Resources in a dual-stack subnet can communicate over IPv4 and IPv6.
+ **IPv6 only** – The subnet has an IPv6 CIDR block but does not have an IPv4 CIDR block. The VPC must have an IPv6 CIDR block. Resources in an IPv6-only subnet must communicate over IPv6.
**Note**  
Resources in IPv6-only subnets are assigned IPv4 link-local addresses from CIDR block 169.254.0.0/16. These addresses are used to communicate with services that are available only in the VPC. For examples, see [Link-local addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#link-local-addresses) in the *Amazon EC2 User Guide*. 

For more information, see [IP addressing for your VPCs and subnets](vpc-ip-addressing.md).

### Subnet types
<a name="subnet-types"></a>

The subnet type is determined by how you configure routing for your subnets. For example:
+ **Public subnet** – The subnet has a direct route to an [internet gateway](VPC_Internet_Gateway.md). Resources in a public subnet can access the public internet.
+ **Private subnet** – The subnet does not have a direct route to an internet gateway. Resources in a private subnet require a [NAT device](vpc-nat.md) to access the public internet.
+ **VPN-only subnet** – The subnet has a route to a [Site-to-Site VPN connection](https://docs.aws.amazon.com/vpn/latest/s2svpn/) through a virtual private gateway. The subnet does not have a route to an internet gateway.
+ **Isolated subnet** – The subnet has no routes to destinations outside its VPC. Resources in an isolated subnet can only access or be accessed by other resources in the same VPC.
+ **EVS subnet** – This type of subnet is created using Amazon EVS. For more information, see [VLAN subnet](https://docs.aws.amazon.com/evs/latest/userguide/concepts.html#concepts-evs-network) in the *Amazon EVS User Guide*.

### Subnet diagram
<a name="subnet-diagram"></a>

The following diagram shows a VPC with subnets in two Availability Zones and an internet gateway. Each Availability Zone has a public subnet and a private subnet.

![\[A VPC with subnets in two Availability Zones.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/subnet-diagram.png)


For diagrams that show subnets in Local Zones and Wavelength Zones, see [How AWS Local Zones work](https://docs.aws.amazon.com/local-zones/latest/ug/how-local-zones-work.html) and [How AWS Wavelength works](https://docs.aws.amazon.com/wavelength/latest/developerguide/how-wavelengths-work.html).

### Subnet routing
<a name="subnet-routing"></a>

Each subnet must be associated with a route table, which specifies the allowed routes for outbound traffic leaving the subnet. Every subnet that you create is automatically associated with the main route table for the VPC. You can change the association, and you can change the contents of the main route table. For more information, see [Configure route tables](VPC_Route_Tables.md).

### Subnet settings
<a name="subnet-settings"></a>

All subnets have a modifiable attribute that determines whether a network interface created in that subnet is assigned a public IPv4 address and, if applicable, an IPv6 address. This includes the primary network interface (for example, eth0) that's created for an instance when you launch an instance in that subnet. Regardless of the subnet attribute, you can still override this setting for a specific instance during launch.

After you create a subnet, you can modify the following settings for the subnet:
+ **Auto-assign IP settings**: Enables you to configure the auto-assign IP settings to automatically request a public IPv4 or IPv6 address for a new network interface in this subnet.
+ **Resource-based Name (RBN) settings**: Enables you to specify the hostname type for EC2 instances in this subnet and configure how DNS A and AAAA record queries are handled. For more information, see [Amazon EC2 instance hostname types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html) in the *Amazon EC2 User Guide*.

## Subnet security
<a name="subnet-security"></a>

To protect your AWS resources, we recommend that you use private subnets. Use a bastion host or NAT device to provide internet access to resources, such as EC2 instances, in a private subnet.

AWS provides features that you can use to increase security for the resources in your VPC. *Security groups* allow inbound and outbound traffic for associated resources, such as EC2 instances. *Network ACLs* allow or deny inbound and outbound traffic at the subnet level. In most cases, security groups can meet your needs. However, you can use network ACLs if you want an additional layer of security. For more information, see [Compare security groups and network ACLs](infrastructure-security.md#VPC_Security_Comparison).

By design, each subnet must be associated with a network ACL. Every subnet that you create is automatically associated with the default network ACL for the VPC. The default network ACL allows all inbound and outbound traffic. You can update the default network ACL, or create custom network ACLs and associate them with your subnets. For more information, see [Control subnet traffic with network access control lists](vpc-network-acls.md).

You can create a flow log on your VPC or subnet to capture the traffic that flows to and from the network interfaces in your VPC or subnet. You can also create a flow log on an individual network interface. For more information, see [Logging IP traffic using VPC Flow Logs](flow-logs.md).

# Create a subnet
<a name="create-subnets"></a>

Use the following procedure to create subnets for your virtual private cloud (VPC). Depending on the connectivity that you need, you might also need to add gateways and route tables.

**Considerations**
+ You must specify an IPv4 CIDR block for the subnet from the range of your VPC. You can optionally specify an IPv6 CIDR block for a subnet if there is an IPv6 CIDR block associated with the VPC. For more information, see [IP addressing for your VPCs and subnets](vpc-ip-addressing.md).
+ If you create an IPv6-only subnet, be aware of the following. An EC2 instance launched in an IPv6-only subnet receives an IPv6 address but not an IPv4 address. Any instances that you launch into an IPv6-only subnet must be [instances built on the Nitro System](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html).
+ To create the subnet in a Local Zone or a Wavelength Zone, you must enable the Zone. For more information, see [Regions and Zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) in the *Amazon EC2 User Guide*.

**To add a subnet to your VPC**

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

1. Choose **Create subnet**.

1. Under **VPC ID**, choose the VPC for the subnet.

1. (Optional) For **Subnet name**, enter a name for your subnet. Doing so creates a tag with a key of `Name` and the value that you specify.

1. For **Availability Zone**, you can choose a Zone for your subnet, or leave the default **No Preference** to let AWS choose one for you.

1. For **IPv4 CIDR block**, select **Manual input** to enter an IPv4 CIDR block for your subnet (for example, `10.0.1.0/24`) or select **No IPv4 CIDR**. If you are using Amazon VPC IP Address Manager (IPAM) to plan, track, and monitor IP addresses for your AWS workloads, when you create a subnet you have the option to allocate a CIDR block from IPAM (**IPAM-allocated**). For more information on planning VPC IP address space for subnet IP allocations, see [Tutorial: Plan VPC IP address space for subnet IP allocations](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-subnet-planning.html) in the *Amazon VPC IPAM User Guide*.

1. For **IPv6 CIDR block**, select **Manual input** to choose the VPC's IPv6 CIDR that you want to create a subnet in. This option is available only if the VPC has an associated IPv6 CIDR block. If you are using Amazon VPC IP Address Manager (IPAM) to plan, track, and monitor IP addresses for your AWS workloads, when you create a subnet you have the option to allocate a CIDR block from IPAM (**IPAM-allocated**). For more information on planning VPC IP address space for subnet IP allocations, see [Tutorial: Plan VPC IP address space for subnet IP allocations](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-subnet-planning.html) in the *Amazon VPC IPAM User Guide*.

1. Choose an **IPv6 VPC CIDR block**.

1. For **IPv6 subnet CIDR block**, choose a CIDR for the subnet that's equal to or more specific than the VPC CIDR. For example, if the VPC pool CIDR is /50, you can choose a netmask length between **/50** to **/64** for the subnet. Possible IPv6 netmask lengths are between **/44** and **/64** in increments of /4.

1. Choose **Create subnet**.

**To add a subnet to your VPC using the AWS CLI**  
Use the [create-subnet](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-subnet.html) command.

**Next steps**

After you create a subnet, you can configure it as follows:
+ Configure routing. You can then create a custom route table and route that send traffic to a gateway that's associated with the VPC, such as an internet gateway. For more information, see [Configure route tables](VPC_Route_Tables.md).
+ Modify the IP addressing behavior. You can specify whether instances launched in the subnet receive a public IPv4 address, an IPv6 address, or both. For more information, see [Modify the IP addressing attributes of your subnet](subnet-public-ip.md).
+ Modify the resource-based name (RBN) settings. For more information, see [Amazon EC2 instance hostname types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html#instance-naming-modify-instances).
+ Create or modify your network ACLs. For more information, see [Control subnet traffic with network access control lists](vpc-network-acls.md).
+ Share the subnet with other accounts. For more information, see [Share a subnet](vpc-sharing-share-subnet-working-with.md#vpc-sharing-share-subnet).

# Add or remove an IPv6 CIDR block from your subnet
<a name="subnet-associate-ipv6-cidr"></a>

You can associate an IPv6 CIDR block with an existing subnet in your VPC. The subnet must not have an existing IPv6 CIDR block associated with it. 

If you no longer want IPv6 support in your subnet, but you want to continue to use your subnet to create and communicate with IPv4 resources, you can remove the IPv6 CIDR block.

Before you can remove an IPv6 CIDR block, you must first unassign any IPv6 addresses that are assigned to any instances in your subnet.

**To add or remove an IPv6 CIDR block to a subnet**

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

1. Select your subnet and choose **Actions**, **Edit IPv6 CIDRs**.

1. To add a CIDR, choose **Add IPv6 CIDR**, choose a **VPC CIDR block**, enter a **Subnet CIDR block**, and choose a netmask length that's equal to or more specific than the netmask length of the VPC CIDR. For example, if the VPC pool CIDR is /50, you can choose a netmask length between **/50** to **/64** for the subnet. Possible IPv6 netmask lengths are between **/44** and **/64** in increments of /4.

1. To remove a CIDR, find the IPv6 CIDR block and choose **Remove**.

1. Choose **Save**.

**To associate an IPv6 CIDR block with a subnet using the AWS CLI**  
Use the [associate-subnet-cidr-block](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-subnet-cidr-block.html) command.

**To disassociate an IPv6 CIDR block from a subnet using the AWS CLI**  
Use the [disassociate-subnet-cidr-block](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-subnet-cidr-block.html) command.

# Modify the IP addressing attributes of your subnet
<a name="subnet-public-ip"></a>

By default, nondefault subnets have the IPv4 public addressing attribute set to `false`, and default subnets have this attribute set to `true`. An exception is a nondefault subnet created by the Amazon EC2 launch instance wizard — the wizard sets the attribute to `true`. You can modify this attribute using the Amazon VPC console.

By default, all subnets have the IPv6 addressing attribute set to `false`. You can modify this attribute using the Amazon VPC console. If you enable the IPv6 addressing attribute for your subnet, network interfaces created in the subnet receive an IPv6 address from the range of the subnet. Instances launched into the subnet receive an IPv6 address on the primary network interface. 

Your subnet must have an associated IPv6 CIDR block.

**Note**  
If you enable the IPv6 addressing feature for your subnet, your network interface or instance only receives an IPv6 address if it's created using version `2016-11-15` or later of the Amazon EC2 API. The Amazon EC2 console uses the latest API version.

**To modify your subnet's IP addressing behavior**

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

1. Select your subnet and choose **Actions**, **Edit subnet settings**.

1. The **Enable auto-assign public IPv4 address** check box, if selected, requests a public IPv4 address for all instances launched into the selected subnet. Select or clear the check box as required, and then choose **Save**.

1. The **Enable auto-assign IPv6 address** check box, if selected, requests an IPv6 address for all network interfaces created in the selected subnet. Select or clear the check box as required, and then choose **Save**.

**To modify a subnet attribute using the AWS CLI**  
Use the [modify-subnet-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-subnet-attribute.html) command.

# Subnet CIDR reservations
<a name="subnet-cidr-reservation"></a>

A *subnet CIDR reservation* is a range of IPv4 or IPv6 addresses that you set aside so that AWS won't assign them to your network interfaces. This enables you to reserve IPv4 or IPv6 CIDR blocks (also called "prefixes") for use with your network interfaces.

When you create a subnet CIDR reservation, you specify how you will use the reserved IP addresses. The following options are available:
+ **Prefix** — Allows you to assign a prefix to a single network interface. For more information, see [Assign prefixes to Amazon EC2 network interfaces](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-prefix-eni.html) in the *Amazon EC2 User Guide*.
+ **Explicit** — Allows you to manually assign an individual IP address to a single network interface. 

The following rules apply to subnet CIDR reservations:
+ When you create a subnet CIDR reservation, the IP address range can include addresses that are already in use. Creating a subnet reservation does not unassign any IP addresses that are already in use.
+ You can reserve multiple CIDR ranges per subnet. When you reserve multiple CIDR ranges within the same VPC, the CIDR ranges can't overlap.
+ When you reserve more than one range in a subnet for Prefix Delegation, and Prefix Delegation is configured for automatic assignment, we choose the IP addresses to assign to network interfaces at random.
+ When you delete a subnet reservation, the unused IP addresses are available for AWS to assign to your network interfaces. Deleting a subnet reservation does not unassign any IP addresses that are in use.
+ The reservation type affects the count of available IP addresses for the subnet. If you create a prefix reservation, the count decreases immediately. If you create an explicit prefix reservation, the count decreases when the IP addresses are assigned.

For more information about Classless Inter-Domain Routing (CIDR) notation, see [IP addressing for your VPCs and subnets](vpc-ip-addressing.md).

**Topics**
+ [

## Work with subnet CIDR reservations using the console
](#edit-subnet-cidr-reservations)
+ [

## Work with subnet CIDR reservations using the AWS CLI
](#work-with-subnet-cidr-reservations)

## Work with subnet CIDR reservations using the console
<a name="edit-subnet-cidr-reservations"></a>

You can create and manage subnet CIDR reservations as follows.

**To edit subnet CIDR reservations**

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

1. Select the subnet.

1. Choose the **CIDR reservations** tab to get information about any existing subnet CIDR reservations.

1. To add or remove subnet CIDR reservations, choose **Actions**, **Edit CIDR reservations** and then do the following:
   + To add an IPv4 CIDR reservation, choose **IPv4**, **Add IPv4 CIDR reservation**. Choose the reservation type, enter the CIDR range, and choose **Add**.
   + To add an IPv6 CIDR reservation, choose **IPv6**, **Add IPv6 CIDR reservation**. Choose the reservation type, enter the CIDR range, and choose **Add**.
   + To remove a CIDR reservation, choose **Remove** for the subnet CIDR reservation.

## Work with subnet CIDR reservations using the AWS CLI
<a name="work-with-subnet-cidr-reservations"></a>

You can use the AWS CLI to create and manage subnet CIDR reservations.

**Topics**
+ [

### Create a subnet CIDR reservation
](#Create-subnet-cidr-reservations)
+ [

### View subnet CIDR reservations
](#view-subnet-cidr-reservations)
+ [

### Delete a subnet CIDR reservation
](#delete-subnet-cidr-reservations)

### Create a subnet CIDR reservation
<a name="Create-subnet-cidr-reservations"></a>

You can use [create-subnet-cidr-reservation](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-subnet-cidr-reservation.html) to create a subnet CIDR reservation.

```
aws ec2 create-subnet-cidr-reservation --subnet-id subnet-03c51e2eEXAMPLE --reservation-type prefix --cidr 2600:1f13:925:d240:3a1b::/80
```

The following is example output.

```
{
    "SubnetCidrReservation": {
        "SubnetCidrReservationId": "scr-044f977c4eEXAMPLE",
        "SubnetId": "subnet-03c51e2ef5EXAMPLE",
        "Cidr": "2600:1f13:925:d240:3a1b::/80",
        "ReservationType": "prefix",
        "OwnerId": "123456789012"
    }
}
```

### View subnet CIDR reservations
<a name="view-subnet-cidr-reservations"></a>

You can use [get-subnet-cidr-reservations](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-subnet-cidr-reservations.html) to view the details of a subnet CIDR reservation.

```
aws ec2 get-subnet-cidr-reservations --subnet-id subnet-05eef9fb78EXAMPLE
```

### Delete a subnet CIDR reservation
<a name="delete-subnet-cidr-reservations"></a>

You can use [delete-subnet-cidr-reservation](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-subnet-cidr-reservation.html) to delete a subnet CIDR reservation.

```
aws ec2 delete-subnet-cidr-reservation --subnet-cidr-reservation-id scr-044f977c4eEXAMPLE
```

# Configure route tables
<a name="VPC_Route_Tables"></a>

A *route table* serves as the traffic controller for your virtual private cloud (VPC). Each route table contains a set of rules, called *routes*, that determine where network traffic from your subnet or gateway is directed. When you create a VPC, we also create the main route table for the VPC. You can create additional route tables for your VPC, so that you have more granular control over the network paths for your VPC.

You can use route tables to specify which networks your VPC can communicate with, such as other VPCs or on-premises networks. Each route specifies a destination (CIDR block or prefix list) and a target (such as an internet gateway, NAT gateway, VPC peering connection, or VPN connection). Traffic is routed to targets based on its destination IP address. Route tables enable you to create complex networking architectures that include public subnets, private subnets, VPN-only subnets, and isolated subnets.

**Topics**
+ [

# Route table concepts
](RouteTables.md)
+ [

# Subnet route tables
](subnet-route-tables.md)
+ [

# Gateway route tables
](gateway-route-tables.md)
+ [Route priority](route-tables-priority.md)
+ [

# Example routing options
](route-table-options.md)
+ [Create a route table and routes](create-vpc-route-table.md)
+ [

# Manage subnet route tables
](WorkWithRouteTables.md)
+ [

# Replace the main route table
](Route_Replacing_Main_Table.md)
+ [Associate a route table with a gateway](associate-route-table-gateway.md)
+ [

# Replace or restore the target for a local route
](replace-local-route-target.md)
+ [Advanced routing](advanced-routing.md)
+ [Troubleshoot reachability issues](route-table-routes-troubleshoot.md)

# Route table concepts
<a name="RouteTables"></a>

The following are the key concepts for route tables:
+ **Main route table**—The route table that automatically comes with your VPC. It controls the routing for all subnets that are not explicitly associated with any other route table.
+ **Custom route table**—A route table that you create for your VPC.
+ **Destination**—The range of IP addresses where you want traffic to go (destination CIDR). For example, an external corporate network with the CIDR `172.16.0.0/12`.
+ **Target**—The gateway, network interface, or connection through which to send the destination traffic; for example, an internet gateway.
+ **Local route**—A default route for communication within the VPC. If the VPC has both IPv4 and IPV6 addresses, there is a local route for IPv4 and a local route for IPv6.
+ **Route table association**—The association between a route table and a subnet, internet gateway, or virtual private gateway.
+ **Subnet route table**—A route table that's associated with a subnet.
+ **Propagation**—If you've attached a virtual private gateway to your VPC and enable route propagation, we automatically add routes for your VPN connection to your subnet route tables. This means that you don't need to manually add or remove VPN routes. For more information, see [Site-to-Site VPN routing options](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html) in the *Site-to-Site VPN User Guide*.
+ **Gateway route table**—A route table that's associated with an internet gateway or virtual private gateway.
+ **Edge association**—A route table that you use to route inbound VPC traffic to an appliance. You associate a route table with the internet gateway or virtual private gateway, and specify the network interface of your appliance as the target for VPC traffic.
+ **Transit gateway route table**—A route table that's associated with a transit gateway. For more information, see [Transit gateway route tables](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html) in *Amazon VPC Transit Gateways*.
+ **Local gateway route table**—A route table that's associated with an Outposts local gateway. For more information, see [Local gateways](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html) in the *AWS Outposts User Guide*.

## Example VPC with route tables
<a name="route-table-example-diagram"></a>

The following diagram shows a VPC with five subnets, a main route table, and three custom route tables. All four route tables have local routes. Custom route table 1 has a route to an internet gateway, and it is associated with the public subnet in Availability Zone A. Custom route table 2 has a route to a peered VPC, and it is associated with the private subnet in Availability Zone B. Custom route table 3 has a route to a virtual private gateway, and it is associated with the VPN-only subnets in both Availability Zones.

![\[VPC with subnets in 2 AZs, 3 route tables, internet gateway, and gateway endpoint\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/route-tables.png)


# Subnet route tables
<a name="subnet-route-tables"></a>

Your VPC has an implicit router, and you use route tables to control where network traffic is directed. Each subnet in your VPC must be associated with a route table, which controls the routing for the subnet (subnet route table). You can explicitly associate a subnet with a particular route table. Otherwise, the subnet is implicitly associated with the main route table. A subnet can only be associated with one route table at a time, but you can associate multiple subnets with the same subnet route table.

**Topics**
+ [

## Routes
](#route-table-routes)
+ [

## Main route table
](#main-route-table)
+ [

## Custom route tables
](#custom-route-tables)
+ [

## Subnet route table association
](#route-table-assocation)

## Routes
<a name="route-table-routes"></a>

Each route in a table specifies a destination and a target. For example, to enable your subnet to access the internet through an internet gateway, add the following route to your subnet route table. The destination for the route is `0.0.0.0/0`, which represents all IPv4 addresses. The target is the internet gateway that's attached to your VPC.


| Destination | Target | 
| --- | --- | 
| 0.0.0.0/0 | igw-id | 

CIDR blocks for IPv4 and IPv6 are treated separately. For example, a route with a destination CIDR of `0.0.0.0/0` does not automatically include all IPv6 addresses. You must create a route with a destination CIDR of `::/0` for all IPv6 addresses.

If you frequently reference the same set of CIDR blocks across your AWS resources, you can create a [customer-managed prefix list](managed-prefix-lists.md) to group them together. You can then specify the prefix list as the destination in your route table entry. 

Every route table contains a local route for communication within the VPC. This route is added by default to all route tables. If your VPC has more than one IPv4 CIDR block, your route tables contain a local route for each IPv4 CIDR block. If you've associated an IPv6 CIDR block with your VPC, your route tables contain a local route for the IPv6 CIDR block. You can [replace or restore](replace-local-route-target.md) the target of each local route as needed.<a name="route-table-rule-considerations"></a>

**Rules and considerations**
+ You can add a route to your route tables that is more specific than the local route. The destination must match the entire IPv4 or IPv6 CIDR block of a subnet in your VPC. The target must be a NAT gateway, network interface, or Gateway Load Balancer endpoint.
+ If your route table has multiple routes, we use the most specific route that matches the traffic (longest prefix match) to determine how to route the traffic.
+ You can't add routes to IPv4 addresses that are an exact match or a subset of the following range: 169.254.168.0/22. This range is within the link-local address space and is reserved for use by AWS services. For example, Amazon EC2 uses addresses in this range for services that are accessible only from EC2 instances, such as the Instance Metadata Service (IMDS) and the Amazon DNS server. You can use a CIDR block that is larger than but overlaps 169.254.168.0/22, but packets destined for addresses in 169.254.168.0/22 will not be forwarded.
+ You can't add routes to IPv6 addresses that are an exact match or a subset of the following range: fd00:ec2::/32. This range is within the unique local address (ULA) space and is reserved for use by AWS services. For example, Amazon EC2 uses addresses in this range for services that are accessible only from EC2 instances, such as the Instance Metadata Service (IMDS) and the Amazon DNS server. You can use a CIDR block that is larger than but overlaps fd00:ec2::/32, but packets destined for addresses in fd00:ec2::/32 will not be forwarded.
+ You can add middlebox appliances to the routing paths for your VPC. For more information, see [Routing for a middlebox appliance](route-table-options.md#route-tables-appliance-routing).

**Example**  
In the following example, suppose that the VPC has both an IPv4 CIDR block and an IPv6 CIDR block. IPv4 and IPv6 traffic are treated separately, as shown in the following route table.


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | Local | 
| 2001:db8:1234:1a00::/56 | Local | 
| 172.31.0.0/16 | pcx-11223344556677889 | 
| 0.0.0.0/0 | igw-12345678901234567 | 
| ::/0 | eigw-aabbccddee1122334 | 
+ IPv4 traffic to be routed within the VPC (10.0.0.0/16) is covered by the Local route.
+ IPv6 traffic to be routed within the VPC (2001:db8:1234:1a00::/56) is covered by the Local route.
+ The route for 172.31.0.0/16 sends traffic to a peering connection.
+ The route for all IPv4 traffic (0.0.0.0/0) sends traffic to an internet gateway. Therefore, all IPv4 traffic, except for traffic within the VPC and to the peering connection, is routed to the internet gateway.
+ The route for all IPv6 traffic (::/0) sends traffic to an egress-only internet gateway. Therefore, all IPv6 traffic, except for traffic within the VPC, is routed to the egress-only internet gateway.

## Main route table
<a name="main-route-table"></a>

When you create a VPC, it automatically has a main route table. When a subnet does not have an explicit routing table associated with it, the main routing table is used by default. On the **Route tables** page in the Amazon VPC console, you can view the main route table for a VPC by looking for **Yes** in the **Main** column. 

By default, when you create a nondefault VPC, the main route table contains only a local route. If you [Create a VPC](create-vpc.md) and choose a NAT gateway, Amazon VPC automatically adds routes to the main route table for the gateways.

The following rules apply to the main route table:
+ You can add, remove, and modify routes in the main route table.
+ You can't delete the main route table.
+ You can't set a gateway route table as the main route table.
+ You can replace the main route table by associating a custom route table with a subnet.
+ You can explicitly associate a subnet with the main route table, even if it's already implicitly associated. 

  You might want to do that if you change which table is the main route table. When you change which table is the main route table, it also changes the default for additional new subnets, or for any subnets that are not explicitly associated with any other route table. For more information, see [Replace the main route table](Route_Replacing_Main_Table.md).

## Custom route tables
<a name="custom-route-tables"></a>

By default, a route table contains a local route for communication within the VPC. If you [Create a VPC](create-vpc.md) and choose a public subnet, Amazon VPC creates a custom route table and adds a route that points to the internet gateway. One way to protect your VPC is to leave the main route table in its original default state. Then, explicitly associate each new subnet that you create with one of the custom route tables you've created. This ensures that you explicitly control how each subnet routes traffic.

You can add, remove, and modify routes in a custom route table. You can delete a custom route table only if it has no associations.

## Subnet route table association
<a name="route-table-assocation"></a>

Each subnet in your VPC must be associated with a route table. A subnet can be explicitly associated with custom route table, or implicitly or explicitly associated with the main route table. For more information about viewing your subnet and route table associations, see [Determine the explicit associations](WorkWithRouteTables.md#Route_Which_Associations).

Subnets that are in VPCs associated with Outposts can have an additional target type of a local gateway. This is the only routing difference from non-Outposts subnets.

**Example 1: Implicit and explicit subnet association**  
The following diagram shows the routing for a VPC with an internet gateway, a virtual private gateway, a public subnet, and a VPN-only subnet.

![\[Diagram of private subnet associated with main route table and public subnet with custom route table\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/subnet-association.png)


Route table A is a custom route table that is explicitly associated with the public subnet. It has a route that sends all traffic to the internet gateway, which is what makes the subnet a public subnet.


| Destination | Target | 
| --- | --- | 
| VPC CIDR | Local | 
| 0.0.0.0/0 | igw-id | 

Route table B is the main route table. It is implicitly associated with the private subnet. It has a route that sends all traffic to the virtual private gateway, but no route to the internet gateway, which is what makes the subnet a VPN-only subnet. If you create another subnet in this VPC and don't associate a custom route table, the subnet will also be implicitly associated with this route table because it is the main route table.


| Destination | Target | 
| --- | --- | 
| VPC CIDR | Local | 
| 0.0.0.0/0 | vgw-id | 

**Example 2: Replacing the main route table**  
You might want to make changes to the main route table. To avoid any disruption to your traffic, we recommend that you first test the route changes using a custom route table. After you're satisfied with the testing, you can replace the main route table with the new custom table.

The following diagram shows two subnets and two route tables. Subnet A is implicitly associated with route table A, the main route table. Subnet B is implicitly associated with route table A. Route table B, a custom route table, isn't associated with either subnet.

![\[Two subnets with implicit associations with route table A, the main route table.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/replace-route-table-initial.png)


To replace the main route table, start by creating an explicit association between subnet B and route table B. Test route table B. 

![\[Subnet B is now explicitly associated with route table B, a custom route table.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/replace-route-table-step1.png)


After you've tested route table B, make it the main route table. Subnet B still has an explicit association with route table B. However, subnet A now has an implicit association with route table B, because route table B is the new main route table. Route table A is no longer associated with either subnet.

![\[Diagram of Subnet A associated with main route table B and Subnet B associated with route table B\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/replace-route-table-step2.png)


(Optional) If you disassociate subnet B from route table B, there is still an implicit association between subnet B and route table B. If you no longer need route table A, you can delete it.

![\[Both subnets are implicitly associated with route table B.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/replace-route-table-step3.png)


# Gateway route tables
<a name="gateway-route-tables"></a>

You can associate a route table with an internet gateway or a virtual private gateway. When a route table is associated with a gateway, it's referred to as a *gateway route table*. You can create a gateway route table for fine-grain control over the routing path of traffic entering your VPC. For example, you can intercept the traffic that enters your VPC through an internet gateway by redirecting that traffic to a middlebox appliance (such as a security appliance) in your VPC.

**Topics**
+ [

## Gateway route table routes
](#gateway-route-table-routes)
+ [

## Rules and considerations
](#gateway-route-table-rules)

## Gateway route table routes
<a name="gateway-route-table-routes"></a>

A gateway route table associated with an internet gateway supports routes with the following targets:
+ The default local route
+ A [Gateway Load Balancer endpoint](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/)
+ A network interface for a middlebox appliance

A gateway route table associated with a virtual private gateway supports routes with the following targets:
+ The default local route
+ A [Gateway Load Balancer endpoint](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/)
+ A network interface for a middlebox appliance

When the target is a Gateway Load Balancer endpoint or a network interface, the following destinations are allowed:
+ The entire IPv4 or IPv6 CIDR block of your VPC. In this case, you replace the target of the default local route.
+ The entire IPv4 or IPv6 CIDR block of a subnet in your VPC. This is a more specific route than the default local route.

If you change the target of the local route in a gateway route table to a network interface in your VPC, you can later restore it to the default `local` target. For more information, see [Replace or restore the target for a local route](replace-local-route-target.md). 

**Example**  
In the following gateway route table, traffic destined for a subnet with the `172.31.0.0/20` CIDR block is routed to a specific network interface. Traffic destined for all other subnets in the VPC uses the local route.


| Destination | Target | 
| --- | --- | 
| 172.31.0.0/16 | Local | 
| 172.31.0.0/20 | eni-id | 

**Example**  
In the following gateway route table, the target for the local route is replaced with a network interface ID. Traffic destined for all subnets within the VPC is routed to the network interface.


| Destination | Target | 
| --- | --- | 
| 172.31.0.0/16 | eni-id | 

## Rules and considerations
<a name="gateway-route-table-rules"></a>

You cannot associate a route table with a gateway if any of the following applies:
+ The route table contains existing routes with targets other than a network interface, Gateway Load Balancer endpoint, or the default local route.
+ The route table contains existing routes to CIDR blocks outside of the ranges in your VPC.
+ Route propagation is enabled for the route table.

In addition, the following rules and considerations apply:
+ You cannot add routes to any CIDR blocks outside of the ranges in your VPC, including ranges larger than the individual VPC CIDR blocks. 
+ You can only specify `local`, a Gateway Load Balancer endpoint, or a network interface as a target. You cannot specify any other types of targets, including individual host IP addresses. For more information, see [Example routing options](route-table-options.md).
+ You cannot specify a prefix list as a destination.
+ You cannot use a gateway route table to control or intercept traffic outside of your VPC, for example, traffic through an attached transit gateway. You can intercept traffic that enters your VPC and redirect it to another target in the same VPC only.
+ To ensure that traffic reaches your middlebox appliance, the target network interface must be attached to a running instance. For traffic that flows through an internet gateway, the target network interface must also have a public IP address.
+ When configuring your middlebox appliance, take note of the [appliance considerations](route-table-options.md#appliance-considerations).
+ When you route traffic through a middlebox appliance, the return traffic from the destination subnet must be routed through the same appliance. Asymmetric routing is not supported.
+ Route table rules apply to all traffic that leaves a subnet. Traffic that leaves a subnet is defined as traffic destined to that subnet's gateway router's MAC address. Traffic that is destined for the MAC address of another network interface in the subnet makes use of data link (layer 2) routing instead of network (layer 3) so the rules do not apply to this traffic.
+ Not all Local Zones support edge association with virtual private gateways. For more information on available zones, see [Considerations](https://docs.aws.amazon.com/local-zones/latest/ug/how-local-zones-work.html#considerations) in the *AWS Local Zones User Guide*.

# How route priority works
<a name="route-tables-priority"></a>

In general, we direct traffic using the most specific route that matches the traffic. This is known as the longest prefix match. If your route table has overlapping or matching routes, additional rules apply. 

The following list shows a route priority summary with links to sections below with more detailed information and examples:

1. [Longest prefix](#route-table-longest-prefix-match) (for example, 10.10.2.15/32 has priority over 10.10.2.0/24)

1. [Static routes](#route-table-priority-propagated-routes) (like VPC peering and internet gateway connections)

1. [Prefix list routes](#route-priority-managed-prefix-list)

1. [Propagated routes](#route-table-priority-propagated-routes)

   1. Direct Connect BGP routes (dynamic routes)

   1. VPN static routes

   1. VPN BGP routes (dynamic routes) (like virtual private gateways)

## Longest prefix match
<a name="route-table-longest-prefix-match"></a>

Routes to IPv4 and IPv6 addresses or CIDR blocks are independent of each other. We use the most specific route that matches either IPv4 traffic or IPv6 traffic to determine how to route the traffic. 

The following example subnet route table has a route for IPv4 internet traffic (`0.0.0.0/0`) that points to an internet gateway, and a route for `172.31.0.0/16` IPv4 traffic that points to a peering connection (`pcx-11223344556677889`). Any traffic from the subnet that's destined for the `172.31.0.0/16` IP address range uses the peering connection, because this route is more specific than the route for internet gateway. Any traffic destined for a target within the VPC (`10.0.0.0/16`) is covered by the `local` route, and therefore is routed within the VPC. All other traffic from the subnet uses the internet gateway.


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | local | 
| 172.31.0.0/16 | pcx-11223344556677889 | 
| 0.0.0.0/0 | igw-12345678901234567 | 

## Route priority for static and dynamically propagated routes
<a name="route-table-priority-propagated-routes"></a>

If you've attached a virtual private gateway to your VPC and enabled route propagation on your subnet route table, routes representing your Site-to-Site VPN connection automatically appear as propagated routes in your route table.

If the destination of a propagated route is identical to the destination of a static route, the static route takes priority. The following resources use static routes:
+ internet gateway
+ NAT gateway
+ Network interface
+ Instance ID
+ Gateway VPC endpoint
+ Transit gateway
+ VPC peering connection
+ Gateway Load Balancer endpoint

For more information, see [Route tables and VPN route priority](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html#vpn-route-priority) in the *AWS Site-to-Site VPN User Guide*.

The following example 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`. Because a static route to an internet gateway takes priority, all traffic destined for `172.31.0.0/24` is routed to the internet gateway. 


| Destination | Target | Propagated | 
| --- | --- | --- | 
| 10.0.0.0/16 | local | No | 
| 172.31.0.0/24 | vgw-11223344556677889 | Yes | 
| 172.31.0.0/24 | igw-12345678901234567 | No | 

## Route priority for prefix lists
<a name="route-priority-managed-prefix-list"></a>

If your route table references a prefix list, the following rules apply: 
+ If your route table contains a propagated route that matches a route that references a prefix list, the route that references the prefix list takes priority. Please note that for routes that overlap, more specific routes always take priority irrespective of whether they are propagated routes, static routes, or routes that reference prefix lists.
+ If your route table references multiple prefix lists that have overlapping CIDR blocks to different targets, we randomly choose which route takes priority. Thereafter, the same route always takes priority.

# Example routing options
<a name="route-table-options"></a>

The following topics describe routing for specific gateways or connections in your VPC.

**Topics**
+ [

## Routing to an internet gateway
](#route-tables-internet-gateway)
+ [

## Routing to a NAT device
](#route-tables-nat)
+ [

## Routing to a virtual private gateway
](#route-tables-vgw)
+ [

## Routing to an AWS Outposts local gateway
](#route-tables-lgw)
+ [

## Routing to a VPC peering connection
](#route-tables-vpc-peering)
+ [

## Routing to a gateway VPC endpoint
](#route-tables-vpce)
+ [

## Routing to an egress-only internet gateway
](#route-tables-eigw)
+ [

## Routing for a transit gateway
](#route-tables-tgw)
+ [

## Routing for a middlebox appliance
](#route-tables-appliance-routing)
+ [

## Routing using a prefix list
](#route-tables-managed-prefix-list)
+ [

## Routing to a Gateway Load Balancer endpoint
](#route-tables-gwlbe)

## Routing to an internet gateway
<a name="route-tables-internet-gateway"></a>

You can make a subnet a public subnet by adding a route in your subnet route table to an internet gateway. To do this, create and attach an internet gateway to your VPC, and then add a route with a destination of `0.0.0.0/0` for IPv4 traffic or `::/0` for IPv6 traffic, and a target of the internet gateway ID (`igw-xxxxxxxxxxxxxxxxx`). 


| Destination | Target | 
| --- | --- | 
| 0.0.0.0/0 | igw-id | 
| ::/0 | igw-id | 

For more information, see [Enable internet access for a VPC using an internet gateway](VPC_Internet_Gateway.md).

## Routing to a NAT device
<a name="route-tables-nat"></a>

To enable instances in a private subnet to connect to the internet, you can create a NAT gateway or launch a NAT instance in a public subnet. Then add a route for the private subnet's route table that routes IPv4 internet traffic (`0.0.0.0/0`) to the NAT device. 


| Destination | Target | 
| --- | --- | 
| 0.0.0.0/0 | nat-gateway-id | 

You can also create more specific routes to other targets to avoid unnecessary data processing charges for using a NAT gateway, or to route certain traffic privately. In the following example, Amazon S3 traffic (pl-xxxxxxxx, a prefix list that contains the IP address ranges for Amazon S3 in a specific Region) is routed to a gateway VPC endpoint, and 10.25.0.0/16 traffic is routed to a VPC peering connection. These IP address ranges are more specific than 0.0.0.0/0. When instances send traffic to Amazon S3 or the peer VPC, the traffic is sent to the gateway VPC endpoint or the VPC peering connection. All other traffic is sent to the NAT gateway. 


| Destination | Target | 
| --- | --- | 
| 0.0.0.0/0 | nat-gateway-id | 
| pl-xxxxxxxx | vpce-id | 
| 10.25.0.0/16 | pcx-id | 

For more information, see [NAT devices](vpc-nat.md).

## Routing to a virtual private gateway
<a name="route-tables-vgw"></a>

You can use an AWS Site-to-Site VPN connection to enable instances in your VPC to communicate with your own network. To do this, create and attach a virtual private gateway to your VPC. Then add a route in your subnet route table with the destination of your network and a target of the virtual private gateway (`vgw-xxxxxxxxxxxxxxxxx`).


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | vgw-id | 

You can then create and configure your Site-to-Site VPN connection. For more information, see [What is AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) and [Route tables and VPN route priority](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html#vpn-route-priority) in the *AWS Site-to-Site VPN User Guide*.

A Site-to-Site VPN connection on a virtual private gateway does not support IPv6 traffic. However, we support IPv6 traffic routed through a virtual private gateway to an Direct Connect connection. For more information, see the [Direct Connect User Guide](https://docs.aws.amazon.com/directconnect/latest/UserGuide/).

## Routing to an AWS Outposts local gateway
<a name="route-tables-lgw"></a>

This section describes routing table configurations for routing to an AWS Outposts local gateway.

**Topics**
+ [

### Enable traffic between Outpost subnets and your on-premises network
](#route-tables-lgw-on-prem)
+ [

### Enable traffic between subnets in the same VPC across Outposts
](#route-tables-lgw-intra-vpc)

### Enable traffic between Outpost subnets and your on-premises network
<a name="route-tables-lgw-on-prem"></a>

Subnets that are in VPCs associated with AWS Outposts can have an additional target type of a local gateway. Consider the case where you want to have the local gateway route traffic with a destination address of 192.168.10.0/24 to the customer network. To do this, add the following route with the destination network and a target of the local gateway (`lgw-xxxx`).


| Destination | Target | 
| --- | --- | 
| 192.168.10.0/24 | lgw-id | 

### Enable traffic between subnets in the same VPC across Outposts
<a name="route-tables-lgw-intra-vpc"></a>

You can establish communication between subnets that are in the same VPC across different Outposts using Outpost local gateways and your on-premise network. 

You can use this feature to build architectures similar to multi-Availability Zone (AZ) architectures for your on-premise applications running on Outposts racks by establishing connectivity between Outposts racks that are anchored to different AZs.

![\[Traffic between subnets in the same VPC across Outposts using local gateways\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/outpost-intra-vpc-connection.png)


To enable this feature, add a route to your Outpost rack subnet route table that is more specific than the local route in that route table and has a target type of local gateway. The destination of the route must match the entire IPv4 block of the subnet in your VPC that is in another Outpost. Repeat this configuration for all the Outpost subnets that need to communicate.

**Important**  
To use this feature, you must use [direct VPC routing](https://docs.aws.amazon.com/outposts/latest/userguide/routing.html#direct-vpc-routing). You cannot use your own [customer-owned IP addresses](https://docs.aws.amazon.com/outposts/latest/userguide/routing.html#ip-addressing).
Your on-premise network that the Outposts local gateways are connected to must have the required routing so that subnets can access to each other.
If you want to use security groups for resources in the subnets, you must use rules that include IP address ranges as source or destination in the Outpost subnets. You cannot use security group IDs.
Existing Outposts racks may require an update to enable support for intra-VPC communication across multiple Outposts. If this feature doesn't work for you, [contact AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).

**Example**  
For a VPC with a CIDR of 10.0.0.0/16, an Outpost 1 subnet with a CIDR of 10.0.1.0/24, and an Outpost 2 subnet with a CIDR of 10.0.2.0/24, the entry for Outpost 1 subnet’s route table would be as follows:


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | Local | 
| 10.0.2.0/24 | lgw-1-id | 

The entry for Outpost 2 subnet’s route table would be as follows:


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | Local | 
| 10.0.1.0/24 | lgw-2-id | 

## Routing to a VPC peering connection
<a name="route-tables-vpc-peering"></a>

A VPC peering connection is a networking connection between two VPCs that allows you to route traffic between them using private IPv4 addresses. Instances in either VPC can communicate with each other as if they are part of the same network. 

To enable the routing of traffic between VPCs in a VPC peering connection, you must add a route to one or more of your subnet route tables that points to the VPC peering connection. This allows you to access all or part of the CIDR block of the other VPC in the peering connection. Similarly, the owner of the other VPC must add a route to their subnet route table to route traffic back to your VPC.

For example, you have a VPC peering connection (`pcx-11223344556677889`) between two VPCs, with the following information:
+ VPC A: CIDR block is 10.0.0.0/16
+ VPC B: CIDR block is 172.31.0.0/16

To enable traffic between the VPCs and allow access to the entire IPv4 CIDR block of either VPC, the VPC A route table is configured as follows.


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | Local | 
| 172.31.0.0/16 | pcx-11223344556677889 | 

The VPC B route table is configured as follows.


| Destination | Target | 
| --- | --- | 
| 172.31.0.0/16 | Local | 
| 10.0.0.0/16 | pcx-11223344556677889 | 

Your VPC peering connection can also support IPv6 communication between instances in the VPCs, if the VPCs and instances are enabled for IPv6 communication. To enable the routing of IPv6 traffic between VPCs, you must add a route to your route table that points to the VPC peering connection to access all or part of the IPv6 CIDR block of the peer VPC.

For example, using the same VPC peering connection (`pcx-11223344556677889`) above, assume the VPCs have the following information:
+ VPC A: IPv6 CIDR block is `2001:db8:1234:1a00::/56`
+ VPC B: IPv6 CIDR block is `2001:db8:5678:2b00::/56`

To enable IPv6 communication over the VPC peering connection, add the following route to the subnet route table for VPC A.


| Destination | Target | 
| --- | --- | 
| 10.0.0.0/16 | Local | 
| 172.31.0.0/16 | pcx-11223344556677889 | 
| 2001:db8:5678:2b00::/56 | pcx-11223344556677889 | 

Add the following route to the route table for VPC B.


| Destination | Target | 
| --- | --- | 
| 172.31.0.0/16 | Local | 
| 10.0.0.0/16 | pcx-11223344556677889 | 
| 2001:db8:1234:1a00::/56 | pcx-11223344556677889 | 

For more information about VPC peering connections, see the [Amazon VPC Peering Guide](https://docs.aws.amazon.com/vpc/latest/peering/).

## Routing to a gateway VPC endpoint
<a name="route-tables-vpce"></a>

A gateway VPC endpoint enables you to create a private connection between your VPC and another AWS service. When you create a gateway endpoint, you specify the subnet route tables in your VPC that are used by the gateway endpoint. A route is automatically added to each of the route tables with a destination that specifies the prefix list ID of the service (`pl-xxxxxxxx`), and a target with the endpoint ID (`vpce-xxxxxxxxxxxxxxxxx`). You cannot explicitly delete or modify the endpoint route, but you can change the route tables that are used by the endpoint.

For more information about routing for endpoints, and the implications for routes to AWS services, see [Routing for gateway endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html#gateway-endpoint-routing).

## Routing to an egress-only internet gateway
<a name="route-tables-eigw"></a>

You can create an egress-only internet gateway for your VPC to enable instances in a private subnet to initiate outbound communication to the internet, but prevent the internet from initiating connections with the instances. An egress-only internet gateway is used for IPv6 traffic only. To configure routing for an egress-only internet gateway, add a route in the private subnet's route table that routes IPv6 internet traffic (`::/0`) to the egress-only internet gateway. 


| Destination | Target | 
| --- | --- | 
| ::/0 | eigw-id | 

For more information, see [Enable outbound IPv6 traffic using an egress-only internet gateway](egress-only-internet-gateway.md).

## Routing for a transit gateway
<a name="route-tables-tgw"></a>

When you attach a VPC to a transit gateway, you need to add a route to your subnet route table for traffic to route through the transit gateway. 

Consider the following scenario where you have three VPCs that are attached to a transit gateway. In this scenario, all attachments are associated with the transit gateway route table and propagate to the transit gateway route table. Therefore, all attachments can route packets to each other, with the transit gateway serving as a simple layer 3 IP hub. 

For example, you have two VPCs, with the following information:
+ VPC A: 10.1.0.0/16, attachment ID tgw-attach-11111111111111111
+ VPC B: 10.2.0.0/16, attachment ID tgw-attach-22222222222222222

To enable traffic between the VPCs and allow access to the transit gateway, the VPC A route table is configured as follows.


| Destination | Target | 
| --- | --- | 
| 10.1.0.0/16 | local | 
| 10.0.0.0/8 | tgw-id | 

The following is an example of the transit gateway route table entries for the VPC attachments.


| Destination | Target | 
| --- | --- | 
| 10.1.0.0/16 | tgw-attach-11111111111111111 | 
| 10.2.0.0/16 | tgw-attach-22222222222222222 | 

For more information about transit gateway route tables, see [Routing](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#tgw-routing-overview) in *Amazon VPC Transit Gateways*.

## Routing for a middlebox appliance
<a name="route-tables-appliance-routing"></a>

You can add middlebox appliances into the routing paths for your VPC. The following are possible use cases:
+ Intercept traffic that enters your VPC through an internet gateway or a virtual private gateway by directing it to a middlebox appliance in your VPC. You can use the middlebox routing wizard to have AWS automatically configure the appropriate route tables for your gateway, middlebox, and destination subnet. For more information, see [Middlebox routing wizard](middlebox-routing-console.md).
+ Direct traffic between two subnets to a middlebox appliance. You can do so by creating a route for one subnet route table that matches the subnet CIDR of the other subnet and specifies a Gateway Load Balancer endpoint, NAT gateway, Network Firewall endpoint, or the network interface for an appliance as a target. Alternatively, to redirect all traffic from the subnet to any other subnet, replace the target of the local route with a Gateway Load Balancer endpoint, NAT gateway, or network interface.

You can configure the appliance to suit your needs. For example, you can configure a security appliance that screens all traffic, or a WAN acceleration appliance. The appliance is deployed as an Amazon EC2 instance in a subnet in your VPC, and is represented by an elastic network interface (network interface) in your subnet.

If you enable route propagation for the destination subnet route table, be aware of route priority. We prioritize the most specific route, and if the routes match, we prioritize static routes over propagated routes. Review your routes to ensure that traffic is routed correctly and that there are no unintended consequences if you enable or disable route propagation (for example, route propagation is required for an Direct Connect connection that supports jumbo frames).

To route inbound VPC traffic to an appliance, you associate a route table with the internet gateway or virtual private gateway, and specify the network interface of your appliance as the target for VPC traffic. For more information, see [Gateway route tables](gateway-route-tables.md). You can also route outbound traffic from your subnet to a middlebox appliance in another subnet.

For middlebox routing examples, see [Middlebox scenarios](middlebox-routing-examples.md).

**Topics**
+ [

### Appliance considerations
](#appliance-considerations)
+ [

### Routing traffic between a gateway and an appliance
](#appliance-routing-configuration)
+ [

### Routing inter-subnet traffic to an appliance
](#appliance-routing-configuration-inter-subnet)

### Appliance considerations
<a name="appliance-considerations"></a>

You can choose a third-party appliance from [AWS Marketplace](https://aws.amazon.com/marketplace), or you can configure your own appliance. When you create or configure an appliance, take note of the following:
+ The appliance must be configured in a separate subnet to the source or destination traffic.
+ You must disable source/destination checking on the appliance. For more information, see [Changing the Source or Destination Checking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#change_source_dest_check) in the *Amazon EC2 User Guide*.
+ You cannot route traffic between hosts in the same subnet through an appliance.
+ The appliance does not have to perform network address translation (NAT).
+ You can add a route to your route tables that is more specific than the local route. You can use more specific routes to redirect traffic between subnets within a VPC (East-West traffic) to a middlebox appliance. The destination of the route must match the entire IPv4 or IPv6 CIDR block of a subnet in your VPC.
+ To intercept IPv6 traffic, ensure that your VPC, subnet, and appliance support IPv6.

### Routing traffic between a gateway and an appliance
<a name="appliance-routing-configuration"></a>

To route inbound VPC traffic to an appliance, you associate a route table with the internet gateway or virtual private gateway, and specify the network interface of your appliance as the target for VPC traffic. In the following example, the VPC has an internet gateway, an appliance, and a subnet with instances. Traffic from the internet is routed through an appliance.

![\[Routing inbound traffic through an appliance\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/gateway-appliance-routing.png)


Associate this route table with your internet gateway or virtual private gateway. The first entry is the local route. The second entry sends IPv4 traffic destined for the subnet to the network interface for the appliance. This route is more specific than the local route.


| Destination | Target | 
| --- | --- | 
| VPC CIDR | Local | 
| Subnet CIDR | Appliance network interface ID | 

Alternatively, you can replace the target for the local route with the network interface of the appliance. You can do this to ensure that all traffic is automatically routed to the appliance, including traffic destined for subnets that you add to the VPC in the future.


| Destination | Target | 
| --- | --- | 
| VPC CIDR | Appliance network interface ID | 

To route traffic from your subnet to an appliance in another subnet, add a route to your subnet route table that routes traffic to the appliance's network interface. The destination must be less specific than the destination for the local route. For example, for traffic destined for the internet, specify `0.0.0.0/0` (all IPv4 addresses) for the destination.


| Destination | Target | 
| --- | --- | 
| VPC CIDR | Local | 
| 0.0.0.0/0 | Appliance network interface ID | 

Then, in the route table associated with the appliance's subnet, add a route that sends the traffic back to the internet gateway or virtual private gateway.


| Destination | Target | 
| --- | --- | 
| VPC CIDR | Local | 
| 0.0.0.0/0 | igw-id | 

### Routing inter-subnet traffic to an appliance
<a name="appliance-routing-configuration-inter-subnet"></a>

You can route traffic destined for a specific subnet to the network interface of an appliance. In the following example, the VPC contains two subnets and an appliance. Traffic between the subnets is routed through an appliance.

![\[Routing traffic between subnets through an appliance\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/inter-subnet-appliance-routing.png)


**Security groups**  
When you route traffic between instances in different subnets through a middlebox appliance, the security groups for both instances must allow traffic to flow between the instances. The security group for each instance must reference the private IP address of the other instance, or the CIDR range of the subnet that contains the other instance, as the source. If you reference the security group of the other instance as the source, this does not allow traffic to flow between the instances.

**Routing**  
The following is an example route table for subnet A. The first entry enables instances in the VPC to communicate with each other. The second entry routes all traffic from subnet A to subnet B to the network interface of the appliance.


| Destination | Target | 
| --- | --- | 
| VPC CIDR | Local | 
| Subnet B CIDR | Appliance network interface ID | 

The following is an example route table for subnet B. The first entry enables instances in the VPC to communicate with each other. The second entry routes all traffic from subnet B to subnet A to the network interface of the appliance.


| Destination | Target | 
| --- | --- | 
| VPC CIDR | Local | 
| Subnet A CIDR | Appliance network interface ID | 

Alternatively, you can replace the target for the local route with the network interface of the appliance. You can do this to ensure that all traffic is automatically routed to the appliance, including traffic destined for subnets that you add to the VPC in the future.


| Destination | Target | 
| --- | --- | 
| VPC CIDR | Appliance network interface ID | 

## Routing using a prefix list
<a name="route-tables-managed-prefix-list"></a>

If you frequently reference the same set of CIDR blocks across your AWS resources, you can create a [customer-managed prefix list](managed-prefix-lists.md) to group them together. You can then specify the prefix list as the destination in your route table entry. You can later add or remove entries for the prefix list without needing to update your route tables.

For example, you have a transit gateway with multiple VPC attachments. The VPCs must be able to communicate with two specific VPC attachments that have the following CIDR blocks:
+ 10.0.0.0/16
+ 10.2.0.0/16

You create a prefix list with both entries. In your subnet route tables, you create a route and specify the prefix list as the destination, and the transit gateway as the target.


| Destination | Target | 
| --- | --- | 
| 172.31.0.0/16 | Local | 
| pl-123abc123abc123ab | tgw-id | 

The maximum number of entries for the prefix lists equals the same number of entries in the route table.

## Routing to a Gateway Load Balancer endpoint
<a name="route-tables-gwlbe"></a>

A Gateway Load Balancer enables you to distribute traffic to a fleet of virtual appliances, such as firewalls. You can create a Gateway Load Balancer, configure a [Gateway Load Balancer endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-gateway-load-balancer-endpoint-service.html), and then create a [Gateway Load Balancer endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-load-balancer-endpoints.html) in your VPC to connect it to the service.

To route your traffic to the Gateway Load Balancer (for example, for security inspection), specify the Gateway Load Balancer endpoint as a target in your route tables.

For an example of a security appliances behind a Gateway Load Balancer, see [Configure middlebox traffic routing and inspection in a VPC](gwlb-route.md).

To specify the Gateway Load Balancer endpoint in the route table, use the ID of the VPC endpoint. For example to route traffic for 10.0.1.0/24 to a Gateway Load Balancer endpoint, add the following route.


| Destination | Target | 
| --- | --- | 
| 10.0.1.0/24 | vpc-endpoint-id | 

When using a Gateway Load Balancer endpoint as a target, you cannot specify a prefix list as a destination. If you attempt to create or replace a prefix list route targeting a VPC Endpoint, you'll receive the error: "Cannot create or replace a prefix list route targeting a VPC Endpoint."

For more information, see [Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html).

# Create a route table for your VPC
<a name="create-vpc-route-table"></a>

Complete the following tasks to create and configure a custom route table for your VPC. By default your new route table contains local routes that allow communication within the VPC. You can add routes to direct network traffic to specific targets based on the destination IP address range.

To apply route table routes to a particular subnet, you must associate the route table with the subnet. A route table can be associated with multiple subnets. However, a subnet can only be associated with one route table at a time. Any subnet not explicitly associated with a table is implicitly associated with the main route table by default.

You can disassociate a subnet from a route table. Until you associate the subnet with another route table, it's implicitly associated with the main route table.

**Note**  
There is a quota on the number of route tables that you can create per VPC. There is also a quota on the number of routes that you can add per route table. For more information, see [Amazon VPC quotas](amazon-vpc-limits.md).

**Topics**
+ [

## Create the route table
](#CustomRouteTable)
+ [

## Add routes to the route table
](#AddRoutes)
+ [

## Associate a subnet with the route table
](#AssociateSubnet)

## Create the route table
<a name="CustomRouteTable"></a>

**To create a route table using the 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 **Route tables**.

1. Choose **Create route table**.

1. (Optional) For **Name**, enter a name for your route table.

1. For **VPC**, choose your VPC.

1. (Optional) To add a tag, choose **Add new tag** and enter the tag key and tag value.

1. Choose **Create route table**.

**To create a route table using the AWS CLI**  
Use the [create-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-route-table.html) command.

## Add routes to the route table
<a name="AddRoutes"></a>

**To add routes to a route table using the 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 **Route tables**, and select the route table.

1. Choose **Actions**, **Edit routes**.

1. Choose **Add route**.

1. For **Destination** enter one of the following:
   + An IP address range - For example, 192.168.0.0/16
   + A single IP address - For example, 192.168.10.1/32
   + The ID of a prefix list - For example, pl-0abcdef1234567890

1. For **Target**, select a resource type (for example, a network interface) and then enter the ID of the resource (for example, eni-11223344556677889).

1. Choose **Save changes**.

**To add routes to a route table using the AWS CLI**  
Use the [create-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-route.html) command.

## Associate a subnet with the route table
<a name="AssociateSubnet"></a>

**To associate a route table with a subnet using the 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 **Route tables**, and then select the route table.

1. On the **Subnet associations** tab, choose **Edit subnet associations**.

1. Select the check box for the subnet to associate with the route table.

1. Choose **Save associations**.

**To associate or disassociate a subnet with a route table using the AWS CLI**
+ [associate-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-route-table.html)
+ [disassociate-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-route-table.html)

# Manage subnet route tables
<a name="WorkWithRouteTables"></a>

Use the following procedures to manage VPC routing using route tables.

**Topics**
+ [

## Determine the route table for a subnet
](#SubnetRouteTables)
+ [

## Determine the explicit associations
](#Route_Which_Associations)
+ [

## Add, modify, and remove routes
](#AddRemoveRoutes)
+ [

## Enable or disable route propagation
](#EnableDisableRouteProp)
+ [

## Change the route table for a subnet
](#ChangeRouteTable)

## Determine the route table for a subnet
<a name="SubnetRouteTables"></a>

You can determine which route table a subnet is associated with by looking at the subnet details in the Amazon VPC console.

**To determine the route table for a subnet using the 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 **Subnets**.

1. Select the subnet.

1. Choose the **Route table** tab to view information about the route table and its routes. To determine whether the association is to the main route table, and if that association is explicit, see [Determine the explicit associations](#Route_Which_Associations).

## Determine the explicit associations
<a name="Route_Which_Associations"></a>

You can determine how many and which subnets or gateways are explicitly associated with a route table.

The main route table can have explicit and implicit subnet associations. Custom route tables have only explicit associations.

Subnets that aren't explicitly associated with any route table have an implicit association with the main route table. You can explicitly associate a subnet with the main route table. For an example of why you might do that, see [Replace the main route table](Route_Replacing_Main_Table.md).

**To determine which subnets are explicitly associated using the 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 **Route tables**.

1. Check the **Explicit subnet association** column to determine the explicitly associated subnets and the **Main** column to determine whether this is the main route table.

1. Select the route table and choose the **Subnet associations** tab.

1. The subnets under **Explicit subnet associations** are explicitly associated with the route table. The subnets under **Subnets without explicit associations** belong to the same VPC as the route table, but are not associated with any route table, so they are implicitly associated with the main route table for the VPC.

**To determine which gateways are explicitly associated using the 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 **Route tables**.

1. Select the route table and choose the **Edge associations** tab.

**To describe one or more route tables and view its associations using the AWS CLI**  
Use the [describe-route-tables](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-route-tables.html) command.

## Add, modify, and remove routes
<a name="AddRemoveRoutes"></a>

You can add, modify, and delete routes for your route tables.

For more information about working with static routes for a Site-to-Site VPN connection, see [Editing Static Routes for a Site-to-Site VPN Connection](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html#vpn-edit-static-routes) in the *AWS Site-to-Site VPN User Guide*.

**Considerations**
+ You can only modify routes that you've added.
+ When you modify or delete a route, existing connections that use these routes are affected. Connections that use the other routes are not affected.
+ There is a quota on the number of routes that you can add per route table. For more information, see [Amazon VPC quotas](amazon-vpc-limits.md).

**To update the routes for a route table using the 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 **Route tables**, and select the route table.

1. Choose **Actions**, **Edit routes**.

1. To add a route, choose **Add route**. For **Destination** enter an IP address range, a single IP address, or the ID of a prefix list. For **Target**, select the resource type and then enter the ID of the resource.

1. To modify a route, enter the new destination CIDR block or prefix list ID and choose a target.

1. To delete a route, choose **Remove**.

1. Choose **Save changes**.

**To update the routes for a route table using the AWS CLI**

If you add a route using a command line tool or the API, the destination CIDR block is automatically modified to its canonical form. For example, if you specify `100.68.0.18/18` for the CIDR block, we create a route with a destination CIDR block of `100.68.0.0/18`.
+ [create-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-route.html)
+ [replace-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-route.html)
+ [delete-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-route.html)

## Enable or disable route propagation
<a name="EnableDisableRouteProp"></a>

Route propagation allows a virtual private gateway to automatically propagate routes to your route tables. This means that you don't need to manually add or remove VPN routes.

To complete this process, you must have a virtual private gateway.

For more information, see [Site-to-Site VPN routing options](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html) in the *Site-to-Site VPN User Guide*.

**To enable or disable route propagation using the 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 **Route tables**, and then select the route table.

1. Choose **Actions**, **Edit route propagation**.

1. Select or clear the **Enable** check box next to the virtual private gateway.

1. Choose **Save**.

**To enable or disable route propagation using the AWS CLI**
+ [enable-vgw-route-propagation](https://docs.aws.amazon.com/cli/latest/reference/ec2/enable-vgw-route-propagation.html)
+ [disable-vgw-route-propagation](https://docs.aws.amazon.com/cli/latest/reference/ec2/disable-vgw-route-propagation.html)

## Change the route table for a subnet
<a name="ChangeRouteTable"></a>

You can change the route table association for a subnet.

When you change the route table, your existing connections in the subnet are dropped unless the new route table contains a route for the same traffic to the same target.

**To change a subnet route table association using the 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 **Subnets**, and then select the subnet.

1. From the **Route table** tab, choose **Edit route table association**.

1. For **Route table ID**, select the new route table.

1. Choose **Save**.

**To change the route table associated with a subnet using the AWS CLI**  
Use the [replace-route-table-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-route-table-association.html) command.

# Replace the main route table
<a name="Route_Replacing_Main_Table"></a>

This section describes how to change which route table is the main route table in your VPC. 

**To replace the main route table using the 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 **Route tables**, and then select the new main route table.

1. Choose **Actions**, **Set main route table**.

1. When prompted for confirmation, enter **set**, and then choose **OK**.

**To replace the main route table using AWS CLI**
+ Use the [replace-route-table-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-route-table-association.html) command.

The following procedure describes how to remove an explicit association between a subnet and the main route table. The result is an implicit association between the subnet and the main route table. The process is the same as disassociating any subnet from any route table.

**To remove an explicit association with the main route table**

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 **Route tables**, and then select the route table.

1. From the **Subnet associations** tab, choose **Edit subnet associations**.

1. Clear the checkbox for the subnet.

1. Choose **Save associations**.

# Control traffic entering your VPC using a gateway route table
<a name="associate-route-table-gateway"></a>

To control traffic entering your VPC with a gateway route table, you can associate or disassociate an internet gateway or a virtual private gateway with a route table. For more information, see [Gateway route tables](gateway-route-tables.md).

**To associate or disassociate a gateway with a route table using the 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 **Route tables**, and then select the route table.

1. From the **Edge associations** tab, choose **Edit edge associations**.

1. Select or deselect the checkbox for the gateway.

1. Choose **Save changes**.

**To associate a gateway with a route table using the AWS CLI**  
Use the [associate-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-route-table.html) command. The following example associates the specified route table with the specified internet gateway.

```
aws ec2 associate-route-table
    --route-table-id rtb-01234567890123456 \
    --gateway-id igw-11aa22bb33cc44dd1
```

**To disassociate a gateway from a route table using the AWS CLI**  
Use the [disassociate-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-route-table.html)command. Specify the ID of the association between the route table and the gateway.

```
aws ec2 disassociate-route-table \
    --association-id rtbassoc-0abcdef1234567890
```

# Replace or restore the target for a local route
<a name="replace-local-route-target"></a>

You can change the target of the default local route. If you replace the target of a local route, you can later restore it to the default `local` target. If your VPC has [multiple CIDR blocks](vpc-cidr-blocks.md#vpc-resize), your route tables have multiple local routes—one per CIDR block. You can replace or restore the target of each of the local routes as needed.

**To replace the local route using the 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 **Route tables**, and then select the route table.

1. From the **Routes** tab, choose **Edit routes**.

1. For the local route, clear **Target** and then choose a new target.

1. Choose **Save changes**.

**To restore the target for a local route using the 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 **Route tables**, and then select the route table.

1. Choose **Actions**, **Edit routes**.

1. For the route, clear **Target**, and then choose **local**.

1. Choose **Save changes**.

**To replace the target for a local route using the AWS CLI**  
Use the [replace-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-route.html) command. The following example replaces the target of the local route with the specified network interface.

```
aws ec2 replace-route \
    --route-table-id rtb-01234567890123456 \
    --destination-cidr-block 10.0.0.0/16 \
    --network-interface-id eni-11223344556677889
```

**To restore the target for a local route using the AWS CLI**  
The following example restores the local target for the specified route table.

```
aws ec2 replace-route \
    --route-table-id rtb-01234567890123456 \
    --destination-cidr-block 10.0.0.0/16 \
    --local-target
```

# Advanced routing in your VPC
<a name="advanced-routing"></a>

Configure advanced routing scenarios for your VPC. This section covers both static and dynamic routing approaches for managing traffic flow:
+ **Static ingress routing**: Configure static routes to direct inbound internet traffic destined for your BYOIP (Bring Your Own IP) address pools to specific network interfaces within your VPC.
+ **Dynamic routing with VPC Route Server:** Use BGP-based dynamic routing to automatically update VPC and internet gateway route tables, providing fault tolerance and automatic failover for your workloads.

**Topics**
+ [

# Route internet traffic to a single network interface
](igw-ingress-routing.md)
+ [

# Dynamic routing in your VPC using VPC Route Server
](dynamic-routing-route-server.md)

# Route internet traffic to a single network interface
<a name="igw-ingress-routing"></a>

You can route inbound internet traffic destined for large pools of public IP addresses to a single elastic network interface (ENI) in your VPC.

Previously, internet gateways only accepted traffic destined for public IP addresses that were directly associated with network interfaces in the VPC. Instance types have limits on the number of IP addresses that can be associated with network interfaces, creating challenges for industries like Telecommunications and Internet of Things (IoT) that need to handle traffic for IP pools larger than these limits.

This routing eliminates complex address translation on inbound internet connections. You can bring your own public IP pools (BYOIP) and configure your VPC internet gateway to accept and route traffic for the entire pool to a single network interface. This feature is particularly valuable for:
+ **Telecommunications**: Managing large subscriber IP pools without address translation overhead
+ **IoT applications**: Consolidating traffic from thousands of device IP addresses
+ **Any scenario**: Requiring traffic routing beyond ENI association limits

You can integrate this routing with VPC Route Server for dynamic route updates during failover scenarios.

**Key benefits**  
This routing approach provides the following benefits:
+ **No address translation required** - Direct routing eliminates NAT complexity
+ **Bypass ENI limits** - Handle IP pools larger than instance association limits
+ **Industry-optimized** - Purpose-built for Telco and IoT requirements
+ **Dynamic failover** - Integrates with Route Server for automatic updates

**Availability**  
You can use this feature in all AWS commercial regions, AWS China regions, and AWS GovCloud regions.

**Topics**
+ [

## Before you begin
](#before-you-begin)
+ [

## How this feature works
](#how-this-feature-works)
+ [

## Step 1: Create a VPC
](#step-1-create-a-vpc)
+ [

## Step 2: Create and attach an internet gateway
](#step-2-create-and-attach-an-internet-gateway)
+ [

## Step 3: Create a subnet for your target instance
](#step-3-create-a-subnet)
+ [

## Step 4: Create a route table for the subnet
](#step-4-create-a-route-table-for-the-subnet)
+ [

## Step 5: Create a security group for the target instance
](#step-5-create-a-security-group)
+ [

## Step 6: Launch target EC2 instance
](#step-6-launch-an-ec2-instance)
+ [

## Step 7: Create the internet gateway route table
](#step-7-create-a-route-table-for-the-internet-gateway)
+ [

## Step 8: Associate the route table with the internet gateway
](#step-8-associate-the-route-table-with-the-internet-gateway)
+ [

## Step 9: Associate your BYOIP pool with the internet gateway
](#step-9-associate-your-byoip-pool-with-the-internet-gateway)
+ [

## Step 10: Add static route to target your instance
](#step-10-add-static-route-to-target-your-instance)
+ [

## Step 11: Configure the target instance
](#step-11-configure-the-target-instance)
+ [

## Step 12: Configure instance for traffic handling
](#step-12-configure-instance-for-traffic-handling)
+ [

## Step 13: Test connectivity
](#step-13-test-connectivity)
+ [

## Troubleshooting
](#troubleshooting)
+ [

## Advanced option: Route server integration for dynamic routing
](#advanced-option-route-server-integration)
+ [

## Clean up
](#clean-up)

## Before you begin
<a name="before-you-begin"></a>

Before starting this tutorial, ensure you have:

1. **A BYOIP pool**: You must have already brought your own IP address range to AWS. Complete the steps in [Bring your own IP addresses (BYOIP) in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html).

1. **Verify your BYOIP pool**: Confirm your pool is ready by running:

   ```
   aws ec2 describe-public-ipv4-pools --region us-east-1
   ```

   Look for your pool in the output and ensure the `PoolAddressRanges` shows `Available` addresses.

1. **Appropriate permissions**: Ensure your AWS account has permissions to create VPC resources, EC2 instances, and manage BYOIP pools.

## How this feature works
<a name="how-this-feature-works"></a>

This section explains the technical concepts behind internet gateway ingress routing and how traffic flows from the internet to your target instance.

### Why use internet gateway ingress routing
<a name="why-use-internet-gateway-ingress-routing"></a>

Previously, you needed to perform address translation to consolidate traffic for large numbers of IP addresses due to ENI association limits. This enhancement removes that complexity by allowing direct routing of BYOIP pools to target instances.

### How the routing works
<a name="how-the-routing-works"></a>

This feature only works with the public IP CIDRs that you bring to AWS following the BYOIP process. The BYOIP process ensures that your account owns the public IP CIDR. Once you have the BYOIP public CIDR:

1. You associate this public IP address pool with an internet gateway route table. The internet gateway must already be associated with a VPC. This association allows the VPC to accept traffic destined for the IP CIDR. Ensure that the internet gateway has a dedicated route table that is not shared with any subnets.

1. Now that you have associated the BYOIP pool with the internet gateway route table, you can enter a route with a destination equal to the IP CIDR or a subset of it in the internet gateway route table. The target of this route would be the ENI where you want to route your traffic.

1. When your traffic destined for your BYOIP CIDR enters AWS, AWS looks at the internet gateway route table and accordingly routes traffic to the relevant VPC.

1. Inside the VPC, the internet gateway routes the traffic to the target ENI.

1. The target (an elastic network interface associated with your workload) processes the traffic.

**Best practices**
+ **Keep route tables separate**: The internet gateway route table must be dedicated only to the internet gateway. Do not associate this route table with any VPC subnets. Use separate route tables for subnet routing.
+ **Don't directly assign BYOIP IPs**: Do not associate public IP addresses from your BYOIP pool directly to EC2 instances or network interfaces. The internet gateway ingress routing feature routes traffic to instances without requiring direct IP association.

**Important**  
If you are using [VPC Block Public Access (BPA)](security-vpc-bpa.md), when BPA is enabled, it will block traffic to subnets using ingress routing, even if you've set a subnet-level BPA exclusion. Subnet-level exclusions do not work for ingress routing. To allow ingress routing traffic with BPA enabled:  
Disable BPA completely, or
Use a VPC-level exclusion

## Step 1: Create a VPC
<a name="step-1-create-a-vpc"></a>

Complete this step to create a VPC that will host your target instance and internet gateway.

**Note**  
Ensure you have not reached your VPC quota limit. For more information, see [Amazon VPC quotas](amazon-vpc-limits.md).

**AWS console**

1. Open the [Amazon VPC console](https://console.aws.amazon.com/vpc).

1. On the VPC dashboard, choose **Create VPC**.

1. For **Resources to create**, choose **VPC only**.

1. For **Name tag**, enter a name for your VPC (for example, **IGW-Ingress-VPC**).

1. For **IPv4 CIDR block**, enter a CIDR block (for example, **10.0.0.0/16**).

1. Choose **Create VPC**.

**AWS CLI**

```
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=IGW-Ingress-VPC}]' --region us-east-1
```

## Step 2: Create and attach an internet gateway
<a name="step-2-create-and-attach-an-internet-gateway"></a>

Complete this step to create an internet gateway and attach it to your VPC to enable internet connectivity.

**AWS console**

1. Open the [Amazon VPC console](https://console.aws.amazon.com/vpc).

1. In the VPC console, choose **Internet gateways**.

1. Choose **Create internet gateway**.

1. For **Name tag**, enter a name for your internet gateway (for example, **IGW-Ingress-Gateway**).

1. Choose **Create internet gateway**.

1. Select your internet gateway and choose **Actions**, **Attach to VPC**.

1. Select your VPC and choose **Attach internet gateway**.

**AWS CLI**

```
aws ec2 create-internet-gateway --tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=IGW-Ingress-Gateway}]' --region us-east-1

aws ec2 attach-internet-gateway --internet-gateway-id igw-0123456789abcdef0 --vpc-id vpc-0123456789abcdef0 --region us-east-1
```

**Note**: Replace the resource IDs with your actual IDs from the previous step.

## Step 3: Create a subnet for your target instance
<a name="step-3-create-a-subnet"></a>

Complete this step to create a subnet where your target instance will be deployed.

**AWS console**

1. In the VPC console navigation pane, choose **Subnets**.

1. Choose **Create subnet**.

1. Under **VPC ID**, choose your VPC.

1. For **Subnet name**, enter a name (for example, **Target-Subnet**).

1. For **Availability Zone**, you can choose a Zone for your subnet, or leave the default **No Preference** to let AWS choose one for you.

1. For **IPv4 CIDR block**, select **Manual input** and enter a CIDR block (for example, **10.0.1.0/24**).

1. Choose **Create subnet**.

**AWS CLI**

```
aws ec2 create-subnet \
    --vpc-id vpc-0123456789abcdef0 \
    --cidr-block 10.0.1.0/24 \
    --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=Target-Subnet}]' \
    --region us-east-1
```

## Step 4: Create a route table for the subnet
<a name="step-4-create-a-route-table-for-the-subnet"></a>

Complete this step to create a route table for your subnet and associate it with the subnet.

**AWS console**

1. In the VPC console navigation pane, choose **Route tables**.

1. Choose **Create route table**.

1. For **Name**, enter a name for your route table (for example, **Target-Subnet-Route-Table**).

1. For **VPC**, choose your VPC.

1. Choose **Create route table**.

1. Select your route table and choose **Actions**, **Edit subnet associations**.

1. Select your subnet and choose **Save associations**.

**AWS CLI**

```
aws ec2 create-route-table \
    --vpc-id vpc-0123456789abcdef0 \
    --tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=Target-Subnet-Route-Table}]' \
    --region us-east-1

aws ec2 associate-route-table \
    --route-table-id rtb-0987654321fedcba0 \
    --subnet-id subnet-0123456789abcdef0 \
    --region us-east-1
```

## Step 5: Create a security group for the target instance
<a name="step-5-create-a-security-group"></a>

Complete this step to create a security group that will control network access to your target instance.

**AWS console**

1. In the VPC console navigation pane, choose **Security Groups**.

1. Choose **Create security group**.

1. For **Security group name**, enter a name (for example, **IGW-Target-SG**).

1. For **Description**, enter **Security group for IGW ingress routing target instance**.

1. For **VPC**, select your VPC.

1. To add inbound rules, choose **Inbound rules**. For each rule, choose **Add rule** and specify the following:
   + **Type**: All ICMP - IPv4, **Source**: 0.0.0.0/0 (for ping testing).
   + **Type**: SSH, **Port**: 22, **Source**: 0.0.0.0/0 (for EC2 Instance Connect).

**Note**  
This security group opens SSH ports to all internet traffic for this tutorial. This tutorial is for educational purposes and should not be configured for production environments. In production, restrict SSH access to specific IP ranges.
+ Choose **Create security group**.

**AWS CLI**

```
aws ec2 create-security-group \
    --group-name IGW-Target-SG \
    --description "Security group for IGW ingress routing target instance" \
    --vpc-id vpc-0123456789abcdef0 \
    --region us-east-1

aws ec2 authorize-security-group-ingress \
    --group-id sg-0123456789abcdef0 \
    --protocol icmp \
    --port -1 \
    --cidr 0.0.0.0/0 \
    --region us-east-1

aws ec2 authorize-security-group-ingress \
    --group-id sg-0123456789abcdef0 \
    --protocol tcp \
    --port 22 \
    --cidr 0.0.0.0/0 \
    --region us-east-1
```

## Step 6: Launch target EC2 instance
<a name="step-6-launch-an-ec2-instance"></a>

Complete this step to launch the EC2 instance that will receive traffic from your BYOIP pool.

**AWS console**

1. Open the [Amazon EC2 console](https://console.aws.amazon.com/ec2).

1. Choose **Launch instance**.

1. For **Name**, enter a name for your instance (for example, **IGW-Target-Instance**).

1. For **Application and OS Images (Amazon Machine Image)**, choose **Amazon Linux 2023 AMI**.

1. For **Instance type**, choose **t2.micro** (eligible for free tier).

1. For **Key pair (login)**, select an existing key pair or create a new one.

1. For **Network settings**, choose **Edit** and configure:
   + **VPC**: Select your VPC
   + **Subnet**: Select your subnet
   + **Auto-assign public IP**: Enable
   + **Firewall (security groups)**: Select existing security group and choose your security group

1. Choose **Launch instance**.

1. **Important**: After launch, go to the instance details and note the **Network interface ID** (starts with "eni-") - you'll need this for Step 10.

**AWS CLI**

```
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --count 1 \
    --instance-type t2.micro \
    --key-name your-key-pair \
    --security-group-ids sg-0123456789abcdef0 \
    --subnet-id subnet-0123456789abcdef0 \
    --associate-public-ip-address \
    --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=IGW-Target-Instance}]' \
    --region us-east-1
```

**To find the ENI ID in the console:**

1. In the EC2 console, select your instance.

1. Go to the **Networking** tab.

1. Note the **Network interface ID** (for example, `eni-0abcdef1234567890`).

**To find the ENI ID using AWS CLI:**

```
aws ec2 describe-instances --instance-ids i-0123456789abcdef0 --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' --output text --region us-east-1
```

## Step 7: Create the internet gateway route table
<a name="step-7-create-a-route-table-for-the-internet-gateway"></a>

Complete this step to create a dedicated route table for the internet gateway that will handle ingress routing.

**AWS console**

1. In the VPC console, choose **Route tables**.

1. Choose **Create route table**.

1. For **Name**, enter a name for your route table (for example, **IGW-Ingress-Route-Table**).

1. For **VPC**, choose your VPC.

1. Choose **Create route table**.

1. Select your route table and choose the **Edge associations** tab.

1. Choose **Edit edge associations**.

1. Select your internet gateway and choose **Save changes**.

**AWS CLI**

```
aws ec2 create-route-table \
    --vpc-id vpc-0123456789abcdef0 \
    --tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=IGW-Ingress-Route-Table}]' \
    --region us-east-1
```

## Step 8: Associate the route table with the internet gateway
<a name="step-8-associate-the-route-table-with-the-internet-gateway"></a>

Complete this step to associate your route table with the internet gateway to enable ingress routing functionality.

**AWS console**

1. In the VPC console navigation pane, choose **Route tables**, and then select the route table you created.

1. From the **Edge associations** tab, choose **Edit edge associations**.

1. Select the checkbox for the internet gateway.

1. Choose **Save changes**.

**AWS CLI**

```
aws ec2 associate-route-table \
    --route-table-id rtb-0123456789abcdef0 \
    --gateway-id igw-0123456789abcdef0 \
    --region us-east-1
```

## Step 9: Associate your BYOIP pool with the internet gateway
<a name="step-9-associate-your-byoip-pool-with-the-internet-gateway"></a>

Complete this step to associate your BYOIP pool with the internet gateway route table, enabling the VPC to accept traffic for your IP range.

**AWS console**

1. In the VPC console navigation pane, choose **Route tables**, and select the internet gateway route table you created.

1. Click on the **IPv4 pool associations** tab.

1. Click on the **Edit associations** button.

1. Select your BYOIP pool (for example, `pool-12345678901234567`).

1. Click on the **Save associations** button.

**AWS CLI**

```
aws ec2 associate-route-table \
    --route-table-id rtb-0123456789abcdef0 \
    --public-ipv4-pool pool-12345678901234567 \
    --region us-east-1
```

**Note**: Replace `rtb-0123456789abcdef0` with your internet gateway route table ID and `pool-12345678901234567` with your BYOIP pool ID.

## Step 10: Add static route to target your instance
<a name="step-10-add-static-route-to-target-your-instance"></a>

Complete this step to add a route that directs traffic from your BYOIP range to your target instance's network interface.

**AWS console**

1. In the VPC console navigation pane, choose **Route tables**, and select the internet gateway route table you created.

1. Choose **Actions**, **Edit routes**.

1. Choose **Add route**.

1. For **Destination**, enter your BYOIP CIDR or a subset (for example, **203.0.113.0/24**). The prefix must be between /23 and /28.

1. For **Target**, select **Network interface** and enter your instance's ENI ID (for example, `eni-0abcdef1234567890`).

1. Choose **Save changes**.

**AWS CLI**

```
aws ec2 create-route \
    --route-table-id rtb-0123456789abcdef0 \
    --destination-cidr-block 203.0.113.0/24 \
    --network-interface-id eni-0abcdef1234567890 \
    --region us-east-1
```

## Step 11: Configure the target instance
<a name="step-11-configure-the-target-instance"></a>

Complete this step to configure your target instance to properly handle traffic destined for BYOIP addresses.

**Important**: Complete this instance configuration step before testing connectivity (Step 12). The instance must be configured to respond to BYOIP addresses for the ingress routing to work properly.

**AWS console**

1. Connect to your target instance using EC2 Instance Connect:
   + In the EC2 console, select your instance.
   + Choose **Actions** > **Connect**.
   + Select **EC2 Instance Connect** tab.
   + Choose **Connect**.

1. Add specific BYOIP IP address to your instance interface:

   First, find your network interface name:

   ```
   ip link show
   ```

   Then add the IP address (replace `203.0.113.10` with an IP from your BYOIP range):

   ```
   sudo ip addr add 203.0.113.10/32 dev eth0
   ```

   **Note**: Replace `203.0.113.10` with any IP address from your BYOIP range that you want to test. The interface name may be `eth0`, `ens5`, or similar depending on your instance type.

1. In the EC2 console, disable source/destination check:
   + Select your instance.
   + Go to **Networking** tab, click on the network interface.
   + Choose **Actions**, **Change source/dest check**, **Disable**.

**AWS CLI**

```
aws ec2 modify-network-interface-attribute \
    --network-interface-id eni-0abcdef1234567890 \
    --no-source-dest-check \
    --region us-east-1
```

## Step 12: Configure instance for traffic handling
<a name="step-12-configure-instance-for-traffic-handling"></a>

Complete this step to add BYOIP addresses to your instance and disable source/destination checking to enable proper traffic handling.

**AWS console**

1. Connect to your target instance using EC2 Instance Connect:
   + In the EC2 console, select your instance.
   + Choose **Actions** > **Connect**.
   + Select **EC2 Instance Connect** tab.
   + Choose **Connect**.

1. Add specific BYOIP IP address to your instance interface:

   First, find your network interface name:

   ```
   ip link show
   ```

   Then add the IP address (replace `ens5` with your actual interface name):

   ```
   sudo ip addr add 203.0.113.10/32 dev ens5
   ```

   **Note**: Replace `203.0.113.10` with any IP address from your BYOIP range that you want to test. The interface name may be `eth0`, `ens5`, or similar depending on your instance type.

1. In the EC2 console, disable source/destination check:
   + Select your instance.
   + Go to **Networking** tab, click on the network interface.
   + Choose **Actions**, **Change source/dest check**, **Disable**.

**AWS CLI**

```
aws ec2 modify-network-interface-attribute \
    --network-interface-id eni-0abcdef1234567890 \
    --no-source-dest-check \
    --region us-east-1
```

## Step 13: Test connectivity
<a name="step-13-test-connectivity"></a>

Complete this step to verify that internet traffic is properly routed to your target instance through the BYOIP addresses.

1. On your target instance, monitor incoming traffic using tcpdump:

   ```
   sudo tcpdump -i any icmp
   ```

1. From another terminal or computer, test connectivity to your BYOIP IP address:

   ```
   ping 203.0.113.10
   ```

1. Expected results:
   + Ping should succeed and show responses from your BYOIP IP address.
   + tcpdump should show incoming packets for the BYOIP address, similar to:

     ```
     12:34:56.789012 IP 203.0.113.100 > 203.0.113.10: ICMP echo request, id 1234, seq 1, length 64
     12:34:56.789123 IP 203.0.113.10 > 203.0.113.100: ICMP echo reply, id 1234, seq 1, length 64
     ```
   + Traffic should appear to come from external IP addresses, proving the internet gateway ingress routing is delivering internet traffic to your instance.

## Troubleshooting
<a name="troubleshooting"></a>

Use this section to resolve common issues you might encounter when setting up internet gateway ingress routing.

**Traffic not reaching the instance**  
+ Verify the route table has the correct ENI ID as the target.
+ Confirm the BYOIP pool is associated with the internet gateway route table.
+ Check that source/destination check is disabled on the instance.
+ Ensure security groups allow the traffic type you're testing.

**Route creation fails**  
+ Verify the BYOIP pool is properly associated with the route table.
+ Confirm the destination CIDR is within your BYOIP range.
+ Check that the target ENI exists and is attached to a running instance.
+ Ensure your BYOIP prefix is between /23 and /28 (prefixes outside this range are not supported).

**Ping/connectivity fails**  
+ Verify the IP addresses are added to the instance interface.
+ Check security groups allow ICMP (for ping) or relevant ports.
+ Confirm the instance is in a running state.
+ Test from multiple external locations.

## Advanced option: Route server integration for dynamic routing
<a name="advanced-option-route-server-integration"></a>

For environments requiring automatic failover, this feature integrates with VPC Route Server to:
+ **Dynamically update routes** during instance failures.
+ **Eliminate manual intervention** for route management.
+ **Provide enterprise-grade availability** for critical workloads.

This is particularly important for Telco and IoT use cases where high availability is essential.

**Note**  
When using Route Server with multiple BGP peers, be aware that a maximum of 32 BGP peers can advertise the same prefix to the same route table using route server.

For environments requiring dynamic routing, automatic failover, and load distribution across multiple instances, consider integrating with AWS Route Server. Route Server enables BGP-based dynamic routing instead of static routes, providing:
+ **Dynamic route advertisement** from instances through BGP.
+ **Automatic failover** between multiple target instances.
+ **Load distribution** across multiple endpoints.
+ **Centralized route management** through BGP protocols.

This is an important use case for enterprise deployments where high availability and dynamic routing capabilities are required. For detailed Route Server setup instructions, see the [AWS Route Server documentation](dynamic-routing-route-server.md).

## Clean up
<a name="clean-up"></a>

To avoid ongoing charges, delete the resources you created in this tutorial:

### Step 1: Terminate EC2 instance
<a name="step-1-terminate-ec2-instance"></a>

Complete this step to terminate the EC2 instance and stop incurring charges for compute resources.

**AWS console**

1. Open the [Amazon EC2 console](https://console.aws.amazon.com/ec2).

1. In the EC2 console navigation pane, choose **Instances**.

1. Select your instance and choose **Instance state**, **Terminate instance**.

1. Choose **Terminate** to confirm.

**AWS CLI**

```
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0 --region us-east-1
```

### Step 2: Detach internet gateway from VPC
<a name="step-2-detach-internet-gateway-from-vpc"></a>

Complete this step to detach and delete the internet gateway from your VPC.

**AWS console**

1. Open the [Amazon VPC console](https://console.aws.amazon.com/vpc).

1. In the VPC console navigation pane, choose **Internet gateways**.

1. Select your internet gateway and choose **Actions**, **Detach from VPC**.

1. Choose **Detach internet gateway**.

1. After detaching, choose **Actions**, **Delete internet gateway**.

1. Choose **Delete internet gateway**.

**AWS CLI**

```
aws ec2 detach-internet-gateway --internet-gateway-id igw-0123456789abcdef0 --vpc-id vpc-0123456789abcdef0 --region us-east-1

aws ec2 delete-internet-gateway --internet-gateway-id igw-0123456789abcdef0 --region us-east-1
```

### Step 3: Delete VPC
<a name="step-3-delete-vpc"></a>

Complete this step to delete the VPC and all associated resources to complete the cleanup process.

**AWS console**

1. In the VPC console, choose **Your VPCs**.

1. Select your VPC and choose **Actions**, **Delete VPC**.

1. Type **delete** to confirm and choose **Delete**.

**AWS CLI**

```
aws ec2 delete-vpc --vpc-id vpc-0123456789abcdef0 --region us-east-1
```

**Note**  
Deleting the VPC will also delete associated subnets, route tables, and security groups.

**Note**  
Your BYOIP pool remains available for future use and is not deleted as part of this cleanup process.

# Dynamic routing in your VPC using VPC Route Server
<a name="dynamic-routing-route-server"></a>

Amazon VPC Route Server simplifies routing for traffic between workloads that are deployed within a VPC and its internet gateways. With this feature, VPC Route Server dynamically updates VPC and internet gateway route tables with your preferred IPv4 or IPv6 routes to achieve routing fault tolerance for those workloads. This enables you to automatically reroute traffic within a VPC, which increases the manageability of VPC routing and interoperability with third-party workloads.

Route server supports the following route table types:
+ VPC route tables not associated with subnets
+ Subnet route tables
+ Internet gateway route tables

Route server does not support route tables associated with virtual private gateways. To propagate routes into a transit gateway route table, use [Transit Gateway Connect](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html).

**Quotas**

For quotas associated with Amazon VPC Route Server, see [Route server quotas](amazon-vpc-limits.md#vpc-limits-route-servers).

**Pricing**

For information about costs associated with Amazon VPC Route Server, see the [VPC Route Server](https://aws.amazon.com/vpc/pricing/) tab on the Amazon VPC pricing page.

**Topics**
+ [

# Terminology
](route-server-terms.md)
+ [

# How Amazon VPC Route Server works
](route-server-how-it-works.md)
+ [

# Route server peer logging
](route-server-peer-logging.md)
+ [

# Get started tutorial
](route-server-tutorial.md)

# Terminology
<a name="route-server-terms"></a>

The following terms are used in this guide:
+ **FIB**: The [Forwarding Information Base (FIB)](https://en.wikipedia.org/wiki/Forwarding_information_base) serves as a forwarding table for what route server has determined are the best-path routes in the RIB after evaluating all available routing information and policies. The FIB routes that are installed on the route tables. The FIB is recomputed whenever there are changes to the RIB.
+ **RIB**: The [Routing Information Base (RIB)](https://en.wikipedia.org/wiki/Routing_table) serves as a database that stores all the routing information and network topology data collected by a router or routing system, such as routes learned from BGP peers. The RIB is constantly updated as new routing information is received or existing routes change. This ensures that the route server always has the most current view of the network topology and can make optimal routing decisions.
+ **Route server**: The route server component updates your VPC and internet gateway route tables with the IPv4 or IPv6 routes in your Forwarding Information Base (FIB). The route server represents a single FIB and Routing Information Base (RIB).
+ **Route server association**: A route server association is the connection established between a route server and a VPC.
+ **Route server endpoint**: A route server endpoint is an AWS-managed component inside a subnet that facilitates [BGP (Border Gateway Protocol)](https://en.wikipedia.org/wiki/Border_Gateway_Protocol) connections between your route server and your BGP peers.
+ **Route server peer**: A route server peer is a session between a route server endpoint and the device deployed in AWS (such as a firewall appliance or other network security function running on an EC2 instance). The device must meet these requirements: 
  + Have an elastic network interface in the VPC
  + Support BGP (Border Gateway Protocol)
  + Can initiate BGP sessions
+ **Route server propagation**: When enabled, route server propagation installs the routes in the FIB on the route table you've specified. Route server supports IPv4 and IPv6 route propagation.

# How Amazon VPC Route Server works
<a name="route-server-how-it-works"></a>

This section explains how Amazon VPC Route Server works and helps you understand how it achieves routing fault tolerance for your workloads running in subnets.

**Topics**
+ [

## Overview
](#route-server-overview)
+ [

## Diagrams
](#route-server-diagrams)

## Overview
<a name="route-server-overview"></a>

How Amazon VPC Route Server works:

1. You configure a network device (like a firewall running on an EC2 instance in the VPC) to use Amazon VPC Route Server.

1. The network device fails.

1. The route server endpoints detect the failure through [BFD (Bidirectional Forwarding Detection)](https://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection) configured on the route server peer.

1. The route server endpoints update the route server to withdraw routes in a [Routing Information Base (RIB)](https://en.wikipedia.org/wiki/Routing_table) where the failed device is the next hop.

1. The route server computes a [Forwarding Information Base (FIB)](https://en.wikipedia.org/wiki/Forwarding_information_base) from the RIB, selecting the best available routes.

1. Route server updates the configured route tables with the routes from the FIB.

1. All new traffic is forwarded to the standby device.

## Diagrams
<a name="route-server-diagrams"></a>

The following is an example diagram of VPC route server with route server endpoints configured for devices in two subnets.

![\[Basic Amazon VPC Route Server setup\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/route-server-main.png)


Starting with the example above as a baseline, the example below shows a more detailed design, where both Device A and Device B advertise over BGP that they can accept any traffic with a destination IP in the range of 192.0.0.0/24 (from 192.0.0.0 to 192.0.0.255). The MED (Multi-Exit Discriminator) attribute of 0 tells route server that Device A should be preferred over Device B. The route server receives the route and the MED attribute from Device A and installs that route in the subnet route tables with the network interface of Device A as the "next hop". As a result, any traffic within the subnet with a destination IP in the 192.0.0.0/24 range is sent to Device A. Device A then processes the traffic and sends it onward. Traffic within either subnet (10.0.0.0/24 or 10.0.1.0/24) that is bound for 192.0.0.0/24 will be routed to Device A eni-abcd (10.0.0.1) as the next hop.

![\[Amazon VPC Route Server setup before device A failure\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/route-server-failover-part-1.png)


This last example below shows how route server handles failover. While the higher MED attribute tells route server that Device B is less preferred than Device A, if Device A eni-abcd (10.0.0.1) goes down, route server updates the subnet route tables, and traffic to 192.0.0.0/24 is routed to Device B eni-efgh (10.0.1.1) as the next hop.

![\[Amazon VPC Route Server failover to device B\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/route-server-failover-part-2.png)


# Route server peer logging
<a name="route-server-peer-logging"></a>

Use VPC Route Server peer logging when you need to:
+ Monitor BGP and BFD session health
+ Troubleshoot connection issues
+ Review historical session changes
+ Track network status

## Pricing
<a name="pricing"></a>
+ **CloudWatch**: Data ingestion and archival charges for vended logs apply when you publish route server peer logs to CloudWatch Logs. 
+ **S3**: Data ingestion and archival charges for vended logs apply when you publish route server peer logs to Amazon S3.
+ **Data Firehose**: Standard ingestion and delivery charges apply.

Vended logs are logs from specific AWS services that are available at volume tiered pricing and delivered to CloudWatch Logs, Amazon S3, or Amazon Data Firehose. For more information, open [Amazon CloudWatch Pricing](https://aws.amazon.com//cloudwatch/pricing/), select **Logs** and find **Vended Logs**.

## Example log format
<a name="example-log-format"></a>

```
{
    "resource_arn": "arn:aws:ec2:us-east-1:111122223333:route-server-peer/rsp-1234567890abcdef0",
    "event_timestamp": 1746643505367,
    "type": "RouteStatus",
    "status": "ADVERTISED",
    "message": {
        "prefix": "10.24.34.0/32",
        "asPath": "65000",
        "med": 100,
        "nextHopIp": "10.24.34.1"
    }
}

{
    "resource_arn": "arn:aws:ec2:us-east-1:111122223333:route-server-peer/rsp-1234567890abcdef0",
    "event_timestamp": 1746643490000,
    "type": "BGPStatus",
    "status": "UP",
    "message": null
}
```

Where:
+ The `resource_arn` is the ARN for the route server peer.
+ The `event_timestamp` is the timestamp of the event.
+ The `type` of log events we produce (`RouteStatus`, `BGPStatus`, `BFDStatus`).
+ The `status` field is the status update.
  + For `RouteStatus` type messages
    + `ADVERTISED` (route was advertised by the peer)
    + `UPDATED` (existing route was updated by the peer)
    + `WITHDRAWN` (route was withdrawn by peer)
  + For `BFDStatus` and `BGPStatus` updates
    + `UP`, `DOWN`.
+ The `message` field is currently only used for route attributes for the RouteStatus message type but may be populated with relevant information for any type.

------
#### [ AWS Management Console ]

To create route server peer logs:

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, under **Virtual private cloud**, choose **Route servers**.

1. On the **Route servers** page, choose **Route server peers**.

1. Choose the **Log delivery** tab.

1. Choose **Add log delivery**.

1. Choose a destination and configure the settings:
   + Amazon CloudWatch Logs
     + **Log type**: Types of logs to deliver. The only supported log type is EVENT\$1LOGS.
     + **Destination log group**: The CloudWatch log group where logs will be sent. You can pick an existing log group or create a new one (example: /aws/vpc/route-server-peers).
     + **Field selection**: Data fields to include in your logs.
     + **Output format**: How logs are formatted:
       + JSON: Structured format for computer processing
       + Text: Plain text format
     + **Field delimiter**: When using Text format, this is the character that separates fields (example: comma, tab, space).
   + Amazon S3
     + Cross account - Sending logs to different AWS accounts
       + **Log type**: Types of logs to deliver. The only supported log type is EVENT\$1LOGS.
       + **Delivery destination ARN**: The Amazon Resource Name of the S3 bucket in another AWS account where logs will be sent.
       + **Field selection**: Data fields to include in your logs.
       + **Suffix**: The ending added to log file names (example: .log, .txt).
       + **Hive-compatible**: When turned on, organizes logs in a folder structure that works with Hive-based tools for easier searching with services like Amazon Athena.
       + **Field delimiter**: When using Text format, this is the character that separates fields.
     + In current account
       + **Log type**: Types of logs to deliver. The only supported log type is EVENT\$1LOGS.
       + **Destination S3 bucket**: The S3 bucket in your account where logs will be sent. You can specify a subfolder path.
       + **Field selection**: Data fields to include in your logs.
       + **Suffix**: The ending added to log file names (example: .log, .txt).
       + **Hive-compatible**: When turned on, organizes logs in a folder structure that works with Hive-based tools for easier searching.
       + **Field delimiter**: When using Text format, this is the character that separates fields.
   + Amazon Data Firehose
     + Cross account
       + **Log type**: Types of logs to deliver. The only supported log type is EVENT\$1LOGS.
       + **Delivery destination ARN**: The Amazon Resource Name of the Firehose delivery stream in another AWS account.
       + **Field selection**: Data fields to include in your logs.
       + **Field delimiter**: When using Text format, this is the character that separates fields.
     + In current account
       + **Log type**: Types of logs to deliver. The only supported log type is EVENT\$1LOGS.
       + **Delivery destination stream**: The Firehose delivery stream in your account where logs will be sent. The stream must use the "Direct Put" source type.
       + **Field selection**: Data fields to include in your logs.
       + **Output format**: How logs are formatted:
         + JSON: Structured format for computer processing
         + Text: Plain text format
       + **Field delimiter**: When using Text format, this is the character that separates fields.

------
#### [ Command line ]

The commands in this section link to the *AWS CLI Command Reference*. The documentation provides detailed descriptions of the options that you can use when you run the commands.

To create route server peer logs:

1. Use the [put-delivery-source](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/put-delivery-source.html) command.
   + Example request

     ```
     aws logs put-delivery-source --name "source-rsp-1234567890abcdef0" --resource-arn "arn:aws:ec2:us-east-1:111122223333:route-server-peer/rsp-1234567890abcdef0" --log-type "EVENT_LOGS"
     ```
   + Example response

     ```
     {
          "deliverySource": {
             "name": "source-rsp-1234567890abcdef0",
             "arn": "arn:aws:logs:us-east-1:111122223333:delivery-source:source-rsp-1234567890abcdef0",
             "resourceArns": [
                 "arn:aws:ec2:us-east-1:111122223333:route-server-peer/rsp-1234567890abcdef0"
             ],
             "service": "ec2",
             "logType": "EVENT_LOGS"
         }
     }
     ```

1. Use the [put-delivery-destination](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/put-delivery-destination.html) command.
   + The following AWS CLI example creates a route server log. The logs are delivered to the specified log group.
   + Example request

     ```
     aws logs put-delivery-destination --name "destination-rsp-abcdef01234567890" --destination-resource-arn "arn:aws:logs:us-east-1:111122223333:log-group:/aws/vendedlogs/ec2/route-server-peer/EVENT_LOGS/rsp-abcdef01234567890"
     ```
   + Example response

     ```
     {
          "deliveryDestination": {
             "name": "destination-rsp-abcdef01234567890",
             "arn": "arn:aws:logs:us-east-1:111122223333:delivery-destination:destination-rsp-abcdef01234567890",
             "deliveryDestinationType": "CWL",
             "deliveryDestinationConfiguration": {
                 "destinationResourceArn": "arn:aws:logs:us-east-1:111122223333:log-group:/aws/vendedlogs/ec2/route-server-peer/EVENT_LOGS/rsp-abcdef01234567890"
             }
         }
     }
     ```

1. Use the [create-delivery](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/create-delivery.html) command.
   + Example request

     ```
     aws logs create-delivery --delivery-source-name "source-rsp-1234567890abcdef0" --delivery-destination-arn "arn:aws:logs:us-east-1:111122223333:delivery-destination:destination-rsp-abcdef01234567890"
     ```
   + Example response

     ```
     {
          "delivery": {
             "id": "1234567890abcdef0",
             "arn": "arn:aws:logs:us-east-1:111122223333:delivery:1234567890abcdef0",
             "deliverySourceName": "source-rsp-1234567890abcdef0",
             "deliveryDestinationArn": "arn:aws:logs:us-east-1:111122223333:delivery-destination:destination-rsp-abcdef01234567890",
             "deliveryDestinationType": "CWL",
             "recordFields": [
                 "resource_arn",
                 "event_timestamp",
                 "type",
                 "status",
                 "message"
             ]
         }
     }
     ```

------

# Get started tutorial
<a name="route-server-tutorial"></a>

This tutorial walks you through the process of setting up and configuring VPC Route Server to enable dynamic routing in your VPC. You'll learn how to create and configure all the necessary components, establish BGP peering, and verify proper operation. The tutorial covers everything from initial IAM setup through testing and cleanup.

Before beginning this tutorial, ensure you have:
+ Administrative access to your AWS account
+ A VPC with at least two subnets where you want to enable dynamic routing
+ Network devices (like firewalls running on EC2 instances) that support BGP and can serve as route server peer devices
+ Basic familiarity with BGP concepts and AWS networking

The steps can be completed using either the AWS Management Console or AWS CLI. Both methods are provided for each step.

Estimated time to complete: 15-30 minutes

**Topics**
+ [

# Step 1: Configure required IAM Role permissions
](route-server-iam.md)
+ [

# Step 2: Create a route server
](route-server-tutorial-create.md)
+ [

# Step 3: Associate route server with a VPC
](route-server-tutorial-associate.md)
+ [

# Step 4: Create route server endpoints
](route-server-tutorial-create-endpoints.md)
+ [

# Step 5: Enable route server propagation
](route-server-tutorial-enable-prop.md)
+ [

# Step 6: Create route server peer
](route-server-tutorial-create-peer.md)
+ [

# Step 7: Initiate BGP sessions from the devices
](route-server-tutorial-initiate-bgp.md)
+ [

# Step 8: Cleanup
](route-server-tutorial-cleanup.md)

# Step 1: Configure required IAM Role permissions
<a name="route-server-iam"></a>

To use VPC Route Server, ensure that the IAM user or role you are using has the required IAM permissions. Below is a guide to which permissions are required for each API:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "CreateRouteServer",
            "Effect": "Allow",
            "Action": [
                "sns:CreateTopic"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DeleteRouteServer",
            "Effect": "Allow",
            "Action": [
                "sns:DeleteTopic"
            ],
            "Resource": "*"
        },
        {
            "Sid": "CreateRouteServerEndpoint",
            "Effect": "Allow",
            "Action": [
                "ec2:CreateNetworkInterface",
                "ec2:CreateNetworkInterfacePermission",
                "ec2:CreateSecurityGroup",
                "ec2:DescribeSecurityGroups",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateTags",
                "ec2:DeleteTags"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DeleteRouteServerEndpoint",
            "Effect": "Allow",
            "Action": [
                "ec2:DeleteNetworkInterface",
                "ec2:DeleteSecurityGroup",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:CreateTags",
                "ec2:DeleteTags"
            ],
            "Resource": "*"
        },
        {
            "Sid": "CreateRouteServerPeer",
            "Effect": "Allow",
            "Action": [
                "ec2:AuthorizeSecurityGroupIngress"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DeleteRouteServerPeer",
            "Effect": "Allow",
            "Action": [
                "ec2:RevokeSecurityGroupIngress"
            ],
            "Resource": "*"
        }
    ]
}
```

------

# Step 2: Create a route server
<a name="route-server-tutorial-create"></a>

Complete the steps in this section to create a route server.

The route server component updates your VPC and internet gateway route tables with the IPv4 or IPv6 routes in your Forwarding Information Base (FIB). The route server represents a single FIB and Routing Information Base (RIB).

------
#### [ AWS Management Console ]

**To create a route server**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, under **Virtual private cloud**, choose **Route servers**.

1. On the **Route servers** page, choose **Create route server**.

1. On the **Create route server** page, configure the following settings:
   + For **Name**, enter a name for your route server (e.g., "my-route-server-01"). The name must be 255 characters or less in length.
   + For **Amazon Side ASN**, enter a BGP ASN value. This value must be in the range of 1-4294967295. We recommend using a private ASN in the 64512–65534 (16-bit ASN) or 4200000000–4294967294 (32-bit ASN) range.
   +  For **Persist routes**, choose either **Enable** or **Disable**. This option determines whether routes should be maintained after all BGP sessions are terminated:
     + If enabled: Routes will be preserved in the route server's routing database even if all BGP sessions end
     + If disabled: Routes will be removed from the routing database when all BGP sessions end
   + If you enabled persist routes, for **Persist duration**, enter a value between 1-5 minutes. This duration specifies how long the route server will wait after BGP is re-established to unpersist the routes. For example, if you set it to 1 minute, your device has 1 minute after re-establishing BGP to relearn and advertise its routes before the route server resumes normal functionality. While 1 minute is typically sufficient, you can set up to 5 minutes if your BGP network needs more time to fully re-establish and re-learn all routes.
   + (Optional) To enable SNS notifications for BGP status changes, toggle the **Enable SNS notifications** switch. Enabling SNS notifications persists BGP or BFD session status changes on route server peers and maintenance notifications for route server endpoints to an SNS topic provisioned by AWS. For details about these notifications, see the **SNS notification details** table below.

1. (Optional) To add tags to your route server, scroll down to the **Tags - optional** section and choose **Add new tag**. Enter a key and an optional value for each tag. You can add up to 50 tags.

1. Review your settings and choose **Create route server**.

1. Wait for the route server to be created. Once complete, you will be redirected to the **Route servers** page, where you can see your new route server listed with a status of *Available*.

------
#### [ Command line ]

Use the following procedure to create a new route server to manage dynamic routing in a VPC.

For `--amazon-side-asn`, enter a BGP ASN value. This value must be in the range of 1-4294967295. We recommend using a private ASN in the 64512–65534 (16-bit ASN) or 4200000000–4294967294 (32-bit ASN) range.

1. Command:

   ```
   aws ec2 create-route-server --amazon-side-asn 65000
   ```

   Response:

   ```
   {
       "RouteServer": {
           "RouteServerId": "rs-1",
           "AmazonSideAsn": 65000,
           "State": "pending"
       }
   }
   ```

1. Wait for the route server to be available.

   Command:

   ```
   aws ec2 describe-route-servers
   ```

   Response:

   ```
   {
       "RouteServer": {
           "RouteServerId": "rs-1",
           "AmazonSideAsn": 65000,
           "State": "available"
       }
   }
   ```

------

**SNS notification details**

The following table shows details about the messages that Amazon VPC Route Server will send using Amazon SNS:


| Standard fields |  | Message attributes (Metadata) |  |  |  | 
| --- | --- | --- | --- | --- | --- | 
| Message | When it is sent | timestamp | eventCode | routeServerEndpointId | affectedRouteServerPeerIds | 
| Route Server Endpoint [ENDPOINT ID] is now undergoing maintenance. BFD and BGP sessions may be impacted. | Route server endpoint maintenance | Format: 2025-02-17T15:55:00Z | ROUTE\$1SERVER\$1ENDPOINT\$1MAINTENANCE | Affected endpoint ID | List of affected peer IDs | 
| Message | When it is sent | timestamp | eventCode | routeServerPeerId | newBgpStatus | 
| BGP for Route Server Peer [PEER ID] is now [UP/DOWN]. | Route server peer BGP status change | Format: 2025-02-17T15:55:00Z | ROUTE\$1SERVER\$1PEER\$1BGP\$1STATUS\$1CHANGE | Affected peer ID | UP or DOWN | 
| Message | When it is sent | timestamp | eventCode | routeServerPeerId | newBfdStatus | 
| BFD for Route Server Peer [PEER ID] is now [UP/DOWN]. | Route server peer BFD status change | Format: 2025-02-17T15:55:00Z | ROUTE\$1SERVER\$1PEER\$1BFD\$1STATUS\$1CHANGE | Affected peer ID | UP or DOWN | 

# Step 3: Associate route server with a VPC
<a name="route-server-tutorial-associate"></a>

Complete the steps in this section to associate the route server with a VPC.

A route server association is the connection established between a route server and a VPC. This is a fundamental configuration step that enables the route server to work with appliances in your VPC.

When you create a route server association:
+ It links the route server to a specific VPC.
+ It enables the route server to interact with route tables within the VPC’s subnets.
+ It allows the route server to receive and propagate routes within the associated VPC.
+ It establishes the scope of where the route server can operate.

Key aspects of a route server association:
+ Each route server can be associated with one VPC. Each VPC can have up to 5 separate route server associations by default. For more information about quotas, see [Route server quotas](amazon-vpc-limits.md#vpc-limits-route-servers).
+ The association must be created before the route server can manage routes.
+ The association can be monitored to track its state (such as associating and associated).
+ The association can be removed (disassociated) if you no longer want the route server to operate in that VPC.

------
#### [ AWS Management Console ]

**Associate a route server with a VPC**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, under **Virtual private cloud**, choose **Route servers**.

1. Select the route server you want to associate with a VPC.

1. On the **Association tab**, choose **Associate route server**.

1. In the Associate route server dialog box:
   + The **Route server ID** field is automatically populated with your selected route server
   + For **VPC ID**, choose the VPC you want to associate from the dropdown list

1. Choose **Associate route server**.

1. Wait for the association to complete. Once finished, the **State** will show as *Associated* on the **Association** tab.

------
#### [ Command line ]

Use the following procedure to associate a route server with a VPC.

1. Command:

   ```
   aws ec2 associate-route-server --route-server-id rs-1 --vpc-id vpc-1
   ```

   Response:

   ```
   {
       "RouteServerAssociation": {
           "RouteServerId": "rs-1",
           "VpcId": "vpc-1",
           "State": "associating"
       }
   }
   ```

1. Wait for the association to complete.

   Command:

   ```
   aws ec2 get-route-server-associations --route-server-id rs-1
   ```

   Response:

   ```
   {
       "RouteServerAssociation": {
           "RouteServerId": "rs-1",
           "VpcId": "vpc-1",
           "State": "associated"
       }
   }
   ```

------

# Step 4: Create route server endpoints
<a name="route-server-tutorial-create-endpoints"></a>

Complete the steps in this section to create route server endpoints. Create two endpoints per subnet for redundancy.

A route server endpoint is an AWS-managed component inside a subnet that facilitates [BGP (Border Gateway Protocol)](https://en.wikipedia.org/wiki/Border_Gateway_Protocol) connections between your route server and your BGP peers. 

Route server endpoints are the "contact points" where your network devices establish BGP sessions with the route server. They're the components that actually handle the BGP connections, while the route server itself manages the routing decisions and route propagation.

**Note**  
Route server endpoints are charged \$10.75 per hour.

------
#### [ AWS Management Console ]

**To create route server endpoints**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation pane, under **Virtual private cloud**, choose **Route servers**.

1. Select the route server for which you want to create endpoints.

1. In the lower pane, choose the **Route server endpoints** tab.

1. Choose **Create route server endpoint**.

1. On the **Create route server endpoint** page, configure the following settings:
   + For **Name**, enter a descriptive name for your endpoint.
   + For **Route server**, confirm that the correct route server is selected.
   + For **Subnet**, select the subnet in which you want to create the endpoint.

1. (Optional) To add tags to your route server endpoint, scroll down to the **Tags - optional** section and choose **Add new tag**. Enter a key and an optional value for each tag.

1. Review your settings and choose **Create route server endpoint**.

1. Wait for the endpoint to be created. Once complete, you will see a success message.

1. Repeat steps 5-9 to create a second endpoint in the same subnet, using a different name.

1. Repeat steps 5-10 for each subnet where you need route server endpoints.

1. After creating the endpoints, return to the **Route server endpoints** tab for your route server.

1. Verify that you see two endpoints listed for each subnet.

1. Check that the **State** for each endpoint is *Available*.

------
#### [ Command line ]

Use the following procedure to create a route server endpoint.

1. Command:

   ```
   aws ec2 create-route-server-endpoint --route-server-id rs-1 --subnet-id subnet-1
   ```

   Response:

   ```
   {
       "RouteServerEndpoint": {
           "RouteServerId": "rs-1",
           "RouteServerEndpointId": "rse-1",
           "VpcId": "vpc-1",
           "SubnetId": "subnet-1",
           "State": "pending"
       }
   }
   ```

1. You may need to wait a few minutes for the endpoints to become fully available after creation.

   Command:

   ```
   aws ec2 describe-route-server-endpoints
   ```

   Response:

   ```
   {
       "RouteServerEndpoint": {
           "RouteServerId": "rs-1",
           "RouteServerEndpointId": "rse-1",
           "VpcId": "vpc-1",
           "SubnetId": "subnet-1",
           "EniId": "eni-123",
           "EniAddress": "10.1.2.3",
           "State": "available"
       }
   }
   ```

Repeat the steps to create a second endpoint in the same subnet using a different name and create endpoints for each subnet where you need route server endpoints.

------

# Step 5: Enable route server propagation
<a name="route-server-tutorial-enable-prop"></a>

Complete this step to enable route server propagation.

When enabled, route server propagation installs the routes in the FIB on the route table you've specified. Route server supports IPv4 and IPv6 route propagation. 

Route server propagation is the mechanism that automates route table updates - instead of manually updating route tables, the route server automatically propagates the appropriate routes to the configured route tables with routes from the FIB.

Key aspects of route server propagation:
+ Configuration
  + Links a route server to specific route tables
  + Determines which route tables will receive dynamic route updates
  + Can be enabled or disabled per route table
+ Functionality
  + Automatically updates route tables with routes learned from BGP peers
  + Propagates the best available routes based on BGP attributes
  + Maintains route consistency across specified route tables
  + Updates routes dynamically when network conditions change
+ States
  + Can be enabled (routes are being propagated)
  + Can be disabled (routes are not being propagated)

------
#### [ AWS Management Console ]

**To enable route server propagation**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. Select the route server for which you want to enable propagation.

1. Choose the **Propagations** tab in the route server details panel.

1. Choose **Enable propagation**.

1. In the **Enable propagation** dialog:
   + The **Route server ID** will be pre-populated.
   + Under **Route table**, select the destination route table from the dropdown menu for newly propagated routes.

1. Choose **Enable propagation** to confirm.

1. Wait for the propagation status to change to Available in the **Propagations** list.

1. Verify that the selected route table appears in the **Propagations** list with a state of *Available*.

------
#### [ Command line ]

Use the following procedure to enable route server propagation.

1. Command:

   ```
   aws ec2 enable-route-server-propagation --route-table-id rtb-1 --route-server-id rs-1
   ```

   Response:

   ```
   {
       "RouteServerRoutePropagation": {
           "RouteServerId": "rs-1",
           "RouteTableId": "rtb-1",
           "State": "pending"
       }
   }
   ```

1. Wait for the propagation state to change to available.

   Command:

   ```
   aws ec2 get-route-server-propagations --route-server-id rs-1
   ```

   Response:

   ```
   {
       "RouteServerRoutePropagation": {
           "RouteServerId": "rs-1",
           "RouteTableId": "rtb-1",
           "State": "available"
       }
   }
   ```

------

# Step 6: Create route server peer
<a name="route-server-tutorial-create-peer"></a>

A route server peer is a session between a route server endpoint and the device deployed in AWS (such as a firewall appliance or other network security function running on an EC2 instance). The device must meet these requirements: 
+ Have an elastic network interface in the VPC
+ Support BGP (Border Gateway Protocol)
+ Can initiate BGP sessions

**Note**  
We recommend you create one route server peer per route server endpoint for redundancy.

------
#### [ AWS Management Console ]

**To create a route server peer**

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. In the navigation path, choose **VPC** > **Route server peers** > **Create route server peer**.

1. Under **Details**, configure the following:
   + **Name**: Enter a name for your route server peer (up to 255 characters). Example: my-route-server-peer-01
   + **Route server endpoint ID**: Choose a route server endpoint from the dropdown. Optionally, choose **Create a route server endpoint** to create a new one.
   + **Peer address**: Enter the IPv4 address of the peer. Must be a valid IP address. The peer address must be reachable from the route server endpoint.
   + **Peer ASN**: Enter the ASN (Autonomous System Number) for the BGP peer. Value must be in range of 1-4294967295. The ASN should typically use private ranges (64512-65534 for 16-bit or 4200000000-4294967294 for 32-bit)
   + **Peer liveness detection**:
     + **BGP keepalive** (default): Standard BGP keep alive mechanism
     + **BFD**: Bidirectional Forwarding Detection for faster failover
   + (Optional) Under **Tags**, choose **Add new tag** to add key-value pair tags. Tags help identify and track AWS resources.

1. Review your settings and choose **Create route server peer**.

------
#### [ Command line ]

Use the following procedure to create a route server peer.

1. Command:

   ```
   aws ec2 create-route-server-peer --route-server-endpoint-id rse-1 --peer-address 10.0.2.3 --bgp-options PeerAsn=65001,PeerLivenessDetection=bfd
   ```

   Response:

   In the response, the state values can be `pending|available|deleting|deleted`.

   ```
   {
       "RouteServerPeer": {
           "RouteServerPeerId": "rsp-1",
           "RouteServerId": "rs-1",
           "VpcId": "vpc-1",
           "SubnetId": "subnet-1",
           "State": "pending",
           "EndpointEniId": "eni-2,
           "EndpointEniAddress": "10.0.2.4",
           "PeerEniId": "eni-1",
           "PeerAddress": "10.0.2.3",
           "BgpOptions": {
               "PeerAsn": 65001,
      "PeerLivenessDetection": "bfd"
           },
           "BgpStatus": {
               "Status": "Up"
           }
       }
   }
   ```

1. Wait for the propagation state to change to available.

   Command:

   ```
   aws ec2 describe-route-server-peers
   ```

   Response:

   ```
   {
       "RouteServerPeer": {
           "RouteServerPeerId": "rsp-1",
           "RouteServerId": "rs-1",
           "VpcId": "vpc-1",
           "SubnetId": "subnet-1",
           "State": "available",
           "EndpointEniId": "eni-2,
           "EndpointEniAddress": "10.0.2.4",
           "PeerEniId": "eni-1",
           "PeerAddress": "10.0.2.3",
           "BgpOptions": {
               "PeerAsn": 65001,
      "PeerLivenessDetection": "bfd"
           },
           "BgpStatus": {
               "Status": "down"
           }
       }
   }
   ```

------

# Step 7: Initiate BGP sessions from the devices
<a name="route-server-tutorial-initiate-bgp"></a>

When the status of route server peer is available, configure your workload to initiate the BGP session with the route server endpoint. 

Initiating a BGP session from the devices in your subnets is outside the scope of this guide. The route server endpoint does not initiate the BGP session.

You can check that the VPC Route Server feature is working by verifying that the route table contains the best routes propagated by route server.

# Step 8: Cleanup
<a name="route-server-tutorial-cleanup"></a>

The building portion of the tutorial is complete. Complete the steps in this section to remove the VPC Route Server components that you created.

**7.1: Withdraw BGP advertisement on the devices**

Withdrawing BGP advertisement on the devices in your subnets is outside the scope of this guide. Refer to your third-party vendor for your BGP configurations as needed.

**7.2: Disable route server propagation**

Use the following procedure to disable route server propagation.

------
#### [ AWS Management Console ]

****

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. Select the route server for which you want to disable propagation.

1. Choose **Actions > Modify route server**.

1. Choose the **Propagations** tab in the route server details panel.

1. Choose the propagation you want to disable and then choose **Disable propagation**.

1. In the dialog box, choose **Disable route server propagation**.

------
#### [ Command line ]

1. Disable propagation:

   ```
   aws ec2 disable-route-server-route-propagation --route-table-id rtb-1 --route-server-id rs-1
   ```

1. Confirm that the propagation has been deleted:

   ```
   aws ec2 get-route-server-route-propagations --route-server-id rs-1 [--route-table-id rtb-1]
   ```

------

**7.3: Delete route server peers**

Use the following procedure to delete route server peers.

------
#### [ 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 path, choose **Route servers** > **Route server peers**.

1. Select a route server peer.

1. Choose **Actions** > **Delete route server peer**.

------
#### [ Command line ]

1. Delete peers:

   ```
   aws ec2 delete-route-server-peer --route-server-peer-id rsp-1
   ```

1. Confirm the deletion:

   ```
   aws ec2 describe-route-server-peers [--route-server-peer-ids rsp-1] [--filters Key=RouteServerId|RouteServerEndpointId|VpcId]
   ```

------

**7.4: Delete route server endpoints**

Use the following procedure to delete route server endpoints.

------
#### [ AWS Management Console ]

****

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. Select the route server for which you want to delete endpoints.

1. Choose **Route server endpoints**.

1. Select the endpoint and choose **Actions** > **Delete route server endpoint**.

1. Enter delete and choose **Delete**.

------
#### [ Command line ]

1. Describe endpoints:

   ```
   aws ec2 describe-route-server-endpoints
   ```

1. Delete route server endpoints:

   ```
   aws ec2 delete-route-server-endpoint --route-server-endpoint-id rse-1
   ```

1. Confirm that the endpoints have been deleted:

   ```
   aws ec2 describe-route-server-endpoints [--route-server-endpoint-ids rsp-1] [--filters Key=RouteServerId|VpcId|SubnetId]
   ```

------

**7.5: Disassociate route server from VPC**

Use the following procedure to disassociate the route server from the VPC.

------
#### [ AWS Management Console ]

****

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. Select the route server for which you want to disassociate.

1. Choose **Association**.

1. Choose **Disassociate route server**.

1. Confirm the changes that will be made and choose **Disassociate route server**.

------
#### [ Command line ]

1. Disassociate route server from the VPC:

   ```
   aws ec2 disassociate-route-server --route-server-id rs-1 --vpc-id vpc-1
   ```

1. Confirm the disassociation:

   ```
   aws ec2 get-route-server-associations --route-server-id rs-1
   ```

------

**7.6 Delete route server**

Use the following procedure to delete the route server.

------
#### [ AWS Management Console ]

****

1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).

1. Select the route server to delete.

1. Choose **Actions** > **Delete route server**.

1. Enter *delete* and choose **Delete**.

------
#### [ Command line ]

1. Delete route server:

   ```
   aws ec2 delete-route-server --route-server-id rs-1
   ```

1. Confirm the deletion:

   ```
   aws ec2 describe-route-servers [--route-server-ids rs-1] [--filters Key=VpcId]
   ```

------

The Amazon VPC Route Server tutorial is complete.

# Troubleshoot reachability issues in your VPC
<a name="route-table-routes-troubleshoot"></a>

Reachability Analyzer is a static configuration analysis tool. Use Reachability Analyzer to analyze and debug network reachability between two resources in your VPC. Reachability Analyzer produces hop-by-hop details of the virtual path between these resources when they are reachable, and identifies the blocking component otherwise. For example, it can identify missing or misconfigured route table routes.

For more information, see the [Reachability Analyzer Guide](https://docs.aws.amazon.com/vpc/latest/reachability/).

# Middlebox routing wizard
<a name="middlebox-routing-console"></a>

If you want to configure fine-grain control over the routing path of traffic entering or leaving your VPC, for example, by redirecting traffic to a security appliance, you can use the middlebox routing wizard in the VPC console. The middlebox routing wizard helps you by automatically creating the necessary route tables and routes (hops) to redirect traffic as needed.

The middlebox routing wizard can help you configure routing for the following scenarios:
+ Routing traffic to a middlebox appliance, for example, an Amazon EC2 instance that's configured as a security appliance.
+ Routing traffic to a Gateway Load Balancer. For more information, see the [User Guide for Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/).

For more information, see [Middlebox scenarios](middlebox-routing-examples.md).

**Topics**
+ [

## Middlebox routing wizard prerequisites
](#routing-console-rules)
+ [

# Redirect VPC traffic to a security appliance
](working-with-routing-console.md)
+ [

## Middlebox routing wizard considerations
](#console-routes-considerations)
+ [

# Middlebox scenarios
](middlebox-routing-examples.md)

## Middlebox routing wizard prerequisites
<a name="routing-console-rules"></a>

Review [Middlebox routing wizard considerations](#console-routes-considerations). Then, make sure that you have the following information before you use the middlebox routing wizard.
+ The VPC.
+ The resource where traffic originates from or enters the VPC, for example, an internet gateway, virtual private gateway, or network interface.
+ The middlebox network interface or Gateway Load Balancer endpoint.
+ The destination subnet for the traffic.

# Redirect VPC traffic to a security appliance
<a name="working-with-routing-console"></a>

The middlebox routing wizard is available in the Amazon VPC console.

**Topics**
+ [

## 1. Create routes using the middlebox routing wizard
](#creating-routing-console)
+ [

## 2. Modify middlebox routes
](#modify-route)
+ [

## 3. Delete the middlebox routing wizard configuration
](#deleting-routing-console)

## 1. Create routes using the middlebox routing wizard
<a name="creating-routing-console"></a>

**To create routes using the middlebox routing wizard**

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 **Your VPCs**.

1. Select your VPC, and then choose **Actions**, **Manage middlebox routes**.

1. Choose **Create routes**.

1. On the **Specify routes** page, do the following:
   + For **Source**, choose the source for your traffic. If you choose a virtual private gateway, for **Destination IPv4 CIDR**, enter the CIDR for the on-premises traffic entering the VPC from the virtual private gateway.
   + For **Middlebox**, choose the network interface ID that is associated with your middlebox appliance, or when you use a Gateway Load Balancer endpoint, choose the VPC endpoint ID.
   + For **Destination subnet**, choose the destination subnet.

1. (Optional) To add another destination subnet, choose **Add additional subnet**, and then do the following:
   + For **Middlebox**, choose the network interface ID that is associated with your middlebox appliance, or when you use a Gateway Load Balancer endpoint, choose the VPC endpoint ID.

     You must use the same middlebox appliance for multiple subnets.
   + For **Destination subnet**, choose the destination subnet.

1. (Optional) To add another source, choose **Add source**, and then repeat the previous steps.

1. Choose **Next**.

1. On the **Review and create** page, verify the routes and then choose **Create routes**.

## 2. Modify middlebox routes
<a name="modify-route"></a>

You can edit your route configuration by changing the gateway, the middlebox, or the destination subnet.

When you make any modifications, the middlebox routing wizard automatically perform the following operations:
+ Creates new route tables for the gateway, middlebox, and destination subnet.
+ Adds the necessary routes to the new route tables.
+ Disassociates the current route tables that the middlebox routing wizard associated with the resources.
+ Associates the new route tables that the middlebox routing wizard creates with the resources.

**To modify middlebox routes using the middlebox routing wizard**

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 **Your VPCs**.

1. Select your VPC, and then choose **Actions**, **Manage middlebox routes**.

1. Choose **Edit routes**.

1. To change the gateway, for **Source**, choose the gateway through which traffic enters your VPC. If you choose a virtual private gateway, for **Destination IPv4 CIDR**, enter the destination subnet CIDR.

1. To add another destination subnet, choose **Add additional subnet**, and then do the following:
   + For **Middlebox**, choose the network interface ID that is associated with your middlebox appliance, or when you use a Gateway Load Balancer endpoint, choose the VPC endpoint ID.

     You must use the same middlebox appliance for multiple subnets.
   + For **Destination subnet**, choose the destination subnet.

1. Choose **Next**.

1. On the **Review and update** page, a list of route tables and their routes that will be created by the middlebox routing wizard is displayed. Verify the routes, and then in the confirmation dialog box, choose **Update routes**.

## 3. Delete the middlebox routing wizard configuration
<a name="deleting-routing-console"></a>

If you decide that you no longer want the middlebox routing wizard configuration, you must manually delete the route tables.

**To delete the middlebox routing wizard configuration**

1. View the middlebox routing wizard route tables.

   After you perform the operation, the route tables that the middlebox routing wizard created are displayed on a separate route table page. 

1. Delete each route table that is displayed.

## Middlebox routing wizard considerations
<a name="console-routes-considerations"></a>

Take the following into consideration when you use the middlebox routing wizard:
+ If you want to inspect traffic, you can use an internet gateway or a virtual private gateway for the source.
+ If you use the same middlebox in a multiple middlebox configuration within the same VPC, make sure that the middlebox is in the same hop position for both subnets.
+ The appliance must be configured in a separate subnet from the source or destination subnet. 
+ You must disable source/destination checking on the appliance. For more information, see [Changing the Source or Destination Checking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#change_source_dest_check) in the *Amazon EC2 User Guide*.
+ The route tables and routes that the middlebox routing wizard creates count toward your quotas. For more information, see [Route tables](amazon-vpc-limits.md#vpc-limits-route-tables).
+ If you delete a resource, for example a network interface, the route table associations with the resource are removed. If the resource is a target, the route destination is set to blackhole. The route tables are not deleted.
+ The middlebox subnet and the destination subnet must be associated with a non-default route table.
**Note**  
We recommend that you use the middlebox routing wizard to modify or delete any route tables that you created using the middlebox routing wizard.
+ If you use middlebox routing to route through a security appliance, [security group referencing](security-group-rules.md#security-group-referencing) between the source and ultimate destination after inspection is not supported.

# Middlebox scenarios
<a name="middlebox-routing-examples"></a>

Amazon Virtual Private Cloud (VPC) provides a wide range of networking capabilities that allow you to customize and control the routing of traffic within your virtual network. One such feature is the middlebox routing wizard, which enables fine-grained control over the routing path of traffic entering or leaving your VPC.

If you need to redirect traffic to a security appliance, load balancer, or other network device for inspection, monitoring, or optimization purposes, the middlebox routing wizard can simplify the process. This wizard automatically creates the necessary route tables and routes (hops) to redirect the specified traffic as needed, eliminating the manual effort required to set up complex routing configurations.

The middlebox routing wizard supports several different scenarios. For example, you can use it to inspect traffic destined for a particular subnet, configure middlebox traffic routing and inspection across your entire VPC, or selectively inspect traffic between specific subnets. This granular control over traffic routing allows you to implement advanced security policies, enable centralized network monitoring, or optimize the performance of your cloud-based applications.

The following examples describe scenarios for the middlebox routing wizard.

**Topics**
+ [

# Inspect traffic destined for a subnet
](internet-gateway-subnet.md)
+ [

# Configure middlebox traffic routing and inspection in a VPC
](gwlb-route.md)
+ [

# Inspect traffic between subnets
](intra-vpc-route.md)

# Inspect traffic destined for a subnet
<a name="internet-gateway-subnet"></a>

Consider the scenario where you have traffic coming into the VPC through an internet gateway and you want to inspect all traffic that is destined for a subnet, say subnet B, using a firewall appliance installed on an EC2 instance. The firewall appliance should be installed and configured on an EC2 instance in a separate subnet from subnet B in your VPC, say subnet C. You can then use the middlebox routing wizard to configure routes for traffic between subnet B and the internet gateway.

 The middlebox routing wizard, automatically performs the following operations:
+ Creates the following route tables:
  + A route table for the internet gateway
  + A route table for the destination subnet 
  + A route table for the middlebox subnet
+ Adds the necessary routes to the new route tables as described in the following sections.
+ Disassociates the current route tables associated with the internet gateway, subnet B, and subnet C.
+ Associates route table A with the internet gateway (the **Source** in the middlebox routing wizard), route table C with subnet C (the **Middlebox** in the middlebox routing wizard), and route table B with subnet B (the **Destination** in the middlebox routing wizard).
+ Creates a tag that indicates it was created by the middlebox routing wizard, and a tag that indicates the creation date.

The middlebox routing wizard does not modify your existing route tables. It creates new route tables, and then associates them with your gateway and subnet resources. If your resources are already explicitly associated with existing route tables, the existing route tables are first disassociated, and then the new route tables are associated with your resources. Your existing route tables are not deleted.

If you do not use the middlebox routing wizard, you must manually configure, and then assign the route tables to the subnets and internet gateway.

![\[Inbound routing to a VPC\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/ingress-routing-firewall-ipv6.png)


## Internet gateway route table
<a name="internet-gateway-igw-route-table"></a>

Add the following routes to the route table for the internet gateway.


| Destination | Target | Purpose | 
| --- | --- | --- | 
| 10.0.0.0/16 | Local | Local route for IPv4 | 
| 10.0.1.0/24 | appliance-eni | Route IPv4 traffic destined for subnet B to the middlebox | 
| 2001:db8:1234:1a00::/56 | Local | Local route for IPv6 | 
| 2001:db8:1234:1a00::/64 | appliance-eni | Route IPv6 traffic destined for subnet B to the middlebox | 

There is an edge association between the internet gateway and the VPC.

When you use the middlebox routing wizard, it associates the following tags with the route table:
+ The key is "Origin" and the value is "Middlebox wizard"
+ The key is "date\$1created" and the value is the creation time (for example, "2021-02-18T22:25:49.137Z")

## Destination subnet route table
<a name="internet-gateway-subnet-route-table"></a>

Add the following routes to the route table for the destination subnet (subnet B in the example diagram).


| Destination | Target | Purpose | 
| --- | --- | --- | 
| 10.0.0.0/16 | Local | Local route for IPv4 | 
| 0.0.0.0/0 | appliance-eni | Route IPv4 traffic destined for the internet to the middlebox | 
| 2001:db8:1234:1a00::/56 | Local | Local route for IPv6 | 
| ::/0 | appliance-eni | Route IPv6 traffic destined for the internet to the middlebox | 

There is a subnet association with the middlebox subnet.

When you use the middlebox routing wizard, it associates the following tags with the route table:
+ The key is "Origin" and the value is "Middlebox wizard"
+ The key is "date\$1created" and the value is the creation time (for example, "2021-02-18T22:25:49.137Z")

## Middlebox subnet route table
<a name="internet-gateway-middlebox-subnet-route-table"></a>

Add the following routes to the route table for the middlebox subnet (subnet C in the example diagram).


| Destination | Target | Purpose | 
| --- | --- | --- | 
| 10.0.0.0/16 | Local | Local route for IPv4 | 
| 0.0.0.0/0 | igw-id | Route IPv4 traffic to the internet gateway | 
| 2001:db8:1234:1a00::/56 | Local | Local route for IPv6 | 
| ::/0 | eigw-id | Route IPv6 traffic to the egress-only internet gateway | 

There is a subnet association with the destination subnet.

When you use the middlebox routing wizard, it associates the following tags with the route table:
+ The key is "Origin" and the value is "Middlebox wizard"
+ The key is "date\$1created" and the value is the creation time (for example, "2021-02-18T22:25:49.137Z")

# Configure middlebox traffic routing and inspection in a VPC
<a name="gwlb-route"></a>

Consider the scenario where you need to inspect the traffic entering a VPC from the internet gateway and destined for a subnet, using a fleet of security appliances configured behind a Gateway Load Balancer. The owner of the service consumer VPC creates a Gateway Load Balancer endpoint in a subnet in their VPC (represented by an endpoint network interface). All traffic entering the VPC through the internet gateway is first routed to the Gateway Load Balancer endpoint for inspection before it's routed to the application subnet. Similarly, all traffic leaving the application subnet is first routed to Gateway Load Balancer endpoint for inspection before it is routed to the internet.

The middlebox routing wizard automatically performs the following operations:
+ Creates the route tables.
+ Adds the necessary routes to the new route tables.
+ Disassociates the current route tables associated with the subnets.
+ Associates the route tables that the middlebox routing wizard creates with the subnets.
+ Creates a tag that indicates it was created by the middlebox routing wizard, and a tag that indicates the creation date.

The middlebox routing wizard does not modify your existing route tables. It creates new route tables, and then associates them with your gateway and subnet resources. If your resources are already explicitly associated with existing route tables, the existing route tables are first disassociated, and then the new route tables are associated with your resources. Your existing route tables are not deleted.

If you do not use the middlebox routing wizard, you must manually configure, and then assign the route tables to the subnets and internet gateway.

![\[Using a Gateway Load Balancer endpoint to access an endpoint service\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/vpc-endpoint-service-gwlbe.png)


## Internet gateway route table
<a name="igw-route-table-table"></a>

The route table for the internet gateway has the following routes.


| Destination | Target | Purpose | 
| --- | --- | --- | 
| Consumer VPC CIDR | Local | Local route | 
| Application subnet CIDR | endpoint-id | Routes traffic destined for the application subnet to the Gateway Load Balancer endpoint | 

There is an edge association with the gateway.

When you use the middlebox routing wizard, it associates the following tags with the route table:
+ The key is "Origin" and the value is "Middlebox wizard"
+ The key is "date\$1created" and the value is the creation time (for example, "2021-02-18T22:25:49.137Z")

## Application subnet route table
<a name="subnet1-route-table-table"></a>

The route table for the application subnet has the following routes.


| Destination | Target | Purpose | 
| --- | --- | --- | 
| Consumer VPC CIDR | Local | Local route | 
| 0.0.0.0/0 | endpoint-id | Route traffic from the application servers to the Gateway Load Balancer endpoint before it is routed to the internet | 

When you use the middlebox routing wizard, it associates the following tags with the route table:
+ The key is "Origin" and the value is "Middlebox wizard"
+ The key is "date\$1created" and the value is the creation time (for example, "2021-02-18T22:25:49.137Z")

## Provider subnet route table
<a name="subnet2-route-table"></a>

The route table for the provider subnet has the following routes.


| Destination | Target | Purpose | 
| --- | --- | --- | 
| Provider VPC CIDR | Local | Local route. Ensures that traffic originating from the internet is routed to the application servers | 
| 0.0.0.0/0 | igw-id | Routes all traffic to the internet gateway | 

When you use the middlebox routing wizard, it associates the following tags with the route table:
+ The key is "Origin" and the value is "Middlebox wizard"
+ The key is "date\$1created" and the value is the creation time (for example, "2021-02-18T22:25:49.137Z")

# Inspect traffic between subnets
<a name="intra-vpc-route"></a>

Consider the scenario where you have multiple subnets in a VPC and you want to inspect the traffic between them using a firewall appliance. Configure and install the firewall appliance on an EC2 instance in a separate subnet in your VPC.

The following diagram shows a firewall appliance installed on an EC2 instance in subnet C. The appliance inspects all traffic that travels from subnet A to subnet B (see 1) and from subnet B to subnet A (see 2).

![\[Inspect subnet traffic\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/middlebox-intra-vpc_updated.png)


You use the main route table for the VPC and the middlebox subnet. Subnets A and B each have a custom route table.

The middlebox routing wizard, automatically performs the following operations:
+ Creates the route tables.
+ Adds the necessary routes to the new route tables.
+ Disassociates the current route tables associated with the subnets.
+ Associates the route tables that the middlebox routing wizard creates with the subnets.
+ Creates a tag that indicates it was created by the middlebox routing wizard, and a tag that indicates the creation date.

The middlebox routing wizard does not modify your existing route tables. It creates new route tables, and then associates them with your gateway and subnet resources. If your resources are already explicitly associated with existing route tables, the existing route tables are first disassociated, and then the new route tables are associated with your resources. Your existing route tables are not deleted.

If you do not use the middlebox routing wizard, you must manually configure, and then assign the route tables to the subnets and internet gateway.

## Custom route table for subnet A
<a name="subneta-route-table-table"></a>

The route table for subnet A has the following routes.


| Destination | Target | Purpose | 
| --- | --- | --- | 
| VPC CIDR | Local | Local route | 
| Subnet B CIDR | appliance-eni | Route traffic destined for subnet B to the middlebox | 

When you use the middlebox routing wizard, it associates the following tags with the route table:
+ The key is "Origin" and the value is "Middlebox wizard"
+ The key is "date\$1created" and the value is the creation time (for example, "2021-02-18T22:25:49.137Z")

## Custom route table for subnet B
<a name="subnetb-route-table-table"></a>

The route table for subnet B has the following routes.


| Destination | Target | Purpose | 
| --- | --- | --- | 
| VPC CIDR | Local | Local route | 
| Subnet A CIDR | appliance-eni | Route traffic destined for subnet A to the middlebox | 

When you use the middlebox routing wizard, it associates the following tags with the route table:
+ The key is "Origin" and the value is "Middlebox wizard"
+ The key is "date\$1created" and the value is the creation time (for example, "2021-02-18T22:25:49.137Z")

## Main route table
<a name="example-main-route-table"></a>

Subnet C uses the main route table. The main route table has the following route.


| Destination | Target | Purpose | 
| --- | --- | --- | 
| VPC CIDR | Local | Local route | 

When you use the middlebox routing wizard, it associates the following tags with the route table:
+ The key is "Origin" and the value is "Middlebox wizard"
+ The key is "date\$1created" and the value is the creation time (for example, "2021-02-18T22:25:49.137Z")

# Delete a subnet
<a name="subnet-deleting"></a>

If you no longer need a subnet, you can delete it. You cannot delete a subnet if it contains any network interfaces. For example, you must terminate any instances in a subnet before you can delete it.

When you delete a subnet, the CIDR block associated with that subnet is returned to the VPC's available IP address pool. This means that the IP addresses within the subnet's CIDR range can be reallocated to other subnets or resources within the same VPC.

It's important to note that deleting a subnet does not automatically delete the resources within it. You must first terminate any EC2 instances, delete any network interfaces, and remove any other resources associated with the subnet before you can proceed with the subnet deletion.

**To delete a subnet using the console**

1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Terminate all instances in the subnet. For more information, see [Terminate your instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) in the *Amazon EC2 User Guide*.

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

1. Select the subnet and choose **Actions**, **Delete subnet**.

1. When prompted for confirmation, type **delete** and then choose **Delete**.

**To delete a subnet using the AWS CLI**  
Use the [delete-subnet](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-subnet.html) command.