In our last post, we talked about how to export data from AWS S3 for migration and today let’s discuss what AWS Virtual Private Network is.
AWS Client VPN
First, AWS Client VPN is a client-based managed VPN service provided by AWS. With AWS Client VPN, you can access resources in your AWS private subnets from anywhere using an OpenVPN-based VPN client, allowing you to securely connect to AWS resources and resources in your on-premises network.
Once the Client VPN endpoint is created and configured in AWS, clients, such as my laptop, can connect to the Client VPN endpoint using an OpenVPN client. This enables access to resources in the subnet via the private IP address of the AWS subnet through the VPN tunnel on the local laptop.
Of course, the VPN connection is made over the Internet. Once the VPN connection is established, the local laptop and the VPC subnet can communicate securely via private IP addresses through the VPN tunnel. This is the primary purpose of establishing a VPN. For example, if there is an EC2 instance in the associated subnet, we can use the EC2 instance’s private IP address to access that instance through the VPN on the local laptop.
In this architecture, we can connect the VPC to the on-premises data center network via AWS Site-to-Site VPN. In this way, when our laptop establishes a VPN connection, it can directly access resources in the on-premises data center using their private IP addresses.
For certification exams, having a basic understanding of AWS Client VPN is generally sufficient. In actual organizations, there are quite a few scenarios where AWS Client VPN is used. If you are interested in this part, you can conduct experiments and set it up yourself.
Software VPN
Next, let’s discuss software VPNs. Previously, we talked about AWS Site-to-Site VPN and AWS Client VPN; these are managed services by AWS, and we only need to configure and use them.
However, you can also choose not to use these managed services and instead set up a software VPN on your local environment or on EC2. If you are setting it up yourself, you will need to handle all the configuration and management tasks, such as whether the VPN server’s bandwidth is sufficient, the security of the EC2 hosting the VPN, high availability, etc.
Let’s take a look.
By setting up a software VPN on the EC2 instance in the public subnet of the VPC and on the servers in the on-premises data center, and establishing a VPN connection, you can enable communication between instances in the on-premises data center and the VPC’s private subnet using private IP addresses.
This method of software VPN gives us more control over settings and routing configurations. However, as mentioned earlier, a self-hosted software VPN server requires us to be responsible for all management tasks, such as ensuring sufficient bandwidth, redundancy, high availability of the VPN server, and failover management, which can increase management tasks significantly.
VPN Connections for Multiple VPCs
So how can an on-premises data center establish VPN connections with multiple VPCs?
AWS recommends creating a separate VPN connection for each user’s VPC.
For example, if the on-premises data center needs to establish VPN communication with the left VPC, let’s assume it is VPC 1, we will need to create a customer gateway and VGW and create an AWS Site-to-Site VPN for it. If we have a second VPC, we will need to create another AWS Site-to-Site VPN for it. If there is a third VPC, the same applies.
In this scenario, as the number of VPCs increases, the VPN configuration becomes increasingly complex and difficult to maintain. There are two solutions:
If you have many VPCs, AWS recommends using Direct Connect and then using Direct Connect Gateway to meet the aforementioned needs. We will discuss Direct Connect in future sessions.
Aside from this approach, we can also create a shared services VPC.
Shared Services VPC
Let’s take a look at the shared services VPC.
First, create a VPC for placing shared services.
Establish an AWS Site-to-Site VPN between this VPC and the on-premises data center, allowing the on-premises and shared services VPC to communicate via the VPN connection.
Then, we can replicate the services, applications, databases, etc., from the on-premises data center that need to be shared in the shared services VPC; or we can deploy a batch of proxy services in the shared services VPC, allowing other VPCs to access on-premises requests through the proxy services.
Through these two methods, the shared services VPC can have all the replicas of the services that the on-premises data center needs to share, available for access by other VPCs; or by deploying proxy services, access requests from other VPCs can be proxied to the on-premises data center.
In this way, if other VPCs need to access on-premises resources, such as VPC1, VPC2, and VPC3, they only need to create VPC peering connections with the shared services VPC. Since we replicated the services of the on-premises data center in the shared services VPC via Site-to-Site VPN or set up proxies, VPC1, VPC2, and VPC3 can access the on-premises data center resources through the shared services VPC.
This approach of replicating data or services from the on-premises data center within a VPC or providing shared resources to other VPCs via proxy services is the implementation concept of the shared services VPC.
The advantage of a shared services VPC is that it does not require creating VPN connections between the on-premises data center and all VPCs; it only needs to create one VPN connection between the shared services VPC and the on-premises data center. Other VPCs can achieve access by establishing peering connections with the shared services VPC.
It should be noted that in this architecture, VPC1, VPC2, and VPC3 cannot communicate directly with the on-premises data center because, as mentioned earlier, VPC peering connections do not support route propagation.
Other Solutions (Transit VPC and Transit Gateway)
To meet the VPN connection needs for multiple VPCs, another solution is to use a Transit VPC. We will discuss Transit VPC in future sessions; for now, let’s just have a basic understanding.
A Transit VPC is set up by self-hosting a software VPN on an EC2 instance within a VPC, connecting all other VPCs and the on-premises data center through this VPN. The connections established in this way allow route propagation, meaning that communication can be established between VPCs as well as between a VPC and the on-premises data center.
The advantage of using Transit VPC compared to the previously mentioned shared services VPC is that if certain on-premises services or applications are not easy to replicate, they cannot be made available to other VPCs through the shared services VPC. In this case, using Transit VPC becomes much easier and more convenient.
One important point to note is that VPC peering connections cannot be used, as they do not support route propagation, necessitating a VPN connection.
Of course, we can also use Transit Gateway.
Transit Gateway can connect everything together; it is a simpler way to implement.
