AWS VPC with single and multiple IPv4 CIDR blocks
Building a strong network is crucial for any successful solution, impacting how well it scales and performs in the future. Therefore, when designing a solution in AWS, it’s crucial to understand how to effectively create and manage the network where resources will be deployed. One of the fundamental services to master for this purpose is Amazon Virtual Private Cloud (VPC), which allows you create isolated networks with full control over the virtual networking environment.
This article is the first in a two-part series designed to provide an in-depth understanding of VPC components and how to tailor them to meet your specific needs in AWS. The series will cover:
- VPC with single and multiple IPv4 CIDR blocks
- Dual-stack VPC
In this first article, we will focus on detailing the components of an IPv4 VPC with a single CIDR block. We will also explore the implications and adjustments required when extending an IPv4 VPC to include multiple CIDR blocks, ensuring you have the knowledge to manage and scale your network effectively within AWS.
Creating a VPC with a Single IPv4 CIDR Block
AWS VPC (Amazon Virtual Private Cloud) is a service that enables the creation of private and isolated networks within AWS in order to launch and manage your resources. Think of it as your private apartment within a larger building: you have your own space, and you control what happens inside, ensuring no one can access it without your authorization.
VPC Design Considerations
When designing a VPC, several decisions need to be made according to the solution’s requirements. You must decide on the region where the VPC will be created, the size of the VPC, how it will be segmented, the distribution of resources within the network, and how these resources will interact both within the VPC and with external networks. Once these decisions are made, the next step is to implement them within the VPC service.
VPC region
A VPC is a regional resource, meaning it belongs to a specific AWS region and spans all its availability zones. Choosing the right region is crucial for reducing latency, ensuring compliance with regional data residency laws, optimizing costs, and guaranteeing the availability of required AWS services and features.
VPC size
When designing your VPC, consider the number of IP addresses you’ll need, potential connections with on-premises networks or other VPCs, and future scalability. This helps you choose the correct CIDR block (Classless Inter-Domain Routing) for your VPC.
In AWS, it is mandatory to specify an IPv4 CIDR block for the VPC, with a size between a /16 netmask and a /28 netmask.
VPC Subnets
Subnets in AWS VPC are used to divide a VPC into multiple logical networks, giving you full control over their size, location, and access. Subnets are zonal resources, meaning you choose in which Availability Zone (AZ) within your VPC you want to create each subnet. You also define the size of each subnet by specifying a range of IP addresses (CIDR block) from the VPC’s CIDR block range. You should consider that there are five reserved IP addresses in each subnet (the first four and the last one of each subnet CIDR block). You can create multiple subnets within your VPC, as long as their CIDR blocks do not overlap.
Subnets enable you to place your resources strategically within a VPC and manage access control based on your architectural needs. Resources with different access requirements should be placed in different subnets. For example, resources that need to be reachable from the internet, such as web servers, should be placed in public subnets, which have access to the internet. In contrast, resources that need to be secured, such as databases, should be placed in private subnets, which do not have direct internet access.
VPC Gateways
To configure public or private subnets within a VPC, specific gateway components must be set up correctly to ensure resource access aligns with your solution’s requirements.
Internet Gateway
An Internet Gateway is a horizontally scaled, redundant, and highly available VPC component that makes your resources reachable from the internet and enable them to initiate communication with the internet. You only need one Internet Gateway attached to your VPC.
NAT gateway
A NAT (Network Address Translation) gateway allows instances in a private subnet to initiate outbound IPv4 traffic to the internet while preventing inbound traffic initiated by the internet. Alternatively, a NAT instance can be used, which is a less expensive solution but you need to manage the instance yourself.
VPC route tables
VPC route tables define how traffic flows within a VPC and between the VPC and external networks. They contain a set of rules, known as routes. A route consists of a destination and a target. The destination is the IP range that the traffic is being sent to, and the target is the network interface or gateway through which the traffic is sent. When a source tries to reach a destination, it looks up the route table and routes the traffic to the target based on the configured routes. This process ensures that traffic is correctly directed within the VPC and to external networks.
Main Route Table
A main route table is automatically created when you create a VPC. It includes a local route, allowing traffic to flow between subnets within the VPC. By default, when you create a new subnet, it is implicitly associated with this main route table. The main route table cannot be deleted, but it can be customized by adding or removing routes.
Custom Route Tables
You can create custom route tables and associate them with specific subnets, overriding the default association with the main route table.
Public Subnet
When resources in a subnet need to be reachable from the Internet, they must be placed in a public subnet. By default, newly created subnets are private, so certain configurations at the VPC, subnet, and resource levels are required to make a subnet public and its resources accessible from the Internet.
You have to attach an Internet Gateway to the VPC to have a gateway to the Internet. Then, update the route table associated with the subnet by adding a route that directs traffic destined for the Internet to the Internet Gateway. Specifically, the route destination should be 0.0.0.0/0, which represents all Internet traffic, and the target should be the Internet Gateway ID.
With these configurations, the subnet is considered a public subnet. However, this does not automatically make all resources public. Each resource that needs to communicate with the Internet must have a public IP address or elastic IP address.
Elastic IP address
Public IP addresses assigned to your resources by AWS are temporary and not tied to your account. They are returned to the AWS pool when no longer in use. If you need a static public IPv4 address, you should use an Elastic IP (EIP) which remains associated with your account until you explicitly release it. This ensures continuity even if instances are stopped and restarted or fail.
Private subnet
Resources in a private subnet have private IP addresses and can communicate with other resources within the same VPC but cannot directly access the Internet or receive inbound traffic from the Internet. However, private resources may need to reach the Internet for tasks such as downloading software, accessing container images, or accessing public AWS services.
In this case, you need to create a NAT Gateway in a public subnet and assign it an elastic IP. Then, update the private subnet route table by adding a route to the NAT Gateway for traffic going to the internet.
Note: NAT Gateways are deployed in a specific subnet and provide redundancy at the Availability Zone level. For high availability, you should create NAT Gateways in each Availability Zone used by your VPC.
A picture is worth a thousand words 😉
VPC traffic control
While the configurations we’ve covered make communication possible, it is not permitted by default until explicitly allowed at both the subnet and instance levels.
Security groups (SG) and Network Access Control Lists (NACLs) are two security layers in a VPC that act as virtual firewalls to protect your network.
NACL
A NACL allows or denies specific inbound or outbound traffic at the subnet level using defined rules. NACL rules are evaluated when traffic enters or leaves the subnet, applying control to all resources within the associated subnet.
Each subnet in your VPC must be associated with a single NACL. You can associate a NACL with multiple subnets. If you don’t explicitly associate a subnet with a NACL, it is automatically associated with the default NACL created by default in each VPC. The default NACL is configured to allow all traffic to flow in and out of the subnets with which it is associated.
In a NACL rule, you specify the rule number, the type of traffic, the protocol, the source or destination of the traffic, and whether to allow or deny the specified traffic. Each rule has a number from 1 to 32766. The rules are evaluated in order, starting with the lowest numbered rule. If the traffic matches a rule, the rule is applied regardless of any higher-numbered rule that might contradict it. NACL rules only allow CIDR blocks as a source or destination.
NACLs are stateless, meaning that when traffic is allowed in one direction (inbound or outbound), responses to that traffic are not automatically allowed. Therefore, you must define your NACL rules carefully to ensure that legitimate traffic can both enter and leave the subnet as required.
Security Groups (SGs)
Security Groups operate at the instance level, managing both inbound and outbound traffic through defined rules. These rules specify the protocol, port or port range, and the source or destination of the traffic. The protocol can be common ones like SSH, HTTP, or HTTPS, or custom protocols. The source or destination can be an IPv4 address, CIDR block, security group, or a prefix list. A specific IPv4 address is given with the /32 prefix. Specifying a security group as the source allows instances associated with this SG to communicate with your instance using the defined protocol and port.
SGs are stateful, meaning if traffic is allowed in one direction (inbound or outbound), the response traffic is automatically allowed. Each security group can be linked to multiple instances in a VPC, and each instance must be associated with at least one security group. The rules from all associated security groups are aggregated to determine access.
Note:
Security Groups are technically associated with Elastic Network Interfaces (ENIs), so they can be applied not only to EC2 instances but also to other resources such as RDS instances and Application Load Balancers (ALBs).
Expanding VPCs with Multiple CIDR Blocks
In the first part of this article, we discussed the basics of creating a VPC with a single IPv4 CIDR block. As your network grows, you may need to scale your VPC to accommodate more resources. One way to achieve this is by adding additional CIDR blocks to your VPC. This section provides an overview of VPC with multiple CIDR blocks and outlines the changes compared to a VPC with only one IPv4 CIDR block.
Adding Secondary CIDR Blocks
A VPC must have an associated IPv4 CIDR block, which cannot be decreased or increased once set. However, to accommodate growth and scalability, you can optionally associate additional IPv4 CIDR blocks.
By default, your VPC can have up to five IPv4 CIDR blocks: one primary and four secondary blocks. The CIDR blocks must not overlap with any existing CIDR block associated with the VPC. There are specific restrictions on choosing secondary CIDR blocks based on your primary CIDR block.
Secondary CIDR blocks can be removed after deleting all resources and subnets associated with them. However, this is not possible for the primary CIDR block, which remains a permanent part of the VPC configuration.
Route table changes
Upon associating a secondary CIDR block with your VPC, a new local route is automatically added to all VPC route tables. This route has the destination set to the newly added CIDR block, enabling internal routing within the VPC.
Subnets
You can create subnets from any of the VPC’s CIDR blocks, whether they are primary or secondary. The process for configuring public and private subnets remains unchanged compared to the configuration in a VPC with a single IPv4 CIDR block. Subnets created from different CIDR blocks can communicate with each other within the same VPC if permitted by the NACL and SG configurations.
VPC Traffic Control
With the addition of new CIDR blocks, it’s crucial to revisit your VPC’s traffic control settings. Review and update SGs to ensure they allow communication between resources from different CIDR blocks. Similarly, adjust NACLs to permit or deny traffic between subnets from different CIDR blocks as required.
AWSharing: Together, We Keep Growing! ❤️💪🚀
