VPC Peering is the way that two VPC’s with distinct CIDR spaces within the same REGION can be linked together. Whether you actually need to do this could be moot – but I can imagine a scenario where each VPC were different companies within in a holding group, or else you were using VPC’s on a departmental basis. You could still maintain separate “root” accounts for billing purposes, as VPC peering can be setup with multiple “root” AWS user accounts. For legal reasons the VPC’s might need to be separated, but they maybe “natural synergies” between companies within the same group or between departments where communication is desirable or needed.
Aside: You should normally be VERY worried when management uses the term “natural synergies”, as it is term that normally suggests two companies merging and job redundancies. Such are the euphemisms of modern employee relations!
Note: I found this Rackspace article useful especially as it outlined some of the limits around using VPC connections and some of the pitfalls of excessive VPC and VPC Peer Connections – https://blog.rackspace.com/vpc-peering-architecture-use-cases-guidance
There are two main “rules” around VPC Peer Connection in Amazon AWS. Firstly, The two VPC’s to be connected together must have own unique CIDR. It’s not possible to VPC Peer a VPC where they both have the same CIDR such as 10.0.x.y/16. Secondly, the VPC can be managed by the SAME Amazon “root” account or as I said a moment ago – DIFFERENT Amazon “root” accounts. If it different accounts the later then the two “root” administrators of the VPC’s would have to work together as credentials are needed on both sides.
I see this as being a lot like the “trust” relationships we used to make manually in the not so good old days of Windows NT4 (God, how that ages me!). However, if you of my generation you might remember that before “Active Directory” those trust relationships were not transitive. So just because VPC1 connects to VCP2 and VCP2 connects to VCP3, it does NOT follow that VCP1 can communicate to VCP3. So the VCP Peering Connections do not flow from one VPC seamlessly to another.
The VPC Peering wizard creates a “PCX” target that can be referenced in the routing tables to allow communication to pass from one VCP to another. When using the VCP wizard one side of the relationship between the VCP acts as the “Requester”, and the opposite side acts as the “Acceptor”. The communication is automatically two-way so there’s no need to create the VPC Peering Connection twice. If you making the VCP Peering Connection between two VCP under the SAME Amazon “root” account you merely select two different VPCs – as you are both the “requestor” and “acceptor” at the same time.
So in the screen grab below the “Requestor” is my VCP called “Prod” using 10.0.x.y./16 as the CIDR, and the “Acceptor” is my VCP called “Dev” with the CIDR of 10.1.x.y/16. The fields are completed by merely browsing the VPC metadata queried using the currently used “root” account.
Once you click “Create Peering Connection” the status will change to “Pending Acceptance”. This happens even if you using the SAME account to create both the request and acceptance. You must right-click and select “Accept Request” for it to be approved. Essentially, you are approving your own admin tasks…
Once accepted, the routing tables will need to be updated. The pop-up box that that appears doesn’t really do much accept redirect you to the routing tables section for your VPCs.
As with all routing I need to tell both side of the link what “target” should be used to get to the other network. So the routing table for Prod (10.0.x.y/16) needs to be told there is a network called 10.1.x.y/16 and what target to use for it…
and like wise for the opposite end of the connection in VPC “Dev” default routing table.
Note: I must admit doing routing tables in this way feels somewhat arcane. It takes me back to the mid-90s when I was Microsoft Certified Trainer teaching a 5-day course on TCP/IP (Yes, I know 5-days on TCP!). The course had a section on routing – first with manual routing tables, and then looking at protocols like RIP/OSPF. After becoming a Citrix and later a VMware instructor, I didn’t think I’d ever have to get my hands dirty at this level with routing tables!
These routing updates had immediate effect as I was modifying the tables for two VPCs that had I ownership for. However, if they were controlled by separate route accounts, these changes could be being made by two different “root” accounts, so they won’t take effect until the VPC Peer Connection itself is approved.
Once I was setup I was able to ping from one Windows Instance in my prod (10.0.4.16) to another Windows Instance in my dev environment (10.1.2.102). I must admit this didn’t work right out of the box, because of previous admin work that I had done. I did have to make sure that the 10.0.4.x.y network was associated with the default routing table for traffic to flow.
Finally, something not touched on in the PluralSight course (perhaps because it was a feature not added until June, 2016) is enabling DNS support between the VPC’s once the VPC Peering Connection has been enabled. I found the how to do this, and support statement here:
It’s a pretty easy task to do, as you merely edit the settings of the VPC Peer Connection, and enable it. I found once enabled it worked immediately without any waiting around.
Finally, deleting peer connections – also gives you the option to clean up the routing table changes associated with the PCX target like so:
Conclusions
To be honest I didn’t really learn anything new by revising the “VPC Peer Connection” feature. But it was helpful revision – the only thing I really experienced that was “new” was enabling the DNS options on the properties of the connection itself.
What next for me. Well, I intend to keep on ploughing through my notes that I made on the course. Re-reading them to refresh the brain-cells and blogging along the way when I find something worthy of note. There are other training materials out there – but I actually think getting my hands dirty and writing my own notes and blog posts is helping me get this into my head. Like anyone studying towards a certification it’s tempting to jump in and take a practice test to find out how much I actually know. But I’m actually enjoying the consolidation process of getting this stuff rock solid in my head first. My priority isn’t really passing a certification test to be a SysOps Admin – as it’s a role that I’m unlikely ever to do for real. Although it would be handy to have a certificate to show for my efforts – just like the swimming certificate I have up on my office wall for completing my 25 meters back in the 1980’s.