Subnets have Implicit Routing

Subnets should be explicitly associated with a route table to ensure route updates are explicit and controlled.

Details ¶

When creating a subnet in a VPC (Virtual Private Cloud), you have the option to assign a route table. This route table governs the network access for that subnet and directs the traffic originating from that subnet to the various endpoints listed in the route table. Properly configuring these route tables is critical, as the routes determine the traffic behaviour of your resources including whether your subnets can connect to the internet directly using publicly addressable IP addresses, whether they use a NAT (Network Address Translation) gateway or if they have no internet connectivity at all. Additionally, route tables help manage the various privately accessible gateways and services connected to your VPC.

If a VPC does not have an explicitly designated route table for a subnet, it will default to using the default route table for that VPC. Using the default route table reduces your control over implicitly attached subnet’s internet connectivity therefore treating each subnet’s traffic the same. This may not be intentional but as it is an implicit attachment the default route table will take full control of your subnet’s routing.

A best practice in network architecture is to ensure that every component should be designed and explicitly configured. Therefore, explicit route tables are preferred over implicit ones as they safeguard against unintended traffic changes affecting implicitly connected subnets. In this scenario, any changes to the default route table will affect all regions of your network lacking explicitly attached route tables, which can disrupt networking and create substantial connectivity issues that might not be immediately apparent in your infrastructure’s code changes or changelogs.

Remediation ¶

To address these issues, review your network and evaluate the intended functionality of each subnet. This assessment should include clarifying the internet connectivity requirements for each subnet - for example, whether the subnet needs to be privately networked, publicly networked, or configured with a NAT for protected internet access.

For each type of subnet configuration, ensure that there is a dedicated route table. Public route tables are usually straightforward: they should cover the local network’s routing and allow outbound internet traffic through a direct internet gateway. Similarly, NAT subnets should have local networking rules and route all outbound traffic through a single NAT gateway.

It is important to assign individual route tables to each NAT gateway; using multiple NAT gateways within a single route table can complicate your network without providing efficient redundancy benefits. If using a single NAT for your network then only one route table would be needed. However, if the marginal redundancy is required for multiple NAT endpoints then there will need to be a separate route table corresponding to each respective NAT gateway in the same availability zone.

Private route tables should be simple and generally include only the private network routes specific to the VPC.

By clearly defining each route table and associating them explicitly with the appropriate subnets, you can create a more robust and manageable network architecture that is easy to understand and whose maintenance is explicit.