This chapter dives deep into Amazon Virtual Private Cloud (VPC), the foundational networking service in AWS. For the CLF-C02 exam, Domain 3 (Cloud Technology Services) includes VPC as a core compute and networking service, and questions on VPC can appear across multiple objectives. Understanding VPC is critical because it underpins almost every other AWS service—EC2, RDS, Lambda, and more all run inside a VPC. This chapter will cover VPC components, default vs. custom VPCs, subnets, gateways, security, and connectivity options, all from the perspective of what you need to know for the exam.
Jump to a section
Imagine you are the IT manager for a large apartment complex. The complex is the AWS cloud—a vast network of resources. Your residents (EC2 instances) need secure, private apartments (subnets) where they can live and work. You cannot just throw them into the open street (the public internet); they need a gated community. That gated community is your Amazon VPC. You decide the layout: you build separate wings for different types of residents—one wing for public-facing services like a lobby (public subnet) and another for sensitive operations like the security office (private subnet). You install a front gate (Internet Gateway) that allows controlled entry and exit to the outside world. For residents who need to leave the complex but not go fully outside—like going to a secure warehouse across town—you build a private tunnel (Virtual Private Gateway) to your other properties (on-premises data center). You also set up a security guard (Network ACL) at each wing entrance to check IDs (IP addresses) and a doorman (Security Group) at each apartment door to verify the resident's identity (traffic type). You can even create a private bus service (VPC Peering) that connects two of your complexes directly, without ever going on public streets. The key is that you, the IT manager, have full control over the network layout, security rules, and connectivity—all within your own isolated piece of the cloud. This is exactly what Amazon VPC provides: a logically isolated section of AWS where you can launch resources in a virtual network that you define. You control IP addressing, subnets, route tables, and gateways. The mechanism is that AWS uses overlay networking with your VPC, meaning your traffic is encapsulated and isolated from other VPCs in the same region, even though they share the same physical infrastructure. This isolation is what makes VPC the foundation of secure cloud architecture.
What is Amazon VPC and the Problem It Solves
Amazon Virtual Private Cloud (VPC) is a logically isolated section of the AWS cloud where you can launch AWS resources in a virtual network that you define. Without a VPC, your EC2 instances would be directly exposed to the internet with no network boundaries—like putting every server on a public street. The problem VPC solves is network isolation and control. In on-premises data centers, you have physical routers, switches, firewalls, and VLANs to segment and secure traffic. In the cloud, you need the same capability virtually. VPC gives you full control over your virtual networking environment, including IP address ranges, subnets, route tables, and network gateways. You can create a VPC that is completely isolated from the internet (private) or one that has both public and private subnets for web servers and databases. VPC is regional—it spans all Availability Zones (AZs) in a region. Each AWS account comes with a default VPC in each region, which is pre-configured with a /20 CIDR block (usually 172.31.0.0/16), a default subnet in each AZ, an internet gateway, and a main route table. However, for production workloads, you should create custom VPCs tailored to your needs.
How VPC Works: Key Components and Their Mechanisms
CIDR Blocks: When you create a VPC, you specify a CIDR block (Classless Inter-Domain Routing) for the entire VPC, e.g., 10.0.0.0/16. This defines the IP address range. You cannot change the CIDR after creation, but you can add secondary CIDRs. The maximum size is /16 (65,536 IPs) and the minimum is /28 (16 IPs). AWS reserves the first four and the last IP in each subnet for networking purposes.
Subnets: Subnets are subdivisions of the VPC’s CIDR block, each associated with a single Availability Zone. You create subnets to segment traffic—for example, a public subnet for web servers and a private subnet for databases. Public subnets have a route to an internet gateway; private subnets do not. Each subnet has its own route table and network ACL. Subnets cannot span AZs.
Route Tables: A route table contains a set of rules (routes) that determine where network traffic from your subnet or gateway is directed. Each subnet must be associated with exactly one route table (explicit association) or the main route table (default). The main route table controls routing for subnets not explicitly associated. A default VPC has a main route table that includes a local route (for traffic within the VPC) and a route to the internet gateway. In a custom VPC, you must add routes yourself.
Internet Gateway (IGW): An IGW is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet. It serves as the target for routes in public subnets. An IGW supports both IPv4 and IPv6. To make a subnet public, you attach an IGW to the VPC and add a route in the subnet’s route table pointing 0.0.0.0/0 to the IGW. Instances in public subnets must have a public IP or Elastic IP to be reachable from the internet.
NAT Gateway / NAT Instance: A NAT (Network Address Translation) gateway allows instances in a private subnet to initiate outbound traffic to the internet (e.g., for software updates) but prevents the internet from initiating connections to those instances. NAT gateways are managed by AWS, highly available within an AZ, and scale automatically. NAT instances are deprecated but still exist—they are EC2 instances configured to perform NAT. You must use a NAT gateway in a public subnet with an Elastic IP. NAT gateways are charged per hour and per GB of data processed.
Virtual Private Gateway (VGW): A VGW is the VPN concentrator on the AWS side of a VPN connection between your VPC and your on-premises network. It supports IPsec VPN. You attach a VGW to your VPC, then create a VPN connection to your on-premises customer gateway (CGW). The VGW is highly available and handles encryption.
VPC Peering: VPC peering connects two VPCs (in the same or different accounts) using private IPv4 or IPv6 addresses. Traffic stays within AWS’s network. Peering is not transitive—if VPC A peers with VPC B and VPC B peers with VPC C, VPC A cannot communicate with VPC C unless there is a direct peering connection. You must add routes in both VPCs’ route tables.
VPC Endpoints: VPC endpoints allow you to privately connect your VPC to supported AWS services (like S3, DynamoDB) without using an internet gateway or NAT device. There are two types: Interface Endpoints (powered by PrivateLink) and Gateway Endpoints (for S3 and DynamoDB). Gateway endpoints are free and use route tables; interface endpoints are charged per hour and per GB.
Security Groups vs. Network ACLs: Security groups act as a virtual firewall for instances (stateful), controlling inbound and outbound traffic at the instance level. Network ACLs act as a firewall for subnets (stateless), controlling traffic at the subnet level. Security groups support allow rules only; NACLs support allow and deny rules. Security groups are evaluated as a whole; NACLs are processed in order by rule number. Exam tip: Security groups are stateful—if you allow inbound traffic, the outbound return traffic is automatically allowed. NACLs are stateless—you must explicitly allow both inbound and outbound traffic.
Default VPC vs. Custom VPC
Every AWS account comes with a default VPC in each region. The default VPC is pre-configured with a /20 CIDR, a default subnet in each AZ, an internet gateway, and a main route table with a route to the IGW. Instances launched in the default VPC automatically receive a public IP and can be accessed from the internet. This is convenient for testing but not recommended for production because it lacks isolation and control. A custom VPC gives you full control over CIDR, subnets, routing, and security. On the exam, remember that the default VPC exists and is ready to use, but for most workloads you create custom VPCs.
Pricing
VPC itself is free. You pay for components like NAT gateways (hourly + data processing), VPN connections (hourly), VPC endpoints (Interface endpoints: hourly + data processing; Gateway endpoints: free), and Elastic IPs (when not associated to a running instance). Data transfer between AZs and regions also incurs charges. Inbound data transfer from the internet is free; outbound is charged per GB.
When to Use VPC vs. Alternatives
VPC is the default networking construct for almost all AWS services that require network isolation. If you need to run EC2, RDS, Lambda (in VPC mode), or ECS, you use a VPC. For serverless services like Lambda (outside VPC) or API Gateway, you may not need a VPC, but you can still use VPC endpoints to access services privately. There is no alternative to VPC for network isolation—it is the foundation. For hybrid connectivity, you choose between VPN (via VGW) and AWS Direct Connect (dedicated line). For connecting multiple VPCs, you use VPC peering or Transit Gateway (for many VPCs). For connecting to on-premises, you use VPN or Direct Connect.
Create a Custom VPC
Log in to the AWS Management Console and navigate to VPC Dashboard. Click 'Create VPC'. Provide a name tag (e.g., 'MyVPC'), choose an IPv4 CIDR block (e.g., 10.0.0.0/16). Optionally add an IPv6 CIDR (Amazon-provided or BYOIP). Select 'Default' tenancy (shared hardware) or 'Dedicated' (your own hardware, more expensive). Click 'Create'. AWS will allocate the IP range and create a VPC with a main route table, a default security group, and a default network ACL. The VPC is now ready but has no subnets or gateways. Behind the scenes, AWS creates a virtual network overlay that isolates this VPC from other VPCs and the internet until you add connectivity.
Create Subnets in Multiple AZs
In the VPC Dashboard, select 'Subnets' and click 'Create subnet'. Choose the VPC you created. Specify a subnet name (e.g., 'Public-1a'), select an Availability Zone (e.g., us-east-1a), and enter a CIDR block that is a subset of the VPC CIDR, such as 10.0.1.0/24 (256 IPs). Repeat for a private subnet (e.g., 10.0.2.0/24) in a different AZ for high availability. AWS automatically reserves the first four IPs and the last IP in each subnet (for network, router, DNS, future use, and broadcast). You cannot use those IPs. The subnet is now associated with the VPC and the main route table. At this point, the subnets are private—they have no internet access.
Attach Internet Gateway and Configure Route Tables
Go to 'Internet Gateways' and click 'Create internet gateway'. Name it (e.g., 'MyIGW') and click 'Create'. Then select it and click 'Actions' > 'Attach to VPC'. Choose your VPC. This attaches the IGW to the VPC. Next, create a custom route table for the public subnet: click 'Route Tables' > 'Create route table', name it 'Public-RT', select your VPC. In the 'Routes' tab, click 'Edit routes' > 'Add route'. For destination, enter 0.0.0.0/0 (all internet traffic). For target, select 'Internet Gateway' and choose your IGW. Then associate this route table with the public subnet: click 'Subnet associations' > 'Edit subnet associations' and select the public subnet. Now the public subnet can reach the internet. Instances in this subnet need a public IP to be reachable from the internet.
Launch an EC2 Instance in the Public Subnet
Go to EC2 Dashboard and launch an instance. In 'Network settings', select your VPC and the public subnet. Enable 'Auto-assign public IP' (or later assign an Elastic IP). For security group, create a new one that allows SSH (port 22) from your IP (or 0.0.0.0/0 for testing). Launch the instance. AWS assigns a private IP from the subnet’s range and a public IP (if enabled). The instance can now be accessed via SSH using the public IP. Traffic flows: your request goes to the IGW, which forwards it to the instance’s private IP via the route table. The instance’s response goes back through the IGW. The security group acts as a stateful firewall, allowing return traffic automatically.
Set Up a NAT Gateway for Outbound Internet from Private Subnet
To allow instances in the private subnet to download updates but not be reachable from the internet, create a NAT gateway. Go to 'NAT Gateways' > 'Create NAT gateway'. Specify a name, select the public subnet (must be in the same AZ for reliability), and allocate an Elastic IP. Click 'Create'. AWS provisions a managed NAT service that translates private IPs to the Elastic IP for outbound traffic. Then go to the route table associated with the private subnet (or create a new one). Edit routes: add a route with destination 0.0.0.0/0 and target the NAT Gateway. Now instances in the private subnet can initiate outbound traffic to the internet (e.g., yum update) but cannot be directly accessed from the internet. The NAT gateway is charged per hour and per GB of data processed. For high availability, create NAT gateways in each AZ.
Business Scenario 1: Multi-Tier Web Application
A company runs a web application with a public-facing web server and a private database. They use a custom VPC with a /16 CIDR. They create a public subnet in us-east-1a for the web server (EC2 instance) and a private subnet in us-east-1b for the RDS MySQL database. The web server is placed in an Auto Scaling group behind an Application Load Balancer (ALB) in the public subnet. The database is in the private subnet with a security group that only allows inbound traffic from the web server's security group on port 3306. They use a NAT Gateway in the public subnet so the database can get patches. The VPC is connected to their on-premises data center via a VPN connection using a Virtual Private Gateway and a Customer Gateway. This setup isolates the database from the internet, reducing attack surface. Cost: VPC is free, NAT Gateway costs ~$0.045/hour + data processing, VPN connection costs ~$0.05/hour. Misconfiguration: If the database's security group accidentally allows 0.0.0.0/0 on port 3306, it becomes publicly accessible, leading to potential data breach. Also, if the route table for the private subnet does not point to the NAT Gateway, the database cannot download updates.
Business Scenario 2: Hybrid Cloud with Direct Connect
A financial services firm needs a dedicated, low-latency connection between their on-premises data center and AWS. They set up AWS Direct Connect with a 1 Gbps connection. They create a VPC with a /16 CIDR and attach a Virtual Private Gateway. They configure a private virtual interface (VIF) from the Direct Connect connection to the VGW. The VPC has subnets for production and development, each with appropriate security groups and NACLs. The on-premises network can now access EC2 instances and RDS databases in the VPC as if they were on the same local network. They do not use an Internet Gateway for this traffic. They also use VPC Endpoints for S3 to keep traffic within AWS. Cost: Direct Connect port hours (~$0.30/hour for 1 Gbps) + data transfer out (~$0.02/GB). Misconfiguration: If the VGW is not attached correctly or the route tables on-premises do not point to the Direct Connect, connectivity fails. Also, if the VPC CIDR overlaps with on-premises CIDR, routing issues occur.
Business Scenario 3: Isolated Development Environment
A startup wants multiple isolated environments for development, testing, and production. They create separate VPCs for each environment. For the development VPC, they use a /28 CIDR (16 IPs) to save costs. They only create one public subnet and one private subnet, both in the same AZ. They do not set up a NAT Gateway to save money—developers instead use a bastion host (jump box) in the public subnet to SSH into private instances. This is a cost-saving measure but reduces availability. The production VPC uses a /16 CIDR with multiple AZs and NAT Gateways in each AZ for high availability. They use VPC Peering between the development and production VPCs for occasional data transfer. Misconfiguration: If the development VPC’s CIDR overlaps with production, peering fails. Also, relying on a single bastion host creates a single point of failure.
What CLF-C02 Tests on VPC
The CLF-C02 exam tests your understanding of VPC as a foundational networking service. You need to know the purpose of VPC, its components, and basic configuration. Specific topics include: default VPC vs. custom VPC, public vs. private subnets, Internet Gateway, NAT Gateway, Security Groups vs. Network ACLs (stateful vs. stateless), VPC Peering (non-transitive), VPC Endpoints (Gateway vs. Interface), and VPN connectivity. The exam does not require deep configuration steps but expects you to identify correct use cases.
Common Wrong Answers and Why Candidates Choose Them
"A security group is stateless" – Many candidates confuse security groups with network ACLs. Security groups are stateful; NACLs are stateless. The exam may ask which is stateful—remember: Security Groups track connection state.
"VPC Peering allows transitive routing" – Candidates think if VPC A peers with B and B with C, then A can talk to C. This is false—peering is non-transitive. You need a direct peering connection or use Transit Gateway.
"NAT Gateway is used for inbound traffic from internet" – NAT Gateway only allows outbound traffic from private subnets. For inbound, you need an Internet Gateway and a public IP.
"Default VPC is automatically deleted if not used" – The default VPC is not deleted automatically. It remains until you delete it manually. Some candidates think it disappears after a period of inactivity.
"VPC Endpoints require an Internet Gateway" – VPC Endpoints (Gateway type) do not use IGW; they use route tables. Interface Endpoints use PrivateLink without IGW.
Specific Service Names and Values on the Exam
CIDR block sizes: /16 to /28
Default VPC CIDR: 172.31.0.0/16 (or /20, but exam says /16)
Internet Gateway (IGW)
Virtual Private Gateway (VGW)
Customer Gateway (CGW)
NAT Gateway (not NAT Instance)
Security Group: stateful, supports allow rules only
Network ACL: stateless, supports allow and deny rules, evaluated by rule number
VPC Peering: non-transitive, no overlapping CIDRs
VPC Endpoints: Gateway (S3, DynamoDB) and Interface (other services)
Tricky Distinctions
Security Group vs. Network ACL: The exam may ask which is the first line of defense. Actually, NACL is the first (subnet level), then Security Group (instance level). But they are complementary.
NAT Gateway vs. Internet Gateway: Both provide internet access, but IGW is for public subnets (bidirectional), NAT is for private subnets (outbound only).
VPC Peering vs. Transit Gateway: Peering is for few VPCs; Transit Gateway is for many VPCs and supports transitive routing.
Decision Rule for Multiple Choice
If a question asks about isolating a database from the internet while allowing it to download patches, the answer involves a private subnet with a NAT Gateway. If the question asks about connecting two VPCs without using the internet, choose VPC Peering. If it asks about a firewall for a subnet, choose Network ACL. If it asks about a firewall for an instance, choose Security Group. Always check if the scenario requires stateful or stateless filtering.
Amazon VPC is a logically isolated network in AWS where you launch resources; it is regional and spans all AZs in that region.
A VPC must have a CIDR block (size /16 to /28); you cannot change it after creation but can add secondary CIDRs.
Subnets are associated with a single AZ; public subnets have a route to an Internet Gateway, private subnets do not.
Security Groups are stateful instance-level firewalls; Network ACLs are stateless subnet-level firewalls.
NAT Gateway allows outbound internet from private subnets; it is charged hourly and per GB; use one per AZ for high availability.
VPC Peering connects two VPCs directly; it is non-transitive and does not support overlapping CIDRs.
VPC Endpoints allow private access to AWS services without IGW or NAT; Gateway endpoints are free for S3 and DynamoDB.
The default VPC exists in each region and is pre-configured with a /20 CIDR, IGW, and default subnets; it is not automatically deleted.
For hybrid connectivity, use Virtual Private Gateway (VPN) or AWS Direct Connect.
VPC itself is free; you pay for NAT Gateways, VPN connections, VPC endpoints (Interface), and data transfer.
These come up on the exam all the time. Here's how to tell them apart.
Security Group
Stateful (return traffic automatically allowed)
Operates at the instance level (first layer at instance)
Supports allow rules only (no explicit deny)
Rules are evaluated as a whole (all rules are considered)
Default security group allows all outbound traffic
Network ACL
Stateless (return traffic must be explicitly allowed)
Operates at the subnet level (first layer at subnet)
Supports both allow and deny rules (numbered list)
Rules are evaluated in order by rule number (lowest first)
Default NACL allows all inbound and outbound traffic
Internet Gateway (IGW)
Provides bidirectional internet access (inbound and outbound)
Attached to VPC, used by public subnets
Requires instances to have public IPs
Free (no hourly charge, only data transfer costs)
Supports IPv4 and IPv6
NAT Gateway
Provides outbound-only internet access from private subnets
Deployed in a public subnet, used by private subnets via route table
Uses Elastic IP for outbound traffic; instances have private IPs
Charged per hour and per GB of data processed
Supports IPv4 only (use egress-only Internet Gateway for IPv6)
Mistake
Security groups are stateless like network ACLs.
Correct
Security groups are stateful. If you allow inbound traffic, the outbound return traffic is automatically allowed, regardless of outbound rules. Network ACLs are stateless and require explicit allow rules for both directions.
Mistake
You can have multiple Internet Gateways attached to a single VPC.
Correct
You can attach only one Internet Gateway to a VPC at a time. However, you can detach and attach a different IGW. For multiple public subnets, a single IGW suffices with proper route tables.
Mistake
VPC Peering supports transitive routing.
Correct
VPC Peering is non-transitive. If VPC A peers with B and B with C, A cannot communicate with C through B. You need a direct peering connection or use AWS Transit Gateway.
Mistake
The default VPC is automatically deleted if you don't use it.
Correct
The default VPC is not automatically deleted. It remains in your account until you manually delete it. You can also create new default VPCs if you delete the existing one.
Mistake
NAT Gateway can be used for inbound connections from the internet.
Correct
NAT Gateway only allows outbound traffic from private subnets to the internet. It does not allow inbound connections initiated from the internet. For inbound, use an Internet Gateway with a public subnet.
A public subnet has a route to an Internet Gateway (IGW) in its route table, allowing instances to receive inbound traffic from the internet if they have a public IP. A private subnet does not have a route to an IGW; instances in a private subnet cannot be directly accessed from the internet. To allow outbound internet access from a private subnet, you use a NAT Gateway or NAT Instance in a public subnet. On the exam, remember that the key difference is the route table entry: 0.0.0.0/0 -> IGW for public, 0.0.0.0/0 -> NAT Gateway for private outbound.
No, you cannot change the primary CIDR block of a VPC after creation. However, you can add secondary CIDR blocks (up to 5) to an existing VPC. This is useful if you need more IP addresses or want to peer with a VPC that has overlapping CIDRs. For the exam, know that you must plan your CIDR carefully before creating a VPC.
You can attach only one Internet Gateway to a VPC at a time. If you need to replace it, you detach the current one and attach a new one. This is a common exam fact. Also, an Internet Gateway can be attached to only one VPC at a time.
A NAT Gateway is a managed AWS service that is highly available within an AZ and scales automatically. You pay per hour and per GB of data processed. A NAT Instance is an EC2 instance that you configure manually; it is not highly available by default and requires you to manage failover. NAT Instances are deprecated but still exist. For the exam, always choose NAT Gateway over NAT Instance for production workloads.
No, VPC Peering does not support transitive routing. If VPC A is peered with VPC B, and VPC B is peered with VPC C, traffic cannot flow from A to C through B. You must create a direct peering connection between A and C. For transitive routing across multiple VPCs, use AWS Transit Gateway.
The default VPC is a pre-configured VPC that AWS creates in each region for your account. It has a /20 CIDR (usually 172.31.0.0/16), a default subnet in each AZ, an Internet Gateway, and a main route table with a route to the IGW. It is designed to let you launch instances immediately without needing to create a VPC. However, for production, you should create custom VPCs for better control and security.
Yes, you can use a Gateway VPC Endpoint for S3 (or DynamoDB). This allows instances in your VPC to access S3 via private IP addresses without traversing the internet or using a NAT Gateway. Gateway endpoints are free and are added as a route in your route table (prefix list for S3). Interface Endpoints (PrivateLink) are used for other services like EC2 API, and they incur charges.
You've just covered Amazon VPC Deep Dive — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?