Understanding the AWS VPC Route Table Limitations for More Specific Routes
In AWS, you typically create route tables and associate them with subnets that will consume them.
For these route tables, AWS limits your route entries in a way that you cannot have a route entry which is more specific then the VPC’s CIDR.
For ex, your VPC CIDR is 172.31.0.0/16. If you try to create a route to 172.31.32.0/20 which is more specific then 172.31.0.0/16, it will fail as in the screenshot below.
(Destination) 172.31.10.0/24 --> (Target could be anything, for ex) ENI-ID.
Reason: This route table is used by a subnet, and doesn't support route destination which are more specific than VPC local CIDR.
Exception for Ingress Routes / Edge Association
There is however an exception to this for Route Tables that are NOT associated with any subnet.
Typically, Ingress routing/route tables are NOT associated with a subnet. Instead they should be associated with an IGW so that when traffic is ingress’ing to the VPC via IGW, it knows the next hop to take. This is usually used to redirect incoming traffic to specific appliance like a firewall.
This route table allows you to have a more specific route then the VPC CIDR. Screenshots below walk thru the config:
a. Ingress Route table with default local route
b. As you can see here, no subnet is associated with this route table
c. An IGW is associated with the route table under Edge Association. The associated IGW will use this route table for ingress traffic.
d. You can see that the Route Table is allowed to have a more specific route (172.31.32.0/20) which didnt work when the route table was associated with a subnet.
One of the impact of this limitation is in the Distributed deployment of AWS Network Firewall, where it forces you to NAT the traffic before being sent to Network Firewall. As in AWS Network Firewall, you need to separately spin up a NAT GW and manage route tables, this limitation reduce usability of the firewall.
Aviatrix Egress FQDN Gateways are not impacted by this limitation and can provide filtering without requiring a separate NAT device with full Source IP visibility and control