AWS VPC (Virtual Private Cloud) provides a networking and security layer for the deployed AWS resources like EC2, RDS, and similar other resources. VPCs form the basis of any cloud architecture. By default, they are isolated from other AWS services or networks. Compared to the real-world networks, AWS VPCs abstract most of the concepts like routers, firewalls, gateways in the form of software. In this post, we will take a look at some of the important concepts related to AWS VPC.
The creation of VPC always happens by assigning an IP CIDR range to it. This is a range of continuous IP addresses, which the VPC uses to allocate IP addresses to the resources placed within that VPC. While assigning a CIDR range, to avoid conflict with public IP addresses CIDR ranges, private IP addresses are used, as per RFC 1918. Once assigned, CIDR range cannot be changed. A VPC is created in a region. One can create multiple VPCs in the same region or multiple regions.
Subnets are logical groups created within VPCs. They are used to isolate resources within a VPC and help control network traffic. It is mandatory to select a subnet while creating an EC2 instance. Subnets are availability zone-specific, they cannot span multiple availability zones in a given region. Thus, if one wants to place resources in multiple availability zones for resiliency, multiple subnets should be created and multiple resources should be deployed in them.
CIDR ranges are also assigned to subnets. It should be made sure that the subnet CIDR range is a subset of VPC’s CIDR range. Assigning CIDR ranges to multiple subnets should be possible and there should be no overlap. Overlapping of IP ranges can cause network issues as there is a chance of allocating the same IP address for multiple devices in a VPC network.
EC2 instance does not have its own network interface, instead, it uses Elastic Network Interface (ENI) to which primary/public IP addresses are assigned. ENIs can exist on their own, independent of EC2 instances. It is possible to create an ENI first and then create an EC2 instance and associate the existing ENI to the newly launched instance.
ENIs are the software version of NICs in AWS. They enable network communication for EC2 instances and provide an interface for the host operating system to manage the same. Whenever an IP address is assigned to an instance in a Subnet, it is being assigned to the ENI associated with that instance.
VPCs, as discussed before, provide an isolated network for AWS resources. However, they can also be connected to other networks, VPCs, and the internet. VPCs make use of Internet Gateways (IGW) to connect to the internet. VPCs do not come bundled with an IGW. IGW can be created independently and associated with VPCs. Every VPC can have only one IGW.
Route tables are a crucial aspect of VPCs as they manage the flow of network traffic, for traffic coming towards VPC (ingress) and for the traffic that is originating from VPC (egress). Based on how route tables are configured, appropriate network access is enabled. Do not misunderstand this as a security measure, however, route tables act more like a network router.
Every VPC has a default route table called the main route table. Subnets within VPCs are associated with the main route table. It is possible to create our route tables and associate them with VPC for use. Route tables enable IP routing within the subnets as well as towards the internet access outside of VPCs.
Route table access rules are defined by configuring routes. To configure a route, 2 key details are needed – Destination and Target. The destination is the destination IP address CIDR range and the target is the AWS network resource. Usually, the targets could be – IGW, ENI, or local. Every route table contains a mandatory default route with Destination as the VPC CIDR range and Target as local. It is this particular route that enables intra-VPC communication within devices.
To enable access to the internet, we can configure a route in which the target can be specified as IGW associated with the VPC. Based on the CIDR range selected in Destination, if the host resides on the internet, this particular route will enable the communication to that instance.
Talking about the security of VPC, there are mainly 2 ways – Security Groups and NACLs. Security groups act as firewalls as they manage permissions for ingress and egress network traffic. Security groups are associated with ENIs, thus the firewall works on the instance level. One security group can be attached to multiple ENIs in the VPC.
Inbound and Outbound rules can be defined in security groups to specify what kind of traffic is allowed. The main inputs to these rules are the source (inbound)/destination (outbound), protocol, and port range. By default Security Groups follow a deny-all policy. If you create a security group with no inbound or outbound rule, all kinds of traffic are denied. Security groups are stateful.
For example, if a jump server is placed in a subnet and we would like to SSH into it for management purposes, then we need to define an inbound rule which allows SSH traffic on port 22 from our source IP (IP address from where we try to log in).
NACLs (Network Access Control Lists) define network access rules on Subnet levels. They function similarly to Security Groups but there are some fundamental differences. Since they are not attached to ENIs and work at the Subnet level, any instance-level changes would have to be done by security groups. Any changes made to NACLs would affect all the resources placed into that subnet.
Every VPC has a default NACL which can be repurposed as per our requirement. NACLs can be associated with any subnet as far as the subnet belongs to the same VPC. Unlike security groups, NACLs are stateless – meaning we need to explicitly specify rules for outbound “reply” traffic for all incoming requests.
So, we talked about a few aspects of network traffic management in VPCs. To put everything into perspective – Route tables and routes are not meant for security, but they enable connectivity at the VPC level. Security groups define inbound and outbound rules at ENI/instance level and NACL inbound and outbound rules are defined at the subnet level.
ENIs of EC2 instances can be assigned a public IP address. The public IP address assigned by default is not permanent. Meaning we can use this IP address to access the EC2 instance from the internet, but when an instance restarts a new IP address is assigned to it. This can break things. To overcome this situation, AWS assigns an Elastic IP (EIP) address, which remains permanent in case of any event. The IP address stays with you till the time you manually release it.
When an EIP is assigned to an instance ENI in a VPC, network translation takes place in the Internet Gateway (IGW). Network translation is used to swap the private IP address of the source instance with its Public IP address before sending the request to the host on the internet. Also, all the requests originating from the internet to this EIP will be translated by IGW and the request will successfully reach the instance.
This is not the best case solution, as anyone trying to access the instance from the internet can do so which is quite vulnerable to an attack. AWS provides Network Address Translation (NAT) devices to take care of this situation. There are mainly 2 types of devices – NAT Gateway and NAT instance.
NAT Gateway is a dedicated gateway that can be placed in a subnet to perform NAT for all the requests originating from any resource within VPC. However, this is true for all the egress requests. NAT protects the resources by denying the incoming traffic from the internet towards VPC via NAT. By using NAT gateways, any resource within the VPC can now have access to the internet, instead of just one instance with EIP in the previous case.
As opposed to NAT Gateway, NAT instance is an EC2 instance with a predefined AMI which supports NAT functions. However, there are additional steps that are needed to use NAT instances like – configuring EIP and managing autoscaling, or select appropriately powerful instances, apply security groups, etc
Introducing NAT devices can cause changes in Route tables. Before NAT devices, all the targets for the destinations were set as IGW. However, to make sure, network address translation takes place, we now need to change the target to NAT device.
It is also possible for VPCs to connect to other VPCs to enable instance-to-instance communication. This can be achieved by enabling VPC peering connection. It should be noted that the IP CIDR ranges used in both VPCs do not overlap. Also, once connected, new routes will need to be created in route tables.