A cloud network architecture is the blueprint that defines how your resources communicate with each other and with the outside world. Understanding VPC fundamentals is the single most important skill for passing the ANS-C01 exam because every advanced networking scenario—hybrid connectivity, multi-region disaster recovery, or high-security workloads—is built on top of these core principles.
Jump to a section
A simple way to picture VPC Fundamentals and Design Principles
A Virtual Private Cloud (VPC) is your own private, fenced-off neighbourhood within a sprawling digital city. You live in a high-rise condo building in that neighbourhood. A VPC is the entire private network space carved out for you inside the massive public cloud provider's data centres, just as your building sits on its own plot of land within the city. The building's perimeter walls and security gate are your VPC's boundaries, stopping random traffic from wandering in. Each apartment in the building is a subnet, a smaller, organised section of your private network.
You have to choose which floor (Availability Zone) your apartment is on, and you must give each apartment a unique number (a CIDR block, which is a range of private IP addresses). The building's lobby with its directory board is the main route table, which holds the rules for how data packets find their way to the correct apartment (subnet). A security guard at the front door is a Network Access Control List (NACL), a stateless firewall that checks IDs on the way in and out. The lock on your individual apartment door is a Security Group, a stateful firewall that only checks IDs when someone first tries to enter, remembering who is allowed to stay. The plumbing and electrical systems are the core network services like DNS and DHCP, which handle essential functions like translating street names to apartment numbers and assigning addresses to devices inside.
The internet connection for the building comes through a single thick cable from the city — this is the Internet Gateway. If the condo wants a private, secure tunnel to another building across town without using the public streets, it installs a private, dedicated phone line — that is a Virtual Private Network (VPN) connection. For a high-speed, direct private link to a specific office building that is owned by the condo's management company, the building digs its own private tunnel — that is AWS Direct Connect.
A VPC, or Virtual Private Cloud, is a logically isolated section of the AWS cloud where you launch your AWS resources. The word virtual means it is software-defined, not a physical piece of hardware you can touch. The word private means only resources and connections you explicitly authorise can interact with that network space. The word cloud means it lives inside Amazon's data centres. Before VPCs existed, if a company wanted its own isolated network, it had to buy routers, switches, and cables and physically wire them together in a room. The VPC replaces all of that physical hardware with software configuration.
Every VPC exists within a single AWS Region (a geographic area like London or Sydney). You cannot create a VPC that spans multiple regions, but you can connect VPCs in different regions. Within a Region, you decide the IP address space for your VPC using a CIDR block. CIDR stands for Classless Inter-Domain Routing, and a CIDR block is a range of IP addresses written in a special format, for example 10.0.0.0/16. The /16 part means this VPC can use 65,536 private IP addresses. You choose this range at creation time, and you cannot change it later. This is a critical design decision.
Inside the VPC, you create subnets. A subnet is a smaller, contiguous segment of the VPC's IP address range. Each subnet lives entirely within one Availability Zone (AZ), which is a physically separate data centre within the Region. By placing subnets in different AZs, you protect your application against the failure of an entire data centre. Subnets are where your resources actually run—things like EC2 instances (virtual servers) and RDS databases. Each subnet has its own route table, a set of rules called routes that determine where network traffic is directed.
Subnets can be public or private. A public subnet has a route to an Internet Gateway (IGW), which is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet. A private subnet does not have a direct route to the internet. Resources in private subnets can still reach the internet for outbound traffic (for example, downloading software updates) using a NAT Gateway or NAT Instance. NAT stands for Network Address Translation, a service that translates the private IP address of your instance into the public IP address of the NAT device and then forwards the traffic.
The main route table is the default table for your VPC. It controls traffic routing for all subnets that you do not explicitly associate with a custom route table. Every subnet must be associated with exactly one route table. You can create custom route tables to isolate traffic between different parts of your network. For example, you might have one route table for public subnets that routes 0.0.0.0/0 (all internet traffic) to an Internet Gateway, and a separate route table for private subnets that routes 0.0.0.0/0 to a NAT Gateway.
Security in a VPC is enforced at two main levels: the subnet perimeter and the instance perimeter. Network Access Control Lists (NACLs) act as a firewall at the subnet boundary. They are stateless, which means if you allow incoming traffic, you must explicitly allow the returning response traffic as well. Security Groups act as a virtual firewall at the instance level. They are stateful, so if you allow incoming traffic, the response is automatically allowed, no matter what the outbound rules say. Security Groups support only allow rules; you cannot write a deny rule. NACLs support both allow and deny rules and are evaluated in numbered order.
VPCs include several optional connectivity features. A Virtual Private Network (VPN) connection allows you to connect your on-premises network (your company's physical office network) to your VPC over the public internet in an encrypted tunnel. AWS Direct Connect provides a dedicated, private, high-bandwidth connection from your on-premises data centre to AWS, bypassing the public internet entirely. VPC Peering connects two VPCs directly using private IP addresses, as if they were part of the same network. A Transit Gateway acts as a central hub to connect multiple VPCs and on-premises networks, simplifying a complex mesh of connections into a star topology.
Finally, VPC Endpoints allow you to connect to AWS services (like S3, DynamoDB, or SQS) from within your VPC without going over the internet. Gateway Endpoints are used for S3 and DynamoDB and are added as a route in your route table. Interface Endpoints use Elastic Network Interfaces (ENIs) with private IP addresses and are used for most other AWS services. This design principle—keeping traffic within the AWS network—is a core concept for security and compliance.
Plan the IP Address Space
Determine the total number of instances and services you will run across all subnets. Choose a VPC CIDR block that is large enough for current and future growth, but does not overlap with any existing on-premises network CIDR or other VPCs you want to peer with. Use RFC 1918 private ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. This step is critical because the primary CIDR cannot be changed later.
Create the VPC and Enable DNS Settings
In the AWS Management Console or via API, create a new VPC with your chosen CIDR. Enable DNS hostnames and DNS resolution for the VPC. DNS hostnames allow instances to receive public DNS names if they have a public IP. DNS resolution enables the VPC's internal DNS resolver to translate private IP addresses to private DNS names. Without these, many AWS services (like RDS) will fail to resolve endpoint names.
Create Subnets in Multiple Availability Zones
Divide your VPC CIDR into smaller subnet CIDRs. Create at least two public subnets and two private subnets, each in a different Availability Zone. Assign larger CIDRs to subnets that will host many resources (like application servers) and smaller CIDRs to subnets with few resources (like database servers). Remember that each subnet must be wholly contained within one AZ and cannot span across AZs.
Configure Route Tables and Gateways
Create a custom route table for public subnets and add a route for 0.0.0.0/0 pointing to an Internet Gateway. Create a second custom route table for private subnets and add a route for 0.0.0.0/0 pointing to a NAT Gateway (or NAT Instance) that is placed in a public subnet. Confirm the main route table (which controls default behaviour) is not accidentally associated with your subnets. Verify that each subnet is explicitly associated with the correct route table.
Apply Security Layers: NACLs and Security Groups
Define the default NACL for each subnet to deny all inbound and all outbound traffic, then add specific allow rules for the required protocols and ports. Since NACLs are stateless, remember to add ephemeral port rules for return traffic (e.g., allow inbound TCP 1024-65535 from the private subnet range). Then create Security Groups for each layer of your application (load balancer, web server, database) with inbound rules restricted to the source Security Group of the previous layer, not IP ranges where possible. This creates a secure, layered defence.
Test Connectivity and Enable Monitoring
Launch a test EC2 instance in a public subnet and verify you can SSH into it via the public IP. Launch a test instance in a private subnet and verify it can reach the internet (ping google.com) through the NAT Gateway but that you cannot SSH into it from the internet. Enable VPC Flow Logs on the VPC, send them to CloudWatch Logs, and review the logs for any unexpected denied traffic. This step validates your design before deploying production workloads.
A mid-sized financial services company, SecureFin, is migrating its customer-facing loan application platform from a physical data centre to AWS. The IT director wants a design that is secure, cost-effective, compliant with financial regulations, and able to handle sudden traffic spikes. As a cloud network architect, you are tasked with designing the VPC and subnet structure.
You start by creating the VPC in the eu-west-2 (London) region because SecureFin's primary customers are European. You choose a CIDR block of 10.0.0.0/16. This gives you 65,536 addresses—more than enough for the current 200 servers, with room for ten years of growth. You decide to create six subnets across two Availability Zones (AZ A and AZ B) to provide high availability. In each AZ, you create a public subnet (for the load balancers and NAT gateways), a private web subnet (for the web servers), and a private data subnet (for the databases). The public subnets use CIDR ranges like 10.0.1.0/24 and 10.0.2.0/24. The private web subnets use 10.0.10.0/24 and 10.0.11.0/24. The private data subnets use 10.0.20.0/24 and 10.0.21.0/24.
You configure the main route table to handle the public subnets by adding a route for 0.0.0.0/0 pointing to the Internet Gateway. You create two custom route tables: one for the private web subnets with a route to a NAT Gateway (which itself lives in a public subnet), and one for the private data subnets with no route to the internet at all—those databases must never be reachable from the public internet. You place an Application Load Balancer (ALB) in the public subnets to accept HTTPS traffic from customers and forward it to the web servers in the private web subnets.
For security, you configure Security Groups with the principle of least privilege. The ALB Security Group allows inbound HTTP and HTTPS traffic from 0.0.0.0/0. The web server Security Group allows inbound traffic only from the ALB Security Group. The database Security Group allows inbound traffic on port 3306 (MySQL) only from the web server Security Group. You then configure the NACLs for the data subnets to deny all inbound traffic except from the private web subnet range, and to deny all outbound traffic except to the private web subnet range. This double layer of security—NACL at the subnet level and Security Groups at the instance level—ensures that even if a misconfiguration occurs in one place, the other catches it.
Finally, you set up a Direct Connect connection from SecureFin's existing London office to AWS to allow the internal audit team to access the database for compliance reporting without traversing the internet. You create a VPN connection as a backup in case the Direct Connect link fails. The entire design is documented in a VPC flow log, which captures IP traffic information and is sent to CloudWatch Logs for analysis. When the IT director asks why the design uses two AZs and two security layers, you explain that this is standard practice for production workloads and directly aligns with the AWS Well-Architected Framework.
The ANS-C01 exam tests VPC design principles extensively in domain 1.0 (Network Design) and particularly in task statement 1.1. You can expect at least six to eight questions that require deep understanding of VPC subnetting, routing, and connectivity options. The exam uses scenario-based questions where you are given a business requirement and must choose the correct architectural design from four options, each of which looks plausible but contains one fatal flaw.
The topics they love to test include:
CIDR planning and subnet sizing: You must be able to calculate how many IP addresses a /27 subnet provides (32 total, 29 usable after AWS reserves five) and choose a CIDR range that does not overlap with on-premises networks.
Route table priority: The most specific route in a route table is always preferred. For example, a route to 10.0.1.0/24 will take priority over a route to 10.0.0.0/16, even if the /16 route was added first.
Stateless versus stateful firewalls: Questions will ask whether a NACL or Security Group is appropriate. The trap is often that a NACL is stateless, so you must remember to add ephemeral port rules for return traffic.
Internet Gateway versus NAT Gateway versus NAT Instance: You must know that an Internet Gateway is required for a subnet to be considered public, and that a NAT Gateway is a managed service (no SSH access) whereas a NAT Instance is an EC2 instance you manage yourself.
VPC Endpoints: Gateway Endpoints are free-of-charge and support S3 and DynamoDB only. Interface Endpoints cost an hourly fee and per-GB data processing fee. The exam loves to ask which endpoint type is appropriate for a service like Kinesis or SQS.
VPC Peering versus Transit Gateway: VPC Peering is a one-to-one connection with no transitive routing (you cannot go through VPC A to reach VPC C). Transit Gateway enables transitive routing and supports hundreds of VPCs.
The traps they set include:
Giving you a CIDR range that overlaps with an existing VPC or on-premises network. The correct answer will always avoid overlap.
Offering a VPC peering connection when the requirement is to connect more than 50 VPCs across multiple accounts. The correct answer will be a Transit Gateway with a centralised route table.
Suggesting a public subnet for a database that must not be internet-reachable. The correct answer will be a private subnet with a NAT Gateway for outbound-only patches.
Claiming that Security Groups support deny rules. They do not; only NACLs support explicit deny.
You must memorise the reserved IP addresses in every subnet: the first four and the last one are reserved by AWS. For a subnet 10.0.0.0/24, the addresses 10.0.0.0 (network), 10.0.0.1 (VPC router), 10.0.0.2 (DNS), 10.0.0.3 (future use), and 10.0.0.255 (broadcast) are unusable. The exam will give you a subnet requirement (e.g., "requires 10 usable IPs for EC2 instances") and ask you to choose the smallest subnet size that meets it. Since a /28 gives 16 total minus 5 reserved = 11 usable, that is the correct answer for such a requirement.
A VPC is a logically isolated network within a single AWS region that cannot be changed after creation, so plan your CIDR block carefully.
Every subnet must be associated with exactly one route table, and a subnet is public only if its route table contains a route to an Internet Gateway.
Security Groups are stateful and support only allow rules; NACLs are stateless and support both allow and deny rules, evaluated in numbered order.
AWS reserves the first four IP addresses and the last IP address in every subnet, so a /28 subnet provides only 11 usable IP addresses.
VPC Peering does not support transitive routing—you cannot route from VPC A through a peered VPC B to reach VPC C.
Gateway Endpoints are free-of-charge and support only S3 and DynamoDB; Interface Endpoints incur hourly and data processing costs.
A NAT Gateway is a managed, highly available service; a NAT Instance is an EC2 instance you must configure and patch yourself.
VPC Flow Logs capture metadata about IP traffic and can be sent to CloudWatch Logs, S3, or Kinesis Firehose for analysis.
These come up on the exam all the time. Here's how to tell them apart.
Security Group
Operates at the instance level (virtual firewall for each EC2/RDS resource)
Stateful: if inbound traffic is allowed, the response outbound traffic is automatically allowed
Supports only allow rules; you cannot explicitly deny traffic
Network ACL (NACL)
Operates at the subnet level (firewall for all resources in that subnet)
Stateless: you must explicitly allow both inbound and outbound traffic for each connection
Supports both allow and deny rules, evaluated in numbered order
VPC Peering
One-to-one connection between two VPCs only
No transitive routing: you cannot route through VPC A to reach VPC C
Simple to set up, cost-effective for small numbers of VPCs
Transit Gateway
Hub-and-spoke model connecting many VPCs and on-premises networks
Supports transitive routing: traffic can flow from spoke A through hub to spoke B
Centralised routing management, ideal for large multi-VPC architectures
Internet Gateway (IGW)
Allows resources with public IPs to have direct inbound and outbound internet access
Mandatory for a subnet to be considered public
Do not perform NAT; resources must have their own public IP
NAT Gateway
Allows private subnet resources to initiate outbound internet traffic
Performs NAT: translates private IPs to its own public IP
Cannot initiate inbound internet traffic; only one direction
Gateway Endpoint
Supports only Amazon S3 and DynamoDB
No hourly or data processing charges
Added as a prefix list entry in the route table, not an ENI
Interface Endpoint (AWS PrivateLink)
Supports over 90 AWS services (e.g., Kinesis, SQS, EC2 API)
Incur per-hour charges and per-GB data processing fees
Creates an Elastic Network Interface (ENI) with a private IP in your subnet
Mistake
A subnet that has an Internet Gateway attached is automatically public.
Correct
A subnet is public only if it has a route in its route table to an Internet Gateway. Simply creating an Internet Gateway in the VPC does not make any subnets public; you must explicitly add a route 0.0.0.0/0 -> IGW to the subnet's route table.
Beginners confuse attaching the Internet Gateway to the VPC (a required first step) with actually using it in a route table. AWS documentation says "attach an Internet Gateway to your VPC" first, which sounds like the subnet becomes public, but it is the route that matters.
Mistake
A Security Group is more secure than a Network ACL.
Correct
Security Groups and NACLs are complementary layers of defence, not substitutes. Security Groups operate at the instance level and support only allow rules, while NACLs operate at the subnet level and support both allow and deny rules. A defence-in-depth strategy uses both.
The industry often uses the phrase "firewall" in a general sense, leading beginners to assume one is a subset or an upgrade of the other. Since Security Groups are introduced first in many tutorials, beginners assume they replace NACLs.
Mistake
You can change a VPC's CIDR block after it is created if you made a mistake.
Correct
The primary CIDR block of a VPC is immutable after creation. You can add secondary CIDR blocks to a VPC, but you cannot modify or delete the primary block. If you chose a /16 and realise you needed a /20, you must delete the VPC and recreate it.
AWS allows adding secondary CIDRs, which gives the impression that the primary can be edited. Users misread 'add' as 'edit'. The immutability of the primary block is a key design constraint that many fail to remember.
Mistake
All traffic to the internet from a private subnet must go through a NAT Gateway.
Correct
Traffic from a private subnet to the internet can instead use a VPC endpoint for supported services (like S3 or DynamoDB) or a proxy instance, and it can also use egress-only internet gateways in IPv6 environments. For IPv4, a NAT Gateway or NAT Instance is the standard method, but it is not the only option.
Most AWS tutorials demonstrate the NAT Gateway pattern almost exclusively, leading beginners to believe it is mandatory. They do not encounter VPC endpoints or proxy patterns until later.
Mistake
A VPC spans multiple regions by default because it is 'virtual'.
Correct
A VPC is region-scoped and cannot span multiple regions. It can span multiple Availability Zones within a single region, but to extend the same logical network to another region, you must create a second VPC and use VPC Peering or a VPN between them.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, you cannot modify the primary CIDR block of a VPC after creation. You can add secondary CIDR blocks (up to 5, or more with a limit increase), but the primary block is immutable. Plan your CIDR carefully before creating the VPC.
A public subnet has a route in its route table to an Internet Gateway, allowing resources to have direct inbound and outbound internet access. A private subnet has no such route; its outbound internet traffic uses a NAT Gateway, and it cannot be directly reached from the internet.
AWS reserves five IP addresses: the first address (network address), the second (VPC router), the third (DNS), the fourth (future use), and the last (broadcast). For example, a /24 subnet has 256 total addresses, of which 251 are usable.
Yes, for a defence-in-depth strategy you should use both. Security Groups provide stateful filtering at the instance level, while NACLs provide stateless filtering at the subnet boundary. If one layer is misconfigured, the other can still block unwanted traffic.
Yes, you can use VPC Peering between VPCs in different regions (inter-region VPC Peering). You can also use a Transit Gateway with inter-region peering attachments, or VPN connections. The traffic stays within the AWS global network and does not traverse the public internet.
A NAT Gateway is a fully managed AWS service that automatically scales, is highly available within an Availability Zone, and requires no management. A NAT Instance is a custom EC2 instance that you configure, patch, and manage yourself. NAT Gateways are preferred for production workloads.
Yes, you can create a VPC with no Internet Gateway at all. This is called an isolated VPC. Resources inside such a VPC can only communicate internally and cannot reach the internet or be reached from the internet. This is common for databases or internal services.
You've finished VPC Fundamentals and Design Principles. Continue through the ANS-C01 study guide to build a complete picture of the exam.
Done with this chapter?