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 on 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.

 Virtual Networks

Properly planning out your networks is essential. You cannot skip this step because once a Virtual Machine (VM) is bound to a Virtual Network (VNet), or if a Site-to-Site (S2S) gateway has been created, some changes to the VNet are not allowed.  You can add an ExpressRoute circuit to an existing VNet that has an S2S VPN, but the S2S VPN would then be removed. If ExpressRoute connectivity is desired with a S2S VPN as a backup, the VNet must be created with an ExpressRoute connection first.

 If possible, consider assigning a full Class B (/16) network to Azure. You can take a full Class A (10.0.0.0/8) network for use if desired, but as most departments or agencies are already using portions of this address space internally, carving out one Class B (or a portion thereof) is typical. It is important that the portion of network addresses that you assign to Azure do not conflict with existing on-premises address ranges. This is because you will most likely create a S2S VPN or an ExpressRoute circuit that extends your on-premises network to Azure. If you have cloud only workloads that do not require connectivity to your internal LAN, then this is not a concern unless you do eventually require that connectivity for other workloads. As such, even if you do not intend on using a VPN connection, it is a best practice to use a non-conflicting address space for those workloads.

 Once you have created an VNet with the desired address space, it is further recommended that you create multiple subnets within that network to segregate different workloads. In doing so, you can create Network Security Groups (NSGs) that secure that subnet as desired. For example, a DMZ subnet can be locked down to only allow inbound traffic from the Internet on ports 80 and 443, and to only communicate with servers on the application or database subnets as needed. All other traffic can be denied, which follows general network security best practices.

 The graphic below depicts what a typical VNet may look like. It assumes a full Class B (10.100.0.0/16) range. It is further subdivided into secured subnets for different workloads:

• DMZ- web servers or ADFS web proxies
• Identity- domain controllers, ADFS, Microsoft Identity Manager, etc.
• Applications- middle-tier application servers
• Servers- databases or other LOB back-end servers
• Gateway- a gateway subnet for routing between VPNs or VNets

Cloud Services

Cloud Services (CS) are generally created for specific workloads or service types. A CS provides a single publically available IP address for all VMs contained within that service. It is also necessary to take into account the maximum limit of 50 VMs per CS. For smaller agencies or departments, it may suffice to create a single CS for all VMs, but the Azure plan should account for all enterprise workloads that may eventually be deployed. As such, creating multiple cloud services is a best practice. Additionally, it is a best practice to utilize a standard naming convention for these services.

 For instance, if your department or agency is called Department of Information Management (DIM), include that along with a city, county or State identifier. Because CS names are available as a part of the Microsoft Azure public DNS, they need to be globally unique. If you are in Los Angeles, California, your cloud service names might look something like this:

 Your unique names are appended with: .usgovcloudapp.net. Using this publically available address will allow you to gain access to any services or servers that reside within this cloud service. Another thing to keep in mind here is that Availability Sets and Load Balancing cannot span multiple cloud services.

 Storage Accounts

Planning of Storage Accounts (SA) are also necessary since they too have limits applied to them. A single SA can support a maximum of 20,000 IOPS. If too many VMs use a single SA for their drives, you can seriously degrade their performance by demanding more IO than the SA can handle. Generally, storage accounts are also created in alignment to the cloud services that contain the VMs stored in those accounts. This is not strictly necessary however, as the most important limit here is the total number of IOPS that an account needs to support.

 The diagram below depicts what your storage accounts may look like:

Storage Accounts are also available externally via their publically available address, and therefore also need to be globally unique. These endpoints are shown below:

Virtual Machines

Once created, VMs are tightly coupled to the CS and VNet. They cannot be simply moved from one VNet (or CS) to another. Instead, they must be re-provisioned with the desired CS and VNet. This can create issues if production workloads have been deployed prior to planning out all of the potential workloads. You can be flexible in adding additional workloads later as long as it is accounted for it from the beginning.It is fairly easy to re-provision the VMs, but it will cause downtime of your production workloads while this reconfiguration is in progress. (reference this article for step-by-step information on how to do this: http://blogs.technet.com/b/canitpro/archive/2014/06/17/step-by-step-move-a-vm-to-a-different-vnet-on-azure.aspx.)

 When creating your VM, the cloud service, storage account, and Vnet will all be tied together within the VM instance. This is a tightly coupled instance, so only certain portions can be altered after creation. You can change subnets within a network for a VM, or add additional storage accounts for added virtual hard drives. However, you cannot change the cloud service, VNet it belongs to, or the storage account that the primary (O/S volume) VHD is attached to.

 The screen below shows where all of these are tied together during the creation process:

Trial Azure Subscriptions

There is value in creating trial accounts for departments or agencies that want to gain some hands-on experience with Azure prior to moving workloads. For trial subscriptions, they are generally meant to be a “sandbox” to test service capabilities prior to purchasing an enrollment. You can convert a trial subscription to a production enrollment, however you should keep in mind that all of the factors mentioned above apply. As such, careful planning should occur as a first step—even in a trial subscription.

 Summary

Proper planning is always essential for any infrastructure project, whether it is on-premises or in the cloud! While Azure does make it easy to deploy and test workloads, it also makes it easy to get into trouble down the road if you do not incorporate best practices into your architecture from the very beginning. Please keep these in mind as you make your move to the cloud.