VPN Service Comparison – AWS vs Azure vs GCP

In our Cloud Product Mapping article, we’ve mapped VPN services provided by AWS, Azure and Google Cloud (GCP). In this article, we’ll compare these three vendors’ VPN services with more details.

Theory

Before we start the comparison, let’s take a quick look at the concept first. If we think of internet as a road, then the data traffic on internet are like cars and trucks travelling on the road. Sometimes certain traffic requires security and privacy. One way to meet this requirement is to build private tunnels and let the vehicles travel within them. Virtual Private Network (VPN) provides such tunnels for companies and users by creating a secure and encrypted private network over a public internet connection.

There are two common types of VPNs, i.e. Site-to-Site (S2S) VPN and Point-to-Site (P2S) VPN. And if we add a cloud flavour to it, these are the common patterns:

The S2S VPN is a common private connection solution for hybrid-cloud and multi-cloud structures. The P2S VPN provides another type of private connection solution for individuals who want to connect to the cloud network from a remote location, like people who work from home. The S2S VPN has an always-on nature that ensures a stable connection between two sites, whereas the P2S VPN is more like an on-demand type of connection. These natures require certain redundancy design for S2S connections, but not so much for P2S connections. Let’s see how AWS, Azure and GCP address these connection scenarios.

VPN Services

Let’s start from AWS first. AWS offers VPN services that can cover both S2S and P2S requirements. For instance, we can use the Site-to-Site VPN service to establish S2S connections. We can use either the Virtual Private Gateway (VPG) as the VPN endpoint to set up a VPN connection to one AWS VPC, or use the Transit Gateway (TGW) to route the VPN connection to multiple VPCs. For P2S connections, we can use the Client VPN service to enable remote users to connect to a VPC instead.

Note that Site-to-Site VPN and Client VPN are two separate services. The high-level overview of where and how to use these services is like below.

For the S2S scenarios, the difference between using TGW and VPG is that TGW supports Hub-spoke topology but VPG doesn’t. In other words, if the VPN traffic needs to reach multiple VPCs, we should use TGW as the VPN endpoint. For the P2S scenario, Client VPN endpoint is the only option. It’s recommend to associate it with more than one subnet to ensure redundancy from the endpoint side. And talking about redundancy, we only showed one “tube” per connection in the diagram, but it’s not suggesting that we only have one tunnel per connection for all these scenarios. We’ll discuss more about it in the High Availability section later.

Azure also provides a fully-managed VPN service that covers both S2S and P2S connections. It’s Azure VPN Gateway. How we can use the VPN Gateway service to set up the S2S and P2S connections are like blow.

Comparing with AWS, Azure provides a “one-service-for-all” type of VPN service to users. We can use this service to provision both S2S and P2S connections. For S2S’s hub-spoke scenario (as shown in the middle lane of the diagram above), we can put VPN Gateway in a shared hub VNet and set up peering connections from this hub VNet to the target VNets. And the bonus is that by using the Gateway Transit, it not only allows the traffic between the on-prem and the spoke VNets, but also allows traffic between the spoke VNets. It addresses the non-transit limitation that’s mentioned in Hub-spoke network topology in Azure.

Now let’s take a look at what GCP offers us. GCP provides the Cloud VPN service that covers the S2S connection. But as of now, GCP yet provides a fully-managed P2S VPN service.

For the hub-spoke scenario, we also need to set up peering connections between the hub VPC and spoke VPC. Unlike AWS’s Transit Gateway and Azure’s Gateway Transit, GCP doesn’t offer a direct transitive option between their spoke VPCs, see VPC Network as a Transit Network. Instead, they addressed this transitive routing in a way via the shared VPC structure. For more information about the shared VPC structure, see GCP Shared VPC.

High Availability

Now let’s come back to the question we parked earlier. We used one “tube” per VPN connection in the earlier diagrams. It doesn’t indicate that there is only one VPN tunnel for all these VPN connections. Instead, one VPN connection can have multiple tunnels within it, especially for S2S connections. Let’s magnify into these “tubes” to explore a little bit more.

Assuming we don’t have the fully-managed VPN services from the cloud end, we’ll then have to use multiple IaaS-based VPN gateways to ensure the adequate redundancy. There are multiple types of redundancy setups. A full-mesh way is like below:

Managing two gateways on the on-prem side is already painful enough, adding two more on the cloud side is doable but not beautiful. So it comes to all these PaaS-based VPN services we are comparing here. When we use these PaaS VPN services, the cloud vendors will take care of the HA and SLA parts. We’ll need to decide what level of redundancy we want to set up, as we may not always require this full-mesh type of redundancy.

To better compare the VPN connection scenarios, we’ve summarized them into the table below. For each connection scenario, we’ll do a comparison among the VPN services from AWS, Azure and GCP.

(*) The quotas per VPG and TGW are different, see Site-to-Site VPN quotas and Transit Gateway quotas.
(**) The maximum number of tunnels and connections vary per SKU, see Azure VPN Gateway SKU.
(***) Each GCP project has its quotas and limits, see VPN and Cloud Router‘s quotas and limits.

Cost

Service cost is an important factor for CSP selection and architectural design. For the same service, the unit costs vary based on the service type and region. CSPs will also adjust their pricing over time. So we won’t compare the dollar amount in this section. Instead, we’ll take a look at how costs are calculated for VPN services across AWS, Azure and GCP.

AWS S2S

• Each VPN connection incurs costs per hour
• Inbound traffic are free
• Outbound traffic, first 100GB is free, the rest incurs costs per GB
• Global Accelerator incurs additional costs per hour
• VPN Data Transfer Premium incurs additional costs per GB
• Transit Gateway incurs additional costs per attachment and per GB

AWS P2S

• Client VPN connection incurs costs per hour
• Each subnet association incurs additional costs per hour

For detailed pricing information and cost calculation examples, see AWS VPN Pricing and Transit Gateway Pricing

Azure S2S

• Each VPN Gateway incurs costs per hour
• Inbound traffic are free
• Outbound traffic incurs costs per GB
• Zone Redundant Gateway SKUs incurs higher costs per hour

Azure P2S

• VPN Gateway incurs costs per hour (different rate comparing with S2S)
• Inbound traffic are free
• Outbound traffic incurs costs per GB (at standard data transfer rates)

For detailed pricing information and cost calculation examples, see Azure VPN Gateway Pricing and Bandwidth Pricing.

GCP S2S

• Each tunnel attached to the gateway incurs costs per hour
• Outbound traffic incurs costs per GB

The hourly rates are the same for both Classic VPN and HA VPN. It boils down to how many tunnels we eventually use. For detailed pricing and cost calculation examples, see GCP Cloud VPN Pricing and External IP Address Pricing.

Summary

AWS, Azure and GCP have provided their own types of VPN as a service to their users. We only compared these services to certain extent in this article. There are a lot more details to be explored and assessed if you are planning to choose a VPN service from these vendors. For these detailed information, you can either refer to the links we added in this article, or navigate from the home vendor page of these VPN services. These home page links are available in our Cloud Product Mapping article.