AWS Virtual Private Cloud (VPC) is another outstanding AWS service. Also, it is something you need to know if you want to pursue the certifications. Besides, when we build a cloud infrastructure, we want control over the security, of the traffic between our services and much more.
In simpler words, AWS VPC provides us with more control.
AWS VIRTUAL PRIVATE CLOUD USE CASES
There are a few use cases for having your private networking environment. Some of the are:
- Hosting websites => You can host a basic web application (e.g. a blog) in your virtual private cloud. The benefits of doing so are that you get additional layers of privacy and security.
- Extend your network into the cloud =>You can move your IT resources into the cloud seamlessly. That is, you do not have to change how the users access your applications. Simply connect your VPC to your network.
- Multi-tier web applications => Improve the security of your web application by enforcing restrictions between the different parts of your application. In simple words, that means to provide internet access to your web servers, while restricting public access to your database.
However, there are other use cases such as disaster recovery, connecting cloud applications to your datacenter, and so on.
WHAT IS AWS VIRTUAL PRIVATE CLOUD
AWS Virtual Private Cloud allows us to define our virtual private network, which we can isolate from all the other networks on AWS. However, let us also have a look at the official AWS definition. AWS VPC allows you to “provision a logically isolated section of the AWS cloud where you can launch AWS resources in a virtual network that you define”.
You might ask “why would I create my private cloud?”. The reason for creating your private cloud is to have full control of your virtual networking environment. Having your private network, you can control the IP address range, create your subnets, configure the route tables and network gateways.
AWS NETWORKING CORE COMPONENTS
A bit of networking knowledge would help us a lot with AWS. However, we can learn along while learning about AWS. There are a handful of components and services that makes up your virtual private cloud. Those are:
- Route tables
- Internet Gateways
- NAT (Network Address Translation)
- Security Groups
- VPC peering
- Elastic IP Addresses
- Public subnets
- Private subnets
I know the above list looks a bit daunting, but do not worry. We take it one by one, and the concepts are going to make sense.
DEFAULT AWS VIRTUAL PRIVATE CLOUD
By default, your account has a default virtual private cloud in each of the AWS regions. That means, you do not have to create a new one from scratch, and you can immediately deploy EC2 instances in your default VPC. Moreover, you can use other services such as Elastic Load Balancing and Amazon RDS in the default VPC.
Should you use a default VPC or a custom VPC? It depends on your needs. If you want to launch a blog or a simple website, you can make use of the default virtual private network. If you want a more complex cloud architecture, with specific requirements, you can create your custom AWS virtual private cloud.
However, how do you know if a default VPC is enough? Where can you see what it consists of? Amazon AWS configures the following for your default VPN:
- The size of the IPv4 CIDR block is
/16, which means it provides up to 65,536 IPv4 addresses
- It creates a default subnet in each Availability Zone of size
/20, which means it provides up to 4,096 addresses per subnet (AWS reserves some of them for their use)
- Creates a default network access control list (ACL)
- Creates an internet gateway and it connects it to the default VPC. The reason for doing so is to allow your instances to access the internet.
- It creates a default security group
- It associates the default DHCP options set for your AWS account with the default VPC
Note that it automatically associates the security group and network ACL with the default VPC. Also, when you create a VPC, it automatically has a main route table.
0.0.0.0/0 represents all the possible IP addresses, which means we are allowing access from anywhere on the internet.
When you specify 0.0.0.0/0 in the Internet Gateway, you allow internet access. In addition, if we define 0.0.0.0/0 in the security groups inbound rules, we grant public internet access to our resources.
However, I want to thank Andrew Brown for this piece of information!
If you wonder how can you connect two AWS Virtual Private Clouds, the answer is VPC peering. With VPC peering, we can connect two Virtual Private Clouds over a direct network route. It routes the traffic between them by using private IP addresses such as IPv4 or IPv6.
Moreover, you can connect VPCs from different AWS accounts or regions, and the instances communicate just like they are in the same network. If the VPCs are in different regions, the connection is called inter-region VPC peering connection.
For instance, you could think of two AWS Virtual Private Clouds as two cities. Thus, the VPC peering acts as a road connecting these two cities.
The above image shows how to create a peering between two Virtual Private Clouds.
To sum up, VPC peering allows you to connect two private clouds irrespective of the accounts and regions they are in. One important thing to note is that there is no transitive peering. That means the peering must take place directly between two VPCs. For example, we cannot go from VPC A to VPC C through VPC B. VPC A and VPC C needs to have a direct connection between them.
Route tables allow you to determine where to direct your network traffic. In other words, route tables are just lists of IP ranges (CIDR blocks) that the traffic can come from or leave from.
Route Tables also have Subnet associations, which means that each subnet in our AWS VPC must be associated with a route table. You can only associate one subnet with one route table at the time, but you can associate multiple subnets with the same route table. In other words, the route table determines the traffic that can enter and leave the associated subnet.
For more information on this subject, check the AWS documentation. They have more information than we need at the moment, but it is always good to go in-depth and understand a concept properly.
The name of this concept is, more or less, describing its purpose. Internet Gateway allows your VPC to communicate with the internet. It is important to note that if your VPC does not have an Internet Gateway, it cannot communicate with the internet.
Let us now talk about the two purposes of this service:
- it provides a target in your Virtual Private Cloud route tables for internet-routable traffic
- it does network address translation for instances with public IPv4 addresses
To make a subnet public, associate it with a route table and connect it to an IG. If you only have a subnet associated with a route table, but not connected to an IG, then your subnet is private.
Therefore, Internet Gateway allows communication between a VPC and the internet.
AWS DIRECT CONNECT
For different reasons, companies use a hybrid cloud. That means they are using AWS as a cloud provider, but they also have their on-premise services. Then, the question becomes, how do we connect the on-premise services to AWS?
They are connected through an Ethernet cable, which in turn, connects the company’s router and the AWS Direct Connect Router. Doing so, you create a virtual interface, bypassing the internet service provider, and you can access public AWS services such as S3 or VPC.
Let us now look at the main components of AWS Direct Connect:
- Connections – It creates a network connection between on-premises services and an AWS region. You need to create a connection in an AWS Direct Connect location.
- Virtual Interfaces – It creates a virtual interface, which allows your on-premise services to access AWS public services such as S3, for instance.
This service is great for high-traffic networks because it increases the bandwidth throughput and helps reduce network costs. (Thanks to Andrew Brown for this piece of information)
AWS VPC ENDPOINTS
AWS Virtual Private Cloud Endpoints gives you the possibility to connect your VPC to various AWS services and other VPC endpoint services. Everything is done in a private network – Amazon network. As a result, there is no need for an internet gateway, VPN Connection, AWS Direct Connect connection and so on.
There are two types of VPC endpoints:
- Interface endpoints – This type of endpoints use AWS PrivateLink, which enables you to access different services privately by using private IP addresses. When you use an interface endpoint for a supported service, this is the entry point for the traffic trying to access that specific service.
- Gateway endpoints – You specify these gateways in your route table as a target for a route. In simple words, you specify what AWS services the instances from a specific subnet can access. For instance, the instances in subnet 4 can access S3 and DynamoDB through a particular gateway endpoint. The only two services that it supports are Amazon AWS S3 and DynamoDB. You can create a gateway endpoint by specifying a VPC where the endpoint resides, and the service to which you want to create the connection.
These VPC endpoints allow instances from a VPC to communicate with various AWS services without adding bandwidth constraints and availability risks on your network traffic.
VPC FLOW LOGS
Like with any other service, we have logs to capture various information which we might inspect later. You can use this service with CloudWatch or S3 to store your logs, in case you need them for a longer period or to analyse them.
What this service does is to allow you to record information about the network traffic to and from your VPC. For instance, you can monitor the traffic that reaches your instances. You can create flow logs for your VPC, Subnet or Network Interface.
It is important to note that collecting log data does not affect your network throughput. It collects the data outside your network traffic.
The above picture illustrates how you can create a VPC flow log. The
filterfield allows us to select what to monitor. By default, it only monitors accepted traffic to our resources. However, we can change it to “Reject” and “All”. The
destinationfield allows us to store the logs in an S3 bucket or to send them to CloudWatch logs.
If you create a flow log, and then you add more instances in your subnet, it creates a log file object for each network interface.
Let us recap what we learnt in this article. We have seen the use cases for AWS Virtual Private Cloud, what this service is, its core components, VPC peering, route tables, Internet Gateway, AWS Direct Connect, VPC Endpoints and Flow Logs.
This article has a lot of information, so make sure you take your time to understand it. In the future, I plan to create labs on YouTube for each AWS article to make it easier to understand and use the concepts. As per usual, there are various sources I consult before writing articles such as Andrew Brown’s videos, AWS Documentation, A Cloud Guru and so on. I want to make sure the information is as accurate as possible.