A VPC is a private cloud in a public cloud

By Franck Pachot

.
If you are surprised that the first thing you do in a Public Cloud is creating a Virtual Private Cloud, this post is for you. This is a beginner level post. And if you are at that level, interested by what is the Cloud and what is AWS, I recommend our free AWS Discovery Days – I give it next week in French: https://www.dbi-services.com/fr/trainings/aws-discovery-days/

Today, with the “digitalization” trend, people are looking at the cloud as a way to move their IT from their own data centers to a public cloud provider. And then, the first thing they will try to understand is how their current infrastructure matches in cloud terms. Everything runs in virtual machines (VM) on their self managed hypervisor. And the equivalent in public clouds is there with compute services: Amazon EC2, Google VM instances, Azure Virtual Machines, Oracle Compute Instances. Different names for virtual computers. And, besides defining their number of vCPUs and amount of RAM (Instance Type in AWS, Machine Type in Google, VM Size in Azure, Instance Shape in Oracle) and before attaching it to disks (block storage), the first thing to do is define on which network it is connected. This network is called VPC (Virtual Private Cloud) in AWS and Google, Virtual Network in Azure, VCN (Virtual Cloud Network) in Oracle. On-premises you have VLANs and subnets. And you can have private cloud. So why is this called Virtual Private Cloud in a Public Cloud?

Actually, you will never see Amazon talking about AWS as a Public Cloud provider. It is a cloud provider with public services, but today what you run in a public cloud can run as a private cloud: AWS Outpost, Google Anthos, Azure Stack, Oracle Cloud@Customer…

And, first of all, the most “cloudy” services in AWS do not run in a VPC at all. These days, Amazon is celebrating the 15 years of its first service: S3 (Simple Storage Service). This didn’t match with anything existing on-premises. Not because of the Web API (HTTP, FTP WebDAV where already there, and Oracle even had iFS at that time). But because it is a public service: no need to provision a network, and servers. It runs over the Internet. That’s where AWS comes from: Amazon Web Services. You want to store a file and access it? Before, you needed a server. Now, you have a service. That’s what “serverless” means. Of course there are servers, but you don’t know were they are, how much they cost, how many of them… You interact only with a service. And today, being truely “cloud-native” and “serverless” is about having files in S3, code in Lambda, data in DynamoDB, interfaces in SQS, messages in SNS… None of those services requires a VPC. Their endpoint is a public IP address on the Internet.

Now you understand how we can have a Private Cloud in a Public Cloud. For the things that are not serverless, where you must have a dedicated VM, you need virtual servers and virtual network, as in your private cloud. When you create an EC2 instance, you do the same as when you create a VMware VM on your premises, except that it is hosted in a cloud provider’s datacenter, and can share some of its infrastructure.

The data center is, physically, in an Availability Zone. For High Availability, there are multiple Availability Zones in a Region. And for Disaster Recovery, latency or data locality, or simply because of price, you have multiple regions in the world. A VPC belongs to a region and has subnets in the Availability Zones. They are defined by their network identification, which is the CIDR. For example, A VPC in /16 has 16 bits to identify it: the first two bytes are fixed, and the subnet mask is 255.255.0.0 and all the 65536 addresses in this VPC are your addresses (except a few used by the infrastructure itself). Virtual doesn’t mean that they are isolated. One day you may want to peer two VPCs across different accounts or regions and then you must be sure that the CIDR ranges do not overlap. You deploy subnets to put VMs in specific availability zones, isolate logically your components, and isolate their services. Even if you can manage the access to the network services at instance level with Security Groups, you can allow or deny trafic from/to your subnet with NACLs. And you have access to the route table in order to define what and how you can reach other networks. For example, a public facing subnet will route though an Internet Gateway. And if you want to access the public cloud services, like S3 or DynamoDB, you go though the internet gateway, or a gateway endpoint which can expose the internet service without going though the internet.

So, even if you first encounter with AWS is though a VPC you should keep in mind that many services do not belong to a VPC and many do not belong to a region either. Take S3 for example. There’s no VPC. The endpoint is on Internet. And the service is not even regional. You create the bucket in a region, because you want it near your users, but the service is Global. For data, DynamoDB and IoT Core are serverless. But databases still need a server with CPU and RAM. Even Aurora Serverless is running in a VPC. The database server is managed for you, and may be re-sized, and scaled with read replicas. But there’s no relational database that runs of of a VPC.