A VPC diagram can look correct and still encode years of future friction. The lines between subnets may be neat, the route tables may have the expected default routes, and every workload may launch successfully on day one. The problems arrive later, when a new Availability Zone is added, an acquisition introduces overlapping address space, a shared NAT path becomes a failure dependency, or a team discovers that the “private” subnet is only private because of assumptions nobody documented.
For the SAA-C03 exam, VPC design sits at the intersection of secure, resilient, high-performing, and cost-aware architecture. In production, those dimensions are inseparable. Address ranges affect connectivity options. Route-table structure affects blast radius. Availability Zone choices affect both resilience and cross-zone traffic. The design task is therefore not to memorize which gateway belongs on which diagram; it is to understand what each boundary commits the system to.
A useful review starts with four questions: what traffic must flow, what traffic must never flow, which failures should remain local, and who will own changes after the architecture grows. Those questions reveal whether a subnet is a meaningful failure or trust boundary, whether a route table expresses intentional policy, and whether the VPC can absorb growth without disruptive renumbering.
Address space is an architectural commitment
The VPC CIDR is one of the earliest choices and one of the easiest to underestimate. A block that feels generous for a single application can become restrictive once teams add container nodes, load balancers, interface endpoints, managed services, or additional environments. Subnet planning matters because AWS subnets are tied to Availability Zones, and every subnet consumes part of the VPC address space even when most addresses are unused.
Good planning leaves room for both horizontal growth and structural change. That means avoiding a design where every usable range is allocated immediately, keeping subnet sizes consistent where operations benefit from predictability, and checking the enterprise-wide IP plan before treating a VPC as an isolated island. The mechanics of CIDR subnetting matter because an address plan becomes a connectivity constraint as soon as VPC peering, Transit Gateway, VPN, Direct Connect, or a merger enters the picture.
A subnet should represent more than a label
Teams often name subnets “public,” “private,” “database,” or “application” and assume the label creates the boundary. It does not. A subnet is a range of addresses in one Availability Zone, associated with a route table and a network ACL. Whether resources are internet-reachable depends on routing, addressing, gateways, security controls, and the resource itself.
That distinction is why multiple subnets should exist for a reason. Separate subnets can isolate routing behavior, spread workloads across failure domains, create different egress paths, or support distinct operational ownership. Creating many subnets simply because a reference diagram shows three tiers adds complexity without necessarily adding security. A useful subnet is one whose routing, availability, or administrative behavior differs intentionally from its neighbors.
Route tables express reachability, not trust
Every subnet is associated with a route table. That table decides where matching traffic is directed, using the most specific applicable route. A local route enables communication within the VPC address space, while additional routes can target internet gateways, NAT gateways, virtual private gateways, Transit Gateway attachments, peering connections, endpoints, or network interfaces depending on the architecture.
The critical distinction is that a route says where traffic can go; it does not say the traffic is authorized. Security groups, network ACLs, service policies, IAM, host controls, and application authentication may still block the request. Treating a missing route and a denied flow as the same class of problem leads to dangerous troubleshooting habits, such as widening security rules when the real failure is reachability. A strong operational model separates routing evidence from authorization evidence.
Public and private behavior comes from the whole path
A subnet is commonly called public when its route table can send internet-bound traffic to an internet gateway and the resources that need direct internet communication have appropriate public addressing. A subnet is commonly called private when instances do not have that direct path. Private workloads may still need outbound internet access for updates, package repositories, or external APIs, which is why NAT gateways are often introduced.
NAT changes the dependency graph. If workloads in several Availability Zones all depend on one NAT gateway in one zone, the design has created a cross-zone dependency and may also create unnecessary data-transfer cost. A zonally aligned egress design is often easier to reason about: workloads use an egress path in their own Availability Zone, and a zone failure does not force unrelated zones through the failed component. The broader AWS VPC model is most useful when these routing choices are treated as architecture rather than setup steps.
Availability Zones should be visible in the route design
A resilient application normally spreads compute across multiple Availability Zones, but the routing architecture has to respect that separation. If a critical next hop exists in only one zone, then placing application instances in three zones does not produce three-zone resilience. Central inspection appliances, NAT paths, custom routers, or self-managed proxies can quietly collapse a multi-zone design back into a single failure domain.
Review every nonlocal route target and ask what happens if its zone becomes unavailable. If traffic can fail over, determine how that failover occurs and whether it depends on manual route changes, DNS convergence, automation, or a managed service. If traffic cannot fail over, decide whether the business impact is acceptable. Resilience comes from tracing the entire flow, not from counting subnets on a diagram.
Connectivity growth can turn a clean VPC into a routing problem
Single-VPC designs rarely stay single forever. New accounts, Regions, shared services, hybrid networks, security inspection, and partner connections create new route domains. Overlapping CIDRs can block straightforward peering and complicate migration. Broad propagated routes can send traffic toward unexpected paths. A route that is harmless in one VPC can become ambiguous when Transit Gateway or hybrid connectivity introduces a larger address space.
This is where the full set of AWS networking tools should be evaluated by relationship rather than popularity. Peering is direct and simple but can become difficult to manage at scale. Transit Gateway centralizes connectivity but creates shared routing domains that need deliberate segmentation. Interface and gateway endpoints can keep service traffic off public paths. The right choice depends on the number of networks, trust boundaries, inspection requirements, and operational ownership.
Shared route tables trade convenience for blast radius
Associating many subnets with one custom route table can make a design consistent and easy to manage. It can also turn one route change into a multi-application event. The main route table deserves particular caution because newly created subnets inherit it unless explicitly associated elsewhere. A permissive main table can therefore create accidental reachability when a team forgets the association step.
A practical model is to share route tables only when the subnets truly have the same routing intent. If database subnets, application subnets, inspection subnets, and egress subnets have different next hops or change ownership, separate tables make those differences explicit. Infrastructure as code, tagging, change review, and automated reachability tests can then protect the intended pattern instead of relying on a naming convention.
A design review should follow packets and failures
The most useful VPC review is not a list of resources. Pick representative flows and trace them end to end: client to load balancer, application to database, private workload to an AWS service, workload to the internet, branch office to a private endpoint, and operations traffic to management systems. For each flow, identify the source subnet, route-table decision, next hop, security controls, return path, and observability available when the flow breaks.
Then repeat the exercise under failure. Remove an Availability Zone. Exhaust an address range. Break a NAT path. Introduce an overlapping network. Ask whether operators can determine which route changed and who owns the fix. That method turns subnetting and routing into an architectural discipline rather than a diagram exercise. It is also the networking judgment expected across the AWS Certified Solutions Architect – Associate path: defend why the boundaries, routes, and failure domains exist, and know which assumption would force the design to change.
IPv6 deserves to be included in the address plan rather than bolted on after IPv4 space becomes tight. Dual-stack subnets introduce additional routes and security considerations, and an egress-only internet gateway solves a different problem from an IPv4 NAT gateway. A team that assumes every private-path design will translate directly to IPv6 can create asymmetric or unexpectedly public behavior. The design review should state which protocols each subnet supports and which external paths are intentional.
Route specificity also becomes more important as networks grow. A broad default route may coexist with more specific routes to inspection, hybrid, or service networks. Operators should know which route will win before a change is deployed. When route propagation is used, document which attachments are allowed to introduce destinations and how those propagated routes interact with static entries. Unexpected reachability is often a control-plane problem long before it becomes a packet-filtering problem.
Observability should be part of the VPC plan. Flow Logs can show accepted and rejected traffic at network interfaces, while route and configuration history can explain why a path changed. Reachability-analysis tools can help validate expected paths before an incident. The useful evidence is not simply that a packet was denied, but where the architecture stopped it and whether that stop was intentional. Designing the evidence path early reduces the temptation to make broad emergency changes later.
At larger scale, address and route governance becomes an organizational problem. Central IP address management can reduce accidental overlap, while automated checks can reject routes that expose restricted networks or bypass required inspection. The useful control is not a spreadsheet that records what engineers intended months ago; it is a source of truth that can be compared with deployed VPCs continuously. When new accounts and Regions are created frequently, drift detection becomes part of network reliability.
This also affects change sequencing. Adding a route before the target is ready can black-hole traffic, while removing an old path too early can strand long-lived connections or management access. Network changes should define preconditions, rollback routes, and verification flows. The route table is small, but the blast radius of one entry can span many applications.
