Main menu

NETWORKING

AWS Security Tutorial: VPC Setup

In this excerpt from "Mastering AWS Security," learn how to configure a Virtual Private Cloud in Amazon Web Services.

Let's look at the steps to create a custom Virtual Private Cloud in an AWS account. This VPC will be created using IPv4 Classless Inter-Domain Routing (CIDR) block. It will have one public subnet and one public-facing instance in this subnet. It will also have one private subnet and one instance in private subnet. For instance, for a private subnet to access the internet, we will use a NAT gateway in a public subnet. This VPC will have security groups and network ACL configured to allow egress and ingress internet traffic along with routes configured to support this scenario:

Create a VPC with a /16 IPv4 CIDR block such as 10.0.0.0/16.

Create an internet gateway and attach it to this VPC.

Create one subnet with /24 IPv4 CIDR block, such as 10.0.0.0/24, and call it a public subnet. Note that this CIDR block is a subset of a VPC CIDR block.

Create another subnet with /24 IPv4 CIDR block, such as 10.0.1.0/24 and call it a private subnet. Note that this CIDR block is a subset of a VPC CIDR block and it does not overlap the CIDR block of a public subnet.

Create a custom route table and create a route for all traffic going to the internet to go through the internet gateway. Associate this route table with the public subnet.

Create a NAT gateway and associate it with the public subnet. Allocate one Elastic IP address and associate it with the NAT gateway.

Create a custom route in the main route table for all traffic going to the internet to go through NAT gateway. Associate this route table with the private subnet. This step will facilitate the routing of all internet traffic for instances in the private subnet to go through the NAT gateway. This will ensure IP addresses for private instances are not exposed to the internet.

Create a network ACL for each of these subnets. Configure rules that will define inbound and outbound traffic access for these subnets. Associate these NACLs with their respective subnets.

Create security groups for instances to be placed in public and private subnets. Configure rules for these security groups as per the access required. Assign these security groups with instances.

Create one instance each in the public and private subnet for this VPC. Assign a security group to each of them. An instance in a public subnet should have either a public IP or an EIP address.

Verify that the public instance can access the internet and private instances can access the internet through the NAT gateway.

Once all steps are completed, our newly created custom VPC will have the following architecture. Private instances are referred to as database servers and public instances are referred to as web servers in the diagram. Note that the NAT gateway should have the Elastic IP address to send traffic to the internet gateway as the source IP address. This VPC has both the public and private subnet in one availability zone; however, in order to have a highly available and fault-tolerant architecture, you can have a similar configuration of resources in additional availability zones:

Figure 11: AWS custom VPC (click on image for larger view)

VPC connectivity options

One of the major features of AWS VPC is the connectivity options it provides for securely connecting various networks with their AWS networks. In this section, you will learn about various connectivity options for AWS VPC, such as connecting remote customer networks with VPC, connecting multiple VPCs into a shared virtual network, and so on. We will look at three connectivity options in detail:

Connecting the user network to AWS VPC

Connecting AWS VPC with another AWS VPC

Connecting the internal user with AWS VPC

Connecting user network to AWS VPC

You can extend and integrate your resources in your remote networks, such as compute power, security, monitoring, and so on, by leveraging your resources in AWS VPC. By doing this, your users can access all resources in AWS VPC seamlessly like any other resource in internal networks. This type of connectivity requires you to have non-overlapping IP ranges for your networks on the cloud and on-premises, so ensure that you have a unique CIDR block for your AWS VPC. AWS recommends that you use a unique, single, non-overlapping, and contiguous CIDR block for every VPC. You can connect your network with AWS VPC securely in the following ways:

Hardware VPN: You can configure AWS-compatible customer VPN gateways to access AWS VPC over an industry standard, encrypted IPsec hardware VPN connection. You are billed for each VPN connection hour; that is, for every hour your VPC connection is up and running. Along with it, you are charged for data transfer as well.

This option is easier to configure and install and uses an existing internet connection. It is also highly available as AWS provides two VPN tunnels in an active and standby mode by default. AWS provides virtual private gateway with two endpoints for automatic failover. You need to configure customer gateway side of this VPN connection; this customer gateway could be software or hardware in your remote network.

On the flip side, hardware VPN connections have data transfer speed limitations. Since they use an internet to establish connectivity, the performance of this connection, including network latency and availability, is dependent on the internet condition.

Directconnect: You can connect your AWS VPC to your remote network using a dedicated network connection provided by AWS authorized partners over 1-gigabit or 10-gigabit Ethernet fiber-optic cable. One end of this cable is connected to your router, the other to an AWS Direct Connect router. You get improved, predictable network performance with reduced bandwidth cost. With Direct Connect, you can bypass the internet and connect directly to your resources in AWS, including AWS VPC.

You can pair Direct Connect with a hardware VPN connection for redundant, highly available connectivity between your remote networks and AWS VPC. The following diagram shows the AWS Direct Connect service interfacing with your remote network:

Figure 12: AWS Direct Connect (click on image for larger view)

AWS VPN CloudHub: You might have multiple remote networks that need to connect securely with AWS VPC. For such scenarios, you will create multiple VPN connections, and use AWS VPN CloudHub to provide secure communication between these sites. This is a hub and spoke model that can be used either for primary connectivity or as a backup option. It uses existing internet connections and VPN connections.

You create a virtual private gateway for your VPC with multiple customer gateways for your remote networks to use AWS VPN CloudHub. These remote networks should not have overlapping IP networks. The pricing model for this option is similar to that of a hardware VPN connection.

Software VPN: Instead of a hardware VPN connection, you can also use an EC2 instance in your VPC with a software VPN appliance running in order to connect your remote network. AWS does not provide any software VPN appliance; however, you can use software VPN appliances through a range of products provided by AWS partners and various open source communities present on AWS marketplace. It also uses the internet for connectivity; hence, reliability, availability, and network performance are dependent on the internet speed.

This option, however, supports a wide variety of VPN vendors, products, and protocols. It is completely managed by customers. It is helpful for scenarios where you are required to manage both ends of a connection, either for compliance purposes or if you are using connectivity devices that are currently not supported by AWS.

Connecting AWS VPC with other AWS VPCs

If you have multiple VPCs in multiple regions across the globe, you may want to connect these VPCs to create a larger, secure network. This connectivity option works only if your VPCs do not have overlapping IP ranges and have a unique CIDR block. Let's look at the following ways to connect AWS VPC with other AWS VPCs:

VPC peering: You can connect two VPCs in the same region using a VPC peering option in AWS VPC. Resources in these VPCs can communicate with each other using private IP addresses as if they are in the same network. You can have a VPC peering connection with a VPC in your AWS account and VPC in other AWS accounts as long as they are in the same region.

AWS uses its own existing infrastructure for this connection. It is not a gateway or a VPN connection that uses any physical device. It is not a single point of failure or a network performance bottleneck.

VPC peering is the most preferred method of connecting AWS VPCs. It is suitable for many scenarios in large and small organizations. Let's look at some of the most common scenarios.

If you need to provide full access to resources across two or more VPCs, you can do that by peering them. For example, you have multiple branch offices in various regions across the globe and each branch office has a different VPC. Your headquarter needs to access all resources for all VPCs for all your branch offices. You can accomplish this by creating a VPC in each region and peering all other VPCs with your VPC.

You might have a centralized VPC that contains information required by other VPCs in your organization, such as policies related to human resources. This is a read-only VPC and you would not want to provide full access to resources in this VPC. You can create a VPC peering connection and restrict access for this centralized VPC.

You can also have a centralized VPC that might be shared with your customers. Each customer can peer their VPC with your centralized VPC, but they cannot access resources in other customers' VPC.

Data transfer charges for a VPC peering connection are similar to charges for data transfer across availability zones. As discussed, VPC peering is limited to VPCs in the same region. A VPC peering is a one-to-one connection between two VPCs; transitive peering is not allowed for a peering connection. In the following diagram, VPC A is peered with VPC B and VPC C; however, VPC B is not peered with VPC C implicitly. It has to be peered explicitly:

Apart from VPC peering, there are other options for connecting VPCs, such as software VPN, hardware VPN, and AWS direct connect as well. All of these options have benefits and limitations similar to the one discussed in the previous section.

Connecting internal users with AWS VPC

If you want to allow your internal users to access resources in AWS VPC, you can leverage your existing remote networks to AWS VPC connections using either hardware VPN, direct connect, or software VPN depending on your requirement. Alternatively, you can combine these connectivity options to suit your requirements, such as cost, speed, reliability, availability, and so on.