How Does Amazon VPC Relate to Amazon EC2 Networking?
An Amazon Virtual Private Cloud provides the foundational, isolated virtual network environment in which Amazon Elastic Compute Cloud instances operate. Every EC2 instance launches into a designated VPC subnet, inheriting its IP addressing scheme, routing rules, and security boundaries directly from the VPC configuration. Without a VPC, an EC2 instance has no network layer to communicate with other AWS resources, on-premises systems, or the public internet.
The Core Architectural Relationship
Amazon VPC acts as the software-defined data center network, while Amazon EC2 instances act as the virtual servers plugged into that network. When you provision an EC2 instance, it does not possess standalone networking capabilities. Instead, it attaches to the VPC through one or more virtual network cards called Elastic Network Interfaces (ENIs).
This relationship governs several critical aspects of instance connectivity:
- IP Addressing: The VPC defines a Classless Inter-Domain Routing (CIDR) block, which is subdivided into smaller subnets. An EC2 instance receives its private IPv4 and optional IPv6 addresses from the specific subnet in which it resides.
- Traffic Routing: Instances rely on subnet route tables to determine where network packets are sent, whether to another instance in the same VPC, across a VPN connection, or out to the internet.
- Network Isolation: By default, resources in one VPC cannot communicate with resources in another VPC unless explicitly connected via VPC Peering or AWS Transit Gateway.
Subnets and IP Address Allocation
A VPC spans an entire AWS Region, whereas subnets are bound to specific Availability Zones (AZs). When launching an EC2 instance, selecting a subnet simultaneously determines both the physical Availability Zone hosting the instance and the pool of IP addresses available to it.
For a subnet with a prefix length of \(n\), the total number of theoretical IPv4 addresses is calculated as:
\[\text{Total IPs} = 2^{32 - n}\]
However, AWS reserves 5 IP addresses in every subnet CIDR block for internal networking functions (network address, VPC router, DNS mapping, future use, and broadcast address). Therefore, the number of usable private IP addresses available for EC2 Elastic Network Interfaces in a subnet is:
\[\text{Usable IPs} = 2^{32 - n} - 5\]
Depending on how the subnet's route table is configured, an EC2 instance experiences one of two networking environments:
- Public Subnet Environment: The subnet route table includes a direct route (\(0.0.0.0/0\)) to an Internet Gateway (IGW). If the EC2 instance is assigned a public IPv4 address or an Elastic IP address, it can send and receive traffic directly over the internet.
- Private Subnet Environment: The subnet route table lacks a direct route to an Internet Gateway. EC2 instances placed here cannot be reached directly from the internet. To initiate outbound internet connections (such as downloading software patches), traffic must be routed through a Network Address Translation (NAT) Gateway or NAT instance located in a public subnet.
Elastic Network Interfaces as the Bridge
The physical link between the VPC and the EC2 instance is abstracted
as an Elastic Network Interface (ENI). Every instance has a primary ENI
(eth0) that cannot be detached from the instance.
An ENI encapsulates the network attributes allocated by the VPC:
- A primary private IPv4 address from the subnet's IPv4 CIDR range
- One or more secondary private IPv4 addresses
- One Elastic IP or public IPv4 address per private IPv4 address
- One or more IPv6 addresses
- One or more Security Groups
- A MAC address
- A source/destination check flag
Because additional secondary ENIs can be created within a subnet and attached to or moved between EC2 instances, network identities and configurations remain decoupled from the underlying compute lifecycle. If an EC2 instance fails, a secondary ENI can be detached and reattached to a standby instance in the same Availability Zone to rapidly reroute traffic.
Layered Network Security
The relationship between a VPC and an EC2 instance uses a defense-in-depth model divided into two distinct firewall layers:
Network Access Control Lists (NACLs)
NACLs operate at the subnet level within the VPC. They act as a stateless perimeter firewall inspecting traffic entering and leaving the subnet before it ever reaches the EC2 instance. Because NACLs are stateless, both inbound and outbound rules must be explicitly defined to allow return traffic, and rules are evaluated in numerical order.
Security Groups
Security Groups operate at the instance (ENI) level. Even though Security Groups are created and scoped within a specific VPC, they are attached directly to the ENIs of an EC2 instance. Unlike NACLs, Security Groups are stateful: if an inbound request is permitted to reach the EC2 instance, the outbound response is automatically allowed regardless of outbound rules. Security Groups only support allow rules and evaluate all rules simultaneously before deciding whether to permit traffic.
DNS Resolution and Internal Communication
Beyond packet routing and security filtering, the VPC controls how EC2 instances resolve domain names. Each VPC has two core attributes that dictate the DNS behavior of its hosted instances:
enableDnsSupport: Determines whether the Amazon Route 53 Resolver server (located at the VPC base CIDR plus two) resolves public DNS hostnames to IP addresses for instances inside the VPC.enableDnsHostnames: Determines whether EC2 instances launched in the VPC receive public DNS hostnames corresponding to their public IP addresses.
When two EC2 instances communicate using their private IP addresses
within the same VPC, traffic stays entirely on the AWS private network
backbone, regardless of whether they are in the same subnet or across
different Availability Zones. The VPC's implicit router handles this
local traffic automatically via the default local route
present in every VPC route table.