A VPC is not simply a private IP range around cloud resources. It is the routing and trust foundation that determines how workloads reach users, AWS services, other VPCs, on-premises networks, and the internet. The AWS SAA-C03 exam expects candidates to choose subnet, route, gateway, endpoint, and connectivity patterns that match the workload rather than relying on one default network layout.
The core design questions are straightforward: which components need direct inbound access, which need outbound access only, which should have no internet path at all, what services must be reached privately, and how many Availability Zones are required for the availability target?
Once those answers are clear, route tables become an expression of architecture rather than an afterthought.
Start with address space that will not trap the future
Choose a VPC CIDR large enough for expected growth and integration but not so carelessly broad that it creates collisions with corporate networks, acquisitions, or other VPCs. Overlapping CIDRs make VPC peering and many hybrid designs difficult or impossible without additional translation layers.
Subnet planning should preserve room for expansion across Availability Zones. Applications often start with a web tier and database tier, then add load balancers, container platforms, interface endpoints, transit attachments, or managed services that consume addresses.
IPv6 should be considered where it solves a real requirement. Dual-stack design changes routing, security, egress, and application assumptions; it should be deliberate rather than added after address exhaustion becomes urgent.
Public and private are routing properties
A subnet becomes public when its route table provides a path to an internet gateway and the resource has an address and security configuration that can use that path. A private subnet typically lacks a direct route to the internet gateway.
Private resources may still need outbound internet access for package repositories, software updates, or external APIs. A NAT gateway can provide IPv4 egress without making those instances directly reachable from the internet. For IPv6, an egress-only internet gateway can provide outbound-only internet connectivity.
This distinction matters in SAA-C03 scenarios. Assigning a public IP does not by itself make a private-subnet resource reachable if routing is wrong, and placing a database in a private subnet does not remove the need for strong security groups and identity controls.
Route tables are the traffic decision layer
Each subnet is associated with a route table. Routes specify a destination and a target such as an internet gateway, NAT gateway, VPC peering connection, virtual private gateway, transit gateway, or network interface. AWS chooses the most specific matching route.
Custom route tables make trust boundaries clearer. Public subnets can route default internet traffic to an internet gateway, application subnets can route egress through NAT, and isolated data subnets can avoid a default internet route entirely.
The design should make paths obvious. A route table that mixes unrelated destinations and appliance paths may work technically but can be difficult to troubleshoot. Simplicity is valuable because networking failures often emerge during incidents when teams need to reason quickly.
Use VPC endpoints to avoid unnecessary internet or NAT paths
Gateway VPC endpoints provide private connectivity to Amazon S3 and DynamoDB without requiring a NAT device or internet gateway. Interface endpoints, powered by AWS PrivateLink, provide private IP connectivity to many other AWS services and supported endpoint services.
Endpoints can improve security architecture and may reduce NAT processing for eligible traffic. They also introduce endpoint policies, DNS behavior, and per-endpoint cost considerations, so they should be applied where the traffic pattern justifies them.
A common exam pattern is a private workload that needs S3 access. A gateway endpoint is often cleaner than sending S3 traffic through a NAT gateway simply because the application sits in a private subnet.
Choose VPC connectivity according to scale
VPC peering creates direct connectivity between two VPCs, but it is non-transitive. A VPC peered with two others does not automatically route traffic between those peers. Peering can be simple for a small number of relationships but becomes harder to manage as the network grows.
AWS Transit Gateway provides a hub for connecting many VPCs and hybrid networks. Transit gateway route tables can segment connectivity so not every attachment reaches every other attachment. This makes it useful for larger multi-account environments.
For service-provider or producer-consumer patterns, PrivateLink can expose a service privately without opening broad network connectivity between VPCs. The AWS architecture certifications repeatedly tests choosing among these patterns based on topology and trust requirements.
Design security groups around application flows
Security groups are stateful and attach to network interfaces. They should describe the intended application relationship: load balancer to web tier, web tier to application tier, application tier to database, or administration path to controlled management endpoints.
Referencing another security group can be clearer than hard-coding instance IP addresses for resources that scale dynamically. Network ACLs operate at the subnet boundary and are stateless; they are useful for certain broad controls but require matching inbound and outbound rule reasoning.
Neither mechanism replaces route design. A security group can allow traffic that still has no route, and a route can exist while security policy blocks the connection.
High availability begins with multiple Availability Zones
Production designs commonly use equivalent subnet tiers across at least two AZs so load balancers, application capacity, and data services can survive an AZ-level impairment. A single public subnet plus a single private subnet may be enough for a lab but creates a location dependency in production.
NAT gateway design also affects resilience and cost. Using a NAT gateway per AZ can avoid cross-AZ dependency and traffic paths for private subnets in that AZ, while a single centralized NAT gateway can reduce fixed cost but creates a larger failure and cross-AZ consideration.
The correct choice follows the workload’s availability and cost objectives. SAA-C03 rewards recognizing those tradeoffs rather than memorizing one topology as universally correct.
Hybrid connectivity changes route design
AWS Site-to-Site VPN can provide encrypted connectivity over the internet. AWS Direct Connect provides dedicated connectivity and is often used for more consistent hybrid network requirements. Many production designs combine Direct Connect with VPN for resilience or encryption requirements.
Hybrid routing must account for prefixes advertised from on-premises networks, routes propagated into VPC or transit route tables, and return paths. Asymmetric routing through stateful inspection can cause difficult failures.
DNS should be part of the hybrid plan. Applications rarely communicate by IP alone, so name resolution across AWS and on-premises environments can become as important as the network path itself.
Optimize the architecture by tracing real flows
A useful SAA-C03 technique is to trace one request end to end. Where does internet traffic enter? Which route and security group permit it? Which private service does the application call? Does that call use NAT or a VPC endpoint? How does the database reply? What happens if one AZ disappears?
This flow-based reasoning also exposes hidden cost. NAT processing, cross-AZ traffic, and unnecessary centralized paths can add expense. The cloud architecture certification layer is strongest when availability, security, routing, and cost are evaluated together.
For SAA-C03, design the VPC from communication requirements first. CIDRs, subnets, route tables, endpoints, gateways, and security controls then become implementation details of a coherent network model.
Central inspection changes the routing problem
Some environments require traffic to pass through centralized firewalls or inspection appliances before reaching the internet, another VPC, or on-premises networks. In those designs, route tables must deliberately steer traffic through the inspection path and preserve symmetric return routing for stateful devices.
AWS Gateway Load Balancer can integrate supported virtual appliances into scalable inspection architectures, while Transit Gateway can provide the routing hub around them. The design is more complex than direct VPC egress, so it should be reserved for requirements that justify centralized control.
In exam scenarios, watch for language about shared security appliances, centralized egress, or many VPCs requiring the same inspection policy. That language often points away from independent NAT gateways and toward a hub-and-spoke network model.
Troubleshoot by separating route, security, DNS, and application layers
When connectivity fails, verify the path in order. Confirm DNS resolves to the expected endpoint, the source subnet has the required route, the destination has a return route, security groups allow the flow, and network ACLs allow both directions. Only after those layers are correct should the application protocol become the main suspect.
This method prevents random configuration changes. It also reflects how SAA-C03 questions are written: several answer choices may alter networking, but only one addresses the layer that is actually broken.
VPC Flow Logs can support troubleshooting and security analysis by recording metadata about accepted and rejected network traffic at supported interfaces, subnets, or VPCs. They do not capture packet payloads, so they complement rather than replace application logs or packet-level diagnostics.
Reachability Analyzer can also help reason about configured network paths without sending packets. These tools are valuable because a complicated VPC often fails through the interaction of several correct-looking settings rather than one obviously broken control.
Route design should also consider future service insertion. Leaving clear subnet tiers and avoiding unnecessary overlap makes it easier to add inspection, transit, or private endpoints later without renumbering the workload.