Introduction
In this blog post, I will be presenting an AWS solution to fully automate the build of multiple VPCs across separate accounts interconnected via AWS Transit Gateway. I will go over the core services used in this solution, the problem we’re solving and how the solution is constructed and deployed. The build for the solution is available on GitHub.
The common challenge we see
- Many organizations have strict requirements and governance around who and what can access their AWS environment
- It can be difficult to set up network resources using infrastructure as code (IaC) as there are a lot of dependencies between resources e.g. Transit gateway needs to be created and shared before it can be referenced across accounts for VPC attachments and these attachments need to exist before we can reference them in the transit gateway route tables
- Manual steps and intervention is often required in deploying a highly dependent network solution
The solution shown in this post solves these problems through a fully automated series of pipelines to build out the entire architecture.
What is CodePipeline and why use it?
AWS CodePipeline is a continuous delivery service you can use to model, visualize, and automate the steps required to release your product.
It is made up of ‘stages’ that occur sequentially. Within each stage you have ‘actions’ that define what to execute as part of the release.
This allows you to define a workflow for full end-to-end automation for any changes you wish to deploy.
The solution shown in this blog post uses source, build and deploy actions to deploy a fully functional Multi-VPC architecture interconnected using Transit Gateway.
What is Transit Gateway and why use it?
AWS transit gateway is a network transit hub that you can use to interconnect your virtual private clouds (VPCs) and on-premises networks.
It is a simple way to allow for many VPCs to be interconnected through a ‘hub and spoke’ model where transit gateway is the hub and the VPCs are the spokes.
It can reduce costs by having a single ‘egress’ VPC reducing the need for redundant NAT Gateways.
It has become a staple service used in many projects that involve many VPCs across several accounts.
What is CDK and why use it?
Cloud Development Kit (CDK) is an Infrastructure as Code (IaC) tool that can be used to standardize and automate the provisioning of your AWS Infrastructure.
It is a high level abstraction of Cloudformation (cfn) where you can define your resources in a common programming language (Python in this solution’s case) which then gets ‘synthesized’ to Cloudformation (JSON).
It does a lot of the heavy lifting for you through ‘L2 constructs’ which generate cfn that would otherwise be verbose to write out.
What we are building
The above shows that we are going to deploy three pipelines to build out our infrastructure. These pipelines will be deployed to a tooling account.
- EnvPipeline — This will link to our repo in GitHub (can also use BitBucket or CodeCommit) and will execute when any change has been pushed to a branch of your choice (has been set to main by default). This pipeline will create our networking VPC and most importantly our Transit Gateway under the networking account
- TGW-Attachments — This pipeline will be executed on completion of the first pipeline and create all the other spoke VPCs including the Egress VPC which contains NAT Gateways and Internet Gateway for outbound internet access. Most importantly, it will create the attachments to the transit gateway
- TGW-Routes — This pipeline will be executed on completion of the second pipeline and create the routes in the transit gateway route tables so that the traffic can be routed correctly to the destination VPC. Currently this has been set to go to the Egress VPC first before being routed to the destination so that the Egress VPC can be potentially turned into an inspection VPC
As you can see, it is a three-step pipeline/process with each pipeline being dependent on the previous one completing. By splitting this up into three pipelines that are executed by the previous one in turn, we are able to automate the whole build end-to-end.
The cdk package we’re using for this implementation is CDK Pipelines which is a construct that makes it very simple to set up a self-mutating pipeline, which is essentially a pipeline that transforms whenever cdk changes so that the updated cloudformation templates are deployed.
We are using SSM parameters to store variables such as Transit gateway/attachment IDs so that we can make cross-stack references to these across accounts.
The above is a diagram to show what these pipelines are building out. As you can see, we are creating a transit gateway and all the VPCs to attach to it which are under different accounts. Finally we are creating the routes on the transit gateway route tables in the center of the diagram.
Setup and Deploy
To setup this solution and deploy is a simple three step process
- Create a codestar connection to link to your repository that will contain your CDK project
- Run a cdk bootstrap on all the accounts that you are attaching to your VPC. This will bootstrap the accounts with roles required for cdk to deploy to our accounts. This will also require the flag to trust the tooling account e.g. cdk bootstrap –-trust <toolingAccountNo> — cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess aws://<accountNo>/<region>
- Run a cdk deploy to deploy all the pipelines to your tooling account i.e. cdk deploy --ignore-errors --require-approval never -all
For more detailed instructions and access to the repository on GitHub
Final thoughts
This same pattern can be applied to anything that has a highly dependent architecture where certain resources need to exist across accounts before other resources can be created. Through using multiple pipelines we are able to make cross-stack references in CDK/cloudformation across accounts using SSM parameters.
