AWS 201: What is a Default VPC?

default-vpc-diagram

To set the stage for explaining Amazon Web Services Virtual Private Clouds, I previously walked through AWS Regions and Availability Zones in another blog post. With that as the foundation, we can start taking a look at the concept of a Virtual Private Cloud and how it enables advanced networking capabilities for your AWS resources.

Virtual Private Cloud, aka VPC, is a logically isolated virtual network, spanning an entire AWS Region, where your EC2 instances are launched. A VPC is primarily concerned with enabling the following capabilities:

  • Isolating your AWS resources from other accounts
  • Routing network traffic to to and from your instances
  • Protecting your instances from network intrusion

There are 6 core components which are fundamental to being able to launch AWS resources, such as EC2 instances, into a VPC. These 6 components are:

  • VPC CIDR Block
  • Subnet
  • Gateways
  • Route Table
  • Network Access Control Lists (ACLs)
  • Security Group

Every AWS account created after 2013-12-04 supports VPCs and these accounts are assigned a default VPC in every Region. These default VPCs are designed to make it easy for AWS users to get started with setting up networking for their EC2 instances.  In the whiteboard video below, I will explain how the basic components of a VPC fit together and walk though how they are configured in a default VPC. For the rest of this post, I will walk you through what a default VPC looks like in the AWS Console and highlight important default settings.

The place to begin looking in your AWS Console is with the VPC Dashboard where you can get an overall view of what components are available as part of your VPC footprint. Note that the basic components I mentioned earlier will already be provisioned as part of the default VPC that is assigned to every AWS account for every region.

screen-shot-2017-02-17-at-1-42-14-pm

VPC CIDR Block

Select “Your VPCs” in the left sidebar and the dashboard will display all your VPCs in a particular Region, including the default VPC. A region can only have one default VPC. Although you can have up 5 VPCs in a region, only the initial VPC that AWS creates for you can be the default VPC.

screen-shot-2017-02-17-at-1-49-02-pm

Every VPC is associated with an IP address range that is part of a Classless Inter-Domain Routing (CIDR) block which will be used to allocated private IP addresses to EC2 instances. AWS recommends that VPCs use private ranges that are defined in RFC 1918. All default VPCs will be be associated with an IPv4 CIDR block with a 172.31.0.0/16 address range. This will give you 65,536 possible IP addresses, minus some AWS reserved addresses.

Subnet

Next, if you go to the “Subnets” screen, you will see that multiple default subnets have already been assigned to your default VPC, one subnet for each Availability Zone in a Region.

screen-shot-2017-02-17-at-10-10-31-pm

A subnet is always associated with a single Availability Zone and cannot span multiple AZs. However, an AZ can host multiple subnets. Each subnet in a VPC is associated with an IPv4 CIDR block that is a subset of the /16 CIDR block of its VPC. In a default VPC, each default subnet is associated with /20 CIDR block address range which will have 4091 possible IP addresses minus the 5 addresses that AWS always reserves. Note that 2 subnets cannot have overlapping address ranges.

When you launch an EC2 instance into a default VPC without specifying a specific subnet, it is automatically launched in one of the default subnets. Every instance in a default subnet receives a private IP address from the pool of addresses associated with that subnet and also a private DNS hostname. In a default subnet, an instance will also receive a public IP address from the pool of addresses owned by AWS along with a public DNS hostname, which will facilitate Internet access for your instances.

ip-addressing

Gateways

Frequently, your EC2 instances will require connectivity outside of AWS to the Internet or to a user’s corporate network via the use of gateways. For communication with the Internet,  a VPC must be attached to an internet gateway. An internet gateway is a fully manged AWS service that performs bi-direction source and destination Network Address Translation (NAT) for your EC2 instances. Optionally, a VPC may use a virtual private gateway to grant instances VPN access to a user’s corporate network.

A subnet that provides its instances a route to an internet gateway is considered a public subnet. A private subnet may be in a VPC with an attached internet gateway but will not have a route to that gateway. In a default VPC, all default subnets are public subnets and will have a route to a default internet gateway.

screen-shot-2017-02-18-at-10-18-49-pm

Route Table

I’ve mentioned routing several times while talking about the internet gateway. Every VPC is attached to an implicit router. This is a router that is not visible to the user and is fully managed and scaled by AWS. What is visible is the route table that is associated with each subnet and is used by the VPC router to determined the allowed routes for outbound network traffic leaving a subnet.

Note from the screenshot below that every route table contains a default local route to facilitate communication between instances in the same VPC, even across subnets. In the case of the main route table that is associated with a default subnet, there will also be a route out to the Internet via the default internet gateway for the VPC.

screen-shot-2017-02-18-at-9-33-01-pm

Also note that every subnet must be associated with a route table. If the association is not explicitly defined, then a subnet will be implicitly associated with the main route table.

screen-shot-2017-02-18-at-10-01-36-pm

Network ACLs

One concern you may rightly have is network security, particularly if all default subnets in a default VPC are public and open to Internet traffic. AWS provides security mechanisms for your instances in the form of network ACLs and security groups. These 2 mechanisms can work together to provide layered protection of your EC2 instances.

A network Access Control List (ACL) acts as firewall that controls network traffic in and out of a subnet. You create Network ACL rules for allowing or denying network traffic for specific protocols, through specific ports and for specific IP address ranges. A network ACL is stateless and has separate inbound and outbound rules. This means both inbound and outbound rules have to be created to allow certain network traffic to enter the subnet and for responses to go back through. For example, if you create an inbound rule allow SSH traffic into the subnet, you must also create an outbound rule to allow SSH related traffic out of the subnet.

A rule number is assigned to each rule and all rules are evaluated starting with the lowest numbered rule. When traffic hits the firewall, it is evaluated against the rules in ascending order. As soon as a rule is evaluated that matches the traffic being considered, it is applied regardless of what is indicated in a subsequent rule.

screen-shot-2017-02-19-at-8-20-47-pm

 

screen-shot-2017-02-19-at-8-35-18-pmAs indicated above, the default Network ACL in a default VPC is configured with lower-numbered rules for both inbound and outbound traffic which combine to explicitly allow bi-directional communication for any protocol, through any port and to and from any source or destination.

You can associate a Network ACL with multiple subnets but any single subnet can only be associated with one Network ACL. If you don’t specifically associate a Network ACL with a subnet, the subnet is automatically associated with the default Network ACL. This is the case with your default VPCs which have all subnets associated with the default Network ACL.

Security Groups

Security groups are considered the first line of defense and is a firewall that is applied at the instance level. This means that only instances explicitly associated with a security group will be subject to its rules while all instances in a subnet are impacted by the network ACL applied to that subnet.

Similar to network ACLs, you create inbound and outbound traffic rules based on protocol, port and source or destination IP. However there are some differences as well.

  • You can specify rules to allow network traffic but cannot create rules to deny specific types of traffic. In essence, all traffic is denied except for traffic you explicitly allow.
  • Security groups are stateful so if you create a rule to allow a certain type of traffic in, then outbound traffic in response is also allowed even if there is no explicit outbound rule to allow such traffic.

Every instance must be associated with a security group and if a security group is not specified at launch time, then that instance will be associated with a default security group.

Screen Shot 2017-02-19 at 9.04.20 PM.png

You can see from the screenshot above that a default security group will have a rule that only allow inbound traffic from other instances that are associated with the same default security group. No other inbound traffic is allowed.

Screen Shot 2017-02-19 at 9.07.49 PM.png

Looking at the outbound rules above, all network traffic out is allowed by the default security group. This includes traffic out to the Internet since a default VPC will have a route to a default internet gateway.

As you can imagine, while a default VPC may be suitable for a small non-critical single tier applications, it is not ideal for a robust production environment. That’s why it is recommended that after getting their feet wet, users modify the default VPC configurations or create custom VPCs for production use. In the next blog post, we will do just that and break down a common use case with a custom VPC that has a public subnet tier and a private subnet tier. Stay tuned.

AWS 101: Global Infrastructure – Regions and Availability Zones

In their most recent earnings call, Amazon reported that their Amazon Web Services division has reached a $14.2 billion run rate. As impressive as that is, AWS and the entire cloud market still only represents a small slice of the total IT budget worldwide. In fact, while IDC projects the Public Cloud to be a ~$200 billion market by 2020, it also projects the total IT budget in 2020 to be $2.7 trillion. Public cloud adoption is accelerating but the market opportunity is even greater than most people think since we are nowhere near market saturation. The reality is that for most companies, AWS and other public clouds are largely untapped resources and many users are only beginning to familiarize themselves with what the Public Cloud has to offer.

To help those who are new to AWS and desire to learn more, I will be writing some 101 and 201 blog series that walk readers through some core concepts and services. Along with many of these posts, I will also be posting some whiteboard and demo videos.

The first such series will be on the important topic of Virtual Private Cloud or VPC. We will be walking though the components of a VPC, including what comes with a default VPC. That will be followed by a deep dive on how to build a custom VPC and the impact it will have on network and application designs. But before jumping into a discussion on Virtual Private Clouds, it is important we understand the concept of Regions and Availability Zones since they are foundational to building on top of AWS.

The AWS Global Infrastructure is currently comprised of 16 Regions worldwide and 42 Availability Zones with 2 additional Regions scheduled to be online in 2017.

global_infrastructure_12-15-2016

Amazon Web Services Region

A Region is a geographical location with a collection of Availability Zones mapped to physical data centers in that Region. Every Region is physically isolated from and independent of every other Region in terms of location, power, water supply, etc.. This level of isolation is critical for workloads with compliance and data sovereignty requirements where guarantees must be made that user data not leave a particular geographic region. The presence of Regions worldwide is also important for workloads that are latency sensitive and need to be located near users in a particular geographic area.

Inside each Region, you will find 2 or more Availability Zones with each AZ being hosted in separate data centers from another AZ. More later on why having at least 2 Availability Zones in a Region is important. The largest AWS Region, us-east-1, has 5 Availability Zones. The current standard for new AWS Regions moving forward is to have 3 or more Availability Zones whenever possible. When you create certain resources in a Region, you will be asked to choose an Availability Zone in which to host that resource.

aws_regions

While each Region is isolated physically from every other Region, they can communicate with each other over the Amazon Global Network. This global network is a redundant 100GBE private network that traverses the globe, running through and between each AWS Region. With regional connectivity, user cans build applications that are global in reach and can survive the failure of even an entire Region. AWS can also leverage connectivity between Regions to replicate data, such as S3 object storage data or Elastic Block Storage snapshots, at the users’ discretion. An example of this can be seen in the diagram below which was shared by Pinterest.

pinterest-ha

I talk more about Availability Zones below but what is worth noting here that by replicating data across regions and using Amazon’s Route 53 managed DNS, it is possible to survive or recover from the failure of an entire region since the failure of any region should have minimal to no impact on any other regions.

Amazon Web Services Availability Zone

An Availability Zone is a logical data center in a Region that is available for use by any AWS customer. Each AZ in a Region has redundant and separate power, networking and connectivity to reduce the likelihood of a two AZs failing simultaneously.  A common misconception is that a single AZ = a single data center. In fact, each AZ is backed by 1 or more physical data centers with the largest AZ being backed by 5 data centers. While a single AZ can span multiple data centers, no two Availability Zones share a data center. Abstracting things further, to distribute resources evenly across the Availability Zones in a given Region, Amazon independently maps AZs to identifiers for each account. This means the us-east-1a Availability Zone for one account may not be backed by the same data centers or physical hardware as us-east-1a for another account.

In each Availability Zone, participating data centers are connected to each other over redundant low-latency private network links. Likewise, all Availability Zones in a region communicate with each other over redundant private network links. These Intra-AZ and Inter-AZ links are heavily used for data replication by a number of AWS services including storage and managed databases.

So why are Availability Zones such an important and foundational concept in Amazon Web Services? The diagram below illustrates a Region with 2 Availability Zones where only one of the AZs are being utilized. The architecture mirrors what a typical three-tier application running in a user’s single on-premises data center may look like. While there are redundant servers running in each tier, the data center itself is a single point of failure.

single-az

In contrast to this architecture, the diagram below illustrates the recommended practice of spanning an application across multiple Availability Zones. By placing cloud instances/virtual servers for each tier in each AZ, users are able to eliminate an AZ as a single point of failure. Amazon Elastic Load Balancers (ELB) situated at different application tiers ensure that even if an entire AZ goes offline, traffic will be directed to the appropriate AZ. It’s worth pointing out that the ELBs “live” outside the AZs and are therefore not impacted by the failure of any particular AZ. ELB is one of many AWS services that have a regional scope and can span across Availability Zones in a given Region. Other services like Route 53 is global in scope, as shown below, and provides services to multiple Regions.

multi-az

This ability to leverage multiple Availability Zones is foundational for building a highly-available, fault-tolerant application using Amazon Web Services.

Next Up: Virtual Private Clouds

With a basic understanding of Regions and Availability Zones under our belts, we can move on to Virtual Private Cloud (VPC) – what they are and how they relate to Regions and Availability Zones. In the next post, I will break down the components of a VPC and explain the concept of a default VPC which is always assigned to each AWS account. Then we will walk through how to build custom VPCs and how a properly configured VPC design can lay the groundwork for building a highly secured production environment. So, stay tuned.