Often, the easiest thing about using the Azure Cloud is getting started. Whether it’s creating a VM, establishing a web service, etc., it’s usually as easy as a few clicks and you’ve got some “thing” running in a bubble. That’s the easy part.
It’s what you do right after that can often be a challenge, since in many cases it involves inter-connectivity with your on-premises environment. And at that point, whether it’s the early on, or even after long-thought-out deliberative designing, you may want to sit down and have a talk with your firewall/network team (who may never even have heard the word “Azure” before) and talk about exactly how to connect.
Please be mindful that the router/firewall people roll in a different workspace, and may have a different approach to what you’re trying to accomplish. They may prefer to use third-party firewall/tunnel capabilities with which they are already familiar, or utilize the off-the-shelf options that Microsoft provides. Note: This article is all about the built-in Microsoft options; we’ll have a discussion about third-party items in a future article.
Specifically when working with the native Azure connectivity options, the first thing you’ll want to do is point yourself and others at this URL, which provides most everything needed to get started:
…note that there are some great sub-pages there too, to take the conversation from “Why are we doing this” to “What is Azure” to “Let’s submit a ticket to increase our route limitation“.
But speaking as a server/cloud guy, I wanted to give you some simple but important tips you’ll need to know off the top of your head when speaking to your router people:
There are two types of Gateways for on-prem connections to the cloud: ExpressRoute and VPN. ExpressRoute is awesome and preferred if you have that option. If you don’t know what ExpressRoute is already, you probably can’t afford it or don’t need it — which leaves you with VPN. The good news is that if done right, the VPNs can be perfectly fine for an Enterprise if you set them up right, and mind them well.
I’m mostly writing these VPN options down because I always forget it, but you need to know the definitions too:
“Static Routing” used to be called “PolicyBased” and your router person knows it as
“Dynamic Routing” used to be called “RouteBased” and your router person knows it as
PolicyBased can only be used with “Basic” SKU, and only permits one tunnel and no transitive routing. You probably do not want this except in the most simple of configurations. Ironically, your router/firewall person will most likely configure your VPN this way if you don’t instruct them otherwise. Watch out!
The firewall you have may not be supported. But even if it’s not, that means two things: you may be forced into PolicyBased (read Tip #3), or in many cases it will work just fine even if it’s not supported. But you might be on your own if you have a problem, so know what you’re getting into.
Please calculate the total number of routes and gateways and such that you’ll be permitted based on the SKUs you’re chosen. Make sure that your fanciful networking dreams will all come true when you finally get where you’re going. Everything in Azure has a quota or limitation of some sort, and you can almost always get them raised from the low original limit, but some things just aren’t possible without changing SKUs.
Extra Bonus Tip
Look into the “Network Watcher” preview for validating some of your networking flow and security, and for an instant dashboard of the quotas (mentioned in Tip #5). It’s only available in some locations right now, but it’s looks like it will be quite nice.
…and that’s just scratching the surface, but those are some of the things I run into out there, and I thought it might save you a minute… or a day… or more…
Good luck out there!