Amazon VPC
WHAT IS IT? [Azure Private Network / Google Private Network]
Think of a VPC as a virtual data center in the cloud. Your data center may have public web servers that are directly accessible to the internet, and a more private set of servers that can only be accessed by direct connection or over a VPN. If you’re dealing with especially sensitive customer information (such as something regulated), you’d want to isolate that data even more.
VPCs allow you to provision an isolated section of AWS where you can launch resources in a spot you define. So you can think of it as a way to do stuff with your private information without that confidential information touching the internet. VPCs are the place to put your database, your application servers, your back-end reporting processes - anything you don’t want directly exposed to anyone with an internet connection.
VPCs allow you to set your IP range, create subnets, and configure root tables and network gateways. You could create a public-facing subnet connected to the web while your backend systems are isolated and not connected to the internet at all. Multiple layers of security can help you control access to each subnet - what’s known as “defence-in-depth”. Every AWS account gives you a default VPC out of the box, but you’ll likely want to set up your own for improved security and customization.
WHAT’S THE FUSS?
You’re essentially trying to keep some information safe and off the internet while connecting internet-facing services to both that information the web simultaneously. That’s complex! Just look at this example [credit to a fellow blogger, I just can’t figure out how to import png files of my own here so it’s easier to someone else’s fantastic work]
All those elements are there to defend your information. But with all those arrows, you can see that there are many points where things can break down. The whole process can get particularly hairy when you’re con- figuring a custom VPC but don’t have a ton of expertise in networking. Just one example: there is no transitive peering between VPCs. You can have one VPC talk to another VPC, but if that VPC talks to a third one, the first one can’t speak to the third one. If VPC A can talk to VPC B, and B can talk to C, A still CAN NOT speak to C!
In linguistics, we deem this phenomena mutual intelligibility. Without prior learning, an English speaker might understand a little bit of Dutch, and in turn a Dutch speaker might recognise a little Afrikaans - but an English speaker knowing Afrikaans by proxy is a bit of a stretch. This concept of intransitiveness also applies here to private networks.
Increasingly, many people will also question whether they need a VPC in the first place. After all, the rise of “zero-trust” networking and serverless architectures has moved more workloads out of private networks and into reliance on good authorization strategies (like AWS IAM). But the reality is that anyone trying to connect legacy services to the cloud will probably need to implement a VPC -- it’s the only way to talk to the private network in your old data centre, after all.
