Building Your Cloud in AWS Part 2: Setting Up a VPC

This article covers the key components and terminology related to creating a Virtual Private Cloud (VPC) environment in AWS. If you need to review Part 1, please visit this link to read about setting up IAM policies in your account.

Everything described in the setup below is available to create in either the AWS console or via the AWS command line tool.

What is a VPC?

A VPC is a virtual network within Amazon’s public cloud that you control. It enables you to utilize AWS resources and allows you to define access at a very granular level. VPCs are the base infrastructure for a lot of core resources, and they can be created very easily in the AWS console or via the AWS CLI.

Your AWS account comes with a default VPC that doesn’t contain any networking or security parameters. It is best practice to create a new environment so that you can build your connection and security protocols from the ground up.

Within a VPC, the common best practice to partition your VPC IP range into subnets, or subsets of the greater range where you can implement resources and assign varying levels of access controls. Creating subnets also enables you to spread your resources across availability zones, an important factor of application building. Most architectures create separate subnets for public-facing and private-facing workloads, as shown in the diagram below:

For starters, your VPC will need an internet gateway, which allows traffic outside your VPC to access resources inside; for example, an EC2 VM or a database like Redshift. Access to AWS resources inside your VPC can be restricted to specific IP address ranges (via route tables), and you have full flexibility to specify these rules. IP ranges can vary from a single IP address (e.g. your own personal machine) to 0.0.0.0/0, which would allow any and all IP addresses.

Security

A simple metaphor for security options within the VPC is the physical security of an office building. Imagine you want to get to a specific server room in the building. That server room is protected with badge access, on a floor that requires a valid key card, in a building that allows only employees or registered guests. These three layers of security are similar to layers available in AWS.

Please note, there lots of additional security layers offered to protect your VPC, from VPN gateways to web application firewalls or WAFs. Only the initial architecture components are going to be covered in this tutorial; the internet gateway plus route tables, network access control lists and security groups.

Network ACLs allow you to specify IP ranges at the subnet level. Let’s say you are building a data warehouse in one subnet and want all of your data engineers at your corporate office to have access. You can restrict access to the subnet for just that office or team, so no other team or person outside your company has access to the database.

Going one layer down, you can apply role restrictions at the resource level by leveraging security groups (SGs). SGs allow you to specify traffic for an individual resource or group of resources, such as in the diagram in Figure 2. For example, if your marketing partners need access to a CRM database and an internal virtual machine that runs queries on it, you can put those two resources in a security group so team members in that department can only access those specific resources.

This is a very high-level summary of how the various components of a VPC interact. There will be more detail regarding these components in later posts focused on the technical implementation of each.