Here is the use case: Imagine you have several VPCs (target VPCs) that you want to attach to a services VPC. In the services VPC you have an application license server, or a Domain Controller, or any other workload that instances in each of the other target VPCs need access to. Every time a new target VPC is created you want to have an easy way to connect that VPC to the services VPC. You also want to use CloudFormation for creating the peer between the target VPCs and the services VPC because it’s easier for you to manage and keep track of the peering connections if they are tied to a CloudFormation stack.
In the picture below, the red arrows represent the target VPCs and the green arrow represents the services VPC. Here we’ll discuss a template that will connect VPC A (services VPC) to VPC G (a target VPC). This template, with slight modifications, could be used for attaching any target VPC (B – G) with the services VPC.
The requirement for a template that would do this would be one that created the following resources;
- A VPC Peering Connection
- A VPC route from the services VPC to the target VPC
- A VPC route from the target VPC to the services VPC.
The two VPC routes listed above could be several routes depending on your routing requirements. Say you had several route tables – one for public subnets and one for private subnets – you would want to account for all of them in the template to make sure they know the proper route to the services VPC.
In this example, since both VPCs (the target and the service VPC) have already been created, the parameters in your CloudFormation template should account for inputting these values. Here we have parameters for the services VPC as well as the target VPC.
Expanding the parameters section we see that the parameter we specified as “ServicesVPC” and “targetVPCtoPeerto” are actually VPC IDs that will be used in the resource section of our template.
Setting these two values as input parameters will let you use this template to theoretically connect any two VPCs together as long as you can provide the VPC IDs. If we were to expand the “RouteTableForTargetVPCYouArePeeringto” we would see the parameter is actually a route table ID.
Since this is a simplified example, we are only peering two VPCs that have a single route table. If we wanted to peer VPCs that had additional route tables, say you had one for private traffic and one for public traffic, you would just add another parameter for the additional route table and tie that to a corresponding resource in the resource section of the template. It’s also important to remember that the parameters can be created and declared but don’t necessarily have to be used or referenced in your template. Additionally, you can see “RouteTableForServicesVPC” is pre-filled because we already are using it with existing peers.
Moving down to the resources section of the template we see that the only resources that need to be created would be the VPC Peering Connection, a VPC route from the services VPC to the target VPC, and a VPC route from the target VPC to the services VPC.
Expanding the resources, we can see that the VPC peering connection will get created and will reference our two VPC ID parameters. Additionally, we will have routes created and assigned to each route table for each VPC. The route has the hard coded “Destination CIDR Block” and references the “VPC Peering Connection ID” created above it. You could very easily strip out the hard coded “Destination CIDR block” and use it as an input parameter as well to give you even more flexibility.
Finally, once this template is run, as long as you put in each of the correct parameters, you will have two VPCs that are connected together via VPC peering.
Remember to adjust the security groups to allow traffic to pass between the VPCs. Also remember the rules of VPC peering. You can see those at http://docs.aws.amazon.com/AmazonVPC/la/PeeringGuide/vpc-peering-overview.html
Please leave a note if you have any comments/question, or you can contact 2nd Watch for all your CloudFormation needs!
-Derek Baltazar, Cloud Architect