AWS Core Services: VPC Fundamentals

Amazon Virtual Private Cloud (VPC) serves as the fundamental building block for networking in AWS, enabling organisations to create isolated virtual networks within the cloud^[1]. Think of a VPC as your own private data centre within AWS, where you maintain complete control over network configuration, IP addressing, routing, and security^[2]. This logical isolation ensures your cloud resources remain secure and accessible only to authorised users, much like how physical walls protect a traditional data centre.

Understanding VPC Architecture

A VPC represents a logically isolated section of the AWS cloud where you can launch resources in a virtual network that you define. When you create a VPC, you must specify an IPv4 CIDR (Classless Inter-Domain Routing) block, which determines the range of IP addresses available for your resources. The allowed block size ranges from /16 (providing 65,536 IP addresses) to /28 (providing 16 IP addresses)^[3].

For example, if you specify 10.0.0.0/16 as your VPC CIDR block, you’re allocating addresses from 10.0.0.0 to 10.0.255.255. AWS recommends using private IPv4 address ranges as specified in RFC 1918, which include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16^[4]. These ranges ensure your internal network traffic remains private and doesn’t conflict with public internet addresses.

Subnets: Dividing Your Network

Subnets represent subdivisions of your VPC’s IP address range and must reside within a single Availability Zone^[5]. This arrangement allows you to organise resources based on security requirements and availability needs. Subnets come in two types: public and private. A public subnet contains resources that need internet access and has a route table pointing to an Internet Gateway^[6]. Private subnets, conversely, house internal resources like databases that shouldn’t be directly accessible from the internet.

Consider a web application architecture where you place web servers in public subnets across multiple Availability Zones for high availability, whilst database servers reside in private subnets for enhanced security. This separation ensures that even if the public-facing layer is compromised, your sensitive data remains protected behind additional security boundaries.

Connectivity Components

Internet Gateway and NAT Gateway

An Internet Gateway (IGW) enables communication between resources in your VPC and the internet. It performs one-to-one Network Address Translation (NAT) for instances with public IP addresses, mapping private IP addresses to public ones as traffic flows to the internet^[7]. Importantly, EC2 instances remain unaware of their public IP addresses; they only know their private addresses within the VPC.

NAT Gateways serve a different purpose. They allow instances in private subnets to initiate outbound connections to the internet whilst preventing unsolicited inbound connections. For instance, a database server in a private subnet might need to download software updates. A NAT Gateway enables this whilst ensuring the server remains inaccessible from the internet. When creating a public NAT Gateway, you must place it in a public subnet and associate it with an Elastic IP address^[8].

Route Tables

Route tables contain rules that determine where network traffic is directed^[9]. Each subnet must be associated with a route table, which can be either the main route table (created automatically with the VPC) or a custom route table you create. Routes consist of a destination CIDR block and a target. For example, a route with destination 0.0.0.0/0 and target pointing to an Internet Gateway directs all internet-bound traffic through that gateway.

Every VPC automatically includes a local route enabling communication between all resources within the VPC^[10]. You cannot modify or delete this local route. When multiple routes could apply to the same traffic, AWS uses the most specific route (longest prefix match) to determine the path^[9].

Security Layers

Security Groups

Security groups act as virtual firewalls at the instance level, controlling inbound and outbound traffic^[11]. They operate in a stateful manner, meaning if you allow inbound traffic on port 80, the return traffic is automatically permitted regardless of outbound rules^[12]. This behaviour simplifies rule management for bidirectional communication.

By default, security groups deny all inbound traffic and allow all outbound traffic. You can only create allow rules; deny rules aren’t supported. Each VPC can have up to 500 security groups, with each security group supporting up to 60 inbound and 60 outbound rules^[13]. A single instance can be associated with multiple security groups, providing flexible, layered security.

Network Access Control Lists

Network Access Control Lists (NACLs) provide an additional security layer at the subnet level^[14]. Unlike security groups, NACLs are stateless, meaning you must explicitly allow both inbound and outbound traffic for each connection^[12]. For example, if you allow inbound HTTP traffic on port 80, you must also create an outbound rule to allow the response traffic.

NACLs contain numbered rules evaluated in ascending order, with the lowest numbered rule taking precedence. Each NACL includes a default deny rule that catches any traffic not explicitly allowed by other rules. The default NACL permits all inbound and outbound traffic, whilst custom NACLs deny all traffic until you add specific allow or deny rules.

The combination of security groups and NACLs creates a defence-in-depth strategy. NACLs serve as the first line of defence at the subnet boundary, whilst security groups provide granular control at the instance level^[15].

Advanced Connectivity

VPC Peering

VPC Peering establishes a direct network connection between two VPCs, enabling resources to communicate using private IP addresses. Peering connections can span different AWS accounts and regions, providing flexibility for multi-account architectures. Traffic between peered VPCs traverses AWS’s private network backbone, ensuring low latency and high bandwidth^[16].

However, VPC Peering doesn’t support transitive routing. If VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot communicate with VPC C through VPC B^[17]. Each peering relationship requires a separate connection. This limitation becomes significant in environments with numerous VPCs requiring interconnection.

Transit Gateway

Transit Gateway simplifies network architecture by acting as a central hub connecting multiple VPCs and on-premises networks^[18]. Rather than creating individual peering connections between every VPC pair, you attach each VPC to the Transit Gateway once^[19]. The hub-and-spoke model supports transitive routing, allowing any connected network to communicate with any other connected network through the gateway.

Transit Gateway particularly benefits organisations managing dozens or hundreds of VPCs. It centralises routing configuration and significantly reduces operational complexity^[20]. The service supports connections to on-premises networks via VPN or AWS Direct Connect, enabling hybrid cloud architectures^[21]. Whilst Transit Gateway incurs additional costs compared to VPC Peering, the simplified management often justifies the expense for complex environments.

Best Practices

When designing your VPC architecture, plan your CIDR blocks carefully to avoid future conflicts. If you’re connecting to on-premises networks, ensure your VPC CIDR doesn’t overlap with existing network ranges^[4]. Use different CIDR blocks across regions to maintain clear network separation.

Implement defence in depth by combining security groups and NACLs. Use security groups for granular, instance-level control and NACLs for broader subnet-level policies^[15]. Enable VPC Flow Logs to capture information about IP traffic, which proves invaluable for troubleshooting and security analysis^[22].

Distribute resources across multiple Availability Zones within subnets to ensure high availability^[5]. This approach protects against zone-level failures. For cost optimisation, carefully consider whether you need a NAT Gateway in each Availability Zone or if a single gateway with cross-zone traffic suffices for your availability requirements.

Amazon VPC provides the foundational networking layer essential for building secure, scalable cloud infrastructure. By understanding its components and thoughtfully architecting your network, you create an environment that supports both current requirements and future growth whilst maintaining robust security and performance.

References