Anatomy of an AWS Virtual Private Cloud
Brian Posey walks through the basic concept of a VPC.
When an organization first begins using Amazon Web Services (AWS), it's common for it to jump right in and begin creating EC2 virtual machine instances, S3 storage buckets and other cloud-based infrastructure components. Although some people understandably disagree with me on this point, I personally think that there's nothing wrong with this approach. I'm a firm believer in the idea that the best way to learn something new, is to get your hands dirty and try it out.
Over time, however, an organization's AWS usage will inevitably begin to grow and mature. As that happens it will become necessary for those supporting the AWS resources to be familiar with virtual private clouds, or VPCs as AWS likes to call them. My goal in writing this article is to familiarize you with the basic concept of a VPC.
A VPC is essentially just an isolation boundary for your cloud resources. While I could delve into a mind-numbing discussion of subnets and virtual network segments, I think that it makes more sense to put the concept of a virtual private cloud into prospective by comparing it to something that might be more familiar -- Microsoft Active Directory.
Now let me just say up front that AD and AWS VPCs are two completely different things. I'm only discussing AD for the sake of illustrating a concept.
With that said, consider the way that AD works. An AD environment is made up of a forest, consisting of one or more domains. The forest represents the boundary of the AD environment, and the domains within a forest act as logical collections of resources such as user accounts and computer objects. Occasionally, however, an organization might need a greater degree of resource isolation than what the domain structure can provide by itself. In those types of situations, the organization might create additional forests that are completely independent of one another. In this type of situation, the organization maintains ownership of all of the forests. It's even possible that a single administrator oversees all of the forests, but the forests themselves act as units of isolation. A user within one forest cannot access resources in another, unless a special trust relationship is put into place.
So let's compare this to how AWS works. As I explained a moment ago, an AD structure is hierarchical. At the top of the hierarchy is the company who owns the AD environment. That company might create one or more forests, each of which can contain one or more domains. In an AWS environment, an organization sets up an AWS subscription, which is essentially the top of the hierarchy. Within that subscription, an administrator can create one or more VPCs. Just as AD forests provide strict isolation of resources, so, too, do VPCs. A VPC isn't the same thing as an AD forest, but like an AD forest, VPCs offer a handy way of keeping resources isolated from one another.
One key difference between AD and an AWS VPC is that AD is based on a database that stores user objects, computer objects, and objects of other types. A VPC, on the other hand, can be thought of as network isolation, not just isolation of users and computers. In fact, when you create an EC2 instance, Step 3: Configure Instance Details asks you to choose a network. However, the networks that are available for selection are actually VPCs. The Configure Instance Details screen even gives you the option of creating a new VPC, as shown in Figure 1.
The point is that when you create a VPC, you're not creating a directory, but rather a virtual network isolation boundary. If you need a cloud-based directory service, you can create a directory inside a VPC. As you can see in Figure 2, for instance, when you create an AD on AWS, you're asked with hich VPC you want to associate it.
If you really stop and think about it, the phrase "virtual private cloud" includes the words private cloud. In an on-premises private cloud environment, a global administrator carves up resources into isolated environments that can be used by self-service administrators. A virtual private cloud works essentially the same way. An administrator can create a virtual private cloud, create resources within the virtual private cloud, and then allow another administrator to manage those resources without fear of impacting resources located in other virtual private clouds.
Brien Posey is a 16-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site at.