Skip to content
Inter-Region WireGuard VPN in AWS

Let's start by defining Inter-Region VPN and what we are doing today. Reading the title, you are probably asking why VPN? Why not peering or Transit Gateway? Will you are correct. We will be using inter-region VPC peering for this exercise, and if you do this in production, it is best to go with a Transit Gateway.

Let’s say we are in Europe, somewhere in Germany, perhaps Frankfurt, and we want to route our public internet traffic through the US and have a US-based IP. This is slow IMO (in my opinion), so instead of going through all the routers that move the traffic over the public internet, we can use the AWS backbone. Here comes the inter-region VPN to speed things up. We will create the WireGuard EC2 server (Hub) in eu-central-1 (Frankfurt) and connect to it in Frankfurt, and we will be using another EC2 instance in us-east-1 as a NAT (Spoke).

The whole point of this exercise is to use the faster AWS backbone and have a US IP, even though we are in Europe. Below is the basic diagram.

For this POC (Proof of concept), we will be using pure ClickOps (I did not come up with this word), but you are welcome to use IaC tools such as TerraformCloudFormation, or any other IaC tool.

We are going to use the new AWS create VPC wizard.

It is already giving us a nice preview of what the network will look like.

We do this in one region and one availability zone (AZ).

There will be no NAT gateways, as we will be using EC2 for the NAT, and no S3 Gateway, as we are not doing anything with S3. Click on crate VPC.

Our VPC should be created.

Follow the same steps for the EU region. Now, we will create an EC2 in the US region, which will be the NAT, and follow the same steps for the EU region, which will be the Hub.

For instance, type I will use an M6i Large, an intel-based CPU and general-purpose machine, and select a key pair or create one.

For networking, remember to select the public subnet for both EC2s. For this POC, I will be just using a public IP, but if you are doing this in production, remember to use an Elastic IP so it will not change after a restart.

I’m allowing all traffic from my home and 10.0.0.0/8 as the internal CIDR. My home IP is hidden for security reasons. If your other spoke server is not your computer, also add its public IP. In my case, I’m not physically located in the EU, so I had to create a server in the EU.

Add a little more space to your volume, and as a security best practice, ensure your EC2s are always encrypted.

Related Articles

Moving at the Speed of Cryptocurrency with Infrastructure as Code

Read more

Call Center Analytics: Part 3 - Sentiment Analysis with Amazon Comprehend

Read more

Call Center Analytics: Part 5 - Full-Stack Development of the AI Call Center Analysis Tool

Read more

Contact Us

Achieve a competitive advantage through BSC data analytics and cloud solutions.

Contact Us