This chapter covers Amazon Virtual Private Cloud (VPC), the foundational networking service in AWS that enables you to provision a logically isolated section of the AWS cloud. For the CLF-C02 exam, networking concepts under Domain 3: Cloud Technology Services carry significant weight, and VPC is a core objective (Objective 3.4). You will learn how to create and configure VPCs, subnets, route tables, internet gateways, and security groups. By the end, you will understand how VPC provides network isolation, control, and security—essential for deploying AWS resources in a production environment.
Jump to a section
Imagine you are a business owner moving into a large office building (the AWS Cloud). The building has shared hallways, elevators, and common areas that anyone can use. However, you need a private, secure office suite where only your employees can enter, and you can control who comes in and out. This is your Virtual Private Cloud (VPC). In AWS, a VPC is your logically isolated section of the cloud where you launch your resources (like EC2 instances, RDS databases). Just as you would install a door with a lock (security group) and maybe a receptionist who checks IDs (network ACL), in a VPC you define subnets (rooms), route tables (hallway signs), and internet gateways (main entrance). You can also set up a VPN (a secure tunnel) to connect your office suite to your home office (on-premises data center) so they feel like one network. The key mechanism: AWS provides the building, but you design and secure your own suite. You decide which rooms are public (facing the internet) and which are private (only internal). This isolation ensures that even if another company in the same building has a security breach, your suite remains unaffected. Understanding VPC is crucial because it's the foundation of almost all AWS services—without it, you cannot launch resources securely.
What is Amazon VPC and the Problem It Solves
Amazon Virtual Private Cloud (VPC) is a service that lets you create a private, isolated section of the AWS cloud where you can launch AWS resources in a virtual network that you define. Think of it as your own data center inside AWS, but without the physical hardware. The problem it solves: In the public cloud, resources like EC2 instances are by default accessible over the internet—that's insecure for most applications. You need a way to isolate your resources, control inbound and outbound traffic, and connect to your on-premises network securely. VPC provides that isolation. Every AWS account comes with a default VPC in each region, but you can create custom VPCs to meet specific requirements.
How VPC Works: The Mechanism
A VPC spans all Availability Zones (AZs) in a region. When you create a VPC, you specify a CIDR block (e.g., 10.0.0.0/16) which defines the IP address range for the entire VPC. Within that VPC, you create subnets—each subnet resides in a single AZ and has its own CIDR block (a subset of the VPC CIDR). Subnets can be public (have direct route to an Internet Gateway) or private (no direct internet access). Traffic between subnets is routed via a route table associated with each subnet. The route table contains rules (routes) that determine where network traffic is directed. For example, a public subnet may have a route to an Internet Gateway (IGW) for internet-bound traffic. Private subnets may have a route to a NAT Gateway or NAT Instance for outbound internet access (e.g., to download updates) while preventing inbound internet traffic.
Key Components and Configurations
Internet Gateway (IGW): A horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet. Only one IGW per VPC. It serves as the target for internet-bound traffic in route tables.
NAT Gateway: A managed service that enables instances in a private subnet to connect to the internet or other AWS services, but prevents the internet from initiating a connection with those instances. It is AZ-specific and requires an Elastic IP. Alternatively, you can use a NAT Instance (an EC2 instance configured as a NAT), but NAT Gateway is preferred for production.
Route Tables: Each subnet must be associated with a route table. The main route table controls routing for subnets not explicitly associated. A default route table has a local route for VPC internal traffic. You add routes to direct traffic to IGW, NAT Gateway, Virtual Private Gateway (for VPN), VPC Peering, etc.
Security Groups: Act as a virtual firewall for instances (or other resources like RDS, Lambda). They operate at the instance level (stateful). You specify allow rules for inbound and outbound traffic; all other traffic is implicitly denied. Security groups support allow rules only (no deny rules). They are stateful: if you allow inbound traffic, the outbound response is automatically allowed regardless of outbound rules.
Network ACLs (NACLs): Act as a firewall for subnets (stateless). They support both allow and deny rules, and are evaluated in order (lowest number first). Because they are stateless, you must explicitly allow both inbound and outbound traffic separately. Default NACL allows all inbound and outbound; custom NACLs deny all by default.
VPC Peering: A networking connection between two VPCs that enables traffic routing using private IPv4 or IPv6 addresses. Peering is not transitive (if VPC A peers with B and B peers with C, A cannot talk to C unless directly peered).
AWS Site-to-Site VPN: Connects your on-premises network to your VPC via a secure VPN tunnel over the internet. Requires a Virtual Private Gateway (VGW) on the VPC side and a Customer Gateway (CGW) on-premises.
AWS Direct Connect: A dedicated physical connection from your on-premises data center to AWS, bypassing the internet for more consistent bandwidth and lower latency.
VPC Endpoints: Allow private connections between your VPC and supported AWS services (e.g., S3, DynamoDB) without traversing the internet. Two types: Gateway Endpoints (for S3 and DynamoDB) and Interface Endpoints (powered by AWS PrivateLink, for many other services).
Elastic IP (EIP): A static, public IPv4 address that you can allocate to your account and associate with an instance or NAT Gateway. Useful for masking instance failures (you can remap the address to another instance).
Pricing Models
VPC itself is free—you only pay for the components you use: - NAT Gateway: Charged per hour and per GB of data processed. - VPN Connection: Hourly charge plus data transfer out. - Direct Connect: Monthly port hours and data transfer out. - VPC Endpoints: Interface endpoints have hourly charges and data processing fees; Gateway endpoints are free but data transfer costs apply. - Elastic IP: Free if associated with a running instance; charged if allocated but not used. - Data Transfer: Outbound data transfer is charged per GB (tiered); inbound is free. Data transfer between AZs within the same VPC is charged.
Comparison to On-Premises Networking
In a traditional on-premises data center, you buy routers, switches, firewalls, and cables, and you have physical control. With VPC, you get the same logical capabilities without hardware: subnets (VLANs), route tables (routing tables), security groups (host firewalls), NACLs (network firewalls), and VPN/Direct Connect (WAN connections). The key difference is that AWS manages the physical infrastructure, and you only pay for what you use. However, you must understand CIDR planning, subnet sizing, and routing—mistakes here can cause connectivity issues or IP exhaustion.
When to Use VPC vs Alternatives
Default VPC: Use for quick experiments or simple setups. It has a default CIDR, one public subnet per AZ, and an IGW attached. Not recommended for production due to lack of isolation.
Custom VPC: Use for production workloads where you need specific IP ranges, multiple tiers (web, app, database), private subnets, and connectivity to on-premises.
Shared VPC (via AWS Organizations): Use when multiple accounts need a common network (e.g., centralized IT).
AWS Transit Gateway: Use when you have many VPCs and on-premises connections to manage—acts as a hub for transitive routing.
VPC Lattice: A newer service for service-to-service connectivity across accounts and VPCs (not covered in CLF-C02).
Step-by-Step: Creating a Custom VPC with Public and Private Subnets
Create a VPC: Choose a CIDR block (e.g., 10.0.0.0/16). Enable DNS hostnames and DNS resolution.
Create Subnets: Create public subnets (e.g., 10.0.1.0/24 in AZ-a) and private subnets (e.g., 10.0.2.0/24 in AZ-a). Repeat for other AZs as needed.
Create and Attach an Internet Gateway: Create an IGW and attach it to your VPC.
Create a Custom Route Table for Public Subnets: Add a route that sends 0.0.0.0/0 traffic to the IGW. Associate this route table with public subnets.
Create a NAT Gateway: Allocate an Elastic IP, create a NAT Gateway in a public subnet, and update the private subnet route table to send 0.0.0.0/0 traffic to the NAT Gateway.
Launch EC2 Instances: Launch an EC2 instance in a public subnet with a security group allowing SSH (port 22) from your IP. Launch another instance in a private subnet with a security group allowing SSH only from the public instance's security group.
Test Connectivity: SSH into the public instance, then from there SSH into the private instance to verify private subnet access. The private instance should be able to reach the internet (e.g., ping google.com) via the NAT Gateway.
Important Limits
Default VPCs per region: 5 (soft limit, can be increased).
Custom VPCs per region: 5 (soft limit).
Subnets per VPC: 200 (soft limit).
Security groups per VPC: 500 (soft limit).
Rules per security group: 60 inbound + 60 outbound (hard limit).
NACLs per VPC: 200 (soft limit).
Rules per NACL: 20 inbound + 20 outbound (hard limit).
Internet Gateways per VPC: 1 (hard limit).
NAT Gateways per AZ: 5 (soft limit).
CLI and CloudFormation Examples
AWS CLI to create a VPC:
aws ec2 create-vpc --cidr-block 10.0.0.0/16Create a subnet:
aws ec2 create-subnet --vpc-id vpc-12345678 --cidr-block 10.0.1.0/24 --availability-zone us-east-1aCloudFormation snippet for a VPC with public subnet:
Resources:
MyVPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsSupport: true
EnableDnsHostnames: true
PublicSubnet:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref MyVPC
CidrBlock: 10.0.1.0/24
AvailabilityZone: us-east-1a
InternetGateway:
Type: AWS::EC2::InternetGateway
AttachGateway:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
VpcId: !Ref MyVPC
InternetGatewayId: !Ref InternetGateway
PublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref MyVPC
PublicRoute:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref PublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref InternetGateway
PublicSubnetRouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnet
RouteTableId: !Ref PublicRouteTableThis is just a minimal example—real production templates include security groups, NACLs, and possibly NAT gateways.
Plan Your IP Addressing
Before creating a VPC, decide on the CIDR block. AWS reserves the first four IP addresses and the last one in each subnet for networking purposes (network address, VPC router, DNS, future use, broadcast). So a /24 subnet (256 IPs) actually has 251 usable IPs. Choose a CIDR that doesn't overlap with other networks you connect to (e.g., on-premises). For production, use RFC 1918 private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Avoid using the same range as your corporate network to prevent routing conflicts when using VPN or Direct Connect.
Create the VPC and Subnets
In the AWS Management Console, go to VPC > Your VPCs > Create VPC. Specify a Name tag, IPv4 CIDR (e.g., 10.0.0.0/16), and optionally IPv6 CIDR (Amazon-provided or bring your own). Enable DNS hostnames and resolution. After creation, create subnets: go to Subnets > Create subnet. Select the VPC, choose a name, AZ, and CIDR (e.g., 10.0.1.0/24 for public, 10.0.2.0/24 for private). Repeat for each AZ you need. AWS automatically associates the main route table with each new subnet, which only has a local route. You will update this later.
Attach Internet Gateway and Configure Route Tables
Create an Internet Gateway (IGW) from the VPC dashboard. Attach it to your VPC. Then create a custom route table for public subnets. Add a route with destination 0.0.0.0/0 targeting the IGW. Associate this route table with all public subnets. For private subnets, keep the main route table (or create a separate one) but do NOT add a route to IGW. Instead, if your private instances need outbound internet access, create a NAT Gateway in a public subnet (requires Elastic IP), then add a route 0.0.0.0/0 to the NAT Gateway in the private route table. Note: NAT Gateway is not free—you pay per hour and per GB processed.
Configure Security Groups and NACLs
Create security groups for your instances. For a web server, allow inbound HTTP (80) and HTTPS (443) from 0.0.0.0/0, and SSH (22) from your IP only. For a database server, allow inbound MySQL (3306) only from the web server security group. Security groups are stateful, so outbound rules are not needed for responses. Optionally, configure Network ACLs for additional subnet-level filtering. For example, on a public subnet NACL, allow inbound HTTP/HTTPS from 0.0.0.0/0 and ephemeral ports from 0.0.0.0/0 for return traffic (stateless requirement). Default NACL allows all traffic; custom NACLs deny all initially.
Launch Resources in Subnets
When launching an EC2 instance, select the VPC and subnet. For public instances, enable 'Auto-assign Public IP' (or use an Elastic IP). Assign the appropriate security group. For private instances, do not assign a public IP. Ensure the private instance's security group allows inbound traffic only from the public instance's security group (or specific IPs). After launch, test connectivity: the public instance should be reachable via SSH from the internet. From the public instance, SSH into the private instance using its private IP. The private instance should be able to reach the internet (e.g., curl google.com) if a NAT Gateway is properly configured.
Set Up VPC Peering or VPN (Optional)
To connect two VPCs, create a VPC Peering connection: request from one VPC to another (they can be in different accounts or regions). Accept the request, add routes in both VPCs' route tables to point to the peering connection for the other VPC's CIDR. Note: Peering is not transitive. To connect to on-premises, set up a Site-to-Site VPN: create a Virtual Private Gateway (VGW) and attach to VPC, create a Customer Gateway (CGW) with your on-premises router's public IP, then create a VPN connection. Download the configuration for your router. On-premises traffic is routed via the VPN tunnel. Alternatively, use Direct Connect for dedicated bandwidth.
Scenario 1: Multi-Tier Web Application
A startup hosts a web application on AWS. They create a custom VPC with a /16 CIDR. They create public subnets in two AZs for web servers (EC2 behind an Application Load Balancer) and private subnets for application servers and RDS database. Public subnets have a route to an Internet Gateway. Private subnets have a route to a NAT Gateway for outbound updates. Security groups are tightly configured: web servers allow HTTP/HTTPS from 0.0.0.0/0, app servers allow traffic only from web security group, and database allows MySQL only from app security group. This architecture ensures that the database is never directly exposed to the internet. Cost: NAT Gateway ($0.045/hour + data processing), plus data transfer costs. Misconfiguration: If the database subnet's route table accidentally has a route to IGW, the database could become publicly accessible—a major security risk. Also, if security groups are too permissive (e.g., allow all traffic), the attack surface increases.
Scenario 2: Hybrid Cloud with VPN
A financial services company has an on-premises data center and wants to extend its network to AWS. They create a VPC with a CIDR that does not overlap with their on-premises (e.g., 10.1.0.0/16). They set up a Site-to-Site VPN using a Virtual Private Gateway and a Customer Gateway. The company's on-premises routers are configured to route traffic destined for 10.1.0.0/16 through the VPN tunnel. In the VPC, route tables for private subnets include a route to the on-premises network via the VGW. This allows EC2 instances to access on-premises databases and applications securely over the internet with encryption. Cost: VPN connection ($0.05/hour) + data transfer out. Misconfiguration: If the VPN tunnel goes down (e.g., due to ISP issues), connectivity is lost unless a backup VPN or Direct Connect is configured. Also, overlapping CIDRs would cause routing conflicts.
Scenario 3: Isolated Development Environments
A software company uses multiple VPCs for different environments (dev, test, prod). Each environment has its own VPC with separate CIDRs. They use VPC Peering to allow limited connectivity between dev and test VPCs, but prod is isolated. They also use VPC Endpoints to access S3 and DynamoDB privately without internet. This keeps development traffic from affecting production. Cost: Each VPC is free, but peering data transfer charges apply ($0.01/GB per direction). Misconfiguration: If route tables are not updated after peering, instances cannot communicate. Also, if security groups are not adjusted, traffic may be blocked.
What CLF-C02 Tests on VPC
Domain 3: Cloud Technology Services, Objective 3.4: 'Identify the components of a VPC.' The exam expects you to know:
The purpose of a VPC: logically isolated network.
Subnets: public vs private, and that each subnet maps to a single AZ.
Internet Gateway: allows public internet access to public subnets.
NAT Gateway/Instance: allows outbound internet from private subnets.
Security Groups vs Network ACLs: stateful vs stateless, instance-level vs subnet-level, allow vs allow/deny.
Route Tables: how traffic is directed.
VPC Peering: non-transitive, can be cross-account/region.
VPN and Direct Connect: hybrid connectivity.
VPC Endpoints: private access to AWS services.
Default VPC: pre-configured with public subnets and IGW.
Common Wrong Answers and Why Candidates Choose Them
'Security groups are stateless.' This is false—security groups are stateful. Candidates confuse them with NACLs which are stateless. Remember: Security Groups = Stateful, Network ACLs = Stateless.
'A subnet spans multiple Availability Zones.' Wrong—each subnet resides in exactly one AZ. This is a classic trap. Candidates think subnets are AZ-agnostic.
'You can attach multiple Internet Gateways to a VPC.' False—only one IGW per VPC. Some think you can have more for redundancy, but AWS does not allow it.
'NAT Gateway is used for inbound traffic from the internet.' No—NAT Gateway is for outbound only. Candidates confuse it with Internet Gateway.
'VPC Peering allows transitive routing.' False—VPC Peering is not transitive. If A peers with B and B peers with C, A cannot talk to C unless directly peered.
Specific Terms and Values on the Exam
CIDR notation (e.g., /16, /24).
Reserved IPs in a subnet: first four, last one (total 5).
Default VPC: comes with one public subnet per AZ, IGW, and a default security group allowing all traffic within the group.
NACL rules: evaluated in ascending order; deny rules can override allow rules.
Ephemeral ports: required in NACL for return traffic (e.g., 1024-65535).
VPC Endpoints: Gateway type (S3, DynamoDB) vs Interface type (many services).
Decision Rule for Exam Questions
If a question asks about controlling traffic at the instance level, choose Security Group. If at the subnet level, choose Network ACL. If the question mentions 'stateful', it's Security Group; 'stateless' means NACL. For internet access: if inbound and outbound, use Internet Gateway; if only outbound from private subnet, use NAT Gateway. For connecting two VPCs, consider VPC Peering; for connecting on-premises, consider VPN or Direct Connect.
A VPC is a logically isolated network within AWS, spanning all AZs in a region.
Each subnet resides in exactly one AZ and can be public (with IGW) or private (no direct IGW).
Security Groups are stateful instance-level firewalls with only allow rules; NACLs are stateless subnet-level firewalls with allow and deny rules.
Only one Internet Gateway can be attached per VPC; NAT Gateway enables outbound internet from private subnets.
VPC Peering is non-transitive and can be cross-account/region; VPN and Direct Connect connect on-premises to VPC.
VPC Endpoints (Gateway for S3/DynamoDB, Interface for others) provide private access to AWS services without internet.
Default VPC is pre-configured with public subnets and IGW; custom VPCs are recommended for production.
AWS reserves 5 IPs per subnet (first four, last one); plan CIDR accordingly.
Security group rules cannot reference other security groups across regions or VPCs (unless using VPC peering with proper configuration).
NACL rules are evaluated in ascending order; the first matching rule determines allow/deny.
These come up on the exam all the time. Here's how to tell them apart.
Security Group
Operates at the instance level (first layer of defense).
Stateful: return traffic is automatically allowed.
Supports allow rules only (no explicit deny).
Evaluated as a whole (all rules are considered).
Default security group allows all traffic within the group.
Network ACL
Operates at the subnet level (second layer of defense).
Stateless: return traffic must be explicitly allowed.
Supports both allow and deny rules, evaluated in order.
Rules are evaluated in ascending order by rule number.
Default NACL allows all inbound and outbound traffic.
Internet Gateway
Allows both inbound and outbound internet access.
Attached to a VPC (one per VPC).
Required for public subnets to be reachable from internet.
Free (no hourly charge, only data transfer costs).
Used with public subnets and route table 0.0.0.0/0 -> IGW.
NAT Gateway
Allows outbound internet access only (not inbound).
Deployed in a specific public subnet and AZ.
Used by private subnets to access internet for updates, etc.
Charged per hour and per GB of data processed.
Requires an Elastic IP and is highly available within an AZ.
Mistake
A VPC spans multiple regions.
Correct
A VPC exists within a single region, but spans all Availability Zones in that region. To have resources in multiple regions, you must create a separate VPC in each region and optionally peer them (cross-region VPC peering).
Mistake
Security groups have deny rules.
Correct
Security groups only support allow rules. All traffic not explicitly allowed is implicitly denied. If you need to explicitly deny traffic, use a Network ACL.
Mistake
A subnet can be in multiple Availability Zones.
Correct
Each subnet is confined to a single Availability Zone. This is a fundamental design: subnets provide AZ-level fault isolation. You create multiple subnets (one per AZ) for high availability.
Mistake
NAT Gateway provides high availability across AZs automatically.
Correct
A NAT Gateway is deployed in a single AZ. To be highly available, you must create NAT Gateways in multiple AZs and route traffic appropriately (e.g., using separate route tables per AZ).
Mistake
Default VPC is not secure and should never be used.
Correct
The default VPC is pre-configured with public subnets and an IGW, which can be less secure if you launch instances with public IPs without proper security groups. However, you can still use it for development or testing if you apply proper security groups. For production, a custom VPC is recommended.
No, you cannot modify the primary CIDR block of a VPC after creation. However, you can add secondary IPv4 CIDR blocks (up to 5) to an existing VPC, as long as they do not overlap with existing CIDRs. Plan your IP addressing carefully before creating a VPC. If you need a different primary CIDR, you must create a new VPC and migrate resources.
A public subnet has a route table that directs 0.0.0.0/0 traffic to an Internet Gateway (IGW), allowing instances with public IPs to be reachable from the internet. A private subnet does not have a route to IGW; its route table may direct 0.0.0.0/0 to a NAT Gateway for outbound internet, but instances in private subnets do not have public IPs and cannot be directly accessed from the internet. The subnet type is determined solely by its route table.
Only one Internet Gateway can be attached to a VPC at a time. This is a hard limit. If you need more internet connectivity, consider using a NAT Gateway or multiple VPCs with peering. For high availability, you can attach a single IGW and use multiple public subnets across AZs.
Not always. If your private instances only need to communicate within the VPC or with on-premises via VPN/Direct Connect, you do not need a NAT Gateway. However, if they need to access the internet (e.g., to download software updates, access AWS public APIs), you need a NAT Gateway or NAT Instance. Alternatively, you can use a VPC Endpoint for specific AWS services like S3, avoiding the need for internet access.
Yes, VPC Peering supports inter-region peering. You can create a VPC peering connection between VPCs in different regions (e.g., us-east-1 and eu-west-1). Note that data transfer across regions incurs higher charges. Also, security group references across peered VPCs are supported only within the same region; for cross-region, you must use CIDR-based rules.
A Gateway Endpoint is a target for a route in your route table and is used only for S3 and DynamoDB. It is free (no hourly charge) but data transfer costs apply. An Interface Endpoint (powered by AWS PrivateLink) creates an elastic network interface in your subnet with a private IP, and is used for many other AWS services (e.g., SNS, SQS, KMS). Interface Endpoints have hourly charges and data processing fees. Both provide private connectivity without internet.
You cannot directly access an instance in a private subnet from the internet because it has no public IP. Instead, you can use a bastion host (jump box): launch a public EC2 instance in a public subnet, configure its security group to allow SSH from your IP, and then SSH from the bastion to the private instance. Alternatively, use AWS Systems Manager Session Manager, which does not require a public IP or bastion host, and works via the SSM agent and IAM permissions.
You've just covered Amazon VPC — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?