AWS Virtual Private Cloud (VPC)                                

As useful as EC2 undoubtedly is, many customers prefer a more secure offering. As I noted in the earlier section “Security Group Best Practices,” even with the best security practices regarding security groups, a potential vulnerability in applications is present when each EC2 instance has a public IP address. Fortunately, AWS addresses this problem with its Virtual Private Cloud (VPC) offering. In broad terms, VPC lets users segregate their instances and shield them from direct Internet access. VPC makes it possible to implement AWS applications that are more secure.          

 

VPC overview

VPC operates by providing you with a virtual network topology that’s separatef rom the general AWS environment. Another way to say this is that via the use of clever software, AWS provides you with a segregated computing environment. Instances are located within your own, private VPC, with no access to them other than via the VPC environment. In a certain sense, what you end up with isn’t dissimilar from a VLAN environment.                            

 

Using a VPC, you can create a separate set of resources that carry private IP addresses within a range you select. You set rules for how traffic enters and leaves instances within the VPC. You can choose to make instances accessible to the public Internet via Elastic IP addresses. Moreover, you can create subnets (in effect, subdivisions of the overall VPC) and control access to and from the subnets and between subnets.                                           

 

You can also make a VPN connection between your own data center and your VPC running over a private circuit. You can use this capability to ensure that no traffic between the two sites is exposed to public access, and you can use your ability to select the private IP address range to align your VPC addresses with your internal company address scheme. The VPC can then act, in effect, as an extension of your corporate computing environment.                                               

 

How VPC works

VPC is straightforward conceptually, though a number of details make it more challenging than “vanilla” EC2. As you make your way through my explanation, keep Figure 7-5 in mind, which should make it easier for yout o follow along. (Note that Amazon goes out of its way to make managing VPCs easier by including VPC administrative capabilities within the AWS Management Console.)                                                        

You start by declaring a VPC within your account. You identify the address you want to use and a CIDR mask to define how many IP addresses you want within your VPC. (See the little cloud within the larger cloud in Figure 7-5? That’s your VPC.) Traffic to and from your VPC is sent via a “virtual router” (Amazon’s term), although a better way to describe it is as a set of rules used to control traffic for your VPC.                                                  

 

Every VPC can have one or more subnets, which can then be used in these four VPC scenarios, based on the types of subnets the VPC contains:

✓ VPC with public subnet: A public subnet is accessible to the public Internet, and instances within a public subnet can directly access the Internet with inbound or outbound traffic. By default, every VPC is created with a public subnet.

✓ VPC with public and private subnet: A private subnet is located within a VPC and cannot access the Internet. Instances within the subnet are limited to sending traffic among themselves, unless an instance offering NAT support is available in a public subnet within the VPC. NAT, which stands for network address translation, is a service commonlyused to send and receive traffic from servers or virtual machines (or, indeed, AWS instances, in this case). If an instance supporting NATis in the associated public subnet, instances within the private subnet can route external traffic through it.

✓ VPC with public and private subnet and hardware VPN access: It’s similar to the scenario in the preceding bullet, but a direct connect also exists between the VPC and an external location (your corporate datacenter, for example).

✓ VPC with only private subnet and hardware VPN access: This scenario allows AWS resources to be completely isolated from public Internet access but to be accessible from an external location, such as your corporate data center.                                                                                              

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

As with standard “vanilla” EC2, you must declare security groups to control traffic for your instances. There’s a major difference between EC2 security groups and VPC security groups, though: Whereas EC2 security groups control traffic into instances but allow all traffic from instances, VPC security groups control traffic to and from instances. If you want your instance to be able to download software updates from a particular site, you must put the site’s IP address into a security group that’s attached to the instance. That is for direct outbound traffic; for traffic that carries responses to inbound traffic( traffic responding to an HTPP request on Port 80, for example), VPC automatically allows traffic from a VPC instance to return traffic to the IP address from which the request originated.                                                              

VPC security groups are completely different from EC2 security groups, and one type cannot be used with the other type of AWS computing environment. Each VPC instance is assigned an IP address within the range you defined when you created your VPC. AWS provides a DHCP service that provides the specific private address for your instance from the range you defined wheny ou created the VPC. (DHCP, which stands for Dynamic Host ConfigurationProtocol, is a service that assigns IP addresses on the fly.) In Figure 7-5, you can see that the entire VPC has been assigned an address beginning with 10.0.0.0, with a CIDR mask of 16 bits, allowing 65,534 addresses within the VPC. One subnet has been created, with the same beginning addressa nd a mask of 24 bits, allowing 255 addresses to reside within the subnet. One instance has been created within the subnet, with an IP address of 10.0.0.6.                                                                                                

This particular instance has the given private IP address and no public IP address. To make this instance accessible from the public Internet (and reside within a public subnet), you can attach an Elastic IP address to it. Elastic IP addresses are similar to security groups, in that VPC and EC2 Elastic IP addresses are different and cannot be applied to the other AWS computing environment. Because VPC instances can have more than one Elastic IP, you can load multiple applications on a single server and have each application associated with a given Elastic IP; then you can perform more useful work on a single instance.