The Virtual Public Cloud (VPC) is the first and most elementary element that you need to understand when starting your journey through the plethora of products available from AWS today.
In this post, we are going to discuss some of the main components in your AWS VPC. By default, every single new account has one.
What is a VPC?
The easiest way to describe a VPC is as your own private data center within the AWS infrastructure. You get to decide the network addresses that you will use throughout your infrastructure. Since this is your network, you can decide to slice it up any way you prefer.
For example, you might decide that your VPC network will be 192.168.0.0/16, which can accommodate 65,534 different IP addresses and 256 different subnets. This should suit your needs. The most important thing to take into account is that you only have one opportunity to do this – and that’s when you create the VPC. There is no way to change your VPC’s network block after it has been created.
Subnets are the next piece of the VPC. Why use different subnets in your VPC and not simply leave everything in one big happy (family) network? There are a number of reasons for this.
Not all of your workloads belong together in a single network. There are components that are public facing, and there are those that you do not want to expose to the outside world (such as databases and secrets).
In the cloud world today, you cannot always assume that instances will always be available and that their IP addresses will be the same. As a result, it makes a lot of sense and is also a lot easier to operate an environment where certain groups (or families) of instances are assigned to specific networks. This enables you to maintain a proper level of security between the different tiers without having to know the specific IP addresses of a single instance.
The next important point that you must understand – a subnet cannot traverse more than a single availability zone.
A few words regarding availability zones in AWS. An availability zone (as per the AWS definitions) is a physical data center in that specific region, which is connected to the other availability zones in that same region with a high speed network in a redundant manner.
As a result of their geographical dispersity, a subnet cannot be defined over more than one single availability zone. When deploying your workloads in the cloud, you should definitely make use of the “free”’ and built-in redundancy features inherent in using availability zones. This is why you would probably want to divide your network into a number of subnets.
Public vs. Private Subnets
In your VPCs, you can define subnets that you want to be exposed to the outside world (i.e., you can attach public IP addresses to the instances). You can also define subnets that should never be directly accessed from the outside world. Instances on such a subnet could be your backend database or some secret store that you do not want to be publicly available. The difference between public and private subnets is the route the traffic takes out to the internet – the Internet Gateway or the NAT Gateway.
Internet Gateway (IGW)
Having instances running in AWS is great and fun, but if you cannot get to them from the outside world or if they cannot get to the outside world, manageability is going to be very challenging – if not completely impossible.
Your connection to the outside world is the Internet Gateway.
You don’t have to define IP addresses when you set up your IGW. You don’t have to worry about redundancy or scaling of this gateway either – this is taken care of for you by AWS. All you need to do is create one.
The IGW is a transparent component. It does not have an IP address of its own and is not a component that you need to manage.
It is important to note that for an instance to talk to the outside world, instances must be located on a subnet that has a route defined to the IGW, and there must be a public IP address (Elastic IP) attached to that instance. This is mandatory to enable bi-directional communication between the outside world and the instances.
NAT Gateway (NGW)
As mentioned above, sometimes you don’t want instances to be exposed to the outside world and you don’t want them to have public IP addresses. But more often than not, these instances still need access to the outside world to get updates or to send outbound information.
In AWS, you have the option of creating an NAT Gateway to act as the conduit to the outside world.
Similar to the IGW, you do not have to configure IP addresses. The NGW is highly available and scales automatically – all of that is taken care of by Amazon. All you need to do is choose the subnet that has access to the outside world, and it will be configured for you.
By using a NGW, you can allow outbound access to the internet and limit the inbound access to those instances, providing an additional layer of abstraction and protection for your workloads.
In addition, all traffic is routed through a single IP address. This eases the management overhead if you need identify traffic coming out of your VPC to a single address, for example, with on-premises firewall rules or security groups in other cloud providers.
The basic tenet of networking is that everything inside your subnet stays inside your subnet –and if you want to go outside of your subnet, you need to go through the default gateway and from there be routed to the next hop to get to your destination network.
In AWS, traffic within the VPC does not need to be routed. A router (transparent and created in the background) takes care of this for you and the entries in this router are controlled by you through Route Tables.
When you want to access a resource outside of your VPC, – you route traffic through your IGW (for your public instances) or through the NGW (for instances that are private).
The route tables are associated with each of your subnets to allow the flow of traffic according to the policies and options you have in place.
Network Access Lists
Network Access Control Lists (NACLs) are available as a security feature in your VPC. Your network administrator is no doubt familiar with their use.
Security groups are responsible for controlling the traffic in and out of your instances. There will be cases where you want to enforce a policy at a lower level, regardless of what exists in the security group.
Let’s take the following example: say that one of your users deploys an instance in your VPC and forgot to set the security group to limit the outbound traffic from the instance. As a result, information was leaked due to a malicious exploit.
With the use of an NACL, you could limit the outbound traffic to specific instances or to certain destinations only – ensuring that your infrastructure is secure and safeguarding your intellectual property from mistakes and mishaps. This is a feature that operational security or network administrators really like because they do not have to rely on the each of the developers using the clouds. With this feature, they can maintain overall control regardless of who is using the cloud –– or how aware they are of security best practices.
AWS is aware that not everything can run in the public cloud, which is where the option to connect your on premises infrastructure with your VPC comes in. All the options are available (as with all the AWS services) through an API to allow you to quickly and easily set up an extension of your workloads that can live both inside your datacenter and in AWS.
Consider a VPC as your own private piece of real estate on AWS. There are many components involved in your Virtual Private Cloud. You are familiar with the network layout and settings in your on-premises network locations and datacenters, and you understand how each and every one of them are connected. It is understandable that with the move to the cloud – understanding your VPC infrastructure, its capabilities, and its limitations – it would be good practice to add these as well.