Amazon Virtual Private Cloud (VPC)
Table of Contents
VPCs are a fundamental building block in AWS. VPCs allow you to specify your own IP range. Many AWS Resources must be deployed into a VPC, and VPCs control the network security for those resources. VPCs can be connected to your corporate networks via the use of Direct Connect or VPN, and thus can be a back door path into your enterprise.
AWS Describes VPCs as:
Amazon Virtual Private Cloud (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. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways. You can use both IPv4 and IPv6 in your VPC for secure and easy access to resources and applications.
You can easily customize the network configuration of your Amazon VPC. For example, you can create a public-facing subnet for your web servers that have access to the internet. You can also place your backend systems, such as databases or application servers, in a private-facing subnet with no internet access. You can use multiple layers of security, including security groups and network access control lists, to help control access to Amazon EC2 instances in each subnet. (source)
Service Name: Amazon Virtual Private Cloud
Service Family: Networking & Content Delivery
Supports Resource Policies: No
Service Pricing: Free
Service Webpage: https://aws.amazon.com/VPC/
Knowldge of VPCs is core to understanding AWS Security. Typical VPC misconfigurations involve AWS Security Groups, NACLs, and routing. Each one of those is key to restricting network access to the AWS resources deployed in that VPC.
When a new AWS Account is created, Default VPCs are created in every region. These Default VPCs are great for beginners and help AWS’s customers get started deploying things quickly, but they do not implement most network security best practices. Default VPCs should be deleted at account creation.
Effectively Leveraging VPC
It is wise to remove the default VPC and create new VPCs from CloudFormation or Terraform. These VPCs should leverage non-overlapping IP space and the VPC CIDR ranges should reserve some extra IP space for future needs.
Proper VPC Design
A proper VPC design should leverage multiple tiers of subnets across multiple Availability Zones (three or more where possible). A proper design would have a Public Subnets, Private Subnets, and potentially even a Data Subnets. The definition of these subnet tiers depends on how the VPC’s route table is configured.
- Public Subnets are the only subnets that should have their default route (0.0.0.0/0) pointing to the Internet Gateway (IGW). Inside the Public Subnets should reside the Nat Gateways, and any Load Balancers that are intended to be consumed from off-network.
- Private Subnets exist to contain your compute resources. These should never have a public IP address and be only accessed via the Load Balancers (for production traffic), or bastion host (for admin traffic). If you have Direct Connects, then admin access can be restricted to your network’s private IP space. Resources in private subnets can initiate outbound connections via Nat Gateways (NatGW), and the default route for these subnets should point to the Nat Gateway in the public subnet in the same AZ. It is important for fault-tolerance that each private subnet route to the NatGW in the same AZ.
- Data Subnets are optional subnets you can create to store your data bases and other data storage resources.
By default, all subnets in a VPC can route to each other. Security control exists with how the route table is configured. VPC Routing supports the following destinations: * Internet Gateway (IGW) - the virtual router device that is connected to the Internet * Virtual Private Gateway (VGW) - a router device that is connected to Direct Connect / VPN for access on-prem * NatGateways - a managed service from AWS that acts as a linux masquerading device. * VPC Endpoint (VPCE) - a router device that allows or direct interface with S3 and DynomoDB that is high performance * VPC Peering (VPCX) - a way to link two VPCs together. The VPC router must be configured to send traffic to the other VPCs from the specified subnet.
NACLs & Security Groups
NACLs and Security Groups are the basic firewall building blocks in AWS. NACLs are stateless layer-3 firewalls that are attached to subnets, while Security Groups are stateful layer-3 firewalls attached to EC2 Instances and other resources (technically they are attached to Elastic Network Interfaces, ENIs, that exist in the VPC.)
You can configure VPC Flowlogs, which is a netflow-like record of all the packets going in and out of your VPC. Note however that VPC flowlogs can be quite a lot of data and AWS charges for their collection.
Other VPC-related Services
Because VPCs are such a core function in AWS, and because customers have demanded flexibility from AWS, there are numerous VPC/Network related services available.
- Nat Gateways
- Work Link
- Transit Gateways
- Direct Connect
- Client VPN
- Site-to-site VPN
Suggested Compliance Rules around VPCs
- VPCs should leverage centrally assigned IP Space
- Default VPCs should be deleted in all regions
- Security Groups should not open admin ports (22, 3389, 3306, etc) to 0.0.0.0/0
- Security Groups should never permit ports 0-65535
- EC2 Instances should not have public IP address, but should exist in a subnet without a direct route to the IGW and fronted by and AWS Load Balancer
- Best practice for security groups leverages security group references instead of CIDR ranges as security group sources or destinations.
CloudTrail events of significance
Any modification to your VPC architecture is important to investigate. For historical reasons, VPC API commands exist in the EC2 Namespace. This make it hard to craft IAM policies that permit EC2 but prohibit modifications to VPCs.
Events you might want to monitor consist of:
Network Access Control Lists (NACLS)