[boris-ning-usds]

I'm dealing with similar problems - trying to setup direct connection between AWS and Azure.

How does planetscale handle the complexity of DIY classic VPN and ensuring a high availability on those VPN links - and ensuring that a certain amount of throughput can be sustained?

Is there a requirement for planetscale to create a full network mesh between all cloud providers, all regions? I'm assuming that it's more selective because it becomes untenable as more cloud regions pop out requiring (n * (n-1))/2 VPN links where n is the number of cloud regions.

Happy to learn anything I can here. Thanks for the blog post.

[dkhenry]

Yes there is a requirement for a full mesh, and generally it has to be in all regions. GCP will route for you at the Network level so we could get away with not all GCP regions being peered to all AWS and Azure regions, but all AWS and Azure regions need to be peered to each other.

For the HA of VPN links for most providers its handled automatically, AWS <-> Azure and AWS <-> GCP both are HA links offered by the provider. Azure <-> GCP is a Classic VPN so we need two of them and we need to manage the routes to make sure they would fail over in the event of a loss of one system.

Throughput is another story, we are very much limited by the throughput of the various VPN's. We haven't pushed GCP or Azure to the max to see what they can do, but according to the documentation we should be expecting around 300Mbps across each link in the mesh before we start to see throttling. At that point it makes sense for us to move to a co-located exchange and peer with dedicated connections.

Finally for other providers, when we start to get them inbound we will be looking at using the transit gateway's of the various providers to reduce the total number off links needed, or standing up virtual routers to act as exchanges.

Hopefully we will be doing another post with more technical details and some benchmarks!