The VPC allows us to launch AWS resources into a virtual network that we can define ourselves. It is intended to closely resemble the networking of a private data centre.
Pre-requisites
Before getting into VPCs, it is better if you know the following concepts well:
Knowledge of navigating through the AWS Console
CIDR
As per the CIDR notification, we can specify an IP address range:
Base IP / Subnet mask
The base IP indicates the IPs contained in the range and the subnet mask indicates how many IPs can be present in the range.
The subnet mask basically indicates how many bits of the specified IP can be varied and all these variations shall be part of the IP range that the CIDR notification specifies.
For e.g., 192.168.0.0/31 -> This means that only 1 bit can change. Thus, the IP range specified by this will be 192.168.0.0 and 192.168.0.1. From the tool https://www.ipaddressguide.com/cidr:
Similarly, if we specify 192.168.0.0/16, the range is between 192.168.0.0 to 192.168.255.255
The way to see this is, higher the subnet mask number, the lesser number of IPs that are present in the specified IP range. Thus, if an IP address has /32 at the end, it is just that IP that is part of the range and no other. Similarly, a common use case is specifying 0.0.0.0/0. This means all possible IPs.
Default VPC
When we create our AWS account, one VPC is created for us, by default, in each of the regions AWS operates. This is called the Default VPC. If you create an EC2 instance from the EC2 dashboard directly, without creating any VPC beforehand, you will have one default VPC to launch the instance into.
You can go to the AWS console and search for VPC. You will be presented with a dashboard indicating the VPC and associated resources that you have in that specific region.
Click on “Your VPCs” on the left side and you will see the default VPC here. It also specifies the CIDR range as 172.31.0.0/16. This means that the default VPC has an IP address range between 172.31.0.0 and 172.31.255.255 (with a count of 65536 IP addresses).
Next, click on the “Subnets” on the left menu. Here, based on the region, you will see a few subnets existing and each having their own CIDR range as well.
In the default VPC I have in the Virginia region, I see this:
Virginia region has 6 AZs and thus, we see 6 subnets here, each corresponding to a separate AZ. The CIDR range indicates the IP address range of each of these subnets. You can also see that the addresses don’t overlap. The available IP count indicates how many IP addresses are now available for me, if I want to launch some instances into these subnets.
Reserved IPs
One thing to note here is that the total available IPs is 5 less than what the CIDR range indicates. These 5 are reserved by AWS for some specific purposes and hence not available for us. These IPs are usually the first 4 IPs of the chosen CIDR range and the last IP in the CIDR range.
I have one EC2 running in the US East 1A and thus, the available addresses are one less than those in the other subnets.
VPC overview
We can have up to 5 VPCs per region. This is a soft limit and can be increased by raising a support ticket and specifying our need for more.
We can have CIDR range for the VPC, with the minimum size being /28 (16 addresses) to the maximum size being /16 (65535 addresses). Please ensure that the IP addresses in the specified range don’t over lap with any other networks that you use (especially corporate networks) if you wish to connect to the VPC from the same network directly.
VPC CIDR range
/28 to /16 in the Private address range (192.168.0.0 – 192.168.255.255, 172.16.0.0 – 172.31.255.255 and 10.0.0.0 – 10.255.255.255)
Navigate to the “Your VPCs” menu and click on Create VPC. Here, specify some name for your VPC and select a CIDR range as discussed.
Once done, click on the Create button. This creates the “MyVPC” VPC for us. You can go to the “Your VPCs” section and see that this VPC is listed along with the default one. This will have some other AWS services created with it by default. We shall investigate these later.
Subnets
A subnet is a range of IP addresses in your VPC. While a VPC spans across the entire region, a subnet is limited to a single AZ. We shall launch the AWS resources into an individual subnet or a group of subnets.
Subnets can be public or private. This means, if the subnet is a public one, the resources that reside within it can access the internet. A private subnet is one where the resources cannot reach the internet. Private subnets are a better option to have instances like DB instances, etc., running so that any third party cannot directly reach these resources. Instead, we can have appropriate resources on the public subnet who can talk to the private subnet.
Subnets can be created from by selecting the “Subnets” menu on the left and then clicking on the Create Subnet button at the top. Enter a name, choose a VPC and select an appropriate CIDR range. The selected CIDR range should be such that all the IPs in the CIDR range of the subnet should fall within the CIDR range of the VPC. Also, when creating multiple subnets in the VPC, please ensure that the CIDR ranges of the subnets don’t overlap. AWS anyway doesn’t allow us to create subnets with overlapping CIDR ranges in the same VPC.
If the CIDR range of the VPC is 10.0.0.0/16, then it contains IPs from 10.0.0.0 to 10.0.255.255. Thus, we should choose the subnet CIDR ranges to fall within this. One simple way of doing this is to choose 10.0.0.0/24 (10.0.0.0 to 10.0.0.255), 10.0.1.0/24 (10.0.1.0 to 10.0.1.255), 10.0.2.0/24 (10.0.2.0 to 10.0.2.255) and so on. This ensures distinct IP ranges in each of the subnets.
You can select a preferred AZ from the drop down and click on Create to create the subnet. We can choose to create all of our subnets in the same AZ or have them spread across the available AZs. If we are deploying something that requires high availability, then it would be better to have the resources spread across different AZs. If we have our public facing EC2 instance in a AZ and have a private DB instance that it needs to connect to, it would be better in terms of performance to have both these in the same AZ.
Public subnets can have a smaller IP range when compared to the private subnets. It is customary to have most of our resources not connect to the internet directly. Hence, a larger IP range for the private subnet makes sense.
As seen earlier, the available IPs in the selected CIDR range is 5 less that what it should be.
While planning on creating the subnets, keep in mind to select a larger CIDR range that what is absolutely required since you will not have access to 5 IPs in this range.
Post the creation of the subnet, we can select the subnet and modify the settings to auto assign IP addresses to the resources launched into this.
So far, other than naming our subnets as public or private subnets, we have not done anything that makes them actually public or private. If any EC2 instance is spawned in the public subnet, has an appropriate Security group and has a public IP assigned, we shall still not be allowed to connect to it from the outside world. This is because the subnet needs something called an Internet Gateway to allow connections into and out of the subnet.
An internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in your VPC and the internet.
An internet gateway has two purposes: it provides a target in your VPC route tables for internet-routable traffic and it performs network address translation (NAT) for instances that have been assigned public IPv4 addresses.
Each VPC can have only one IGW and each IGW can only be associated with one VPC. In addition, the IGW is created separately from the VPC and can thus be detached from one VPC and attached to another.
IGWs can be created from the “Internet Gateway” menu in the VPC screen. Creating an IGW is as simple as just specifying its name and clicking on “Create”.
Once the IGW has been created, we can simply attach it to any VPC that currently does not have an IGW attached to it.
Again, this doesn’t allow our EC2 instance in our public subnet in our VPC to connect to the internet. The next step in this process is to add a route from the public subnet to the IGW.
A route table contains a set of rules, called routes, that are used to determine where network traffic is directed.
Each subnet shall have a route table. This table controls the routing for the subnet. Each subnet can have only one route table but multiple subnets can make use of the same route table.
Essentially, a route table shall route the traffic as per its configuration.
We can create a new route table from the VPC service’s left side menu.
Choose a name, choose the VPC and create the Route table. Next, we have to associate this with our public subnet.
Select the newly created Route table and edit the subnet associations:
Choose all the public subnets you want to add routes to the internet and click on Save
Now, these subnets have a route table associated with them. The next step is to configure the Route table to allow traffic from within these subnets to reach the internet. This can be achieved by adding a route to the IGW that we previously created.
What we are saying here is, if the destination IP is in the CIDR Range 10.0.0.0/16, route it locally within the VPC. If the IP range is not in this range, route it to the IGW. This way, we ensure that resources residing on our VPC can communicate with each other without using the public internet. At the same time, if a resource (residing on our public subnet) wants to talk to the outside world, it is allowed to do so now via the IGW.
The subnets are by default associated with a Route table called the Main route table. We can edit the subnet to Route table association either from the Route table settings or from the subnet settings.
So, at this point, any EC2 instances (with public IPs) that are launched into either of the two public subnets here shall have access to the internet.
It is good that we have a clear separation of which subnets can allow the access to the internet and which cannot. This way, we can keep our DB servers, our worker nodes, etc. hidden from the internet. One issue, though, is that these servers also need access to the internet. Assume that you are running a SQL Server on one of the EC2 instances running in a private subnet. There is a critical update that has been released and you would like to update the software on your private subnet. This is not possible now since there is no route between the EC2 instance on the private subnet to the internet. This is where AWS offers two solutions: The NAT instance and the NAT gateway.
If the status of a route in the routing table is shown as Blackhole, this means that the associated route has been deleted or is invalid. This can happen if you created a route to something like a NAT gateway or a NAT instance and then later delete that gateway or instance. It basically means that this route is now invalid.
NAT (Network Address Translation) instances are EC2 instances that can be configured to forward traffic from an instance on a private subnet to the internet (via the IGW). AWS provides a few community AMIs that can act as NAT instances. These are to be launched into the public subnet. Since they are on the same VPC, the EC2 instances on the private subnet can talk to the NAT instance. The NAT instance can in turn help the EC2 instances on the private subnet to reach the internet.
Some essentials of the NAT instances:
Must be launched into a public subnet (one that has a route table that routes to an IGW)
Must have an Elastic IP associated with it
The route table associated with the private subnet should have a rule to route the non-local traffic to the NAT instance
The NAT instance specifies a high port number for the response; if a response comes back, the NAT instance sends it to an instance in the private subnet based on the port number for the response.
Launching a NAT instance is similar to create an EC2 instance. We have to select an appropriate community AMI for NAT instance. Along with this, we have to have a slightly different security group for this instance since we want to only allow HTTP and HTTPS traffic from within the VPC (thus, we should specify the VPC CIDR range for the HTTP and HTTPS protocols in the NAT instance’s Security group).
Additionally, if there are other protocols that need internet access, add those to this list as well. For e.g., we can add All ICMP – Ipv4 to allow our instances to ping web servers.
Once the NAT instance is running, please go disable the Source / Destination check. As per the AWS documentation:
Each EC2 instance performs source/destination checks by default. This means that the instance must be the source or destination of any traffic it sends or receives. However, a NAT instance must be able to send and receive traffic when the source or destination is not itself. Therefore, you must disable source/destination checks on the NAT instance.
Next, we need to update the route table associated with the Private subnets. We do this by adding a route that routes all traffic, other than the one going to the VPC CIDR range, to the NAT instance:
Where we choose IGW in the public subnet, choose “instance” here and the list of available instances will be displayed. Choose the NAT instance from here.
Disadvantages of using NAT Instances
There are disadvantages to using NAT instances. For e.g., it is not Highly Available on it’s own and we would need to create more of these to achieve this. Also, the performance of the NAT instance depends on the type of EC2 instance we have chosen. There are several overheads and hence, NAT instances are no longer the preferred method to allow the EC2 instances on the private subnets to access the internet. For that, the recommended service is the NAT Gateway
NAT Gateway
The NAT Gateway is a managed service that allows the instances on a private subnet to talk to the internet. The difference here is that we are charged for the NAT Gateway as a service (instead of the charges for the NAT instance’s underlying EC2 instance type). Also, NAT Gateway is highly available and can scale up bandwidth upto 45Gbps. We don’t have to specify the Security groups here. For a detailed comparison of the NAT Gateway and the NAT instance, see: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html
NAT Gateways are created in public subnets with Elastic IPs associated with them. Creating one is a simple process from the VPC menu. Each NAT Gateway is created with redundancy in the specified AZ. A good practice is to have one NAT Gateway per AZ and associate the resources in that AZ to talk to that NAT Gateway.
Once a NAT Gateway is created with a specific Elastic IP, we cannot change this IP. Deleting the NAT Gateway doesn’t automatically release the EIP. Hence, care to be taken to delete it manually if will not be used elsewhere.
We cannot secure the NAT gateways with security groups. We have to apply NACLs (see below) to control the traffic to the subnet.
Once we create the NAT Gateway, we have to change the routing table in the private subnet to point all traffic, other than the one in the CIDR range, to the NAT Gateway. Similar to how we routed this to the NAT instance earlier, adding the NAT Gateway as the destination for 0.0.0.0/0 can be done by choose “NAT Gateway” in the dropdown while editing the routes.
NACLs and Security Groups
NACLs and Security Groups together form a protective shield around the EC2 instances in the VPC. NACLs are like firewalls that control traffic in and out of the subnets. Security Groups operate similarly but an instance level.
NACLs are stateless. This means that both inbound and outbound traffic has to be explicitly allowed. Security Groups, on the other hand, are stateful. If an inbound rule allows certain traffic, the same traffic shall be allowed outwards as well and vice versa.
Each VPC comes with a default NACL that allows all traffic in and out of the VPC. We can create a custom NACL and associate it with a subnet. By default, this will deny all inbound and outbound traffic for the associated subnet. We need to modify this to allow and / or deny specific traffic destinations.
Each subnet can have only one NACL but each NACL can be associated with multiple subnets.
NACL rules can be numbered (up to 32766). Rules with a larger number take a lower precedence. Thus, if you have rule 100 to allow some traffic and rule 200 to deny the same, rule 100 wins and the traffic will be allowed. AWS recommends we add rules in increments of 10s or 100s so that we can space to add more rules in between, later, if required.
A NACL comprises of:
A Rule number
Type (indicates the type of traffic like SSH, etc.)
Protocol -> E.g., http, ICMP, etc.
Port range ->Port or port range for traffic
Source -> For inbound rules, specifies the source of the traffic for which this rule is applicable
Destination -> For outbound rules, specifies the destination for the traffic for which this rule is applicable
Allow / Deny -> Allow or deny operation to be performed for the traffic that matches the above parameters
The same set of parameters are available for both the inbound and the outbound rules (except where Source and Destination fields changes)
The following is the default NACL:
A * is added as the last rule and this applies to everything that the previous rules don’t explicitly consider. This rule denies all traffic that is not explicitly allowed.
NACLs provide us with a granular level of traffic control. We can even deny a single specific IP address from accessing our subnet. Assume that you are getting a lot of traffic from one specific IP and want to stop that. You can add an explicit deny for this IP and it will stop all the traffic from that IP from reaching your subnet and instances in it.
Some basic differences between SGs and NACLs:
SGs operate at instance level, NACLs at subnet level
SGs support allow rules only, NACLs support both allow and deny rules
SGs are stateful, NACLs are stateless
SGs process all the available rules to determine if some traffic is to be allowed, NACLs pick the rule with the highest precedence that matches the traffic
An ephemeral port is a short-lived transport protocol port for Internet Protocol (IP) communications. A client initiating the request chooses an Ephemeral port range (based on the OS). Since it is difficult to select the ports based on all possible client OSes, in practice, port ranges 1024-65535 can be kept open and if any ports are known to be malicious, they can be explicitly denied (with a higher precedence rule).
VPC Peering
VPC peering is a process of connecting two VPCs to each other and make them behave like they are in the same network. For this, we have to ensure that there are no overlapping CIDR ranges between the VPCs. Also, VPC peering is not transitive. This means that, if VPC A is peered with VPC B and VPC B is also peered with VPC C, VPC A and VPC C are not peered by default.
For VPC peering to work, each of the route tables in each of the subnets need to be updated appropriately.
VPC peering can be achieved between VPCs of different accounts and even between VPCs in different regions.
VPC peering can be created from the VPC section’s “Peering Connections” menu option. Specify a name, choose the VPC who is requesting the connection, choose the destination VPC with whom you want to peer and create the peering connection. This will create a connection.
This creates a peering request. The accepting VPC account has to accept this request for the peering to be established.
The next step is to modify the route tables to allow the traffic from the subnets in one VPC to the subnets in the other VPC. To do this, in each of the route tables, specify the CIDR range of the other VPC and choose “Peering Connection” in the drop down. This shall list the created peering connection. Select it and save the routes
This has to be done for all the route tables in both the VPCs to enable them to communicate to all the other subnets in either VPCs.
Similar task is to be performed if you want to peer a VPC to yet another VPC.
I will add more details on VPCs and related technologies soon. I hope you found this info useful.
Comments