Subnets should utilise a single exit route for outbound traffic such as an internet gateway or a NAT but not routes to multiple destinations
One key parts of network architecture is to ensure that the network itself is clear with less complexity to reduce maintenance and security burdens. Whilst it is possible to run a complex network the cognitive load is not worth the additional burden as there is unlikely to be any technical functionality gained in the network complexity but an additional burden to knowledge and maintenance in the long term. Simple networks are as functionally capable as complex networks. One aspect of this is ensuring that networks and their subnets have a distinct clear exit routes to the internet whether that surviving internet gateway or a single mat. Having multiple net exit routes causes different traffic patterns that are not immediately clear. For example a subnet with access that takes all traffic to the Exile internet those single net has the known compute that is the external network address for all traffic for that subnet. Having multiple gnats on the root table handling different destination traffic to the internet requires an additional determination as to whether that’s subnet is sending traffic under an external IP address or different external IP address. Our preferred setup is to have subnet split into private subnet Nat subnets and public subnet. Public subnets are technical necessity for resources that need to conjoin to the network but also support public IP address such as network load answer and endpoints. Nat subnet are for resources that should remain in directly inaccessible from outside traffic external to the network but still need to reach out to the network to provide auto-initiate connections such as downloading resources code or other connections to third parties. True private subnets are submits that should only ever talk to the internal vpc network and should have no directory to the internet at all such as databases. By splitting the networks these ways we know that the public subnets should only have access to the internet gateway full stop the natsubness should either have an access route to a single vpc wide net or a availability zone dedicated Nat depending on availability requirements.
Review each route table for your subnets to determine which round tables are pointing to multiple exit points for your vpc and subnets. For those round tables which are pointing to either a internet gateway and now or for multiple now to gateways change the rules such that only one net or internet gateway is available for the Global range I 0.0.0.0/zero. With this configuration the singular net will be your exit point for any Nat subnet and that will give you your public IP address for all traffic originating from the subnet. For internet it gateway subnet I public subnet the elastic IP will not be known however this will ensure that your public subnet are truly public subnet and will not allow Nat base resources in those subnets as any resource in a public subnet will require a public IP address to become functional.
Subnets should utilise a single exit route for outbound traffic, such as an Internet Gateway or a NAT, and not multiple external routes.
A key aspect of good network architecture is to maintain clarity and reduce complexity in order to lower maintenance and security burdens. Although it is possible to run a complex network, the cognitive load often outweighs the benefits, as increased complexity does not typically yield greater technical functionality but adds obstacles to knowledge and long-term maintenance. Simple networks can be just as functionally capable as more complex ones.
One important consideration is ensuring that subnets have a distinct and clear exit route to the internet, whether through an Internet Gateway or a single NAT. Multiple exit routes can lead to complicated traffic patterns that are not immediately obvious. For instance, a subnet that directs all traffic to a single NAT has a single known external IP address for all outgoing traffic. However, having multiple NAT routes in the routing table for different destination traffic can complicate matters, as it requires extra determination regarding which NAT a subnet is sending traffic through based on it’s routing rules.
Our preferred setup is to divide subnets into three categories: private subnets, NAT subnets and public subnets. Public subnets are necessary for resources that need internet connectivity via public IP addresses, such as load balancers VPN services. NAT subnets are for resources that should remain inaccessible to externally initiated connections but host services that still need to initiate connections to the internet for tasks like downloading resources. Private subnets should only communicate within the internal VPC network and should have no direct access to the internet. Private subnets typically host databases and other services that are available to the internal network only.
By organizing networks in this way, we can ensure that public subnets have direct access to an Internet Gateway, while NAT subnets will either route through a single VPC-wide NAT or an availability zone-specific NAT based on availability requirements. This makes the communication management easy as all traffic from a NAT subnet to the internet shows externally as the single IP address for that NAT to all destinations. Additionally, any outbound traffic from public subnets will come from the public IP address assigned to each resource without the utilisation of any network address translation. This provides a very clear origin of traffic originating from your network.
Review each route table for your subnets to identify any that are pointing to multiple exit points for your VPC. For those route tables that connect to both an Internet Gateway and / or multiple NAT gateways, adjust the rules to ensure that only one NAT or Internet Gateway is available for non-local traffic, ie. the global range (0.0.0.0/0). This configuration will designate the singular NAT as your exit point for any NAT subnets - providing a public IP address for all outbound traffic originating from those subnets - and ensure that all public subnet traffic uses the public IP address attached to each resource.
Uncover complex routes, including mixed external paths, with a comprehensive network scan and consultation:
