Microsoft Azure IaaS Architecture Best Practices for ARM


How to design and build an enterprise infrastructure in Azure using the Azure Resource Manager portal

Getting started in Azure is easy to do, and you can have production workloads running in the cloud in very little time. However, there are some essential aspects of the Azure platform that require some forethought and planning. While it is easy to get up and running quickly, without the necessary planning in some areas, you could find it necessary to rebuild these workloads later if you haven’t fully considered the bigger picture—from an enterprise perspective. Let’s avoid the necessity of having to redeploy or redesign your Azure architecture later by considering upfront those things that may become an issue later.

Executive Summary

This post describes and demonstrates the best practices for implementing a consistent naming convention, Resource Group management strategy, and creating architectural designs for your Azure IaaS deployments. Your actual conventions and strategies will differ depending on your existing methodology, but this sample describes some of the key concepts for you to properly plan for your cloud assets. A video walkthrough guide of these principles in practice, is also available for a deeper understanding of the concepts presented here.

This article builds upon the following blog post that was released previously, and describes similar concepts utilizing Azure Service Management (ASM or Classic) resources: Essential Considerations for Azure Architectural Planning

Azure Subscriptions

The very top level container within an Azure enrollment is the subscription. An enrollment can contain many subscriptions—each with their own administrative boundaries. This works well for separation of departments and agencies, as well as for separation of specific workloads such as production, staging, testing, and development. While this is great for establishing clean administrative boundaries, centrally managing many subscriptions can create additional overhead. For instance, a virtual network (VNET) cannot cross a subscription boundary, so if you are utilizing Site-to-Site VPNs for your hybrid connectivity, you will need to create multiple VPNs—one for each VNET. If you are utilizing ExpressRoute (E/R) for your connectivity, this makes it much easier to connect multiple VNETs to your on-premises network. It is also possible to utilize VNET peering to share a single VPN connection as long your VPN edge device supports route-based (or dynamic) routing.

Azure in Education has posted a great article about enterprise and subscription management. For more information, check out this article: Introduction to Azure Enterprise and Subscription Management.

Naming Conventions

Consistent naming conventions are critical to any government agency or commercial enterprise with numerous different departments, services, networks, and applications. If consistent naming is not applied from the very beginning, resources can quickly become hard to find or rapidly identify. As such, it is important to establish a standard convention that will be used throughout these various services. [Note: these are typical examples and will likely vary from your current established naming convention. Just keep in mind that you should have some mechanism in place to distinguish Azure based assets from on-premises based assets when you determine your actual naming convention.]

Additional guidance on naming convention best practices is located here: Naming Conventions

Resource Groups

Within a subscription, the Resource Group (RG) is the top-level container to keep similar workloads or items grouped together. Typically, these RGs are utilized to separate things like virtual machine workloads, network components, storage accounts, and other such items. That makes it easy to go directly to the desired area or workload to find or manage components within it.

A typical resource group naming convention is like the following:
RG-Region-Type-SubType/Workload

Example: RG-West-VM-Identity where
RG indicates it as a Resource Group
West indicates the WestUS region
VM indicates that it contains virtual machines
Identity indicates the “identity” workload

Example: RG-West-Network where
RG indicates it as a Resource Group
West indicates the WestUS region
Network indicates that it contains the Vnet components

Networking Components

A typical resource group naming convention is like the following:
Vnet-Region-Type-SubType/Workload

Example: VNET-West where
VNET indicates it as a virtual network component
West indicates the WestUS region

Example: VNET-West-GW where
VNET indicates it as a virtual network component
West indicates the WestUS region
GW indicates that it is the gateway component

Example: VNET-West-GW-IP where
VNET indicates it as a virtual network component
West indicates the WestUS region
GW indicates that it is the gateway component
IP indicates that it is the IP address of the gateway

Storage Accounts

Storage accounts use publicly accessible URLs, so they require a globally unique DNS name.

A typical storage account naming convention is like the following:
[Entity][Region][Type][Workload].*.core.windows.net (or for Azure Government [Entity][Region][Type][Workload].*.core.usgovcloudapi.net)

Example: spnwwusvmid (https://spnwwusvmid.blob.core.windows.net) where:
spnw indicates the enterprise name
wus indicates it is located in the WestUS region
vm indicates it is for virtual machine disks
id indicates that is for the identity workload

Example: spnweussql (https://spnweussql.blob.core.windows.net) where:
spnw indicates the enterprise name
eus indicates it is located in the EastUS region
sql indicates it is for SQL data storage

Virtual Machines

A typical storage account naming convention is like the following:
[Region][Role][Number]

Example: wusdc01 where:
wus indicates the WestUS region
dc indicates it is a domain controller
01 indicates it is the first domain controller

Example: wusadfs02 where:
wus indicates the WestUS region
adfs indicates it is an ADFS server
02 indicates it is the second server for this workload

Workload Scenario

Let’s build a sample scenario of an enterprise SharePoint farm in Azure. This scenario will include a highly available SharePoint farm that is deployed in the WestUS region, with a disaster recovery farm deployed in the EastUS region. They are connected via two on-premises Site-to-Site (S2S) VPNs (one to each region) as well as a VNET-to-VNET VPN that connects WestUS to EastUS. This last link is utilized for Domain Controller and SQL Always-on replication.

azureiaasarmscenario

Identity Workload: 6 servers in West Region
(2) Domain Controllers
(2) Load balanced ADFS servers
(2) Load balanced Web Proxy servers

SharePoint Workload: 6 servers in West Region
(2) Load balanced SharePoint WFE servers
(2) SharePoint APP servers
(2) Load balanced SQL servers w/always-on

Disaster Recovery Workload: 4 servers in East Region
(1) Domain Controller
(1) SharePoint WFE server
(1) SharePoint APP server
(1) SQL Server w/always-on

Resource Groups

The RGs that we have defined for this scenario are as follows:

RG-West-VM-Identity Contains identity VMs and their storage (DCs, ADFS, Proxy)
RG-West-VM-SharePoint Contains SharePoint VMs (WFE, APP)
RG-West-VM-Database Contains SQL database VMs (SQL)
RG-West-Network Contains network related components (Vnet, S2S VPNs, public IPs, load balancers)
RG-East-VM-Identity Contains identity VMs and their storage (DC)
RG-East-VM-SharePoint Contains SharePoint VMs (WFE, APP)
RG-East-VM-Database Contains SQL database VMs (SQL)
RG-East-Network Contains network related components (Vnet, public IP, etc.)

Networking Components

The networking components defined for this scenario are as follows:

Vnet-West The virtual network configuration (IP ranges, subnets, etc.)
Vnet-West-GW The virtual network gateway
Vnet-West-GW-IP The public IP address of the gateway
Vnet-West-GW-Local The local (on-premises) gateway configuration (IP address, connection type, etc.)
Vnet-West-Vnet-East-Connection The S2S VPN connecting WestUS to EastUS
Vnet-West-Local-Connection The S2S VPN connecting WestUS to on-premises
PLB-West-ADFSProxy The public load balancer for the ADFS proxy servers
PLB-West-ADFSProxy-IP The public IP address of the load balancer
ILB-West-ADFS The internal load balancer for the ADFS servers
PLB-West-SP The public load balancer for the SharePoint WFEs
PLB-West-SP-IP The public IP address of the load balancer
Vnet-East The virtual network configuration (IP ranges, subnets, etc.)
Vnet- East -GW The virtual network gateway
Vnet- East -GW-IP The public IP address of the gateway
Vnet- East -GW-Local The local (on-premises) gateway configuration (IP address, connection type, etc.)

Storage Accounts

Storage accounts (S/A) are publicly available locations where your virtual hard drives (and other data types) are stored. They are IOPS limited depending on the type of storage that is required. A standard S/A has a limit of 20K IOPS and utilizes typical HDDs with a maximum IOPS limit of 500 per disk. A premium S/A is limited to 100K IOPS and utilizes typical SSDs with a maximum IOPS limit of 5000 per disk. As such, it is recommended to split your VHDs into several S/As so that your VMs can use their maximum potential data transfer speeds.

spnwwusvmid West Identity VM S/A
spnwwusvmsp West SharePoint VM S/A
spnwwusvmdb West SQL data VM S/A
spnwwusvmdiag West VM diagnostics S/A
spnweusvmid East Identity VM S/A
spnweusvmsp East SharePoint VM S/A
spnweusvmdb East SQL data VM S/A
spnweusvmdiag East VM diagnostics S/A

Availability Sets

Availability sets group identical server workloads together to provide high availability in Azure. In order to provide a Service Level Agreement (SLA) for specific virtual machine workloads, each workload must contain at least two servers in an availability set, or single instance machines must utilize premium storage for their virtual hard disks. As such, the best practice is to include two servers running each critical workload. In addition, we will add load balancers to these workloads where required.

For this scenario, the WestUS region is our primary location. The EastUS region will only be utilized if a disaster occurs in the WestUS region, so a few single instance VMs in the East would be fine in that scenario. If desired, a fully redundant and high performing infrastructure could be built in the East as well—including the full ADFS resilient identity workload.

The availability sets defined for this scenario are as follows:

AS-DC The A/S for the domain controllers
AS-ADFS The A/S for the ADFS servers
AS-ADFSPXY The A/S for the ADFS proxy servers
AS-SPWFE The A/S for the SharePoint web front end servers
AS-SPAPP The A/S for the SharePoint app servers
AS-SPSQL The A/S for the SharePoint SQL servers

Virtual Machines

All of the virtual machine components are listed in the table following:

VM IP Subnet L/B Avail Set VM Size Resource Group Storage Account
West Region
WUSDC01 10.20.1.11 Identity n/a AS-DC Standard_A2 RG-West-VM-Identity spnwwusvmid
WUSDC02 10.20.1.12 Identity n/a AS-DC Standard_A2 RG-West-VM-Identity spnwwusvmid
WUSADFS01 10.20.1.21 Identity ILB-West-ADFS AS-ADFS Standard_A2 RG-West-VM-Identity spnwwusvmid
WUSADFS02 10.20.1.22 Identity ILB-West-ADFS AS-ADFS Standard_A2 RG-West-VM-Identity spnwwusvmid
WUSADFSPXY01 10.20.0.11 DMZ PLB-West-ADFSPXY AS-ADFSPXY Standard_A2 RG-West-VM-Identity spnwwusvmid
WUSADFSPXY02 10.20.0.12 DMZ PLB-West-ADFSPXY AS-ADFSPXY Standard_A2 RG-West-VM-Identity spnwwusvmid
WUSSPWFE01 10.20.0.21 DMZ PLB-West-SPWFE AS-SPWFE Standard_A3 RG-West-VM-SharePoint spnwwusvmsp
WUSSPWFE02 10.20.0.22 DMZ PLB-West-SPWFE AS-SPWFE Standard_A3 RG-West-VM-SharePoint spnwwusvmsp
WUSSPAPP01 10.20.2.11 Apps n/a AS-SPAPP Standard_A3 RG-West-VM-SharePoint spnwwusvmsp
WUSSPAPP02 10.20.2.12 Apps n/a AS-SPAPP Standard_A3 RG-West-VM-SharePoint spnwwusvmsp
WUSSPSQL01 10.20.3.11 Servers ILB-West-SPSQL AS-SPSQL Standard_DS3 RG-West-VM-Database spnwwusvmdb
WUSSPSQL02 10.20.3.12 Servers ILB-West-SPSQL AS-SPSQL Standard_DS3 RG-West-VM-Database spnwwusvmdb
East Region
EUSDC03 10.30.1.13 Identity n/a n/a Standard_A2 RG-East-VM-Identity spnweusvmid
EUSSPWFE03 10.30.0.13 DMZ n/a n/a Standard_A3 RG-East-VM-SharePoint spnweusvmsp
EUSSPAPP03 10.30.2.13 Apps n/a n/a Standard_A3 RG-East-VM-SharePoint spnweusvmsp
EUSSPSQL03 10.30.3.13 Servers n/a n/a Standard_DS3 RG-East-VM-Database spnweusvmdb

Video Learning Series

The build out of this scenario workload is fully recorded for your review. These videos highlight all the key components of this document so that you can understand how it all comes together in Azure.

1)      Using Consistent Naming Conventions to Create Resource Groups and Storage Accounts (20 minutes)

2)      Creating Virtual Network and VPN Connections in ARM (30 minutes)

3)      Creating Basic Virtual Machines in the Azure Portal (23 minutes)

4)      Creating Advanced Virtual Machines in the Azure Portal (16 minutes)

5)      Creating Load Balancers and Network Security Groups in the Azure Portal (24 minutes)

We welcome your comments and suggestions to help us continually improve your Azure Government experience. To stay up to date on all things Azure Government, be sure to subscribe to our RSS feed and to receive emails, click “Subscribe by Email!” on the Azure Government Blog. To experience the power of Azure Government for your organization, sign up for an Azure Government Trial.

Comments (1)

  1. Anonymous says:

    Thank you for this!

Skip to main content