AWS vs Azure: Market Share, Performance, Monitoring and Cost Control

Amazon and Microsoft have emerged as leaders in the public cloud computing space. As a result, many of us have Googled “AWS vs. Azure” or “Azure vs. AWS” to compare each platform’s growing list of service offerings. Some sources, such as this overview from Microsoft and this post on Public Cloud War: AWS vs Azure vs Google offer vital information.
However, if you’re an enterprise IT technologists or decision maker, you’ll also want to know how the platforms differ when it comes to the following key areas:

• Market Share
• Performance
• Cost Control 
• System Monitoring

In this post, we’ll take a closer look at how AWS and Azure compare in these areas.

AWS vs Azure Market Share

There’s no denying that AWS is currently the largest player in the public cloud space; AWS was first, and it offers a staggering depth and breadth in a dynamic platform.

Azure, long thought to be an ‘also ran’ or only appropriate for Microsoft-centered workloads, has become very competitive.

Take a look at this image from a recent Gartner report:

Azure is slightly behind AWS in the leader space. Microsoft has invested billions of dollars in making Azure competitive in this space, and clearly, it is paying off.  Not only Gartner but also, cloud industry thought leaders such as David Linthicum of Cloud Technology Partners have begun taking notice (listen to this Doppler podcast episode on Azure’s market growth).

For technologists and IT decision makers (and anyone who controls the budget), this means that a commitment to either one of these platforms is a relationship with a technology-forward, market leading organization. (Read more about Gartner’s analysis in this ZDNet article.)

Performance

Cloud computing resources are primarily divided into three distinct categories: compute, storage, and database. Each category has its own performance-related concerns and best practices. There is, however, a right way and wrong way to ask about the performance differences between AWS and Azure.

The wrong question to ask is: Which cloud platform performs better? That’s the wrong question because performance outcomes depend on what services are in-use, what solutions have been built using those services, and how well (or poorly) you’ve architected those solutions.

The right question is to ask is: What are the differences between the key service components and how do you decide which tool is best for the job?

To learn more about the performance considerations for each platform, check out the following resources: Best Practices for Amazon RDS and “Performance best practices for SQL Server in Azure Virtual Machines.  You can review Amazon storage classes here and those for Azure here.

Let’s take a closer look at AWS and Azure virtual machines with performance in mind.

Virtual Machine Performance Considerations

The fundamental computational building block of AWS is EC2 (Elastic Compute Cloud). The corresponding Azure building block is the Azure Virtual Machine.

Both services offer Windows and Linux machine images. It’s important to understand the types of virtual machines and when to use them; this will help you intelligently design solutions by applying the correct resources to your goal.

AWS EC2 Instances Types

• T2: Entry-level and testing instances (Amazon describes them as burstable).
• M4: General purpose instances using Intel Broadwell and Haswell processors are considered appropriate for production applications.
• M3: Another general purpose instance type using Intel’s Ivy Bridge processor.
• C4: Compute optimized instances using Intel’s Haswell processor. C4 instances support enhanced network and clustering.
• C3: Another high-performance instance type using the Ivy Bridge processor. Amazon’s approved use-cases include “…distributed analytics, high-performance science and engineering applications, ad serving, MMO gaming, and video-encoding.”
• X1: X1 instances are described as being “optimized for large-scale, enterprise-class, in-memory applications”. X1 instances employ the Haswell processor (E7-8880 v3).
• R4: R4 instances (utilizing Broadwell processors) are memory optimized and “[are recommended] for high-performance databases, data mining & analysis, in-memory databases, distributed web scale in-memory caches, applications performing real-time processing of unstructured big data, Hadoop/Spark clusters…”
• R3: R3 instances are also memory optimized and approved for database applications (though, not big data). These instances are intended for “high-performance databases, distributed memory caches, in-memory analytics, genome assembly and analysis, Microsoft SharePoint…”
• P2: P2 instances use high-performance GPUs from Intel and NVIDIA and are intended for “[machine learning], high-performance databases, computational fluid dynamics, computational finance, seismic analysis, molecular modeling, genomics, rendering, and other server-side GPU compute workloads.”
• G2: G2 instances are created using processors optimized for graphics from Intel and NVIDIA.
• F1: F1 instances are a specialized type of ultra high-performance EC2 resources that are created using Field Programmable Gate Array technology. Amazon describes the approved use cases as including “genomics research, financial analytics, real-time video processing, big data search and analysis, and security.”
• I3: I3 instances are optimized for high input/output use cases (for example, demanding database applications. Approved scenarios include hosting “NoSQL databases like Cassandra, MongoDB, Redis, in-memory databases such as Aerospike, scale out transactional databases, data warehousing, Elasticsearch, analytics workloads.“
• D2: D2 instances host very large local storage sets (up to 48 TB). The suggested use-case is “Massively Parallel Processing (MPP) data warehousing, MapReduce and Hadoop distributed computing, distributed file systems, network file systems, log or data-processing applications”

Amazon provides a detailed description of each type and usage guidance (with scenarios) here. Note that each of these instance types has subtypes (for example, the T2 type ranges in size from “nano” to “2xlarge.”
Also, note that there isn’t a one-size-fits-all approach to using computing resources. Instead, there are a wide variety of instance types, each designed to optimize specific computing elements and meet different requirements to help you create a well-architected solution.

Amazon provides guidance to help you choose the right EC2 type in the article, “Choosing the Right EC2 Instance Type for Your Application.”

Azure Virtual Machine Types

Like AWS EC2 machines, Azure virtual machines are divided into types, which are optimized for particular use cases.
Here’s a rundown of the different types:

• A series: General purpose VMs
• F series: Another general purpose VM type which will eventually replace the A
• D/DS series: Optimized for faster disk speeds
• G/GS series: Optimized for RAM
• N series: The N stands for NVIDIA (optimized for graphics intensive use cases)
• H series: Optimized for computationally demanding use cases (the “H” stands for HPC)
• L/LS series: Intended for low latency, storage optimized use cases

Microsoft divides these machine types according to category:

• General purpose
• Compute optimized
• Memory optimized
• Storage optimized
• GPU optimized
• High performance compute

Obviously, it isn’t enough to be familiar with the VM types (and the corresponding optimization categories). You also need guidance.

Fortunately, Microsoft has created a helpful concept called the Azure Compute Unit:
“We have created the concept of the Azure Compute Unit (ACU) to provide a way of comparing compute (CPU) performance across Azure SKUs. This will help you easily identify which SKU is most likely to satisfy your performance needs. ACU is currently standardized on a Small (Standard_A1) VM being 100 and all other SKUs then represent approximately how much faster that SKU can run a standard benchmark.”

Read the full documentation at “Overview of the Azure Compute Unit.”
More guidance can be found in Lee Stott’s excellent article, “Choosing the most appropriate Azure Virtual Machine Specification.”

Serverless Performance Considerations

Both Microsoft and Amazon offer serverless platforms that enable you to run code without the need to create, provision, or manage the VMs we reviewed above. The virtual machines detailed comprise these serverless solutions but they’re abstracted as a service.

Serverless computing changes your focus from infrastructure to the code that runs on whatever infrastructure is appropriate. Amazon’s serverless computing platform is called Lambda. Azure Functions is Microsoft’s serverless solution.

Serverless is a software and therefore, a developer-centric model of computing;  performance considerations are correspondingly centered on the needs of the code running on the solution and not the infrastructure.

Key considerations include:

• Supported languages (Lambda: Java, Node.js, Python, C#; Azure Functions: C#, F#, Node.js, Python, PHP, batch, bash)
• Web dashboard ease of use
• Source code (open or closed; Lambda is closed, Azure is open)
• Deployment model
• Authentication methods
• Max number of executions per request

A deeper exploration of performance optimization on Azure Functions and Lambda is well beyond this post’s scope, so I will direct the reader to these high-quality references:
Azure Functions Overview
AWS Lambda Overview

Performance Summary

Measuring cloud platform performance isn’t as simple as, for example, comparing one service’s VM type or serverless offering against its competitor. Architecture and applying the right tools to the right workload use case are key for optimizing performance.

For a deeper consideration of this topic, I suggest consulting Microsoft’s “Azure Solution Architectures” and Amazon’s “AWS Architecture Center.”

Cost Control

For technologists, AWS and Azure provide exciting opportunities to design and implement solutions using computing resources in new, interesting, and dynamic ways.
Amid the reality (and hype) for these new opportunities, it’s important to understand that there’s an ongoing (and for many IT shops, unfamiliar) responsibility to actively monitor and control your cloud-related costs (for an excellent overview of cloud economics, see this Cloud Technology Partners article, “Cloud Economics – Are You Getting the Bigger Picture?”

I’ve seen cloud projects go terribly awry because cost control was not considered a critical task from the start, so don’t take this area for granted.

AWS Cost Control

On AWS, cost controls are available from a collection of built-in tools centered on the Billing and Cost Management dashboard. The dashboard provides information about the following:
– Spend Summary
– Month-to-Date Spend by Service
– Month-to-Date Top Services by Spend
Additional guidance is available in the Amazon article, “Avoiding Unexpected Charges.”

Azure Cost Control

Azure resources are organized around subscriptions (AWS resources are organized around accounts). Azure billing information is gathered from the resources created and consumed within individual subscriptions.

Just as there can be many AWS accounts, there can also be different subscriptions associated with an Azure AD instance (for more information about this see, “How Azure subscriptions are associated with Azure Active Directory“).

Azure’s built-in cost management tools can be labor intensive. You can review Microsoft’s guide to Azure billing at this article on Monitoring Usage and Costs.

Considering the amount of work required to track your Azure spend, luckily you can configure automated billing alerts, which is described here. Even more fortunate is the news that Microsoft recently acquired Cloudyn.

Cloudyn, which is often recommended by Microsoft cloud architects, is a fully featured cloud management and cost monitoring tool. No doubt, Cloudyn’s capabilities will eventually be streamlined into Azure, and we can soon expect simplification of Azure’s cost control toolset.

Monitoring

Last, but certainly not least in our comparative tour, let’s take a look at monitoring.

AWS Cloudwatch

Here’s how Amazon describes Cloudwatch:
“Amazon CloudWatch is a monitoring service for AWS cloud resources and the applications you run on AWS. You can use Amazon CloudWatch to collect and track metrics, collect and monitor log files, set alarms, and automatically react to changes in your AWS resources.”
The full description is here.

And, for an overview of everything you can monitor with Cloudwatch, go to the “Amazon CloudWatch Metrics and Dimensions Reference” article.

Azure Monitor

Here’s how Microsoft describes Azure Monitor:
“Azure Monitor is the platform service that provides a single source for monitoring Azure resources. With Azure Monitor, you can visualize, query, route, archive, and take action on the metrics and logs coming from resources in Azure. You can work with this data using the Monitor portal blade, Monitor PowerShell Cmdlets, Cross-Platform CLI, or Azure Monitor REST APIs. In this article, we walk through a few of the key components of Azure Monitor, using the portal for demonstration.”

The full description is here.

For an overview of Azure Monitor metrics (i.e., what it helps you track), consult the documentation here.

AWS vs Azure: Market Share, Performance, Monitoring and Cost Control: Conclusion

Both Microsoft’s Azure and Amazon’s AWS are powerful, dynamic cloud platforms; you can accomplish remarkable things with either offering.
To choose the right solution, don’t ask yourself, ‘which platform is better’ or faster or some other simplistic measure. Focus instead on understanding the following:

• What you’re trying to accomplish and your current state (it seems simple, but many people overlook a thorough examination of these basic questions)
• VM types and use cases
• PaaS offering types, use cases, and optimization best practices (for example, Azure SQL, or Amazon RDS optimization methods)
• Serverless optimization and development best practices
• Cost control and reporting methods
• Overall platform monitoring (the cloud equivalent of a Network Operations Center)

By keeping these items top of mind, you’ll increase your odds of a successful cloud project and create the foundation for a solid cloud strategy.