CloudFormation Custom Resource: Transit Gateway Peering Accepter
A Transit Gateway Peering Attachment must be accepted by the owner of the attachment. Even if both Transit Gateways are in the same account. To automate this with CloudFormation I have created a custom resource.
Introduction Transit Gateway Peering
Let’s start with a small introduction to Transit Gateway peering.
When you want to connect multiple AWS regions together you have some options. For example this can be done with VPC peering, VPN’s or with Transit Gateway peering. In this article we will focus on Transit Gateway peering.
Transit Gateway has the ability to establish peering connections between Transit Gateways in different AWS Regions. The communication between the peering connections is encrypted, traverses the AWS global network and is not exposed to the public internet. Therefore, allowing the resources attached to the gateways to communicate with each other. These resources include all the VPCs, Site-to-Site VPN connections and Direct Connect gateways.
The Transit Gateway attachments allow bidirectional communication therefore you only need one attachment to connect two gateways together.
Custom Resource - Peering Attachment Accepter
When you set up the peering attachment between two Transit Gateways only the owner of the attachment can accept it. This can be done by hand in the console, the CLI or the API. But when deploying with CloudFormation it can be automated. Therefor I have created a Custom Resource.
The lifecycle of the attachment is as follows:
A Transit Gateway Attachment can be accepted if the state is
pendingAcceptance after accepting the attachment it will go into the
pending state if successful the attachment becomes available after 2-5 minutes.
The Custom Resource will wait for the
pendingAcceptance state and then accept it with the Boto3 function
accept_transit_gateway_peering_attachment(), more information about this function can be found here
After accepting the attachment it will go to the
pending state, the Custom Resource will then wait for the
available state and send a SUCCESS response to CloudFormation.
If however something fails the Custom Resource will send a FAILED response to CloudFormation.
The source code for this Custom Resource can be found in this repository GitHub: transit-gateway-peering-accepter in the file
Also, I have added some CloudFormation templates with the working Custom Resource. And as a bonus I created a CloudFormation template with a fully functional Transit Gateway setup in multiple regions and EC2 instances to perform a ping cross region.
Source code: GitHub: transit-gateway-peering-accepter