Azure for AWS Professionals
This article helps Amazon Web Services (AWS) experts understand the basics of Microsoft Azure accounts, platform, and services. It also covers key similarities and differences between the AWS and Azure platforms.
- How accounts and resources are organized in Azure.
- How available solutions are structured in Azure.
- How the major Azure services differ from AWS services.
Azure and AWS built their capabilities independently over time so that each has important implementation and design differences.
Like AWS, Microsoft Azure is built around a core set of compute, storage, database, and networking services. In many cases, both platforms offer a basic equivalence between the products and services they offer. Both AWS and Azure allow you to build highly available solutions based on Windows or Linux hosts. So, if you're used to development using Linux and OSS technology, both platforms can do the job.
While the capabilities of both platforms are similar, the resources that provide those capabilities are often organized differently. Exact one-to-one relationships between the services required to build a solution are not always clear. There are also cases where a particular service might be offered on one platform, but not the other. See charts of comparable Azure and AWS services.
Accounts and subscriptions
Azure services can be purchased using several pricing options, depending on your organization's size and needs. See the pricing overview page for details.
Azure subscriptions are a grouping of resources with an assigned owner responsible for billing and permissions management. Unlike AWS, where any resources created under the AWS account are tied to that account, subscriptions exist independently of their owner accounts, and can be reassigned to new owners as needed.
Comparison of structure and ownership of AWS accounts and Azure subscriptions
Subscriptions are assigned three types of administrator accounts:
Account Administrator - The subscription owner and the account billed for the resources used in the subscription. The account administrator can only be changed by transferring ownership of the subscription.
Service Administrator - This account has rights to create and manage resources in the subscription, but is not responsible for billing. By default, the account administrator and service administrator are assigned to the same account. The account administrator can assign a separate user to the service administrator account for managing the technical and operational aspects of a subscription. There is only one service administrator per subscription.
Co-administrator - There can be multiple co-administrator accounts assigned to a subscription. Co-administrators cannot change the service administrator, but otherwise have full control over subscription resources and users.
Below the subscription level user roles and individual permissions can also be assigned to specific resources, similarly to how permissions are granted to IAM users and groups in AWS. In Azure all user accounts are associated with either a Microsoft Account or Organizational Account (an account managed through an Azure Active Directory).
Like AWS accounts, subscriptions have default service quotas and limits. For a full list of these limits, see Azure subscription and service limits, quotas, and constraints. These limits can be increased up to the maximum by filing a support request in the management portal.
The term "resource" in Azure is used in the same way as in AWS, meaning any compute instance, storage object, networking device, or other entity you can create or configure within the platform.
Both Azure and AWS have entities called "resource groups" that organize resources such as VMs, storage, and virtual networking devices. However, Azure resource groups are not directly comparable to AWS resource groups.
While AWS allows a resource to be tagged into multiple resource groups, an Azure resource is always associated with one resource group. A resource created in one resource group can be moved to another group, but can only be in one resource group at a time. Resource groups are the fundamental grouping used by Azure Resource Manager.
Resources can also be organized using tags. Tags are key-value pairs that allow you to group resources across your subscription irrespective of resource group membership.
Azure offers several ways to manage your resources:
Web interface. Like the AWS Dashboard, the Azure portal provides a full web-based management interface for Azure resources.
REST API. The Azure Resource Manager REST API provides programmatic access to most of the features available in the Azure portal.
Templates. Azure Resource Manager templates provide similar JSON template-based resource management capabilities to the AWS CloudFormation service.
In each of these interfaces, the resource group is central to how Azure resources get created, deployed, or modified. This is similar to the role a "stack" plays in grouping AWS resources during CloudFormation deployments.
The syntax and structure of these interfaces are different from their AWS equivalents, but they provide comparable capabilities. In addition, many third party management tools used on AWS, like Hashicorp's Terraform and Netflix Spinnaker, are also available on Azure.
Regions and zones (high availability)
In AWS, availability centers around the concept of Availability Zones. In Azure, fault domains and availability sets are all involved in building highly available solutions. Paired regions provide additional disaster recovery capabilities.
Availability Zones, Azure fault domains, and availability sets
In AWS, a region is divided into two or more Availability Zones. An Availability Zone corresponds with a physically isolated datacenter in the geographic region. If you deploy your application servers to separate Availability Zones, a hardware or connectivity outage affecting one zone does not impact any servers hosted in other zones.
In Azure, a fault domain defines a group of VMs that shares a physical power source and network switch. You use availability sets to spread VMs across multiple fault domains. When instances are assigned to the same availability set, Azure distributes them evenly across several fault domains. If a power failure or network outage occurs in one fault domain, at least some of the set's VMs are in another fault domain and unaffected by the outage.
AWS Availability Zones compared with Azure fault domains and availability sets
Availability sets should be organized by the instance's role in your application to ensure one instance in each role is operational. For example, in a standard three-tier web application, you would want to create a separate availability set for front-end, application, and data instances.
Azure availability sets for each application role
When VM instances are added to availability sets, they are also assigned an update domain. An update domain is a group of VMs that are set for planned maintenance events at the same time. Distributing VMs across multiple update domains ensures that planned update and patching events affect only a subset of these VMs at any given time.
In Azure, you use paired regions to support redundancy across two predefined geographic regions, ensuring that even if an outage affects an entire Azure region, your solution is still available.
Unlike AWS Availability Zones, which are physically separate datacenters but may be in relatively nearby geographic areas, paired regions are usually separated by at least 300 miles. This is intended to ensure larger scale disasters only impact one of the regions in the pair. Neighboring pairs can be set to sync database and storage service data, and are configured so that platform updates are rolled out to only one region in the pair at a time.
Azure geo-redundant storage is automatically backed up to the appropriate paired region. For all other resources, creating a fully redundant solution using paired regions means creating a full copy of your solution in both regions.
Consult the complete AWS and Azure service comparison matrix for a full listing of how all services map between platforms.
Not all Azure products and services are available in all regions. Consult the Products by Region page for details. You can find the uptime guarantees and downtime credit policies for each Azure product or service on the Service Level Agreements page.
The following sections provide a brief explanation of how commonly used features and services differ between the AWS and Azure platforms.
EC2 Instances and Azure virtual machines
Although AWS instance types and Azure virtual machine sizes breakdown in a similar way, there are differences in the RAM, CPU, and storage capabilities.
Unlike AWS' per second billing, Azure on-demand VMs are billed by the minute.
Azure has no equivalent to EC2 Spot Instances or Dedicated Hosts.
EBS and Azure Storage for VM disks
Durable data storage for Azure VMs is provided by data disks residing in blob storage. This is similar to how EC2 instances store disk volumes on Elastic Block Store (EBS). Azure temporary storage also provides VMs the same low-latency temporary read-write storage as EC2 Instance Storage (also called ephemeral storage).
Higher performance disk IO is supported using Azure premium storage. This is similar to the Provisioned IOPS storage options provided by AWS.
Lambda, Azure Functions, Azure Web-Jobs, and Azure Logic Apps
Azure Functions is the primary equivalent of AWS Lambda in providing serverless, on-demand code. However, Lambda functionality also overlaps with other Azure services:
WebJobs - allow you to create scheduled or continuously running background tasks.
Logic Apps - provides communications, integration, and business rule management services.
Autoscaling, Azure VM scaling, and Azure App Service Autoscale
Autoscaling in Azure is handled by two services:
VM scale sets - allow you to deploy and manage an identical set of VMs. The number of instances can autoscale based on performance needs.
App Service Autoscale - provides the capability to autoscale Azure App Service solutions.
The Azure Container Service supports Docker containers managed through Docker Swarm, Kubernetes, or DC/OS.
Other compute services
Azure offers several compute services that do not have direct equivalents in AWS:
Azure Batch - allows you to manage compute-intensive work across a scalable collection of virtual machines.
S3/EBS/EFS and Azure Storage
In the AWS platform, cloud storage is primarily broken down into three services:
Simple Storage Service (S3) - basic object storage. Makes data available through an Internet accessible API.
Elastic Block Storage (EBS) - block level storage, intended for access by a single VM.
Elastic File System (EFS) - file storage meant for use as shared storage for up to thousands of EC2 instances.
In Azure Storage, subscription-bound storage accounts allow you to create and manage the following storage services:
- Blob storage - stores any type of text or binary data, such as a document, media file, or application installer. You can set Blob storage for private access or share contents publicly to the Internet. Blob storage serves the same purpose as both AWS S3 and EBS.
Table storage - stores structured datasets. Table storage is a NoSQL key-attribute data store that allows for rapid development and fast access to large quantities of data. Similar to AWS' SimpleDB and DynamoDB services.
Queue storage - provides messaging for workflow processing and for communication between components of cloud services.
File storage - offers shared storage for legacy applications using the standard server message block (SMB) protocol. File storage is used in a similar manner to EFS in the AWS platform.
Glacier and Azure Storage
Azure Storage Standard Archive offers a direct equivalent to AWS' long-term archival Glacier storage. For data that is infrequently accessed and long-lived Azure offers the Azure cool blob storage tier. Cool storage provides cheaper, lower performance storage than standard blob storage and is comparable to AWS' S3 - Infrequent Access.
Elastic Load Balancing, Azure Load Balancer, and Azure Application Gateway
The Azure equivalents of the two Elastic Load Balancing services are:
Load Balancer - provides the same capabilities as the AWS Classic Load Balancer, allowing you to distribute traffic for multiple VMs at the network level. It also provides failover capability.
Application Gateway - offers application-level rule-based routing comparable to the AWS Application Load Balancer.
Route 53, Azure DNS, and Azure Traffic Manager
In AWS, Route 53 provides both DNS name management and DNS-level traffic routing and failover services. In Azure this is handled through two services:
Azure DNS - provides domain and DNS management.
Traffic Manager - provides DNS level traffic routing, load balancing, and failover capabilities.
Direct Connect and Azure ExpressRoute
Azure provides similar site-to-site dedicated connections through its ExpressRoute service. ExpressRoute allows you to connect your local network directly to Azure resources using a dedicated private network connection. Azure also offers more conventional site-to-site VPN connections at a lower cost.
RDS and Azure relational database services
Azure provides several different relational database services that are the equivalent of AWS' Relational Database Service (RDS).
Costs for AWS RDS are determined by the amount of hardware resources that your instance uses, like CPU, RAM, storage, and network bandwidth. In the Azure database services, cost depends on your database size, concurrent connections, and throughput levels.
Security and identity
Directory service and Azure Active Directory
Azure splits up directory services into the following offerings:
Azure Active Directory - cloud based directory and identity management service.
Azure Active Directory B2B - enables access to your corporate applications from partner-managed identities.
Azure Active Directory B2C - service offering support for single sign-on and user management for consumer facing applications.
Azure Active Directory Domain Services - hosted domain controller service, allowing Active Directory compatible domain join and user management functionality.
Web application firewall
Application and messaging services
Simple Email Service
AWS provides the Simple Email Service (SES) for sending notification, transactional, or marketing emails. In Azure, third-party solutions like Sendgrid provide email services.
Simple Queueing Service
AWS Simple Queueing Service (SQS) provides a messaging system for connecting applications, services, and devices within the AWS platform. Azure has two services that provide similar functionality:
Queue storage - a cloud messaging service that allows communication between application components within the Azure platform.
Service Bus - a more robust messaging system for connecting applications, services, and devices. Using the related Service Bus relay, Service Bus can also connect to remotely hosted applications and services.
The AWS Device Farm provides cross-device testing services. In Azure, Xamarin Test Cloud provides similar cross-device front-end testing for mobile devices.
In addition to front-end testing, the Azure DevTest Labs provides back end testing resources for Linux and Windows environments.
Analytics and big data
The Cortana Intelligence Suite is Azure's package of products and services designed to capture, organize, analyze, and visualize large amounts of data. The Cortana suite consists of the following services:
HDInsight - managed Apache distribution that includes Hadoop, Spark, Storm, or HBase.
Data Factory - provides data orchestration and data pipeline functionality.
SQL Data Warehouse - large-scale relational data storage.
Data Lake Store - large-scale storage optimized for big data analytics workloads.
Machine Learning - used to build and apply predictive analytics on data.
Stream Analytics - real-time data analysis.
Data Lake Analytics - large-scale analytics service optimized to work with Data Lake Store
PowerBI - used to power data visualization.
Internet of Things
Notification Hubs do not support sending SMS or email messages, so third-party services are needed for those delivery types.