AWS Step-by-Step
Virtual Private Cloud Peering with AWS, Part 1: The Guidelines
VPC peering can be useful for linking resources that would otherwise be isolated from one another. But before you set it up in AWS, it's important to know the ground rules.
I have been talking about virtual private clouds (VPCs) within Amazon Web Services (AWS) in some of my recent columns -- specifically, here and here. In this one, I'll talk about about VPC peering, which is is essentially a way of enabling IP communications between two VPCs.
Functionally, VPC peering is similar to site-to-site VPN, in that it allows communications between two otherwise isolated environments. The biggest difference between VPC peering and site-to-site VPN, however, is that no VPN connection is required.
VPC peering can be used to enable communications between two VPCs that exist within a common AWS subscription. However, VPC peering tends to be more useful for enabling communications between two different AWS accounts. This is useful if you have created separate VPCs for each department and need to enable inter-department communications.
AWS allows you to set up a VPC peering connection between a VPC that is associated with an AWS account, and another VPC that is associated with a different AWS account.
I will show you how to set up VPC peering in next week's column. For right now, though, I need to spend some time talking about what you can and cannot do with VPC peering.
One of the first limitations that you need to know is that VPC peering is region-specific. As you may recall, when you create a VPC, you must specify a region for that VPC. When you enable VPC peering between two VPCs, those VPCs must exist within the same region.
Another important thing that you will need to know about VPC peering is that the instances within a VPC communicate with instances in a peered VPC using either the IPv4 or the IPv6 protocol. When you enable VPC peering, you are essentially establishing network connectivity between the peers. Because of this, the same rules apply to the VPC peers as would apply to any other IP network.
More specifically, VPCs that have been peered together cannot contain duplicate IP addresses or overlapping IP address scopes.
This brings up another important point. VPC peering supports both IPv4 and IPv6. However, if you want to use IPv6, then you will have to manually configure the various network resources. According to the AWS documentation, you will need to associate an IPv6 block with both of the VPCs. You will also have to configure the instances within the VPCs to use IPv6 communications.
Finally, you are going to have to update your routing tables so that AWS will know how to route IPv6 traffic that is destined for an instance within a peered VPC. Keep in mind that these configuration steps are unique to IPv6 and are not required for IPv4 communications.
Because VPC peering is based on establishing connectivity between two VPCs, there are a couple of architectural limitations that you will need to know about. For starters, AWS only allows you to create a single peering relationship between two VPCs. Of course this limitation is common sense, because there is no real advantage to creating multiple peer links between the same set of VPCs.
A second, more important, architectural limitation is that peer relationships are not transitive. In some instances, the lack of transitive peering can mean more work for an administrator. Ultimately, however, the lack of support for transitive peering is usually a good thing. There are two reasons for this.
Suppose for a moment that you have three VPCs and that you have established a series of peer relationships so that all of your VPCs can communicate with one another. Just to make things interesting, let's also pretend that each VPC is associated with a particular department. Now, suppose that the boss tells you that you have to establish a peer relationship between the VPC for the marketing department and a VPC belonging to a partner organization. In this case, the lack of support for transitive peering would be a good thing, because you probably would not want for the partner organization to have access to resources belonging to other departments.
The other reason why the lack of transitive peering is a good thing is because it protects you against external peer relationships. Suppose that your organization established a peer relationship to a supplier. What happens if that supplier then establishes a peer relationship to another organization? In this, you are not affected by the supplier's new peer relationship, but if peering were transitive, then it might mean that you could see into the new organization's network and they could see into yours.
VPC peering can be a very powerful tool for linking resources that would otherwise be isolated from one another. In Part 2 here, I show you how to set up VPC peering. In the meantime, you can read more about VPC peering limitations in the AWS documentation here.
Related:
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.