Site-to-Site VPN

The Site-to-site VPN can only be highly available if both ends of the tunnel are and it’s implemented correctly.

Compared to other methods (like Dx) VPNs are quick to provision! It generally takes from less than an hour to a bunch of hours.

The speed cap for each connection with 2 tunnels is 1.25 Gbps. The speed cap for VGW is 1.25 Gbps. If you need more speed you need to use something else.

Latency is unpredictable, because packets transit over the public internet with an unknown number of hops.

You’re billed hourly + data transfer.

It can be a backup for Dx but also used in conjunction with Dx to provide encryption. You can also hit the ground running with VPC while Dx is being set up (it can take weeks).

Main components

  • Virtual Private Gateway (VGW): AWS gateway that need to be attached to a VPC.

  • Customer Gateway (CGW): this term refers to both

    • The customer on prem gateway or in general the network appliance on the other end.

    • A configuration object on AWS that reflects the state of the network appliance on the other end

How-to

First you greate the VGW. Then you create the CGW object on AWS with the information about the on-prem router (public ip address and so on).

What happens is that upon creating the VGW AWS actually creates 2 endpoints in 2 AZs with a public ip address each that will allow the connection to the on-prem router to consist of 2 tunnels (HA). This does not mean that the whole system is highly available: the on-prem side must implement measures to be considered highly available too. Without HA on-prem side, if the on-prem router fails the tunnel fails.

If you have another on-prem router you can configure another pair of tunnels, makeing the system effectively HA.

Static Vs Dynamic VPNs

Dynamic VPNs use BGP to exchange routes and links information. The link state is communicated on-the-fly and failover can be automated.

Static VPNs use static configuration, meaning that every change in the remote subnet must manually configured locally in order to preserve routing. Adding a subnet remotely, means having to manually configure routing locally. You get no load balancing or multi connection failover

If you want a fully dynamic solution you can configure Route Propagation on the Route Table in the VPC. This way, any networks learned from the remote peer will automatically be added to the table.