VPC subnets
Even though VPC offers a virtual private cloud, all VPC computing is done within a subnet of a VPC. In other words, your instances all reside within asubnet of the VPC and interact with one another and to the Internet via the subnet. (Your overall set of IP addresses must be partitioned into one or more subnets; every instance in a VPC must reside within a subnet.)
AWS makes it easy to create subnets, in that the VPC wizard in the Management Console provides a dialog box with choices that reflect the subnet types I just discussed. However, your choices aren’t limited to the default topologies listed in the dialog box, because you can add or delete subnets on the subnet page associated with each VPC in your account.
Communication from instances within subnets
Although you can associate an Elastic IP address with an instance within a public subnet, packets from the instance don’t move directly to the Internet.They travel through an Internet gateway associated with the VPC. The Internet gateway isn’t part of any subnet, but resides within the VPC, and all subnet instances that want to send traffic to the Internet have to send it through the Internet gateway.
The concept of communicating to the Internet from an instance in a public subnet is simple: Because the instance has an Elastic IP, it can send and receive traffic from the Internet. Note that an Elastic IP is required even if you want to send traffic to the Internet only from a public subnet. But what happens if you have a private subnet? Private subnets are shielded from the Internet, and it’s impossible to attach an Elastic IP address to an instance within a private subnet. It probably isn’t a problem if the instance can’t receive Internet traffic; if you wanted it to do so, you could have put it in a public subnet. But what if you want it to be able to send traffic to the Internet (to download software updates and patches, for example)? Is this not possible if the instance resides in a private subnet?
The answer is that the instance can’t contact the Internet, though it can talk to a NAT server that can, in turn, forward traffic to the Internet gateway, which makes it possible for the instance to communicate with the Internet. (A NAT server, by the way, is an instance that performs NAT — network address translation. How do you configure the subnets to communicate with other instances and the Internet? You do it with the help of an item called a routing table.
VPC routing tables
Each VPC comes with a virtual router — a (virtual) device that controls all traffic to and from instances. Each subnet must have a specific routing table associated with it to configure how instances within the subnet communicate over the network. The ability to assign a specific routing table to each subnet makes it easy for you to tailor your VPC operation to the needs of your applications.(In Figure 7-5, the routing table is depicted as a circle containing acapital letter R.)
Naturally, each VPC comes with a default routing table; if you don’t explicitly assign a routing table to a subnet, the default routing table is assigned to it.Upon creation, the default routing table has a single rule; this rule enables communication between instances within the subnet.
Just as I recommend that you avoid using the default security group for your security group rules, I also recommend that you avoid using the default routing table for your VPC subnets. You’re always better off creating your own resources with respect to security, because it forces you to think things through more thoroughly and enables better security partitioning.
If, after you’ve created your own routing table, you can — if your subnet is a public subnet — include a rule to allow the subnet instances to communicate with the Internet gateway and thereby communicate with the Internet.
Internet gateway
The Internet gateway is a resource that can be attached to a VPC to enable all subnets to communicate with the Internet. If you use the Management Console to create your VPC, an Internet gateway is automatically created and associated with your VPC.
For any subnets that you want to communicate with the Internet, you must add the Internet gateway to the subnet’s routing table. (Remember that you must also attach an Elastic IP to every instance that you want to communicate with the Internet; an instance with an Elastic IP attached to it can then communicate with the Internet gateway, which in turn forwards traffic to the general Internet.) Any time your instance makes a call to an address outside the bounds of the subnet containing it, the traffic travels through the Internet gateway and then on to the Internet. Likewise, any traffic directed toward your Elastic IP must transit through the Internet gateway.
NAT servers
What if you’ve created a private subnet and want it to communicate with another subnet or the Internet? Are you prevented from doing so because you have a private subnet? Not at all, but you do have to use a special instance that sends traffic back and forth between the two subnets — a NATinstance. Figure 7-6 shows a more complex VPC configuration than the one depicted earlier, in Figure 7-5. In Figure 7-6, you can see that a NAT instancehas been included in the public subnet 10.0.0.0, allowing for traffic fromthe 10.0.1.0 subnet to transit to the Internet via the Internet gateway.
A NAT instance is, in effect, a traffic cop that resides within a public subnet and accepts traffic from instances on private subnets. As you may already ave guessed, for the NAT instance to do its job, you need to create a security group for it. The security group includes which ports the NAT accepts traffic on, but also the source — the private subnet address used to forward traffic to the NAT instance. You need to add multiple rules for, say, Port 80 (web traffic) — one for each private subnet that the NAT instance will accept traffic from.
NAT instances also require a bit of tweaking in that regular EC2 instances are set up for source/destination checking. As Amazon states in its VPC documentation about source/destination checking: “This means the instance must be the source or destination of any traffic it sends or receives. However, the NAT instance needs to be able to send and receive traffic where the eventual source or destination is not the NAT instance itself. To enable that behavior, you must disable source/destination checking on the NAT instance.
”Essentially, EC2 instances always expect to generate or respond to traffic, but never to act as a gateway that passes traffic along. They are configured to accept only traffic that the instance sends or receives and respond to the sending address directly. A NAT instance acts as a gateway and receives traffic from an instance and sends it along to a server on the Internet, so it “breaks” the source/destination checking. For that reason, after you launchthe NAT instance, you have to disable this checking: Select the instance within the AWS Management Console, right-click, and then click the ChangeSource/Destination Check option in dialog box.
The VPC configuration shown in Figure 7-6 illustrates the power of VPC. You can see that the VPC contains two subnets: one public and one private. The public subnet contains a number of instances, all of which are exposed to the Internet. The application’s database servers, however, are segregated into aprivate subnet, and none of them carries public IP addresses. No traffic from the Internet, therefore, can directly access the database servers, thereby increasing their security.
This approach is an improvement over the security group-based tiering (which I outline earlier in this chapter) because with no public IP address exposure, malicious traffic faces much more difficulty in accessing a VPC private subnet instance. Note that in Figure 7-6, the public subnet has a custom routing table that provides traffic routing rules for the instances as well as the Internet Gateway, whereas the main routing table is attached to the private subnet and includes the NAT instance information to enable access to the public subnet and subsequently to the Internet itself.
VPC Network Access Control Lists (ACLs)
VPC offers another traffic controlling mechanism beyond security groups. You can create a Network Access Control List (network ACL)to control traffic flow for an entire subnet. You may use a network ACL to impose a strict security regimen at the subnet level to ensure that, even if someone becomes sloppy with instance-level security groups (say, by opening a wide range ofports for public access from the Internet), you would ensure that no inappropriate traffic can access subnet instances, because the ACL prevents it from even entering the subnet.
To manage an ACL, you create a set of rules that are evaluated in order according to rules numbers you assign to each rule. An ACL essentially offersa Linux-like firewall, with all the fun of managing rules, ensuring that they’re applied in the correct order, and that a later rule doesn’t undo the work of an earlier rule. Good times.
Elastic Network Interfaces
Unlike EC2, which restricts instances to a single virtual network interface card (NIC), a single private IP address, and a single public IP address, VPC allows multiple virtual NICs and multiple IP addresses. Each of these virtual NICs (referred to as elastic network interfaces) can have its own security groups, which enables you to allow public Internet access on one elastic network interface, open on Port 80 to the world, with another elastic network interface with a different security group that has Port 22 (ssh) open only to your corporate network.
Another scenario is that you can have an instance that acts as a gateway between two subnets and passes traffic back and forth. Though this may seem like a NAT instance, a gateway instance with two Elastic Network Interfaces may be used for an all-private subnet scenario in which instances in one subnet (say, a sales group) sends data requests to a database server in the other subnet, which belongs to the finance department. The finance department doesn’t want to allow general access to servers from the sales department, so it sets up a gateway server that shields the database server from direct access.
Elastic network interfaces can be used to partition subnets, and then shouldbe used in environments where the separation of computing resources is important for security or compliance reasons.
VPC access to other AWS services
A theme of this book is that one of the great benefits of AWS is the range of services it provides. Chapters 8 and 9 cover these services in greater detail, but trust me for now: There are a lot of great AWS services. How can a VPC instance access an AWS service such as Simple Queue Service (SQS)?
The answer is that access to other AWS services is routed through the Internet gateway. However, your request to AWS services doesn’t go all the way out to the Internet and back into AWS (which would incur network traffic charges on traffic); instead, the Internet gateway recognizes that the traffic destination is within AWS and takes a shortcut to the AWS service without sending traffic outside of AWS. Cool, right?
VPC scope
VPC is, like most other AWS services, region-scoped. You can have a VPC in US East and a separate VPC in US West-Oregon. Traffic between them travels over the public Internet and incurs a network charge (although it’s a much lower charge than if the traffic were going to a non-AWS location).
VPC cost
The best thing about VPC is its cost: nothing. Amazon provides a way for you to improve your AWS security and doesn’t charge you a cent for it. You pay a fee for any unused VPC Elastic IPs, just as you do for EC2 Elastic IPs, but this fee is nominal. And, of course, you pay normal fees for all AWS resources — an instance running in VPC racks up instance charges. But for VPC itself? Nothing.
Using VPC
VPC is an excellent solution to an issue highlighted earlier in this chapter: How to avoid exposing instances and data that you prefer to shield from outside Internet access when every EC2 instance has a public IP address.
Using VPC, you can implement a dual-subnet application topology, in which the appropriate Internet-facing instances — the web servers — are placed in a public subnet, whereas instances that you’d prefer to not be accessible to the Internet — database servers, of course, but potentially other types ofinstances as well, such as cache servers and the like — are placed in a private subnet.
A viable deployment strategy that you can pursue is to leverage VPC heavily and use a private, subnet-focused application design, where you place in a public subnet only those instances that need to be accessible to outside traffic and you place all other application instances within a private subnet, where they’re shielded from all outside traffic. Any Internet access necessary for private subnet-based instances (to download software updates and patches, for example) can take place via a NAT instance.
