Sometimes you have to wonder in awe at the feat of engineering that makes intercontinental communication possible. When you send a file from Beijing to Los Angeles, it zooms across an astonishing 12,500 mile long fiber optic cable. Imagine how much sand had to be melted to create such a “submarine cable”, and the size of the boat that traveled across the ocean to arduously unspool something that long.
So what does my client say when I demonstrate such a triumph of technology?
It’s too slow 😑.
Going global
Joking aside, when a client asked me to host some of their resources in China, I assumed it would be a complicated setup involving VPN connection between two data centers.
The solution was MUCH simpler than that. Azure has a built-in feature called VNET peering. The video below shows how to set one up in under 9 minutes.
The only snag was that China doesn’t allow foreigners access to their data centers, so my next best option was Japan East.
The video talks briefly about Gateway Transit at the 7:28 mark, but doesn’t explain how to set it up. If you already have a site-to-site VPN setup with Azure to on-prem, any new VNETs you add through peering can share that connection as well. In other words, my client can access the data in Japan just as they would through any site-to-site VPN connection.
The Microsoft Doc below goes into detail of how to set this up, but the TL;DR is to just enable “use this virtual network’s gateway” on the hub and “use the remote virtual network’s gateway” on the spoke. Easy!
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gateway-transit
Hub
Spoke
Conclusion
That was a quick overview of VNET peering. This was one of the easiest and dare I say funnest Azure features to set up. Everything is just point-and-click. Hopefully Microsoft will make more features this easy to use in the future!
