Azure Spot Virtual Machines are a purchasing option that can save significant amounts on infrastructure, for certain types of workloads. Azure Spot VMs are not created as a separate type of VM in Azure, instead, it’s a capability to bid for spare capacity at a discount from on demand pricing. But there’s one caveat: at any given point in time when Azure needs the capacity back, the Azure infrastructure will deallocate and evict the Spot VM from your environment.
In the past, Azure offered Low Priority VMs, which were charged at a fixed price. In March this year, that option was replaced by Azure Spot VMs, except in Azure Batch, where Low Priority VMs are still available. With the newer option, you bid by indicating the maximum price you are willing to pay for a VM.
Why Use Azure Spot VMs
Microsoft allows you to use their unused compute capacity at a discounted rate. These discounts are variable and can go up to >90% of the pay-as-you-go rates, depending on the size of the VM and the unused capacity available. The amount of capacity available can vary based on region, time of day, and more.
You can use Azure Spot VMs for workloads that are not critical or need to run 24×7. For example, a basic scenario would be for testing the load of a particular workload that you want to perform for a fraction of the cost. Other use cases include batch processing, stateless applications that can scale out, short-lived jobs that can be run again if the workload is evicted, etc.
Keeping in mind that there are no SLAs or availability guarantees for these Spot VMs. The most significant concern users have is that they may not be available to you to get resources, especially at peak load times. The issue is not with the service, it’s with how it is intended to work. Be aware of this when making the decision to use this approach.
Some important things to consider when using Azure Spot VMs:
VMs are evicted based on capacity or by if the price exceeds your maximum set price
Azure’s infrastructure will evict Spot VMs if Azure needs the capacity for pay-as-you-go workloads
B-series and promo versions of any size (like Dv2, NV, NC, H promo sizes) are not supported
A Spot VM cannot be converted to a regular VM or vice versa. You would have to delete the VM and attach the disk to a new VM
VMs that are evicted and deallocated are not turned back on when capacity or price comes back inside allowed limits, you will need to manually turn them back on
You will be unable to create your VM if the capacity or pricing are not inside the allowed limits
How to Use Azure Spot VMs
You have two choices when deploying Azure Spot VMs. When you enable the feature in your Azure environment, you need to select what type of eviction and eviction policy you want for the capacity:
Types of eviction:
By capacity only – the VM is evicted when Azure needs capacity. In other words, your maximum price for the spot VM is the current price of the regular VM
By maximum price – the VM is evicted when the spot price is greater than the maximum price
Eviction policy (currently available):
Stop / Deallocate
The eviction policy for Spot VMs is set to Stop / Deallocate which moves your evicted VMs to the stopped-deallocated state, allowing you to redeploy the evicted VMs at a later time. Remember reallocating Spot VMs will be dependent on there being available Spot capacity. However, the deallocated VMs will count against your spot vCPU quota and you will be charged for your underlying disks. If your Spot VM is evicted, but you still need capacity right away, Azure recommends you use a standard VM instead of Spot VM.
Do Azure Spot VMs Save You Money?
Yes: these discounted VMs can save you money. How much will vary? Azure Spot VMs prices are not fixed like standard instances, they change over the day and vary based on the supply and demand in a particular region.
Azure Spot VMs are a good option that can provide cost savings if your application can handle unexpected interruptions.
Use Spot VMs as part of your full cost-saving strategy. For on-demand workloads that aren’t needed 24×7, ensure you have appropriate on/off schedules in place. All VMs should be properly sized to the workload. You can start automating these Azure cost optimization tasks with ParkMyCloud today.
There are a wide range of Microsoft Azure VM types that are optimized to meet various needs. Machine types are specialized, and vary by virtual CPU (vCPU), disk capability, and memory size, offering a number of options to match any workload.
With so many options available, finding the right machine type for your workload can be confusing – which is why we’ve created this overview of Azure VM types (as we’ve done with EC2 instance types, and Google Cloud machine types). Note that while AWS EC2 instance types have names associated with their purpose, Azure instance type names are simply in a series from A to N. The chart below and written descriptions are a brief and easy reference, but remember that finding the right machine type for your workload will always depend on your needs.
General purpose VMs have a balanced CPU and memory, making them a great option for testing and development, smaller to medium databases, and web servers with low to medium traffic:
The newest size recommendation in the DC-series, the DCsv2, stands out because of the data protection and code confidentiality it provides while it’s being processed in the cloud. SGX technology and the latest generation of Intel XEON E-2288G Processor back these machines – these VMs can go up to 5.0GHz.
A-series VMs have a CPU-to-memory ratio that works best for entry-level workloads, like those for development and testing. Sizing is throttled for consistent processor performance to run the instance. Av2-series has the option to be deployed on a number of hardware types and processors. To figure out which hardware the size should be deployed on, users must query the virtual hardware in the VM.
Dv2 and Dsv2-series
Dv2 VMs boast powerful CPUs – roughly 35% faster than D-series VMs – and optimized memory, great for production workloads. They have the same memory and disk configurations as the D-series, based upon either a 2.1 GHz, 2.3 GHz or 2.4 GHz processor and Intel Boost Technology.
Dsv2-series sizes run on the same Dv2 processors with Intel Turbo Boost Technology 2.0 and also use premium storage.
With expanded memory (from ~3.5 GiB/vCPU to 4 GiB/vCPU) and adjustments for disk and network limits, the Dv3 series Azure VM type offers the most value to general purpose workloads. The sizes in this series offer a combination of memory, temporary storage, and vCPU that best fits best for enterprise applications, relational databases, in-memory caching, and analytics. It’s important to note that the Dv3-series no longer has the high memory VM sizes of the D/Dv2-series.
This series’ sizes feature premium storage disks and run on 2.1, 2.3, or 2.4 GHz Intel Xeon processors with Intel Turbo Boost Technology 2.0, the Dsv3-series is best suited for most production workloads.
Similar to the AWS t-series machine type family, B-series burstable VMs and ideal for workloads that do not rely on full and continuous CPU performance. Use cases for this series’ VM types include small databases, dev and test environments and low-trafficweb servers, microservices and more. Thanks to the B-series, customers can purchase a VM size that builds up credits when underutilizedcompared to its base performance, and the accumulated credits can be used as bursts. Spikes in compute power allow the VM to burst above the base performance if for higher CPU performance when needed.
Dav4 and Dasv4-series
Dav4-series are one of the new sizes that utilize a 2.35Ghz AMD EPYCTM 7452 processor and can reach a max frequency of 3.35GHz. The combination of memory, temporary storage and vCPU makes these VMs suitable for most production workloads. For premium SSD, Dasv4-series sizes are the best option.
Ddv4 and Ddsv4-series
Similar to other VMs in the D-series, these sizes utilize a combination of memory, temporary disk storage and vCPU that provides a better value for most general-purpose workloads. These new VM sizes have faster and 50% larger local storage (up to 2,400 GiB) and are designed for applications that benefit from low latency, high-speed local storage. The Ddv4-series processors run in a hyper-threaded configuration making them a great option for enterprise-grade applications, relational databases, in-memory caching, and analytics.
The major difference between the two series is that the Ddsv4-series supports Premium Storage and premium Storage caching, while Ddv4-series does not.
Dv4 and Dsv4-series
Both of these new series are currently in preview. The Dv4-series is optimal for general purpose workloads since they run on processors in a hyper-threaded configuration. It features a sustained all core Turbo clock speed of 3.4 GHz.
The Dsv4-series runs on the same processors as the Dv4-series, and even has the same features. The major difference between the two series is that the Dsv4-series supports Premium Storage and premium Storage caching, while Dv4-series does not.
Compute optimized Azure VM types offer a high CPU-to-memory ratio. They’re suitable for medium traffic web servers, network appliances, batch processing, and application servers.
With a base core frequency of 3.4 GHz and a maximum single-core turbo frequency of 3.7 GHz, Fsv2 series VM types offer up to twice the performance boost for vector processing workloads. Not only do they offer great speed for any workload, the Fsv2 also offers the best value for its price based on the ratio of Azure Compute Unit (ACU) per vCPU.
Memory optimized VM types are higher in memory as opposed to CPU, and best suited for relational database services, analytics, and larger caches.
Enterprise applications and large databases will benefit most from the M-series for having the most memory (up to 3.8 TiB) and the highest vCPU count (up to 128) of any VM in the cloud.
The VMs in this series offer the highest vCPU count (up to 416 vCPUs) and largest memory (up to 11.4 TiB) of any VM. Because of these features, It’s ideal for extremely large databases or applications that benefit from high vCPU counts and large amounts of memory. The Mv2-series runs on an Intel® Xeon® processor with an all core base frequency of 2.5 GHz and a max turbo frequency of 3.8 GHz.
Dv2 and DSv2-series 11-15
The Dv2 and DSv2-series 11-15 follow in the footsteps of the original D-series, the main differentiation is a more powerful CPU. For applications that require fast vCPUs, reliable temporary storage, and demand more memory, the Dv2 and DSv2-series all fit the bill for enterprise applications. The Dv2 series offers speed and power with a CPU about 35% faster than that of the D-series. Based on the 2.1, 2.3 and 2.4 GHz Intel Xeon® processors and with Intel Turbo Boost Technology 2.0, they can reach up to 3.1 GHz. The Dv2-series also has the same memory and disk configurations as the D-series.
Ev3-series and Esv3-series
The Ev3 follows in the footsteps of the high memory VM sizes originating from the D/Dv2 families. This Azure VM types provides excellent value for general purpose workloads, boasting expanded memory (from 7 GiB/vCPU to 8 GiB/vCPU) with adjustments to disk and network limits per core basis in alignment with the move to hyperthreading.
The Esv3-series is the optimal choice for memory-intensive enterprise applications. If you want premium storage disks, the Esv3-series sizes are the perfect ones. A difference between the two series is that the Esv3-series supports Premium Storage and premium Storage caching, while Ev3-series does not.
Eav4 and Easv4-series
The Eav4 and Easv4-series utilize the processors they run on in a multi-threaded configuration increasing options for running memory optimized workloads. Though the Eav4-series and Easv4-series have the same memory and disk configurations as the Ev3 & Esv3-series, the Eav4-series sizes are ideal for memory-intensive enterprise applications.
Use the Easv4-series sizes for premium SSD. The Easv4-series sizes are ideal for memory-intensive enterprise applications. Easv4-series sizes can achieve a boosted maximum frequency of 3.35GHz.
Edv4 and Edsv4-series
High vCPU counts and large amounts of memory make Edv4 and Edsv4-series the ideal option for extremely large databases and other applications that benefit from these features. It features a sustained all core Turbo clock speed of 3.4 GHz and many new technology features. Unlike the Ev3/Esv3 sizes with Gen2 VMs, these new VM sizes will have 50% larger local storage, as well as better local disk IOPS for both read and write.
The Edv4 and Edsv4 virtual machine sizes feature up to 504 GiB of RAM, in addition to fast and large local SSD storage (up to 2,400 GiB). These virtual machines are ideal for memory-intensive enterprise applications and applications that benefit from low latency, high-speed local storage. You can attach Standard SSDs and Standard HDDs disk storage to the Edv4 VMs.
Ev4 and Esv4-series
These new sizes are currently under Public Preview Only – you can signup to access them here.
The Ev4 and Esv4-series are ideal for various memory-intensive enterprise applications. They run in a hyper-threaded configuration on 2nd Generation Intel® Xeon® processors and feature up to 504 GiB of RAM.
For big data, data warehousing, large transactional databases, SQL, and NoSQL databases, storage optimized VMs are the best type for their high disk throughput and IO.
Lsv2-series VMs provide high throughput, low latency, directly mapped local NVMe making it these VMs ideal for NoSQL stores such as Apache Cassandra and MongoDB. The Lsv2-series comes in sizes 8 to 80 vCPU and each vCPU has 8 GiB of memory. VMs in this series are optimized and use the local disk on the node that is attached directly to the VM.
GPU VM types, specialized with single or multiple NVIDIA GPUs, work best for video editing and heavy graphics rendering – as in compute-intensive, graphics-intensive, and visualization workloads.
NC, NCv2 and NCv3-series
The sizes in these series are optimized for compute-intensive and network-intensive applications and algorithms. The NCv2-series is powered by NVIDIA Tesla P100 GPUs and provides more than double the computational performance of the NC-series. The NCv3-series is powered by NVIDIA Tesla V100 GPUs and can provide 1.5x the computational performance of the NCv2-series.
NV and NVv3-series
These sizes were made and optimized for remote visualization, streaming, gaming, encoding, and VDI scenarios. These VMs are targeted for GPU accelerated graphics applications and virtual desktops where customers want to visualize their data, simulate results to view, work on CAD, or render and stream content.
ND and NDv2-series
These series are focused on training and inference scenarios for deep learning. The ND-series VMs are a new addition to the GPU family and offer excellent performance for training and inference making them ideal for Deep Learning workloads and AI. The ND-series is also enabled to fit much larger neural net models thanks to the much larger GPU memory size (24 GB).
The NDv2-series is another new addition to the GPU family and with its excellent performance, it meets the needs of the most demanding machine learning, GPU-accelerated AI, HPC workloads and simulation.
The NVv4-series VMs are optimized and designed for remote visualization and VDI. With partitioned GPUs, NVv4 offers the right size for workloads requiring smaller GPU resources. With separated GPUs, this series offers the perfect size VMs for workloads that require smaller GPU resources.
High Performance Compute
For the fastest and most powerful virtual machines, high performance compute is the best choice with optional high-throughput network interfaces (RDMA).
The H-series VMs were built for handling batch workloads, analytics, molecular modeling, and fluid dynamics. These 8 or 16 vCPU VMs are built on the Intel Haswell E5-2667 v3 processor technology and up to 14 GB of RAM per CPU core, and no hyperthreading.
Besides sizable CPU power, the H-series provides options for low latency RDMA networking with FDR InfiniBand and different memory configurations for supporting memory intensive compute requirements.
Applications driven by memory bandwidth, such as explicit finite element analysis, fluid dynamics, and weather modeling are the best fit for HB-series VMs. These VMs feature 4 GB of RAM per CPU core and no simultaneous multithreading.
For applications driven by dense computation, like implicit finite element analysis, molecular dynamics, and computational chemistry HC-series VMs are the best fit. HC VMs feature 8 GB of RAM per CPU core, and no hyperthreading.
Similar to other VMs in the High Performance compute family, HBv2-series VMs are optimized for applications driven by memory bandwidth, such as fluid dynamics, finite element analysis, and reservoir simulation. HBv2 VMs feature 4 GB of RAM per CPU core, and no simultaneous multithreading. These VMs enhance application performance, scalability, and consistency.
What Azure VM type is right for your workload?
The good news is that with this many options VM types, you’re bound to find the right type to meet your computing needs – as long as you know what those needs are. With good insight into your workload, usage trends, and business needs, you’ll be able to find the Azure VM type that’s right for your workloads.
Spot instances and similar “spare capacity” models are frequently cited as one of the top ways to save money on public cloud. However, we’ve noticed that fewer cloud customers are taking advantage of this discounted capacity than you might expect.
We say “spot instances” in this article for simplicity, but each cloud provider has their own name for the sale of discounted spare capacity – AWS’s spot instances, Azure’s spot VMs and Google Cloud’s preemptible VMs.
Spot instances are a type of purchasing option that allows users to take advantage of spare capacity at a low price, with the possibility that it could be reclaimed for other workloads with just brief notice.
In the past, AWS’s model required users to bid on Spot capacity. However, the model has since been simplified so users don’t actually have to bid for Spot Instances anymore. Instead, they pay the Spot price that’s in effect for the current hour for the instances that they launch. The prices are now more predictable with much less volatility. Customers still have the option to control costs by providing a maximum price that they’re willing to pay in the console when they request Spot Instances.
Spot Instances in Each Cloud
Variations of spot instances are offered across different cloud providers. AWS has Spot Instances while Google Cloud offers preemptible VMs and as of March of this year, Microsoft Azure announced an even more direct equivalent to Spot Instances, called Azure Spot Virtual Machines.
Spot VMs have replaced the preview of Azure’s low-priority VMs on scale sets – all eligible low-priority VMs on scale sets have automatically been transitioned to Spot VMs. Azure Spot VMs provide access to unused Azure compute capacity at deep discounts. Spot VMs can be evicted at any time if Azure needs capacity.
AWS spot instances have variable pricing. Azure Spot VMs offer the same characteristics as a pay-as-you-go virtual machine, the differences being pricing and evictions. Google Preemptible VMs offer a fixed discounting structure. Google’s offering is a bit more flexible, with no limitations on the instance types. Preemptible VMs are designed to be a low-cost, short-duration option for batch jobs and fault-tolerant workloads.
Adoption of Spot Instances
Our research indicates that less than 20% of cloud users use spot instances on a regular basis, despite spot being on nearly every list of ways to reduce costs (including our own).
While applications can be built to withstand interruption, specific concerns remain, such as loss of log data, exhausting capacity and fluctuation in the spot market price.
In AWS, it’s important to note that while spot prices can reach the on-demand price, since they are driven by long-term supply and demand, they don’t normally reach on-demand price.
A Spot Fleet, in which you specify a certain capacity of instances you want to maintain, is a collection of Spot Instances and can also include On-Demand Instances. AWS attempts to meet the target capacity specified by using a Spot Fleet to launch the number of Spot Instances and On-Demand Instances specified in the Spot Fleet request.
To help reduce the impact of interruptions, you can set up Spot Fleets to respond to interruption notices by hibernating or stopping instances instead of terminating when capacity is no longer available. Spot Fleets will not launch on-demand capacity if Spot capacity is not available on all the capacity pools specified.
AWS also has a capability that allows you to use Amazon EC2 Auto Scaling to scale Spot Instances – this feature also combines different EC2 instance types and pricing models. You are in control of the instance types used to build your group – groups are always looking for the lowest cost while meeting other requirements you’ve set. This option may be a popular choice for some as ASGs are more familiar to customers compared to Fleet, and more suitable for many different workload types. If you switch part or all of your ASGs over to Spot Instances, you may be able to save up to 90% when compared to On-Demand Instances.
Another interesting feature worth noting is Amazon’s capacity-optimized spot instance allocation strategy. When customers diversify their Fleet or Auto Scaling group, the system will launch capacity from the most available capacity pools, effectively decreasing interruptions. In fact, by switching to capacity-optimized allocation users are able to reduce their overall interruption rate by about 75%.
Is “Eviction” Driving People Away?
There is one main caveat when it comes to spot instances – they are interruptible. All three major cloud providers have mechanisms in place for these spare capacity resources to be interrupted, related to changes in capacity availability and/or changes in pricing.
This means workloads can be “evicted” from a spot instance or VM. Essentially, this means that if a cloud provider needs the resource at any given time, your workloads can be kicked off. You are notified when an AWS spot instance is going to be evicted: AWS emits an event two minutes prior to the actual interruption. In Azure, you can opt to receive notifications that tell you when your VM is going to be evicted. However, you will have only 30 seconds to finish any jobs and perform shutdown tasks prior to the eviction making it almost impossible to manage. Google Cloud also gives you 30 seconds to shut down your instances when you’re preempted so you can save your work for later. Google also always terminates preemptible instances after 24 hours of running. All of this means your application must be designed to be interruptible, and should expect it to happen regularly – difficult for some applications, but not so much for others that are rather stateless, or normally process work in small chunks.
Companies such as Spot – recently acquired by NetApp (congrats!) – help in this regard by safely moving the workload to another available spot instance automatically.
Our research has indicated that fewer than one-quarter of users agree that their spot eviction rate was too low to be a concern – which means for most, eviction rate is a concern. Of course, it’s certainly possible to build applications to be resilient to eviction. For instance, applications can make use of many instance types in order to tolerate market fluctuations and make appropriate bids for each type.
AWS also offers an automatic scaling feature that has the ability to increase or decrease the target capacity of your Spot Fleet automatically based on demand. The goal of this is to allow users to scale in conservatively in order to protect your application’s availability.
Early Adopters of Spot and Other Innovations May be One and the Same
People who are hesitant to build for spot more likely use regular VMs, perhaps with Reserved Instances for savings. It’s likely that people open to the idea of spot instances are the same who would be early adopters for other tech, like serverless, and no longer have a need for Spot.
For the right architecture, spot instances can provide significant savings. It’s a matter of whether you want to bother.
There’s a vast amount of available resources that give advice on Azure best practices. Based on recent recommendations given by experts in the field, we’ve put together this list of 10 of the best practices for 2020 to help you fully utilize and optimize your Azure environment.
1. Ensure Your Azure VMs are the Correct Size
“There are default VM sizes depending on the image that you choose and the affected Region so be careful and check if the proposed one is really what you need. The majority of the times you can reduce the size to something that fits you better and at a lower cost.”
2. If you use the Azure Cost Management Tool, Know the Limitations
Azure Cost Management can be a useful tool in your arsenal: “Listed as “cost management + billing” in the Azure portal, the Azure Cost Management service’s cost analysis feature offers comprehensive insights into the costs incurred by your Azure resources—starting from the subscription level. This can then be drilled down to specific resource groups and/or resources. The service also provides an overview of current costs as well as a monthly forecast based on the current consumption rate.”
However, know that visibility and action are not equivalent: “Even though [cloud efficiency] is a core tenant of Microsoft Azure Cost Management, optimization is one of the weakest features of the product. The essence of the documentation around this is that you should manually eliminate waste, without going into much detail about what is being wasted or how to eliminate it. Plus, this expects manual intervention and review of each resource without giving direct actions to eliminate the waste.”
3. Approach Role-Based Access Control (RBAC) Systematically
“Using Azure RBAC, you can segregate duties within your team and grant only the amount of access to users that they need to perform their jobs. Instead of giving everybody unrestricted permissions in your Azure subscription or resources, you can allow only certain actions at a particular scope.”
“Even with these specific pre-defined roles, the principle of least privilege shows that you’re almost always giving more access than is truly needed. For even more granular permissions, you can create Azure custom roles and list specific commands that can be run.”
“When you delete a virtual machine in Azure, by default, in order to protect against data loss, any disks that are attached to the VM aren’t deleted. One thing to remember is that after a VM is deleted, you will continue to pay for these “orphaned” unattached disks. In order to minimise storage costs, make sure that you identify and remove any orphaned disk resource.”
“Centralize tagging across your Azure environments. This enables you to discover, group and consistently tag cloud resources across your cloud providers – manually or through automated tag rules. Maintaining a consistent tagging structure allows you to see resource information from all cloud providers for enhanced governance, cost analytics and chargeback.”
6. Decipher how and when to utilize the Azure logging services
“Logs are a major factor when it comes to successful cloud management. Azure users can access a variety of native logging services to maintain reliable and secure operations. These logging options can be broken down into three overarching types, as well as eight log categories. The granular data collected by Azure logs enables enterprises to monitor resources and helps identify potential system breaches.”
“Serverless computing provides a layer of abstraction that offloads maintenance of the underlying infrastructure to the cloud provider. That’s a form of workload automation in and of itself, but IT teams can take it a step further with the right tools.
Developers and admins can use a range of serverless offerings in Azure, but they need to understand how they want their workflow to operate in order to select the right services. To start, determine whether your application has its own logic to direct events and triggers, or whether that orchestration is defined by something else.”
“APIs handle an immense amount of data, which is why it’s imperative to invest in API security. Think of authentication as an identification card that proves you are who you say you are. Although Azure Database provides a range of security features, end users are required to practice additional security measures. For example, you must manage strong credentials yourself. Active Directory is the authentication solution of choice for enterprises around the world, and the Azure-hosted version only adds to the attraction as companies continue migrating to the cloud.”
10. Multi-Factor Authentication for all standard users
“Businesses that don’t add extra layers of access protection – such as two-step authentication – are more susceptible to credential theft. Credential thefts are usually achieved by phishing or by planting key-logging malware on a user’s device; and it only takes one compromised credential for a cybercriminal to potentially gain access to the whole network.
Enforcing multi-factor authentication for all users is one of the easiest – yet most effective – of the seven Azure security best practices, as it can be done via Azure Active Directory within a few minutes.”
You can use these best practices as a reference to help you ensure you are fully optimizing all available features in your Azure environment. Have any Azure best practices you’ve learned recently? Let us know in the comments below!
Microsoft Azure growth has long held the silver medal in public cloud. As of Q1 2020, Azure held 17% of the public cloud market, behind AWS’s 32%. But much of the adaptation to COVID-19 has happened after the Q1 period, which means they’re missing some dramatic activity: the drop in usage for businesses with lower demand, the massive increase in usage for those with high demand, and the infrastructure changes to support the at-home workforce.
Azure Growth Trends
Market reporting comparing Azure to its competitors in the IaaS market has shown steady growth and gain in market share. Microsoft reported that Azure grew 59% year-over-year last quarter, and has been growing at similar rates for the past year.
While these Azure growth rates are reported, the actual revenue numbers are reported as part of the “Intelligent Cloud” business, which includes Azure, other private and hybrid server products, GitHub, and enterprise services.
Something to keep in mind is that it’s easy to equate growth with net new customers Azure has gained – however, much of the growth comes from the increase in resources and usage within each customer. As just one example, among ParkMyCloud users, the average number of resources per Azure account increased 30-fold over a six-month period ending in February this year.
COVID-19 and Azure Usage
Back in March, Microsoft shared that, given any capacity constraints within a region, it would be giving resource priority to certain types of customers: first responders, health and emergency management services, critical government infrastructure, and Microsoft Teams to enable remote work. Even as they shared that, some customers were already running up against capacity constraints in certain regions and unable to create or restart VMs.
Whether customers experienced these shortages themselves or not, we’ve heard anecdotally that the possibility of capacity constraints has instilled enough fear in some that they’ve chosen to leave resources running when not being used as an (expensive) guarantee of availability for the next time they’re needed.
Microsoft Teams and Windows Virtual Desktops (VDI) are also seeing rapid adoption. As of last month, Teams daily active users were up to 75 million, up from 32 million in early March. Teams is part of the Productivity and Business Processes segment and does not impact the Intelligent Cloud revenue. However, it is integrated with Office 365 products, making it the platform of choice for many new users right now almost by default, similarly to the many enterprise users that adopt Azure as part of larger Microsoft agreements.
So – is Azure experiencing growth? Certainly, yes. But is it growing faster than competitors? Right now, there’s no evidence that it is.
New to Azure?
Are you among the newest batch of Azure users? There’s a lot to learn. Here are a few resources other new users have found helpful.
Microsoft Azure IAM, also known as Access Control (IAM), is the product provided in Azure for RBAC and governance of users and roles. Identity management is a crucial part of cloud operations due to security risks that can come from misapplied permissions. Whenever you have a new identity (a user, group, or service principal) or a new resource (such as a virtual machine, database, or storage blob), you should provide proper access with as limited of a scope as possible. Here are some of the questions you should ask yourself to maintain maximum security:
1. Who needs access?
Granting access to an identity includes both human users and programmatic access from applications and scripts. If you are utilizing Azure Active Directory, then you likely want to use those managed identities for role assignments. Consider using an existing group of users or making a new group to apply similar permissions across a set of users, as you can then remove a user from that group in the future to revoke those permissions.
Programmatic access is typically granted through Azure service principals. Since it’s not a user logging in, the application or script will use the App Registration credentials to connect and run any commands. As an example, ParkMyCloud uses a service principal to get a list of managed resources, start them, stop them, and resize them.
2. What role do they need?
Azure IAM uses roles to give specific permissions to identities. Azure has a number of built-in roles based on a few common functions:
Owner – Full management access, including granting access to others
Contributor – Management access to perform all actions except granting access to others
User Access Administrator – Specific access to grant access to others
Reader – View-only access
These built-in roles can be more specific, such as “Virtual Machine Contributor” or “Log Analytics Reader”. However, even with these specific pre-defined roles, the principle of least privilege shows that you’re almost always giving more access than is truly needed.
For even more granular permissions, you can create Azure custom roles and list specific commands that can be run. As an example, ParkMyCloud recommends creating a custom role to list the specific commands that are available as features. This ensures that you start with too few permissions, and slowly build up based on the needs of the user or service account. Not only can this prevent data leaks or data theft, but it can also protect against attacks like malware, former employee revenge, and rogue bitcoin mining.
3. Where do they need access?
The final piece of an Azure IAM permission set is deciding the specific resource that the identity should be able to access. This should be at the most granular level possible to maintain maximum security. For example, a Cloud Operations Manager may need access at the management group or subscription level, while a SQL Server utility may just need access to specific database resources. When creating or assigning the role, this is typically referred to as the “scope” in Azure.
Our suggestion for the scope of a role is to always think twice before using the subscription or management group as a scope. The scale of your subscription is going to come into consideration, as organizations with many smaller subscriptions that have very focused purposes may be able to use the subscription-level scope more frequently. On the flip side, some companies have broader subscriptions, then use resource groups or tags to limit access, which means the scope is often smaller than a whole subscription.
More Secure, Less Worry
By revisiting these questions for each new resource or new identity that is created, you can quickly develop habits to maintain a high level of security using Azure IAM. For a real-world look at how we suggest setting up a service principal with a custom role to manage the power scheduling and rightsizing of your VMs, scale sets, and AKS clusters, check out the documentation for ParkMyCloud Azure access, and sign up for a free trial today to get it connected securely to your environment.