Hot off the presses, last night Microsoft released GA pricing details for Azure Active Directory Domain Services. The smaller two tiers have been aggregated, will be renamed “S1 Domain Services Hours”, and should now cover domains with up to 25,000 objects. S2 covers domains with 25K – 100K objects. Anything larger than that warrants a call to Microsoft.
I think this will be the sweet spot for most small to mid-sized customers, so let’s do a little cost comparison to see how the new pricing compares to just hosting a DC in Azure.
First, what do we get from Azure Active Directory Domain Services (AADDS)? We get AD services hosted natively within Azure without the need to maintain an OS. And that’s handy, but there are some differences between that and a traditional Domain Controller:
Azure Domain Services serves ONLY systems and applications within Azure.
LDAP, NTLM, and Kerberos authentications are supported, but GPO support is limited to one policy per user and one per computer.
AADDS can support Azure Site Recovery sandbox scenarios, obviating the need to add a DC to your orchestration or recovery subnet.
AADDS is natively highly-available, so you don’t need multiple instances (no more fiddling with FSMO’s!)
Access controls are not handled with traditional “Domain Admin” and “Enterprise Admin” groups
AADDS is a totally separate forest from your on-prem AD, even if all the objects are the same
AADDS is presented to a chosen Azure VNET at creation: it’s not universally visible
And then there’s cost, which like all things Azure is computed by the hour:
For comparison, let’s estimate a couple common DC virtual machine scenarios in Azure (ignoring networking):
So it seems that, at least for now, it’s less expensive to run multiple D1 VM’s to achieve high availability than purchasing S2 AADDS. And for small environments that are NOT leveraging Azure Site Recovery, S1 comes out ~$40/month higher than hosting a single traditional VM, or about $475 more per year. So why would you do it?
Well, for one thing you don’t have the overhead of a VM to manage. That may not be a big deal to some, but if all you’re supporting in Azure is workloads, why scale up an infrastructure when you can just turn on a service? And why worry with upgrading? You’re here because you’re probably already leveraging other “evergreen” elements of the Microsoft cloud: stop upgrading domain controllers!
Or in some cases, for customers who have no investment in traditional Active Directory DC’s, don’t bother deploying them at all: a swipe of a credit card and a couple of clicks can enable the customer to support a workload without building out any infrastructure.
Another thing that often (almost always) gets overlooked is AD topology. When spinning up resources in a new site, it’s important to put a DC in that site, but it’s equally important to actually define that site in AD Sites & Services. This prevents cross-site authentications in a healthy network, and can dramatically improve the logon experience for users. I have seen simple topology changes make a 10+ minute improvement in remote logon requests. Huge. Or in 2016 terms: YUGE. Since your Azure DC’s will only be servicing Azure resources, you probably don’t want users authenticating to them. And you probably don’t want workloads trying to access your on-prem DC’s. If AD is a service, you don’t have to worry about maintaining those infrastructure & topology updates. Remember that it’s a totally separate forest, and only presented to your chosen VNET, so it’s just handled.
But what about DNS? Well, Microsoft thought of that, too: when you enable AADDS, the service presents multiple DNS server IP addresses to your VNET. And you don’t have to worry about any of that infrastructure, either. Woohoo!
So it’s simpler, natively HA, automatically scalable (as objects increase), supports Site Recovery without additional infrastructure, and evergreen.