What Startups Should Know about Amazon VPC — Part 1
When you’re developing your cloud strategy, what questions come to your mind? Most startup companies have questions like these:
- Can the cloud provide the availability and fault tolerance that my applications need?
- What latency should I expect when communicating within my cloud environment and to the outside world?
- What does networking and security look like?
The good news is that the answer to all these questions is a simple one: Amazon Virtual Private Cloud (VPC).
This is the first in a two-part series of blog posts that will help you to understand and configure Amazon VPC. The focus of this post is to introduce you to Amazon VPC and its components.
What is Amazon VPC?
Amazon VPC lets you provision a logically isolated section of the AWS cloud where you can launch AWS resources in a virtual network that you define.
Within this logical isolation, you can define a network structure that your workloads run on top of. The VPC lives within a single AWS region, but its subnets can be spread across multiple Availability Zones (AZs) within that region. Availability Zones are highly available clusters of data centers that are connected via low latency fiber. Each AZ is geographically separated and resides on a different fault plain and flood plain.
The ability to spread your subnets and, subsequently, your resources across multiple AZs gives you the ability to build highly available, fault-tolerant environments. The latency within your VPC remains in the single-digit millisecond range whether you are communicating within the same AZ or across AZs.
Much like a traditional environment, Amazon VPC has different elements that you can configure according to the needs of your organization. The greatest difference between your VPC components and that of a traditional network is that the VPC components are completely virtual and far more elastic.
VPC configurable components include the following:
IP addresses: AWS provides you with private and public IP addresses. Your VPC CIDR block determines the number of private IP addresses that you are able to dynamically or statically allocate.
Elastic network interfaces (ENI): An ENI is a virtual network interface that carries a MAC address, one or more private IP addresses, and one or more public IP addresses. The EC2 instance type determines the number of ENIs that can be attached to an instance.
Route tables: A route table contains the routes that determine where your network traffic is routed. When you create your VPC, a main route table is generated. All subnets inside your VPC are attached to this main route table. If you would like to logically separate your routes according to your subnets and their functions, you can create multiple route tables and attach subnets to it. A subnet can be associated with only one route table at a time.
Internet gateways (IGW): As the name suggests, an Internet gateway allows your resources inside your VPC and a public subnet to communicate with things on the Internet. An IGW is not any one thing. It is highly available and scales horizontally to meet the demands of your VPC.
NAT instances: A network address translation (NAT) instance is used to allow resources in a private subnet to communicate with resources or things on the Internet. Resources like EC2 instances that live inside a private subnet cannot have a public IP address attached to its ENI. Therefore, it cannot communicate across the Internet directly via the IGW. So, like a traditional network it needs its private IPs to be translated through a public interface.
DHCP options sets: When you create your VPC, AWS creates a Dynamic Host Configuration Protocol (DHCP) option set for you. AWS assigns a domain name, a DNS, and a NetBIOS-node-type. However, you have the option to edit or create your own DHCP option set, which includes a custom domain name and DNS.
DNS: EC2 instances in your VPC are allocated a DNS hostname by AWS. You can use your own DNS by editing or creating your own DHCP option set and specifying the DNS that you would like to use.
Security groups: Security groups act as stateful firewalls that operate at the instance level. You can define what ports are open and the resources that can communicate with your resources over those ports.
Network access control lists (NACLs): NACLs act as stateless firewalls that allow or block traffic at the subnet level. These can be used in conjunction with your security groups to strengthen your security.
Customer gateway (CGW) and virtual private gateway (VGW): To establish a hardware VPN connection between your corporate network and AWS, you create and configure a customer gateway (CGW) and virtual private gateway (VPG) inside your VPC. The customer gateway is the gateway or firewall in your corporate network that will be used to establish this tunnel. The virtual private gateway is the VPN concentrator that sits on the edge of your VPC.
Inside a Simple VPC
The following illustration shows a VPC in an AWS region with three Availability Zones.
Each Availability Zone has a subnet. The master CIDR block is 10.0.0.0/16, and the subnets inherit the IP addressing range:
Subnet 1: 10.0.0.0/24Subnet 2: 10.0.1.0/24Subnet 3: 10.0.2.0/24
An Internet gateway (IGW) routes traffic from the EC2 instance in Subnet 1 to the Internet. An Elastic IP address is attached directly to the network interface of that EC2 instance, which means that this instance was created in a public subnet.
Each subnet is attached to an individual route table with a default route (to the Internet) and a local route that allows traffic to be sent between resources inside the 10.0.0.0/16 VPC. A virtual private gateway (VPG) establishes a hardware VPN connection between the VPC and the corporate network.
VPC Value-Added Services and Features
In addition to the VPS configurable components, you can achieve your specific use cases with value-added services and features, including the following:
- Enhanced networking
- VPC endpoints
- AWS Direct Connect
- VPC Flow Logs
- VPC peering
Amazon EC2 provides enhanced networking capabilities using single root I/O virtualization (SR-IOV) on supported instance types to achieve higher performance (packets per second), lower latency, and lower jitter.
A VPC endpoint enables you to create a private connection between your VPC and another AWS service without requiring access over the Internet. You can create the connection through a NAT instance, a VPN connection, or AWS Direct Connect.
Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in your VPC and AWS services without imposing availability risks or bandwidth constraints on your network traffic.
Currently, Amazon S3 is the only VPC endpoint. Adding S3 as a VPC endpoint allows you to access your S3 buckets without sending the request through the Internet. You can configure S3 to allow only resources inside your VPC to make HTTP/HTTPS requests to S3.
An endpoint policy is used to enforce the type of access the endpoint has to S3 or the AWS service that it is being created for. In the case of S3, you can also use bucket policies to further secure access to your buckets and their objects.
AWS Direct Connect
AWS Direct Connect allows you to establish a private network connection between your data center and your AWS environment. If you have infrastructure collocated inside an AWS Direct Connect facility, you can make a cross-connection from your rack into the AWS environment. If not, you can use an AWS Direct Connect Partner to establish an MPLS connection between your data center and an AWS Direct Connect facility. AWS Direct Connect allows you to move data at gigabit speeds across a low latency network connection between your corporate network and your AWS environment.
If you have infrastructure collocated inside a Direct Connect facility, you have the choice between two network connection speeds: 1 Gbps and 10 Gbps. If you are not collocated inside a Direct Connect facility, you have the option of network connection speeds ranging between 50Mbps to 10Gbps. It is important to note that the total solution cost for this option differs from the first solution.
The following illustration shows a simple Direct Connect connection with redundant paths.
VPC Flow Logs
VPC Flow Logs is the Amazon answer to the network management features you’ve used for many years to analyze and troubleshoot your network. There are many use cases for VPC Flow Logs. Here are a few examples:
- Capturing data about the IP traffic going to and from the network interfaces in your VPC
- Troubleshooting multiple instances, or a single instance that is not receiving traffic when it should be
- Checking the effectiveness of your security group
A VPC peering connection is a network connection between two or more VPCs in the same AWS region. A peering connection can be established between VPCs in the same account or between VPCs owned by separate entities.
Once this logical peering is done, you can route traffic between VPCs at the same single-digit latency you are familiar with.
A use case for this could be implementing a central database in one VPC under an account with IAM users and policies for only your DBAs, and creating another account and VPC for your developers. You could peer these two VPCs, and add a route to their VPC route table that allows the developers to query the central database. They, however, would not have access to the actual instance that hosts the database, preventing them from accidentally deleting the databases or making any modification to the database environment.
The following Illustration shows an inter-connected VPC via peering connections.
It is important to note that you are cannot do a transient route from VPC B to VPC C via VPC A.
In this post we introduced you to the core components of Amazon VPC. We described what they are, what they do, and how you can use them to add value to your environment. The next post will dive deeper into architecture best practices and how to configure your VPC.
Written by Androski Spicer, Solutions Architect, Amazon Web Services