AWS Certified Advanced Networking Series: VPC Pt9 (VPC networking components)

Danesh Raj
11 min readFeb 1, 2021

Elastic network interfaces

It is a virtual network interface that includes the following attributes:

• a primary private IPv4 address
• one or more secondary private IPv4 addresses
• one Elastic IP address per private IPv4 address
• one public IPv4 address, which can be auto-assigned to the network interface for eth0 when you launch an instance
• one or more IPv6 addresses
• one or more security groups
• a MAC address
• a source/destination check flag
• a description

· Network interface can be created, attached, detached and reattached to instances. Attributes of the network interface follows the network interface.

· Each instance has a default network interface (the primary network interface) that is assigned a private IPv4 address from the IPv4 address range of the VPC. Primary network interface cannot be detached from an instance. The number of network interfaces can be attached varies by instance type.

Route tables

It contains a set of rules, called routes, that are used to determine where network traffic from the subnet or gateway is directed.

Route table concepts

Main route table — The route table that automatically comes with the 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 is created for the VPC.

Edge association — A route table that is used to route inbound VPC traffic to an appliance. It is associated with a route table with the internet gateway or virtual private gateway, and specify the network interface of the appliance as the target for VPC traffic.
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.
Gateway route table — A route table that’s associated with an internet gateway or virtual private gateway.
Local gateway route table — A route table that’s associated with an Outposts local gateway.

Destination — The range of IP addresses where traffic to go (destination CIDR). For example, an external corporate network with a 172.16.0.0/12 CIDR.
Propagation — Route propagation allows a virtual private gateway to automatically propagate routes to the route tables. This means that it doesn’t need to manually enter VPN routes to the route tables

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.

How route tables work

Each VPC has an implicit router and route tables are used to control network traffic direction. Each subnet will be associated with route table manually or automatically to the main route table. A subnet can only associated with one route table but route table can associate with multiple subnets with the same subnet route table.

It is an option to associate a route table with an internet gateway or a virtual private gateway (gateway route table). This enables to specify routing rules for inbound traffic that enters your VPC through the gateway.

There is a quota on the number of route tables that can be created per VPC. There is also a quota on the number of routes that can be added per route table.

Routes

Each route in a table specifies a destination and a target. For example on the left: to enable the subnet to access the internet through an internet gateway, add the following route to the 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 the VPC.

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. A route with a destination CIDR of ::/0 must be created for all IPv6 addresses.

Every route table contains a local route for communication within the VPC. This route is added by default to all route tables. If the VPC has more than one IPv4 CIDR block, the route tables contain a local route for each IPv4 CIDR block. If its associated with an IPv6 CIDR block with the VPC, the route tables contain a local route for the IPv6 CIDR block. These routes cannot be deleted or modified in a subnet route table or in the main route table.

If the route table has multiple routes, the most specific route that matches the traffic is used (longest prefix match) to determine how to route the traffic.

Example

In the following example, an IPv6 CIDR block is associated with the VPC. In the route table:
• IPv6 traffic destined to remain within the VPC (2001:db8:1234:1a00::/56) is covered by the Local route, and is routed within the VPC.
• IPv4 and IPv6 traffic are treated separately; therefore, all IPv6 traffic (except for traffic within the VPC) is routed to the egress-only internet gateway.
• There is a route for 172.31.0.0/16 IPv4 traffic that points to a peering connection.
• There is a route for all IPv4 traffic (0.0.0.0/0) that points to an internet gateway.
• There is a route for all IPv6 traffic (::/0) that points to an egress-only internet gateway.

Main route table

Its created by default when VPC is created. Main route table controls the routing for all subnets that are not explicitly associated with any other route table. On the Route Tables page in the Amazon VPC console, view the main route table for a VPC by looking for Yes in the Main column.

By default, when creating a nondefault VPC the main route table contains only a local route. When using VPC wizard in the console to create a nondefault VPC with a NAT gateway or virtual private gateway, the wizard automatically adds routes to the main route table for those gateways.

Its allowed to add, remove, and modify routes in the main route table. A more specific route than the local route cannot be created. Main route table cannot be deleted but can be replaced with a custom subnet route table that is created. A gateway route table cannot be set as the main route table.

Associate a subnet explicitly with the main route table, even if it’s already implicitly associated. Do this if main route table is changed. When main route table is changed, it also changes the default for additional new subnets, or for any subnets that are not explicitly associated with any other route table.

Custom route tables

By default, a custom route table is empty and will add routes as needed.

When the VPC wizard in the console to create a VPC with an internet gateway, the wizard creates a custom route table and adds a route to the internet gateway.

One way to protect your VPC is to leave the main route table in its original default state. Then, associate each new subnet that is created with one of the custom route tables that is created. This ensures the control of how each subnet routes traffic. Users can add, remove, and modify routes in a custom route table. Users also can delete a custom route table
only if it has no associations.

Subnet route table association

Each subnet in the 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.

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

A subnet cannot be associated with a route table if any of the following applies:
• The route table contains an existing route that’s more specific than the default local route.
• The target of the default local route has been replaced.

Example 1: Implicit and explicit subnet association

The following diagram.1 shows the routing for a VPC with an internet gateway, a virtual private gateway, a public subnet, and a VPN-only subnet. The main route table has a route to the virtual private gateway. A custom route table is explicitly associated with the public subnet. The custom route table has a route to the internet (0.0.0.0/0) through the internet gateway.

diagram.1

When a new subnet is created in this VPC, it’s automatically implicitly associated with the main route table, which routes traffic to the virtual private gateway. If reverse configuration is setup (where the main route table has the route to the internet gateway, and the custom route table has the route to the virtual private gateway), then a new subnet automatically has a route to the internet gateway.

Example 2: Replacing the main route table

To replace main route table its best to test it route using custom route table to avoid any disruption to the traffic.

The following diagram shows a VPC with two subnets that are implicitly associated with the main route table (Route Table A), and a custom route table (Route Table B) that isn’t associated with any subnets.

create an explicit association between Subnet 2 and Route Table B.

After Route Table B is tested, it can be made as the main route table. Note that Subnet 2 still has an explicit association with Route Table B, and Subnet 1 has an implicit association with Route Table B because it is the new main route table. Route Table A is no longer in use.

If Subnet 2 is disassociated from Route Table B, there’s still an implicit association between Subnet 2 and Route Table B. Route Table A can be deleted if no longer needed.

Gateway route tables

Route table can be associated 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. A gateway route table can be created for fine-grain control over the routing path of traffic entering the VPC. For example, traffic that enters the VPC through an internet gateway can be intercepted by redirecting that traffic to a middlebox appliance (such as a security appliance) in the VPC.

A gateway route table supports routes where the target is local (the default local route) or an elastic network interface (network interface) in the VPC that’s attached to the middlebox appliance. When the target is a network interface, the following destinations are allowed:

• The entire IPv4 or IPv6 CIDR block of the VPC. In this case, replace the target of the default local route.
• The entire IPv4 or IPv6 CIDR block of a subnet in the VPC. This is a more specific route than the default local route.

If changing the target of the local route in a gateway route table to a network interface in the VPC, this can be restored later to the default local target.

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.

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

Rules and considerations

Route table cannot be associate with a gateway if any of the following applies:
• The route table contains existing routes with targets other than a network interface or the default local route.
• The route table contains existing routes to CIDR blocks outside of the ranges in the VPC.
• Route propagation is enabled for the route table.

In addition, the following rules and considerations apply:
• Routes cannot be added to any CIDR blocks outside of the ranges in the VPC, including ranges larger than the individual VPC CIDR blocks. Cannot specify any other types of targets.
• Cannot use a gateway route table to control or intercept traffic outside of the VPC, for example, traffic through an attached transit gateway. Intercept traffic that enters the VPC and redirect it to another target in the same VPC only.
• To ensure that traffic reaches the middlebox appliance, the target network interface must be attached to a running instance. For a traffic that flows through an internet gateway, the target network interface must also have a public IP address.
• When configuring the middlebox appliance, take note of the appliance considerations.
• When traffic is routed through a middlebox appliance, the return traffic from the destination subnet must be routed through the same appliance. Asymmetric routing is not supported.

Route priority

most use specific route in the route table that matches the traffic to determine how to route thetraffic (longest prefix match).

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

For example on the left, the following 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.

By attaching a virtual private gateway to the VPC and enabling route propagation on the subnet route table, routes representing the Site-to-Site VPN connection automatically appear as propagated routes in the route table. If the propagated routes overlap with static routes and longest prefix match cannot be applied, the static routes take priority over the propagated routes.

In this example, the route table has a static route to an internet gateway (which is added manually), and a propagated route to a virtual private gateway. Both routes have a destination of 172.31.0.0/24. In this case, all traffic destined for 172.31.0.0/24 is routed to the internet gateway — it is a static route and therefore takes priority over the propagated route.

The same rule applies if your route table contains a static route to any of the following:
• NAT gateway
• Network interface
• Instance ID
• Gateway VPC endpoint
• Transit gateway
• VPC peering connection
If the destinations for the static and propagated routes are the same, the static route takes priority.

PHEW that is a lot covered on route tables & there is more to be covered. Look forward to it.

--

--

Danesh Raj

I'm a Technology Enthusiast that passionate to help people live better by using Technology