Amazon Virtual Private Cloud (VPC) is a service that lets us launch AWS resources in a logically isolated virtual network that we define.
Amazon Virtual Private Cloud (Amazon VPC) enables us to launch Amazon Web Services resources into a virtual network we’ve defined. This virtual network resembles a traditional network that we’d operate in our own data center, with the benefits of using the scalable infrastructure of AWS.
Get Your Free Linux training!
Join our free Linux training and discover the power of open-source technology. Enhance your skills and boost your career! Learn Linux for Free!Table of Contents
How VPCs work: virtual networking environments
Each VPC creates an isolated virtual network environment in the AWS cloud, dedicated to our AWS account. Other AWS resources and services operate inside of VPC networks to provide cloud services.
AWS VPC will look familiar to anyone used to running a physical Data Center (DC). A VPC behaves like a traditional TCP/IP network that can be expanded and scaled as needed. However, the DC components we are used to dealing with—such as routers, switches, VLANS, etc.—do not explicitly exist in a VPC. They have been abstracted and re-engineered into cloud software.
Using VPC, we can quickly spin up a virtual network infrastructure that AWS instances can be launched into. Each VPC defines what our AWS resources need, including:
- IP addresses
- Subnets
- Routing
- Security
- Networking functionality
Where VPCs live
All VPCs are created and exist in one—and only one—AWS region. AWS regions are geographic locations around the world where Amazon clusters its cloud data centers.
The advantage of regionalization is that a regional VPC provides network services originating from that geographical area. If we need to provide closer access for customers in another region, we can set up another VPC in that region.
This aligns nicely with the theory of AWS cloud computing where IT applications and resources are delivered through the internet on-demand and with pay-as-we-go pricing. Limiting VPC configurations to specific regions allows us to selectively provide network services where they are needed, as they are needed.
Each Amazon account can host multiple VPCs. Because VPCs are isolated from each other, we can duplicate private subnets among VPCs the same way we could use the same subnet in two different physical data centers. we can also add public IP addresses that can be used to reach VPC-launched instances from the internet.
Amazon creates one default VPC for each account, complete with:
- Default subnets
- Routing tables
- Security groups
- Network access control list
we can modify or use that VPC for our cloud configurations or we can build a new VPC and supporting services from scratch.
Example of AWS VPC
We can host a public facing website, which could be a blog, a single tier simple web application, or just a simple website using VPC.
we can create a public subnet using the VPC wizard and select the VPC with a single public subnet only option, or we can create it manually.
Secure our website using instance-level firewalls, known as security groups, allowing inbound traffic, either HTTP or HTTPS, from the internet and restricting outbound traffic to the internet when required at the same time.
Managing our AWS VPCs
VPC administration is handled through these AWS management interfaces:
- AWS Management Console is the web interface for managing all AWS functions (image below).
- AWS Command Line Interface (CLI) provides Windows, Linux, and Mac commands for many AWS services. AWS frequently provides configuration instructions as CLI commands.
- AWS Software Development Kit (SDK) provides language-specific APIs for AWS services, including VPCs.
- Query APIs. Low-level API actions can be submitted through HTTP or HTTPS requests. Check AWS’s EC2 API Reference for more information.
The AWS Management Console manages our VPCs and other AWS services
Elements of a VPC
The web-based AWS management consoleshows most of the VPC resources we can create and manage. VPC network services include:
- IPv4 and IPv6 address blocks
- Subnet creation
- Route tables
- Internet connectivity
- Elastic IP addresses (EIPs)
- Network/subnet security
- Additional networking services
Let’s look briefly at each.
IPv4 and IPv6 address blocks
VPC IP address ranges are defined using Classless interdomain routing (CIDR) IPv4 and IPv6 blocks. we can add primary and secondary CIDR blocks to our VPC, if the secondary CIDR block comes from the same address range as the primary block.
AWS recommends that we specify CIDR blocks from the private address ranges specified in RFC 1918, shown in the table below. See the AWS VPCs and Subnets page for restrictions on which CIDR blocks can be used.
Subnet creation
Launched EC2 instances run inside a designated VPC subnet (sometimes referred to as launching an instance into a subnet).
For IP addressing, each subnet’s CIDR contains a subset of the VPC CIDR block. Each subnet isolates its individual traffic from all other VPC subnet traffic. A subnet can only contain one CIDR block. we can designate different subnets to handle different types of traffic.
For example, file server instances can be launched into one subnet, web and mobile applications can be launched into a different subnet, printing services into another, and so on.
Route tables
Route tables contains the rules (routes) that determine how network traffic is directed inside our VPC and subnets. VPC creates a default route table called the main route table. The main route table is automatically associated with all VPC subnets. Here, we have two options:
- Update and use the main route table to direct network traffic.
- Create our own route table to be used for individual subnet traffic.
- Internet connectivity
- For Internet access, each VPC configuration can host one Internet Gateway and provide network address translation (NAT) services using the Internet Gateway, NAT instances, or a NAT gateway.
Elastic IP addresses (EIPs)
EIPs are static public IPv4 addresses that are permanently allocated to our AWS account (EIP is not offered for IPv6). EIPs are used for public Internet access to:
An instance
An AWS elastic network interface (ENI)
Other services needing a public IP address
we allocate EIPs for long-term permanent network usage.
Network/subnet security
VPCs use security groups to provide stateful protection (the state of the connection session is maintained) for instances. AWS describes security groups as virtual firewalls.
VPCs also provide network access control lists (NACLs) to stateless VPC subnets—that is, the state of the connection is not maintained.
Additional networking services
Of course, these are not the only AWS services a VPC provides. we can use VPC to configure other common networking services such as:
- Virtual Private Networks (VPNs)
- Direct connectivity between VPCs (VPC peering)
- Gateways
- Mirror sessions
- elements of aws vpc
VPCs & shared responsibility
Before we start configuring VPCs, check out Amazon’s Shared Responsibility model. Per Amazon, security and compliance is a shared responsibility between AWS and its customers.
For our AWS account and configurations, AWS is responsible for the “Security of the Cloud” while customers are responsible for “Security in the Cloud.” Generally:
- AWS is responsible for the AWS cloud infrastructure (hardware, cloud software, networki
ng, facilities) that run AWS services. - Customers are responsible for what they run in the cloud, such as servers, data, encryption, applications, security, access, operating systems, etc.
- The shared responsibility model lays out who is responsible for specific issues when we experience AWS downtime, security breaches, or loss of business. It is important to understand these limits as we set up our VPC configuration. Consult the shared responsibility model for more information.
More info about AWS VPC
- Create a VPC with a /16 IPv4 CIDR block. Refer to Step 1-Create the VPC in http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/getting-started-ipv4.html for details.
- Edit the VPC to enable DNS hostname. Refer to http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html to enable DNS hostname.
- Create a subnet on the VPC that can be used by elastic load balancers(ELB). This is our public subnet. Refer to http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html#AddaSubnet to add a subnet.
- Enable auto-assignment of public IPv4 addresses for the public subnet created in the step above. Refer to http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html#subnet-public-ip to enable auto-assignment of IPv4 addresses.
- Create and attach an Internet gateway to your VPC. Refer to the Attaching an Internet Gateway section at http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_ Gateway.html, to create and attach an internet gateway to the VPC.
- Create a route table in your VPC and add a route with a destination of 0.0.0.0/0 for IPv4 traffic. Refer to http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_ Gateway.html for details.
- Forward all traffic to the Internet gateway for this route.
- Set the route table as the main route table. Refer to the Main Route Tables section in http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_ Tables.html for details.
- Create a subnet on the VPC. Ensure that the auto-assign IP address attribute is disabled so that this becomes a private subnet. Ensure that the availability zone for this subnet is the same as the one that is used in the public subnet.
- Create a NAT gateway on the public subnet. While creating the NAT gateway, create an Elastic IP and assign it to the NAT gateway. Refer to http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html#nat-gateway-creating for details.
- Create a route table for the private subnet. This is the NAT route table. Add a route for the NAT table and forward all traffic to the NAT gateway created on the VPC.
- Edit the route table subnet association to associate the NAT route table with the private subnet.
- Repeat the steps 3 to 12 for each availability zone to create public and private subnets for the availability zone.