AWS VPC Concepts You Must Know for the SAA-C03 Exam

Networking is one of the most heavily tested areas on the AWS Solutions Architect Associate (SAA-C03) exam. Virtual Private Cloud (VPC) concepts appear across all four exam domains, from designing secure architectures to building resilient and cost-optimized solutions. A weak understanding of VPC fundamentals is one of the most common reasons candidates struggle with the exam.

This guide covers every VPC concept you need to master for the SAA-C03, organized from foundational to advanced topics. Each section includes exam-relevant scenarios to help you connect theory to the types of questions you will face.

If you are following a structured study path, this guide pairs well with our SAA-C03 exam topics overview and study plan.

VPC Fundamentals

What is a VPC?

A Virtual Private Cloud (VPC) is a logically isolated section of the AWS cloud where you launch AWS resources in a virtual network that you define. You have complete control over the IP address range, subnets, route tables, and network gateways. Think of a VPC as your own private data center within AWS, but without the physical hardware to manage.

Key characteristics of a VPC:

Spans all Availability Zones in a single AWS Region
Has a CIDR block that defines its IP address range (e.g., 10.0.0.0/16)
Cannot span multiple Regions (use VPC peering or Transit Gateway for cross-region connectivity)
Each AWS account has a default VPC in every Region with pre-configured internet connectivity
You can create multiple VPCs per Region (default limit is 5, adjustable)

CIDR Blocks

Every VPC requires a primary IPv4 CIDR block between /16 (65,536 addresses) and /28 (16 addresses). You can add secondary CIDR blocks after creation if you need more address space. For the exam, remember that CIDR blocks of peered VPCs cannot overlap.

Common CIDR ranges used in practice:

10.0.0.0/16 — 65,536 addresses, good for large environments
172.16.0.0/16 — Alternative private range, useful for multi-VPC architectures
192.168.0.0/16 — Commonly used for development environments

Public vs Private Subnets

Subnets are subdivisions of your VPC CIDR block. Each subnet exists in a single Availability Zone. The distinction between public and private subnets is one of the most important concepts for the exam.

Public Subnets

A subnet is public when its associated route table has a route to an Internet Gateway (IGW). Resources in a public subnet can have public IP addresses and communicate directly with the internet. Typical resources in public subnets include load balancers, bastion hosts, and NAT Gateways.

Private Subnets

A subnet is private when it has no direct route to an Internet Gateway. Resources in private subnets cannot be reached from the internet and cannot initiate internet connections without a NAT Gateway or NAT instance. Application servers, databases, and backend services belong in private subnets.

Exam Tip

The exam frequently tests whether you understand that subnet “publicity” is determined by the route table, not by a subnet setting. A subnet associated with a route table that has a 0.0.0.0/0 route to an IGW is public. Change the route table, and the same subnet becomes private.

Route Tables

Every subnet must be associated with a route table. The route table controls where network traffic is directed. If you do not explicitly associate a subnet with a route table, it uses the VPC’s main route table.

Key Route Table Concepts

Local route: Every route table automatically includes a local route for the VPC CIDR, enabling communication between all subnets within the VPC. This route cannot be removed.
Internet Gateway route: A route with destination 0.0.0.0/0 pointing to an IGW enables internet access (public subnet).
NAT Gateway route: A route with destination 0.0.0.0/0 pointing to a NAT Gateway enables outbound-only internet access (private subnet).
VPC Peering route: Routes to peered VPC CIDR blocks through a peering connection.
VPN/Direct Connect route: Routes to on-premises CIDR blocks through a Virtual Private Gateway.

Route Priority

Routes are evaluated using the most specific (longest prefix) match. A route to 10.0.1.0/24 takes priority over a route to 10.0.0.0/16 for traffic destined to 10.0.1.50.

Internet Gateway

An Internet Gateway (IGW) is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in your VPC and the internet. It serves two purposes: providing a target in your route table for internet-routable traffic and performing network address translation (NAT) for instances with public IPv4 addresses.

Key points for the exam:

One IGW per VPC
No bandwidth constraints or availability risks (it is fully managed and redundant)
A resource needs both a public IP and a route to the IGW to access the internet
Attaching an IGW alone does not make anything public; you also need route table entries

NAT Gateway vs NAT Instance

Both NAT Gateways and NAT instances allow resources in private subnets to initiate outbound internet connections while preventing inbound connections. The exam heavily favors NAT Gateway as the recommended solution, but you should understand both.

NAT Gateway

Managed by AWS, highly available within an AZ
Scales automatically up to 100 Gbps
Deployed in a public subnet with an Elastic IP
For high availability, deploy one NAT Gateway per AZ and configure routes accordingly
No need to manage security groups (they do not apply to NAT Gateways)
Charged per hour and per GB of data processed

NAT Instance

A regular EC2 instance configured to perform NAT
Must disable source/destination check on the instance
You manage patching, scaling, and high availability
Can be used as a bastion host simultaneously
Less expensive for very low traffic but does not scale
Security groups apply to NAT instances

Comparison Table

Feature	NAT Gateway	NAT Instance
Management	Fully managed by AWS	Self-managed
Availability	Highly available within AZ	Must script failover
Bandwidth	Up to 100 Gbps	Depends on instance type
Security Groups	Not applicable	Required
Source/Dest Check	Not applicable	Must be disabled
Bastion Host	Cannot be used as one	Can double as bastion
Cost	Higher for low traffic	Lower for low traffic

Exam Scenario: When a question asks about enabling internet access for private subnet resources, choose NAT Gateway unless the scenario specifically mentions cost constraints for very low traffic or the need for a bastion host.

Security Groups vs NACLs

This topic appears on virtually every SAA-C03 exam. Understanding the differences and when to use each is critical.

Security Groups

Security groups act as virtual firewalls at the instance level (specifically, at the elastic network interface level). They are stateful, meaning if inbound traffic is allowed, the return traffic is automatically permitted regardless of outbound rules.

Key characteristics:

Stateful — Return traffic is automatically allowed
Allow rules only — You cannot create deny rules
Instance level — Applied to ENIs (elastic network interfaces)
Evaluate all rules — All rules are evaluated before deciding whether to allow traffic
Default: Denies all inbound, allows all outbound
Can reference other security groups (e.g., allow traffic from instances in SG-A)

Network ACLs (NACLs)

Network ACLs operate at the subnet level and are stateless. You must define both inbound and outbound rules. Rules are evaluated in order by rule number, and the first matching rule is applied.

Key characteristics:

Stateless — Return traffic must be explicitly allowed
Allow and deny rules — Can block specific IP addresses
Subnet level — Applied to all traffic entering or leaving the subnet
Ordered rule evaluation — Rules processed in order by number; first match wins
Default NACL: Allows all inbound and outbound traffic
Custom NACL: Denies all traffic by default until rules are added

Comparison Table

Feature	Security Group	Network ACL
Level	Instance (ENI)	Subnet
State	Stateful	Stateless
Rule Types	Allow only	Allow and Deny
Rule Evaluation	All rules evaluated	Rules processed in order
Default Behavior	Deny all inbound, allow all outbound	Allow all (default NACL)
Return Traffic	Automatically allowed	Must be explicitly allowed

When to Use Each

Use security groups as your primary access control mechanism. They are simpler to manage and their stateful nature reduces configuration errors. Use NACLs as a secondary defense layer when you need to:

Explicitly deny traffic from specific IP addresses
Add subnet-level protection as defense in depth
Comply with security requirements that mandate network-level access controls

Exam Scenario: A question states that an application in a private subnet can make outbound API calls but is not receiving responses. The issue is likely a NACL that allows outbound traffic but does not have rules permitting the return traffic on ephemeral ports (1024-65535).

VPC Peering

VPC Peering creates a networking connection between two VPCs that enables traffic routing using private IPv4 or IPv6 addresses. Instances in either VPC can communicate as if they are in the same network.

Key Concepts

Works across accounts and across Regions (inter-Region VPC peering)
CIDR blocks must not overlap
Not transitive — If VPC A peers with VPC B and VPC B peers with VPC C, VPC A cannot communicate with VPC C through VPC B
Must update route tables in both VPCs to direct traffic through the peering connection
Security groups can reference peered VPC security groups (same Region only)

Limitations

Cannot create a peering connection between VPCs with overlapping CIDR blocks
Cannot route traffic through one VPC to reach another (no transitive peering)
Maximum bandwidth depends on instance type and is generally comparable to intra-VPC traffic
No single point of failure or bandwidth bottleneck

Exam Scenario: A company has three VPCs and needs all three to communicate. VPC peering requires three separate connections (A-B, B-C, A-C). If the question mentions many VPCs or centralized routing, Transit Gateway is the better answer.

VPC Endpoints

VPC Endpoints allow you to privately connect your VPC to supported AWS services without requiring an internet gateway, NAT device, VPN connection, or Direct Connect. Traffic never leaves the Amazon network.

Gateway Endpoints

Supported for S3 and DynamoDB only
Free to use (no hourly or data processing charges)
Configured as a route table entry pointing to the endpoint
Use endpoint policies to control access to the service
Cannot be extended out of a VPC (not accessible through VPN or peering)

Interface Endpoints (AWS PrivateLink)

Supported for most other AWS services (SQS, SNS, KMS, CloudWatch, API Gateway, etc.)
Creates an Elastic Network Interface (ENI) in your subnet with a private IP
Charged per hour and per GB of data processed
Can be accessed from on-premises through Direct Connect or VPN
Support security groups for access control
Automatically generate private DNS entries when private DNS is enabled

When to Use Each

Use Gateway Endpoints for S3 and DynamoDB access from private subnets; they are free and simple. Use Interface Endpoints when you need private access to other AWS services, when traffic must stay off the public internet for compliance, or when on-premises systems need to access AWS services privately through Direct Connect.

Exam Scenario: An application in a private subnet needs to access S3 without internet access. The answer is a Gateway Endpoint for S3. If the question mentions accessing SQS or other services, the answer is an Interface Endpoint.

Transit Gateway

AWS Transit Gateway acts as a regional network hub that connects VPCs, VPN connections, and Direct Connect gateways through a central point. It simplifies network topology by replacing complex VPC peering meshes.

Key Features

Supports thousands of VPC connections
Enables transitive routing (unlike VPC peering)
Works with VPN and Direct Connect for hybrid connectivity
Supports route tables for controlling traffic flow between attachments
Can peer with Transit Gateways in other Regions (inter-Region peering)
Supports multicast

When to Choose Transit Gateway Over VPC Peering

Connecting more than a few VPCs
Needing transitive routing between VPCs
Centralizing network management and routing policies
Connecting multiple VPCs to a shared VPN or Direct Connect
Implementing a hub-and-spoke network architecture

Exam Scenario: A company has 20 VPCs that all need to communicate with each other and with an on-premises data center through Direct Connect. Transit Gateway is the correct answer because it provides centralized routing without the complexity of managing hundreds of peering connections.

VPN Connections

AWS provides two types of VPN connections for hybrid cloud architectures.

Site-to-Site VPN

Creates an encrypted IPsec tunnel between your on-premises network and your VPC through a Virtual Private Gateway (VGW) or Transit Gateway. Key points:

Uses the public internet, so bandwidth and latency can vary
Quick to set up (minutes to hours)
Supports two tunnels per connection for redundancy
Maximum throughput of approximately 1.25 Gbps per tunnel
Cost-effective for moderate bandwidth requirements

Client VPN

Provides secure TLS connections for individual users to access AWS resources or on-premises networks. Useful for remote worker connectivity.

Exam Scenario: A company needs to quickly establish secure connectivity between their office and AWS VPC while they wait for a Direct Connect setup. Site-to-Site VPN is the correct answer for temporary or backup connectivity.

AWS Direct Connect

Direct Connect provides a dedicated physical network connection between your on-premises data center and AWS. It does not traverse the public internet.

Key Characteristics

Dedicated connection (1 Gbps, 10 Gbps, or 100 Gbps) or hosted connection (50 Mbps to 10 Gbps)
More consistent latency and throughput compared to VPN
Takes weeks to months to provision
Supports both public and private virtual interfaces
Not encrypted by default (add VPN over Direct Connect for encryption)
Can be combined with VPN as a backup path

Direct Connect Gateway

Allows you to connect a Direct Connect connection to multiple VPCs across different Regions through a single Direct Connect Gateway. This avoids creating separate connections for each Region.

Exam Scenario: A company requires consistent low-latency connectivity with 5 Gbps throughput between their data center and AWS. The answer is Direct Connect, not VPN, because VPN cannot guarantee consistent throughput or latency.

VPC Flow Logs

VPC Flow Logs capture information about IP traffic going to and from network interfaces in your VPC. They are essential for monitoring, troubleshooting, and security analysis.

Levels of Flow Logs

VPC level — Captures all traffic in the VPC
Subnet level — Captures traffic for all interfaces in the subnet
ENI level — Captures traffic for a specific network interface

Key Points for the Exam

Flow logs can be published to CloudWatch Logs or S3
They capture metadata (source IP, destination IP, ports, protocol, action) but not packet contents
Cannot modify a flow log after creation; must delete and recreate
Do not capture DNS traffic to Amazon DNS, DHCP traffic, or traffic to the instance metadata service (169.254.169.254)
Useful for troubleshooting connectivity issues, identifying unauthorized access, and analyzing traffic patterns

Exam Scenario: A security team needs to analyze which IP addresses are being denied access to their application. VPC Flow Logs filtered on REJECT action provide this information.

Common VPC Exam Scenarios and Solutions

Understanding how to apply VPC concepts to specific scenarios is critical for exam success. Here are patterns that appear frequently on the SAA-C03.

Scenario 1: Application Cannot Connect to the Internet

Symptoms: EC2 instance in a public subnet cannot reach the internet. Checklist:

Does the instance have a public IP or Elastic IP?
Does the route table have a 0.0.0.0/0 route to the IGW?
Is the IGW attached to the VPC?
Do security group outbound rules allow the traffic?
Do NACL outbound and inbound (for return traffic) rules allow the traffic?

Scenario 2: Private Subnet Resources Need to Access AWS Services

Solution: Use VPC endpoints. Gateway endpoints for S3 and DynamoDB (free), Interface endpoints for other services. This avoids routing through NAT Gateway, saving on data processing costs.

Scenario 3: Multi-Tier Application Security

Architecture: Place the ALB in a public subnet. Application servers in a private subnet with a security group allowing traffic only from the ALB security group. Database in a private subnet with a security group allowing traffic only from the application security group. This creates a chain of trust through security group references.

Scenario 4: Connecting Hundreds of VPCs

Solution: Use Transit Gateway as a central hub rather than creating a mesh of VPC peering connections. Transit Gateway supports transitive routing and centralizes network management.

Scenario 5: Secure Hybrid Connectivity with High Throughput

Solution: Use Direct Connect for primary connectivity with a Site-to-Site VPN as a backup. This provides consistent high-throughput connectivity with a failover path.

Scenario 6: Blocking Specific IP Addresses

Solution: Use NACLs with deny rules at the subnet level. Security groups cannot deny traffic explicitly, so NACLs are the correct tool for IP blocking.

Practice Your VPC Knowledge

VPC concepts are foundational to nearly every SAA-C03 question. Even questions about compute, databases, or storage often include a networking component. Mastering VPC architecture ensures you can eliminate incorrect answers quickly and identify the best solution.

To test your understanding of VPC and other networking scenarios in the SAA-C03 format, try Sailor.sh’s mock exams. Each practice question includes detailed explanations that cover not just the correct answer but the networking reasoning behind it, helping you build the architectural intuition the exam demands.

For broader exam preparation, explore our SAA-C03 exam tips and practice questions guide.

Frequently Asked Questions

How many VPC questions appear on the SAA-C03 exam?

While AWS does not publish exact numbers, VPC concepts appear in approximately 20 to 30 percent of questions. Networking topics cross all four domains: security (security groups, NACLs, private subnets), resilience (multi-AZ design, redundant connectivity), performance (CloudFront, Direct Connect), and cost (VPC endpoints vs NAT Gateway costs).

Do I need to know how to configure VPC resources in the console for the SAA-C03?

No. The SAA-C03 exam is entirely multiple-choice and does not include hands-on labs. You need to understand VPC concepts, how services interact, and how to choose the right networking solution for a given scenario. You do not need to know the exact console steps.

What is the most commonly tested VPC topic?

Security groups vs NACLs is the most frequently tested VPC topic. Public vs private subnets, NAT Gateways, and VPC endpoints follow closely. Transit Gateway and Direct Connect appear in more complex scenario questions.

Should I memorize CIDR ranges for the exam?

You should understand CIDR notation enough to determine if two VPCs have overlapping address spaces and to estimate the number of available IP addresses in a subnet. You do not need to memorize specific ranges, but knowing that a /24 provides 256 addresses (251 usable in AWS) and a /16 provides 65,536 addresses is helpful.

How do VPC endpoints help with cost optimization?

Gateway endpoints for S3 and DynamoDB are free. By routing traffic through a gateway endpoint instead of a NAT Gateway, you avoid NAT Gateway data processing charges, which are $0.045 per GB. For applications that transfer significant data to S3, this can result in substantial savings.

Can VPC peering work across AWS Regions?

Yes, inter-Region VPC peering is supported. Traffic between peered VPCs in different Regions is encrypted and stays on the AWS global network. Latency is higher than same-Region peering due to the physical distance, but it avoids the public internet.