This article begins with some of the more important Microsoft Azure fundamentals and terminology, including product categories; accounts, tenants, and subscription types; resources and resource groups; and Azure object hierarchy.
Microsoft Azure Resources
The first step in building an MSP cloud practice with Microsoft Azure is deeply familiarizing yourself with Microsoft Azure’s fundamentals: its terminology, elements, and hierarchy. Here we will list and define the most critical Azure elements and discuss how they interrelate with each other.
Microsoft Azure Categories
Microsoft Azure is a diverse cloud platform that contains hundreds of products (also known as SKUs). These Azure SKUs fall into many categories. For instance:
- Infrastructure-as-a-Service (user-managed, raw resources that can be used to build IT environments)
For example:- Virtual Machines
- Storage
- Networking
- Platform-as-a-Service (Microsoft-managed, use-specific, packaged offers designed to be the building blocks of applications)
For example:- Azure SQL – Microsoft managed SQL service without a “server running SQL” that can be used as the database back-end for a new or existing application
- Azure Files – Microsoft managed SMB (CIFS) file share service that behaves just like a Windows file server but without a server to manage
- Data Services – resources such as machine learning, analytics, and cognitive services
- Software-as-a-Service – fully usable, end-user applications written, hosted, and managed by Microsoft
- Office 365
- Dynamics 365
We will focus on IaaS and PaaS services, as those are the most fundamental building blocks an MSP needs to build a cloud practice in Azure.
Microsoft Azure Tenants and Subscriptions
At the highest level is an Azure tenant, also known as an account or directory (these terms will be used interchangeably). An Azure tenant represents an organization in Azure and is uniquely associated with an instance of Entra ID (formerly Azure Active Directory/AAD). An Entra ID tenant is a directory that holds users, devices, groups, and other security principles. An Entra ID tenant is used to manage access to Azure and Microsoft 365 resources. Without an Entra ID tenant, you cannot deploy Azure or Windows 365 resources.
An Azure tenant is free to create and tenant names must be globally unique (i.e. no one else in the world can use the same name). A new tenant has a TenantName.onmicrosoft.com domain associated with it. The tenant name can be updated to a custom domain name.
Nerdio Tip:
It is possible to use a single Azure tenant for all your customers’ infrastructure. We will discuss below the advantages of doing so for flexibility of compute reservations.
Azure is organized by management groups and subscriptions. A management group is a container for subscriptions and other management groups. Management groups are an administrative boundary and are used to organize subscriptions. Settings applied to a management group, such as policies or administrative rights are inherited by all management groups and subscriptions in the parent management group.
An Azure tenant can contain multiple subscriptions, but a subscription can only exist in one tenant. A subscription is a billing an administrative boundary. An Azure subscription is created directly from Microsoft or through an Azure reseller. All resources are billed based on usage, or consumption, within a subscription. The monthly Azure invoice is based on resources deployed and used in a subscription. If you don’t run any resources and therefore have no consumption–-your bill is $0.
Subscriptions come in many flavors, but the easiest way to think about them is an agreement between a customer and Microsoft, where Microsoft agrees to provide services based on the published Service Level Agreement (SLA) and the customer agrees to use and pay for the Azure products under the terms of the subscription. A good comparison is electrical power service in a home. A homeowner opens an account with the electricity provider (subscription), agrees on a rate for electricity and delivery, uses the electricity during a month, and then pays the bill once the power company bills the customer for the electricity consumed.
Subscriptions obtained directly from Microsoft will typically be Pay-as-you-go, Free, EA, CSP, or Sponsored.
- Pay-as-you-go (PAYG) – a PAYG subscription is a direct agreement with a customer created at www.azure.com. A credit card is required for a PAYG subscription and is the agreed-upon payment method for any resources consumed inside of the subscription and will be billed automatically monthly – at Azure’s list prices.
- Free – a free subscription is obtained directly from azure.com to use Azure for a limited time. It comes with a thirty-day credit of $200 within US. The credit amount and availability vary by country. This type of subscription is limited and typically used for testing or training. It is not recommended for MSPs looking to build cloud practices in Azure. A Free subscription can be converted to a PAYG subscription.
- EA (Enterprise Agreement) – if a customer is a larger organization, they will likely have a direct volume licensing agreement with Microsoft that gets negotiated every few years with annual “True Ups”. As part of this EA, the customer prepays for a certain amount of Azure consumption (monetary commitment) and use resources in the subscription up to this amount. Any overages will be reconciled at the time of the customer’s True Up with Microsoft.
- CSP – MSPs that have a Direct CSP with Microsoft can provision a CSP subscription for Azure inside the customers, or the MSPs tenant. Microsoft will bill the MSP for the usage (i.e. consumption) inside of this type of subscription – at the MSPs discounted reseller rate – and the MSP will in turn bill the customer. This is one of the most flexible and powerful Azure subscription types.
- Sponsored – if an MSP is part of the Microsoft Partner Network (MPN) with Silver or Gold competencies, Microsoft may provide a sponsored Azure subscription used to hone the organization’s Azure skills, deliver customer demos, and use internally. Each subscription will have a preset monetary limit, and a credit card is required to cover charges over the preset limit. The details on a sponsorship subscription, if you have any, can be obtained in the Partner Center under MPN or the Partner Development Manager (PDM). A word of caution: do not use sponsored subscriptions for customer workloads. Once charges exceed the sponsored subscription limit, billing is at list rates on the credit card connected to the subscription, and there is no easy way to convert this subscription to CSP. That will require migrating customer resources to another subscription, which is a disruptive process.
Most MSPs, however, purchase Azure through a CSP Provider (like Pax8, Sherweb, Ingram, Techdata, etc.). The MSP in this scenario is known as a “CSP Reseller”. Using the CSP Provider’s own portal, the MSP will be able to create a subscription to consume resources inside this subscription. The CSP Provider will get a bill from Microsoft for the consumption and will in turn bill the MSP. The MSP will then bill its customer for Azure consumption.
Subscriptions have globally unique IDs (GUID) associated with them. They also have a friendly name that can have any value, and the friendly name does not have to be unique. As a matter of fact, it’s possible to have subscriptions with the same friendly name inside of the same tenant. However, try to assign logical, unique names to each of your subscriptions to make things easier to manage.
Carefully consider subscription options before starting to deploy Azure resources, as changing subscription types later can be challenging or even impossible.
Nerdio Tip:
Become a CSP Reseller with a provider of choice and create a dedicated subscription for each customer under a single tenant. This will provide the optimal segregation of billing information on a per-customer basis while taking advantage of portability of Azure reservations between customers since all subscriptions will be in the same tenant.
Microsoft Azure Resource Groups
Within an Azure subscription are resource groups (RG). A resource group is a logical groupings of resources with a similar lifecycle in Azure. Resource groups provide an easy way to organize, view and manage resources in Azure. For example, if there are two complex, multi-component applications A and B, split them into their own resource group (e.g. RG-A and RG-B) to logically group all the compute, storage, and networking for each application with other related components.
Resource groups are not billing units. It is not possible to view the cost associated to a resource group by looking at an Azure invoice. However, it is possible to view resources usage by resource group from Azure Cost Management. Resource groups are for ease of management, resource organization, administrative boundary, and isolation. There are lots of resources in every Azure deployment so keeping things nice, tidy, and logical is very important.
There could be multiple resource groups within a single subscription, but a resource group can only be part of only one subscription. Resource group names do not have to be globally unique but must be unique within a single subscription.
Finally, resources are created inside a resource group, inside a subscription, and inside a management group. The Entra ID Tenant is the directory service used to apply access control at any object in the hierarchy. What are these resources? It’s everything that does something in Azure. Examples are virtual machines, virtual networks, disks, network cards, VPN gateways, IP addresses, etc.
Microsoft Azure Usage and Billing
There are many categories of resources, and each one has different configuration, usage and billing characteristics. We will explore the most important elements in this and future write-ups. For now, let’s focus on billing.
Some resources will be billable while others won’t. For example, a virtual machine (compute resource) will be billable while a virtual network interface (network resource) attached to a virtual machine will not be billable.
Billing in Azure typically has a unit and frequency. The easiest way to think about this is to go back to our electricity at home example. Electric power is a resource, the unit is kWatt and the frequency is an hour. We, therefore, have a pre-defined cost per kWatt-hour. As electricity is used, there is a meter running that measures how many kWatt-hours are consumed. The electric company sends us a bill for what we used. Azure works the same way. For instance, a virtual machine (VM) is billed for compute capacity (unit) on a per-second basis (frequency). Every time we start up (provision) a VM, a meter starts and keeps track of how long the VM is running. At the end of the month, the invoice shows how many hours were used by a particular type of VM and that’s what is owed to either Microsoft directly or via a CSP.
The key takeaway here is that each billable resource has a virtual “meter” that’s running any time the resource in “used” (this is defined differently for each type of resource). If we stop, or in some cases remove the resource, we stop the meter, and we are no longer billed.
Nerdio Tip:
In future articles, we’ll learn how these meters can be stopped even if the resource is running. For example, by using compute reservations and software subscriptions.
Microsoft Azure Object Hierarchy Overview
To summarize, we learned the hierarchy of Azure objects and how the interact with each other:
Azure account/tenant/directory
- Subscription A
- Resource Group 1
- Virtual machine (resource)
- Compute meter
- Premium SSD Managed disk (resource)
- Storage capacity meter
- Virtual machine (resource)
- Resource Group 2
- Virtual machine (resource)
- Compute meter
- Standard SSD Managed disk (resource)
- Storage capacity meter
- Storage operations meter
- Virtual machine (resource)
- Resource Group 1
- Subscription B
- Resource Group 1
- Virtual machine (resource)
- Compute meter
- Virtual Network Interface (resource)
- No billing meter
- Virtual machine (resource)
- Resource Group 2
- Azure SQL (resource)
- vCPU meter OR
- DTU meter
- VPN Gateway (resource)
- VPN gateway
- Transfer meter
- Azure SQL (resource)
- Resource Group 1
Familiarizing yourself with this set of core building blocks including Accounts, Tenants, Management Groups, Subscriptions, Resource Groups, Resources, and Billing options is the first step an MSP should take in determining the most efficient and cost-effective way to build a cloud IT practice in Microsoft Azure.
Now, let’s dive deeper in Azure Resources.
Microsoft Azure Resources
As we stated above, the building blocks of an Azure IT environment are Resources. These resources are organized into Resource Groups inside of an Azure subscription. There are billable and non-billable resources. Billable resources have a Meter attached to them that runs while the resource is provisioned.
In this section, we will explore the three most common types of Azure resources used by MSPs when deploying IT environments: Compute (virtual machines), Storage, and Network.
Every resource used in Azure must be deployed in a geographical location known as a Region. An Azure region is a grouping of data centers located in a specific geographic location. Microsoft is constantly growing its global footprint and adding data centers and regions. At the time of this article, there are over 60 regions available in 140 countries and the list is growing. The most up-to-date map of regions can be viewed here.
Azure resources deployed in the same region are interconnected with high-speed connectivity (think LAN speeds). Resources in different regions can still communicate with each other over Microsoft’s dedicated network, but are subject to additional WAN latency. The latency depends on how far the regions are from each other.
Microsoft Azure Compute (Virtual Machines)
Virtual Machines (VMs) in Azure come in predefined sizes that are called families or series. An individual VM is often referred to as an instance. Different VM families are designed for common use-cases and are comprised of certain amounts of CPU cores and GB of RAM. It’s not possible to arbitrarily mix and match CPU cores and GB of RAM as can be done with Hyper-V and VMware. Here, we will focus on the four commonly used VM families by MSPs: Ds-series, B-series, Esv5-series, and NV-series.
Always use the most recent version of VM’s available. There are minimal cost differences, with newer versions frequently costing less when comparing the same CPU and RAM configuration within a family. Selecting a newer version provides advantages of recent technology introducing faster clock speeds and memory performance.
Ds-series
These are “general purpose” VMs that can be used for a wide variety of workloads. There are four versions of the DS-series: v2, v3, v4, and v5. Only v4 and v5 should be used.
- Purpose: general applications (domain controllers, file servers, application servers, etc.)
- CPU: Intel XEON and XEON Platinum CPU
- CPU-to-RAM ratio
- V2 – 1:3.5GB (each CPU core gets 3.5GB of RAM)
- V3 and newer – 1:4.0GB (each CPU core gets 4.0GB of RAM)
- Storage supported: Standard and Premium
- Difference between versions
- V2 VMs use non-hyperthreaded vCPUs (1 vCPU per 1 physical CPU core), which is why they are slightly more expensive. V2 VMs start at a single core size (DS1v2).
- V3 VMs use hyperthreaded vCPUs (2 vCPUs per 1 physical CPU), which is why they are less expensive. V3 VMs start at a minimum of two vCPUs (D2sv3).
- V4 VMs use hyperthreaded vCPUs using a 3rd generation Intel Xeon Platinum processor. V4 VMs start at a minimum of two vCPUs (D2s_v4)
- V5 VMs use hyperthreaded vCPUs using a 3rd generation Intel Xeon Platinum processor with a clock speed of up to 3.5 GHz. V5 VMs start at a minimum of two vCPUs (D2s_v5)
Ds-series VMs are a good fit for workloads that require consistent CPU usage and are not very RAM hungry.
Esv5-series
These are “general purpose, high-memory” VMs that can be used for many workloads that are more RAM hungry rather than CPU hungry.
- Purpose: general, RAM bound applications (database servers, application servers, desktops, etc.)
- CPU clock speed: 3.5Ghz with 3rd Generation Intel Xeon Platinum processors
- vCPU-to-RAM ratio: 1:8.0GB (each CPU gets 8.0GB of RAM)
- Storage supported: Standard, Premium, and Ultra
Esv5-series VMs are very similar to Dsv5-series but have double the RAM per CPU and are about 15% more expensive. They are ideal for workloads that consistently utilize the CPU and are memory hungry. Examples are database servers and RDS session hosts.
B-series
These are known as “burstable” VMs. They are very useful but the way they work is a bit complicated. B-series are used for non-CPU intensive workloads (e.g. domain controllers, file servers) and cost about 50% of an equivalently sized Ds-series VM. The reason they’re cheaper is because Azure imposes a quota on how much of the total CPU cores can be used. This quota is usually a fraction of the total available CPU.
For instance, B2m’s quota is 60% of a single CPU, which is 30% of the 2 CPUs visible in the VM. Every second that the VM is using less than its quota (less than 60% of a single CPU) it is “banking credits”. These banked credits can be used to burst up to the total available CPUs (100% of 2 CPUs, in this example) when needed. While bursting, the VM is consuming its banked credits. Once credits run out, the VM’s CPU utilization is throttled down to its 60% quota.
Why use B-series VMs? They are cheaper. For approximately the same price that you would pay for a Ds-series VM, you can get a B-series with double the CPUs and double the RAM. However, they should only be used for workloads that are either not CPU intensive or “bursty”, meaning they only occasionally need all the CPU but most of the time the CPU is idle.
For instance, an Active Directory domain controller is not utilizing its CPU very heavily on a regular basis. However, when Windows Updates run, the VM will use all its available CPU horsepower. B-series are perfect for Domain Controllers since they bank credits while idle and then consume them when needed to update or do some other CPU intensive task.
- Purpose: General, non-CPU intensive workloads (e.g. AD domain controllers, file servers)
- CPU clock speed: varies
- vCPU-to-RAM ratio: varies from 1:.5 to 1:4 for VMs larger than B2s
- Storage supported: Standard, Premium, and Ultra with v2
Nerdio Tips:
- Don’t use B-series VMs for CPU intensive workloads such as Azure Virtual Desktop session hosts.
- When a B-series VM is first provisioned, it doesn’t have any banked credits and is subject to its quota limit on the CPU, which means it’s slow. Once the VM is running idle for some time, credits get banked and the VM performance improves when it needs to burst.
- Don’t shut down B-series VMs overnight when they are not in use. This will not allow the VMs to bank credits for the following day of usage.
NV-series
These VMs are intended for special use-cases when a dedicated GPU is needed. They include an NVIDIA GRID 2.0 Tesla GPU and are ideal for running graphically intensive workloads like AutoCAD, SolidWorks, and Revit. These are very large and expensive VMs (starting at 6 CPUs and 56GB of RAM) and need to be used with caution and with a specific purpose in mind to not generate unpredictably large Azure compute consumption bills.
- Purpose: Graphically heavy, visual workloads inside of virtual desktop sessions
- vCPU-to-RAM ratio: 6:56GB (each 6 CPUs get 56GB of RAM)
- vCPU-to-GPU ratio: 6:1 (each 6 CPUs get 1 M60 GPU), 12:1 for NVv3
- Storage supported: Standard only for NV, NVv3 supports Standard, Ultra and Premium
Nerdio Tips:
- Smallest VM is NV6 (6 CPU / 56GB RAM / 1 GPU)
- Since only Standard storage is supported, disk performance is not fast with NV series. Use NVv3 for Premium and Ultra disk support
- Not available in all Azure regions
- New NVv4 VMs are also available. The NVv4 VM’s use an AMD Radeon Instinct MI25 GPU and AMD EPYC 7V12 CPU.
- vCPU-to–RAM ratio: 4:14 (each 6 CPUs get 14GB of RAM
- vCPU-to-GPU ratio: 1:1/8 (each 4 CPUs get 1/8 of a GPU
- Support for Premium and Ultra storage
Anatomy of a VM
Now that we understand the different types of VMs, let’s talk about how to use them. The first important thing to understand is that VMs are not stand-alone resources. For example, a VM must have an OS disk (and optionally data disks) attached to it, as well as a virtual network interface (vNIC). A new VM can be created (deployed) using an existing OS disk and vNIC or new disk and vNIC can be created together with the VM. If a VM is deleted, its data (i.e. OS and Data disks) may not be removed with it. Unless removed with the VM, they remain as resource objects in Azure that are not attached to any VM. More on Storage resources later.
When deploying a VM, its OS disk must be based on an existing image and cannot be blank. Since you don’t have console access to VMs in Azure, the OS cannot be installed on a “blank” OS disk. The OS disk must already have the OS on it. Images could be pulled from the Azure image library and used as-is or used to create custom images in Azure. There is also a less-commonly used option to upload a custom image as a VHD file to use for Azure VM’s.
Most VMs also come with a temporary D: drive that has locally attached fast storage (SSD). Keep in mind that this disk is temporary, and any data stored on it will likely be erased if the VM is ever shut down or moved to another Azure host in the background.
Nerdio tip: Use this disk for the pagefile and temporary data, but be sure to never store anything you need to retain on the temporary disk.
Allocated vs. Deallocated
After you deploy a VM it becomes provisioned or allocated, meaning it is running on an Azure host, consuming Azure resources and you’re consequently being billed for every second that the VM is allocated. To stop being billed for a running VM, you must stop it. This process causes the VM to become deallocated, which means it is effectively powered off and is not consuming Azure resources. It is possible to shut down a VM and still pay for the VM because it stays allocated. When you power off a VM from inside of the OS it shuts down, but Azure still sees it as allocated and you are being billed. Be sure to stop VMs at the Azure level through the portal, PowerShell or the Azure CLI, even if you shut them down at the OS level.
Subscription Core Quotas
Another important concept to mention when discussing VMs is subscription core quotas. To prevent accidental or malicious use of Azure where many VMs are created and a large amount of consumption occurs, Microsoft imposes core quotas on subscriptions by default.
The number of CPU cores that can be provisioned in a subscription in total and per VM family are limited. For instance, a Free subscription has an overall core quota of 4. Direct Pay-As-You-Go subscriptions have a default core quota of 10 and CSP subscriptions have a core quota of 20. This means that with a CSP subscription you cannot provision more VMs whose total CPU cores exceed 20. Be mindful of this limit. To increase the core quota limit, you need to submit a request to Microsoft via the Azure portal for a core limit increase.
Service Level Agreement
Finally, it is important to be aware that only some Azure VMs’ availability is covered by Microsoft’s Service Level Agreement (SLA). VMs not covered by an SLA could be unexpectedly rebooted due to underlying Azure infrastructure upgrades or hardware failure. It has become exceedingly rare to see VMs reboot in Azure, but it can happen.
Presence of an SLA and the availability guarantee (e.g. 99.9% vs. 99.95% vs. 99.99%) is based on several factors that have to do with the type of storage the VM uses for its OS and data disks, as well as if it is deployed in an availability set or an availability zone. You can learn more about the specifics here. The diagram below summarizes the available protection options.
For most situations relevant to an MSP, it is important to know that individual VMs (“Single VM” in Microsoft terms) that use any Standard hard drive storage disks has a 95% SLA. The SLA increases to 99.5% if using a Standard SSD disk and 99.9% when a Premium SSD is used. The chance of outage is very small and even if the VM reboots due to an underlying hardware failure it will restart very quickly on other hardware in the Azure datacenter.
Critical VMs should use Premium storage only, which will provide a higher SLA and guarantee and improved performance. For additional availability guarantees, distributed workloads that can have multiple VMs participating in the same application, can be placed inside Availability Sets and will then be subject to 99.95% availability guarantee. Place multiple VMs in different Availability Zones for a 99.99% SLA. The SLA guarantee for Availability Sets and Availability zones applies to one instance of the VM. At least one instance of the VM will be available for the given SLA.
An example of such a deployment may be Active Directory. You can have two AD domain controllers in an Availability Zones and your AD, as a whole, will have a guarantee of 99.99%. This doesn’t mean that each domain controller VM has this guarantee. Rather, the “application” (i.e. AD), as a whole, is guaranteed to be available 99.99% of the time.
Microsoft Azure Storage
Azure offers multiple storage options with different performance, redundancy, location and price characteristics. It’s easy to get lost in all the available options and to clearly understand what type of storage should be used when.
We will focus on three storage resources that are most commonly used by MSPs when deploying IT environments in Azure: Managed Disks, Backup Vaults, and Azure Files.
When considering the type of storage resource, we need to understand the Data Redundancy, Performance, and Cost for each type of storage object.
Data Redundancy
- LRS – Locally Redundant Storage
- Three redundant copies of data stored in one data center
- 99.9% availability SLA for reads and writes
- ZRS – Zone-Redundant Storage
- Three redundant copies of data stored across two or three data centers within the same Azure region
- 99.9% availability SLA for reads and writes
- GRS – Geo-Redundant Storage
- Six total redundant copies of data; three copies stored in one region and another three copies are asynchronously replicated to a second region
- 99.9% availability SLA for reads and writes
- RA-GRS/RA-GZRS – Read Access GRS, Read Access ZRS
- LRS or GRS for the primary data copy with a LRS copy of the data in a secondary region that provides read access
- 99.9% availability SLA for reads and writes
- 99.99% availability SLA for reads from geo-redundant storage
Disk Performance Tiers
There are three disk performance tiers: Standard, Premium, and Ultra.
Standard HDD storage utilizes inexpensive and slow magnetic hard drives. Standard SSD disks provide improved throughput and input, output per second (IOPS) by using SSD drives.
Premium storage provides higher maximum IOPS and throughput with premium SSD. This type of storage is best for most disk IO intensive applications such as databases and virtual desktops.
Ultra SSD is a new type of storage for very high-performance, disk IO intensive applications.
Storage Resources
Now that we understand the redundancy and performance characteristics of Azure storage, let’s dive into the actual storage resources.
Managed Disks are by far the most commonly used type of storage when deploying an IT environment in Azure using virtual machines. Recall that each VM must have an OS disk and sometimes one or more data disks. These disks attached to a VM are known as Managed Disks in Azure. There is an older type of disk called Unmanaged Disk, but for the purposes of our discussion we will stick to Managed Disks.
If you’re interested in learning more about the differences between managed and unmanaged disks, click here.
Managed disks are only available with LRS data redundancy since they are attached directly to VMs, and these VMs must be able to communicate with disks in a very high throughput, low latency way. This is why managed disks and the VMs they’re attached to must be in the same region. Disks come in Standard HDD, Standard SSD, Premium SSD, and Ultra SSD performance tiers.
Let’s explore each type of managed disk in detail:
- Standard HDD (S-type disk – e.g. S4, S10, S20, etc.)
- Available sizes: 32GB – 32TB in discreet increments (e.g. 32GB, 64GB, 128GB, etc.)
- Billed on allocated space, not used space. Creating an S-type disk of a certain size will result in a bill for the entire size, even if it completely unused.
- What you’re billed for:
- Capacity – Billed on size allocated
- Operations – fraction of a cent fee per 10,000 transactions
- Performance: Up to 2000 IOPS and up to 500 MB/sec throughput (performance varies significantly and can often be far below this limit)
- When to use?
- Very low disk IO applications (e.g. ADFS proxy server)
- Test environments
- When VM is deallocated but you still want to keep it around, changing it to an S-type disk saves on storage costs
- Standard SSD (E-type disk – e.g. E1, E4, E10, E20, etc.)
- Available sizes: 4GB – 32TB in discreet increments (e.g. 4GB, 64GB, 128GB, etc.)
- Billed on allocated space, not used space. Creating an E-type disk of a certain size will result in a bill for the entire size, even if it completely unused.
- What you’re billed for:
- Capacity – Billed on size allocated
- Operations – fraction of a cent fee per 10,000 transactions
- Performance: Up to 6000 IOPS and up to 750 MB/sec throughput (more consistent performance than S-type disks)
- When to use?
- Best for most non-disk IO heavy applications because of the balance between performance consistency and cost (e.g. domain controllers, file servers). Not a good fit for high IO database servers.
- Production environments, if no SLA is needed
- Most VDI desktop workloads for typical users
- Premium SSD (P-type disk – e.g. P1, P6, P10, P20, etc.)
- Available sizes: 4GB – 32TB in discreet increments (e.g. 4GB, 16GB, 32GB, 64GB, 128GB, etc.)
- Billed on allocated space, not used space. Creating a P-type disk of a certain size will result in a bill for the entire size, even if it completely unused.
- What you’re billed for:
- Capacity – Billed on size allocated
- Operations – no transaction costs
- Performance: Up to 20,000 IOPS and 900 MB/sec throughput
- When to use?
- Best disk performance for any disk IO intensive applications such as databases
- Great for power user virtual desktops and RDS session hosts with many users
- Expensive for data storage only when the VM is powered off. Consider converting P to S or E disk if VM is being deallocated and data stored for archival purposes.
- Premium SSD v2
- Available sizes: 1GB – 64TB, price per GB provisioned
- Billed on allocated space, not used space. Each disk has a baseline of 3,000 IOPS and 125 MB/s
- Add IOPS and throughput independently of disk size
- What you’re billed for:
- Capacity – Billed on size allocated
- Provisioned IOPS – Add IOPS independent of disk size
- Provisioned Throughput – Add throughput independent of disk size
- Performance: Up to 80,000 IOPS and 1,200 MB/sec throughput
- Ultra SSD
- High performance and high cost disk option for very disk IO intensive workloads
- Complex billing structure based on provisioned IOPS and throughput in addition to capacity storage
- Not commonly used with typical MSP workloads in Azure
Backup
Backup Vaults, as the name implies, are used by the Azure Backup service to store backup snapshots. It is a Block Blob storage container, and its cost is based on actual consumption. Currently, Azure backup supports Standard HDD performance tiers and LRS, ZRS and GRS data redundancy options.
Azure Backup is most commonly used by MSPs to protect data on VMs running inside of an Azure IT environment and can also be used to back up data from on-premises systems. To protect Azure VMs, the backup vault must reside in the same region as the VMs that are being backed up to it.
Use Azure backup to achieves compliance requirements of saving data in multiple geographic locations by selecting the GRS redundancy option when creating the backup vault. This way, there will be multiple copies of the backup data in the same datacenter where the VMs reside as well as multiple copies in another paired region. With GRS, Microsoft has pre-defined region pairs. More information is available here.
Azure Files
Azure Files is a PaaS offering for file storage. Compare Azure Files to a Microsoft-managed file server where you can create Windows shares and publish them out to the world. These shares can then be mounted directly on Windows, Linux, and macOS devices, either on-premises or in cloud VMs without any special drivers.
Azure Files supports LRS, ZRS, and GRS storage. Cost is based on capacity used and transaction fees. Azure Files is available with Standard and Premiums Azure Storage accounts. A Premium file share offers up to 100,000 IOPS and supports flies up to 100 TB in size. Preimium file shares are only available with LRS and ZRS storage accounts. A Standard file share provides 1,000 IOPS, up to 5 TB files, and supports GRS storage. A standard file share can support files up to 100 TB and 20,000 IOPS by enabling large file support. Enabling large file support is only available on LRS and ZRS standard file shares.
In summary, Azure offers an almost endless list of storage options with varying redundancy, performance, and cost characteristics. For MSPs, it is important to focus on the storage types that are commonly used for typical IT workloads (managed disks for VMs, Block Blob for Azure Backup and Azure Files for creating SMB shares) and avoid confusion around other storage types that are designed for developers creating applications and repositories.
Network
Azure’s flexibility when it comes to networking is vast and not without complexity. Many network resources are for advanced use cases and for developers who are designing new applications.
We will focus on 4 network resources that are most relevant to an MSP and the way they interrelate with each other: Virtual Networks, Public IP Addresses, Network Security Groups, and VPN Gateways.
Before delving into the specifics of these network resources, we need to understand how Azure charges for data transfer (aka bandwidth). The basic rule is that any data coming into an Azure data center is free while going out of an Azure region will be charged on a per GB basis. It doesn’t matter if the data is leaving a region and going into another region or leaving a region and going into some other, non-Azure location. In both cases, there is a charge. There is also a charge for data transfer over VNet peering in the same region as well as global network peering. However, data transfer within the same Azure virtual network free.
Costs of Data Transfer
How is the data transfer cost calculated? There are several factors that go into calculating bandwidth charges in Azure. For egress data, the first 100GB per month is free. The price after the first 100GB will depend on the geography the data is coming from and if the bandwidth is routed via the Microsoft Global Network or routed over an ISP. The price per GB also decreases as the amount of data transfer increases. The charge per GB decrease at 10TB, 40TB, 100TB and 350 TB per month tiers.
It is important to note that Azure data transfer is not charged per mbps (using 95% percentile or some other method), but rather per transferred GB of data. Let’s compare the two methods.
Colocation Provider A charges $50/month for 1mbps of bandwidth using the 95% percentile method. Assuming the line is utilized 95% for the entire month straight, that’s equivalent to 60sec/min*60min/hr*24hr/day*30.5days/month * (0.95 * 1mbps) = 2,503,440 megabits per month, or 305GB/month. For the same amount of data transfer, Azure cost will be $26.48.
Therefore, a useful number for cost comparison between “GB transferred” and “mbps” based pricing is $26 per fully utilized mbps line. Since in a typical hosted IT environment the line is utilized only fractionally the cost of bandwidth in Azure is relatively low compared to the way other hosting and colocation providers charge for bandwidth.
This data transfer fee applies to all methods of transfer: communicating with a VM in Azure, downloading a file from Azure Files, restoring from a backup to outside of the region where the backup vault resides, using site-to-site VPN, etc. Anytime data leaves the boundaries of an Azure region, there is a charge.
Networking Structure
With the cost of data transfer out of the way, let’s delve into the way networking is structured in Azure. At the top level there is a Virtual Network (VNet). A VNet has an address space that you as an MSP can define (e.g. 10.1.0.0/16). All objects within a VNet must fall inside of this address space. VNet also contains Subnets. These subnets are a way to segment the VNet into smaller sections. For instance, you could have a LAN and DMZ subnets within a vNet.
- VNet Address Space – 10.1.0.0/16
- LAN subnet – 10.1.0.0/17
- DMZ subnet – 10.1.254.0/24
Subnets that are part of a VNet and by devault, devices connected to a subnet can communicate with devices on any subnet connected to the VNet. A virtual Network Interfaces (VNIC) attached to a subnet. These VNIC are then attached to a VM and this is how VMs communicate with each other and the rest of the world.
VM->VNIC->Subnet->VNet.
Each VNIC has an assigned private IP address (or addresses), DNS settings, an optional public IP address and other network interface properties. In Azure, IP address and DNS settings are not set at the Windows level inside of a VM. The VM uses DHCP to acquire an IP address. This is required for management communication between Azure and the VM. The VMs can use the default Azure DNS or set custom DNS servers as a VNet property. Static IP reservations are set on the VNIC for VMs that require a consistent IP address.
You can Peer (i.e., connect) different vNets together. These vNets can be in the same Azure region or you can use Global vNet Peering to connect vNets in different regions.
Public IP addresses are billable Azure resources that can be assigned to a vNIC. There are dynamic IP addresses and static IP addresses. Dynamic IP addresses have a persistent DNS name that resolves to a dynamic IP, while a static IP address has a fixed IPv4 address and DNS name. Assigning a public IP address to a vNIC does not automatically expose the VM to the internet. In order to make it accessible from the internet a Network Security Group rule must be applied.
Network Security Groups (NSGs) is an access control list used to allow or deny traffic to a subnet or VNIC. NSGs are groups of rules that specify source, source port, destination, destination port, and protocol. Each rule has an action of allow or deny. If a rule is matched, the action is taken and rule processing stops. If an NSG is assigned to a subnet its rules will apply to all VMs whose VNICs are part of this subnet. Alternatively, NSGs can be assigned directly to a VNIC. In that case, the NSG rules apply to a single VM only. NSGs are non-billable network resources.
VPN Gateway is a service that allows encrypted, site-to-site IPSec VPN connectivity from an on-premises network or another cloud to an Azure VNet. VPN Gateways are Microsoft managed resources that get added to a special subnet in a VNet called the Gateway Subnet. VPN Gateway is a billable network resource. The smallest available is the Basic gateway with a throughput limit of 100 mbps and support for up to 10 site-to-site VPN tunnels. The largest VPN Gateway supports 10 Gbps of throughput with up to 100 tunnels.
Microsoft Azure Fundamentals: Complete!
Nerdio empowers MSPs to build successful cloud practices in Azure. We’ll continue to keep up on the latest Azure news and releases and will keep this document up-to-date in the process. Hopefully, these Microsoft Azure fundamentals helped you to get your head around what is, admittedly, a very complicated subject.
