logo

Hi to everyone,

 

this little article is a chance for me to get back to the technical stuff which I enjoy more than other things and demonstrate a concept that is likely to come up if you take the AWS Advanced Networking Specialty Certification these days. It may also be a feature of the Solution Architect Pro Certification but not as likely.

 

In my professional life it’s not something I have had to architect for customers due to the limited number of regions in Australia (1 at present) and most customers having Data Sovereignty requirements that preclude inter region connectivity. However with a Second region coming online I have decided to document and architect the approach I would take to this and then demonstrate how it is done on the AWS Console (I generally will use code but for this demonstration I am using the AWS Console).

 

What does the Architecture Look Like?

This is very high level as it just shows that using a Peering Connection (Via a specific Transit Gateway Attachment) the regions can be connected. You can also extend this to multi account but that is a rabbit hole for another blog 🙂

 

 

 

Key Components

The Key Components that are used to deliver this are:

  • AWS Transit Gateway
  • AWS VPC
  • AWS VPC Route Tables
  • AWS Security Groups
  • AWS NACLs

 I am not really going to dive deeply into the NACLs and Security Group requirements as they are pretty self explanatory for the target pre-requisite knowledge for this sort of work

 

Time to Build it

In an environment built at scale you would never do this from the console (AWS CDK, Cloudformation, Terraform are all good Infrastructure as Code options and when I get my Public Repo back up I will write this in all of them) but here we are.

Note: This does involve creating resources in AWS accounts so it is assumed you have access to one and those resources create costs. It is recommended that after completion of these steps resources are deleted to remove those costs.

1. Create a VPC in each Region

The first thing to do is to create a single VPC in each region. They need to have non-overlapping CIDRs. Go to the VPC Service within AWS (Search for it if it is not visible)

Once in the VPC Service you click create VPC

AWS Offers a Single Window option to create VPCs with subnets and even Internet Gateway and NAT Gateways by selecting VPC and More. For the purpose of this exercise I have used that but ensured that NAT Gateways is set to None. For Region 1 I have set the CIDR to 10.0.0.0/16 and for region 2 I have set the CIDR to 10.1.0.0/16

 

Switch to Region 2 and then repeat the process to create a VPC there. I used ap-southeast-2 (my home region) and us-east-1 but any 2 regions available to your org should suffice.

 2. Create a Transit Gateway in each Region and Attach to VPC

In the VPC Console you can select Transit Gateways. Once selected choose Create Transit Gateway

Give the Gateway a Name Tag (Optional) and click Create. Other configurations are available but optional for this purpose. Once each Gateway is created add an attachment to each region and a route for the other VPC points to that Transit Gateway in the VPC Route Tables.

3. Create a Peering Connection between them

Transit Gateways can be peered similar to how VPCs can be peered in the same Region. By Peering the Transit Gateway you can create inter region connectivity without  complicated mechanisms such as Direct Connects, Global Networks, etc. Global Networks (Cloud WANs as they are called now) is suitable for advanced usage cases but for a simple case like this it may be overkill. 

Let’s go ahead and create a Peering  Attachment for Each Transit Gateway for the Other Transit Gateway. This is done by creating an attachment as normally done but change the type to Peering Connection. This can be done in Either of the 2 regions and then accepted in the other.

Once the Connection is created it will set a state of “initiating” and then  “pending Acceptance”. When that state pops up change to the other Region and go to the Transit Gateway attachment and click Accept. After that it will take several minutes for the Completion of the Process.

The Final Requirement is Routing. In each VPC ensure that the CIDR for the other VPC is configured to use the transit gateway attached to the VPC. And for each Transit Gateway Ensure the Route Table has a static route pointing the other VPC CIDR to the Peering Connection Attachment.

Repeat the process for the Alternative region and then you are done. Connectivity would then just require that there is Open traffic allowed on the relevant port (ie ICMP, RDP, SSH) from one VPC to the other and then you can test.

 I Tested by creating a Windows VM in each region and confirmed I could RDP between them.

 

Wrap Up

Don’t forget to delete any resources created to stop losing money.

This is an interesting concept and is certainly a key potential element of a Multi Region strategy. If there is DR Regions or parallel regions hosting work this approach can aid connecting between them. It is not an advanced architecture and for a really advanced multi region strategy that also leverages AWS Back end networking better the Core Network capability of AWS Cloud WAN will do a great job and also support tying in to On Premises Networks as well. I will blog on that in future.

 As I said at the top in a real world scenario this would be done as code and I am in the process of developing some code for my work that will achieve this and when I get time I will develop a vanilla version of that for public consumption.

  I do hope you enjoy when I get a little technical and geeky since I personally love getting to the nuts and bolts of how something works and ramble on about it.