The next option for deploying VPN services in Azure is using Windows Server.
This is an interesting option, and I think is a pretty compelling one.
But it does have a rather serious limitation or drawback to it,
which we'll discuss here shortly.
But the advantages to deploying Windows Server RRAS,
Routing and Remote Access Service,
on Windows Server in Azure are that it's really easy to deploy.
It's, you know, spinning up virtual machines in Azure is quite simple.
Deploying Windows Server and configuring it for RRAS is not terribly difficult.
You saw how we did that earlier in this course in some of the earlier lessons.
It's not terribly difficult to get things installed and
configured to support VPN on Windows Server.
I like it because it scales very effectively, so you don't have to scale up.
You can just very easily scale out.
I could deploy 2, 3, 5, 20, 100 VMs in Azure,
if I wish, to meet my demand, and just place them behind a load balancer,
and it will run happily and very effectively.
The other advantage to using Windows Server RRAS in Azure is that
you get full support for the full suite of tools and options
available to you as a part of Always On VPN.
For example,
you now can support both device tunnel and user tunnel on the same server,
so that's a huge win.
That was a serious limitation of the native Azure VPN
infrastructure is that you had to kind of choose one.
It was either going to be device or user, but never both.
For the organizations that are either hybrid Azure AD Join and still,
you know, are still joining their devices to on‑premises AD,
and again that's a perfectly valid deployment scenario,
the device tunnel is really helpful in those scenarios,
and here you don't have to pick and choose.
You get both.
You get to have your cake and eat it too.
You get the device tunnel and the user tunnel.
And importantly,
deploying Windows Server RRAS in Azure still allows you
to support geographic redundancy.
So I could have VPN servers in multiple Azure VNets in
multiple regions spread across Azure,
and then I could just simply use DNS round robin or Azure Traffic
Manager or some other GSLB to route traffic intelligently.
Also, in this scenario, you can have VPN servers running in Azure,
and they will happily coexist with other VPN servers running on‑premises,
so you can use this as a backup.
So you could basically have all of your traffic go on‑premises
and then failover to Azure if it's unavailable.
You could load balance it in terms of percentages.
You might spin off a percentage of traffic to Azure.
It really doesn't matter, it really plays well,
and it works quite effectively, and it's a really,
really good solution.
But again, as I mentioned before,
it does come with one rather important drawback,
and that is the RRAS workload is not supported on Windows Server in Azure.
That is just a form of Microsoft support statement.
It is not a supported workload on Windows Server in Azure.
Now,
a widely recognized enterprise mobility expert has often been quoted as saying
that "Not supported is different than doesn't work." And so,
I would encourage you to take a hard look at this option because I
have deployed RRAS in Azure for many customers, and so far,
everyone's had a great experience with it.
There doesn't seem to be any other technical limitations or
drawbacks that prevent this from working.
And so, at the end of the day,
if you can support the limitation of the lack of support,
so if you can handle that and accept that,
this is a fantastic solution,
one that works quite well and one that I think you'll find really meets the needs of your organization quite well.