VPC segmentation is often reduced to \u201cpublic subnet versus private subnet.\u201d Real AWS network architecture is more precise. Each subnet is associated with a route table, security groups control stateful traffic at interfaces, network ACLs can add subnet-level stateless controls, gateways determine reachability beyond the VPC, and centralized inspection or hybrid connectivity can introduce additional routing domains. Segmentation emerges from how these controls combine.<\/p>\n
Amazon VPC route tables direct traffic by destination and target, and AWS supports patterns that range from isolated subnets to internet-facing, NAT-routed, hybrid, and shared-network designs. Understanding those paths is fundamental to AWS<\/a> architecture and to diagnosing failures that look like security problems but are really routing decisions.<\/p>\n Every subnet uses a route table, either through an explicit association or through the VPC main route table. A useful operating pattern is to keep the main route table conservative and explicitly associate application subnets with custom route tables that match their intended role. That makes accidental internet or hybrid reachability less likely when new subnets are created.<\/p>\n A public subnet is public because its route table provides a path to an internet gateway and the workload has appropriate addressing and security controls. A private subnet may send outbound traffic through a NAT gateway while having no direct inbound internet route. An isolated subnet can omit both. The AWS VPC design<\/a> basics are useful, but production review should trace the actual route for each traffic class.<\/p>\n Segmentation should correspond to application trust. Web tiers, application tiers, databases, management systems, shared services, and inspection components may need different routes even when security groups are also present. Separate route tables make those differences visible and constrain which gateways or attachments each subnet can use.<\/p>\n Do not create separate subnets solely for appearance. A boundary is valuable when it changes exposure, routing, availability-zone placement, address management, or operational ownership. Conversely, if a database subnet inherits the same default route as an application subnet, the diagram may imply separation that the network path does not actually enforce.<\/p>\n Route tables answer where traffic can go; security groups answer whether traffic to or from an attached resource is permitted. A missing route cannot be repaired by opening a security group, and a correct route does not guarantee that a security group allows the flow. This distinction is essential in troubleshooting.<\/p>\n Network ACLs add a stateless subnet boundary and can be useful in specific control models, but they also increase operational complexity because return traffic must be allowed explicitly. Use them for a clear requirement rather than duplicating every security-group rule at another layer. The strongest segmentation has understandable ownership for each control.<\/p>\n Internet-facing architecture receives substantial attention, but outbound paths can leak data or create hidden dependencies. Private subnets that use NAT gateways have internet egress even though they are not directly reachable from the internet. VPC endpoints can keep supported service traffic on AWS networking and may allow additional endpoint-policy constraints.<\/p>\n Decide which workloads need general internet access, which need only specific AWS services, and which should remain isolated. Centralized egress inspection can improve policy consistency but also introduces cost, latency, route complexity, and dependency on shared infrastructure. Egress architecture should be part of the workload threat model, not an afterthought.<\/p>\n Egress resilience matters too. A single NAT gateway used by private subnets in several Availability Zones can introduce cross-AZ data paths and a zonal dependency. Regional designs commonly place NAT capacity per Availability Zone and route local private subnets to the local gateway where the availability requirement and cost model justify it. The same principle applies to inspection: avoid creating an unnecessary zonal choke point.<\/p>\n For AWS service access, gateway and interface endpoints can change both route behavior and security policy. Verify private DNS, endpoint policies, security groups for interface endpoints, and application behavior during endpoint failure. \u201cPrivate\u201d does not mean \u201cautomatically allowed\u201d; it means the network path stays within the designed AWS connectivity boundary.<\/p>\n Centralized firewalls and virtual appliances can fail when forward and return traffic take different paths. AWS networking features such as Gateway Load Balancer and AWS Network Firewall have specific routing patterns, and Transit Gateway appliance mode can be relevant where stateful inspection needs consistent Availability Zone handling.<\/p>\n Build route tables from the packet path backward and forward. Identify ingress point, inspection hop, destination, return hop, and egress. Then test failure and scaling behavior. An architecture that works only because one route currently wins by coincidence can break when a new prefix, attachment, or failover path is added.<\/p>\n VPC peering can be appropriate for direct connectivity between a limited number of VPCs, but it does not provide transitive routing. Transit Gateway is designed for hub-style connectivity across many VPC and hybrid attachments and introduces its own route tables and segmentation model. PrivateLink can expose specific services without creating general network reachability.<\/p>\n The cloud networking<\/a> decision is therefore not simply \u201cconnect the networks.\u201d Ask how many routing domains are needed, who owns route propagation, whether transitive connectivity is desirable, and whether the requirement is service access or full network access.<\/p>\n Shared VPC patterns and cross-account subnet use can separate network ownership from workload ownership. That can improve consistency for large organizations, but it also changes who can modify routes, security controls, and address space. Define the interface between the network platform team and workload teams so cross-account sharing does not create ambiguous responsibility during an outage.<\/p>\n VPN and Direct Connect paths introduce on-premises routing, BGP, route propagation, overlapping-address risk, and dependencies outside the VPC. A route can be correct in AWS and still fail because the on-premises network does not advertise a return path. Conversely, a broad advertisement can make an AWS VPC reachable from locations that were not part of the original trust design.<\/p>\n Maintain an authoritative IP allocation plan and avoid overlapping CIDRs where possible. Document which prefixes are advertised in each direction and which component owns failover. Candidates studying ANS-C01<\/a> should note that the exam remains available in 2026 but is scheduled to retire on December 31, 2026; the underlying routing concepts remain important beyond that date.<\/p>\n Applications often appear to have a routing failure when the real problem is name resolution. Private hosted zones, Route 53 Resolver endpoints, hybrid DNS forwarding, split-horizon records, and service-specific private DNS can determine which network path an application attempts to use.<\/p>\n Document the expected answer for important names from each network context. If a private endpoint is introduced but DNS still returns a public address, traffic may bypass the intended path. If a failover changes network reachability but caches preserve an old answer, recovery can appear inconsistent. Network architecture is incomplete without the name-resolution model that selects endpoints.<\/p>\n Central DNS forwarding can itself become a shared-service dependency. Resolver endpoints need Availability Zone placement, capacity, security-group rules, and monitoring. Conditional forwarding rules should be specific enough to avoid sending unrelated names toward on-premises resolvers, and inbound paths should not create a broad route from corporate DNS infrastructure into every private namespace.<\/p>\n Private hosted-zone associations also need lifecycle control. When VPCs are created, shared, or retired, stale associations can expose names to the wrong environment or leave applications unable to resolve expected private endpoints. Treat DNS association changes with the same review as network attachments because name resolution determines which endpoint the application will attempt to reach.<\/p>\n Start with source address and subnet route table, then evaluate the selected target, target availability, intermediate route domains, destination security controls, and the return path. Use VPC Flow Logs and service-specific telemetry to confirm where traffic stops rather than changing several controls simultaneously.<\/p>\n Route priority matters. Longest-prefix matches, propagated routes, static routes, prefix lists, and gateway-specific behavior can produce a path that differs from what an operator expects from a diagram. Change one assumption at a time and record the observed path. This discipline prevents the common response of opening security groups broadly when the route is actually wrong.<\/p>\n Use Reachability Analyzer where its supported model fits the problem, but treat tools as evidence rather than substitutes for understanding. If a tool reports a blocked path, identify the exact routing or security component responsible. If the tool cannot model a managed appliance or external hop, continue the trace with flow logs and component telemetry.<\/p>\n Keep route changes small during incidents. Adding broad 0.0.0.0\/0 routes or opening security groups can make symptoms disappear while creating a new exposure and obscuring the original fault. Prefer the narrowest change that tests one hypothesis, capture the before-and-after route state, and roll back diagnostic changes when the root cause is understood.<\/p>\n A production VPC should make it easy to answer: which subnets can reach the internet, which can reach on-premises networks, where inspection occurs, which services are private, which shared networks are reachable, and what must change during failover. The AWS, Azure, and Google Cloud networking models<\/a> can help separate universal network principles from AWS-specific implementation choices.<\/p>\nMake subnet intent explicit in the route table<\/h2>\n
Use routing boundaries to reinforce workload boundaries<\/h2>\n
Distinguish security-group policy from route availability<\/h2>\n
Design egress as carefully as ingress<\/h2>\n
Keep inspection paths symmetric when appliances require it<\/h2>\n
Choose connectivity patterns based on route ownership and scale<\/h2>\n
Treat hybrid routing as a separate failure domain<\/h2>\n
Integrate DNS with the network boundary<\/h2>\n
Troubleshoot routes in the same order the packet experiences them<\/h2>\n