Azure for GCP Professionals

This article helps Google Cloud Platform (GCP) experts understand the basics of Microsoft Azure accounts, platform, and services. It also covers key similarities and differences between the GCP and Azure platforms.

You'll learn:

  • How accounts and resources are organized in Azure.
  • How available solutions are structured in Azure.
  • How the major Azure services differ from GCP services.

Azure and GCP built their capabilities independently over time so that each has important implementation and design differences.


Like GCP, 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 GCP and Azure allow you to build highly available solutions based on Linux or Windows 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. In other cases, a particular service might be offered on one platform, but not the other.

Managing accounts and subscription

Azure has a hierarchy of Management group and subscriptions and resource groups to manage resources effectively. This is similar to the Folders and Project hierarchy for resources in Google Cloud.

Diagram shows a tree structure with management groups as the root, then subscriptions, then resource groups as leaf nodes.

Azure levels of management scope

  • Management groups: These groups are containers that help you manage access, policy, and compliance for multiple subscriptions. All subscriptions in a management group automatically inherit the conditions applied to the management group.
  • Subscriptions: A subscription logically associates user accounts and the resources that were created by those user accounts. Each subscription has limits or quotas on the amount of resources you can create and use. Organizations can use subscriptions to manage costs and the resources that are created by users, teams, or projects.
  • Resource groups: A resource group is a logical container into which Azure resources like web apps, databases, and storage accounts are deployed and managed.
  • Resources: Resources are instances of services that you create, like virtual machines, storage, or SQL databases.

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.

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. Only one service administrator is assigned 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. In Azure, all user accounts are associated with either a Microsoft Account or Organizational Account (an account managed through an Azure Active Directory).

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.

See also

Resource management

The term "resource" in Azure means any compute instance, storage object, networking device, or other entity you can create or configure within the platform.

Azure resources are deployed and managed using one of two models: Azure Resource Manager, or the older Azure classic deployment model. Any new resources are created using the Resource Manager model.

Resource groups

Azure additionally has an entity called "resource groups" that organize resources such as VMs, storage, and virtual networking devices. 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.

Management interfaces

Azure offers several ways to manage your resources:

  • Web interface. 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.
  • Command Line. The Azure CLI provides a command-line interface capable of creating and managing Azure resources. The Azure CLI is available for Windows, Linux, and Mac OS.
  • PowerShell. The Azure modules for PowerShell allow you to execute automated management tasks using a script. PowerShell is available for Windows, Linux, and Mac OS.
  • Templates. Azure Resource Manager templates provide JSON template-based resource management capabilities.

In each of these interfaces, the resource group is central to how Azure resources get created, deployed, or modified.

In addition, many third-party management tools like Hashicorp's Terraform and Netflix Spinnaker, are also available on Azure.

See also

Regions and zones (high availability)

Failures can vary in the scope of their impact. Some hardware failures, such as a failed disk, may affect a single host machine. A failed network switch could affect a whole server rack. Less common are failures that disrupt a whole datacenter, such as loss of power in a datacenter. Rarely, an entire region could become unavailable.

One of the main ways to make an application resilient is through redundancy. But you need to plan for this redundancy when you design the application. Also, the level of redundancy that you need depends on your business requirements. Not every application needs redundancy across regions to guard against a regional outage. In general, a tradeoff exists between greater redundancy and reliability versus higher cost and complexity.

In GCP, a region has two or more Availability Zones. An Availability Zone corresponds with a physically isolated datacenter in the geographic region. Azure has numerous features for providing application redundancy at every level of potential failure, including availability sets , availability zones , and paired regions.

The following table summarizes each option.

Availability Set Availability Zone Paired region
Scope of failure Rack Datacenter Region
Request routing Load Balancer Cross-zone Load Balancer Traffic Manager
Network latency Very low Low Mid to high
Virtual networking VNet VNet Cross-region VNet peering

Availability sets

To protect against localized hardware failures, such as a disk or network switch failing, deploy two or more VMs in an availability set. An availability set consists of two or more fault domains that share a common power source and network switch. VMs in an availability set are distributed across the fault domains, so if a hardware failure affects one fault domain, network traffic can still be routed the VMs in the other fault domains. For more information about Availability Sets, see Manage the availability of Windows virtual machines in Azure.

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.

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 three-tier web application, create separate availability sets for the front-end, application, and data tiers.

Diagram that contains availability sets for a web tier with Web Instances, an app tier with App Instances, and a data cluster with Database Instances.

Availability sets

Availability zones

Like GCP, Azure regions can have Availability zones. An Availability Zone is a physically separate zone within an Azure region. Each Availability Zone has a distinct power source, network, and cooling. Deploying VMs across availability zones helps to protect an application against datacenter-wide failures.

Diagram showing a zone redundant virtual machine deployment with a Region that contains three zones with a subnet that crosses all three zones.

Zone redundant VM deployment on Azure

Paired regions

To protect an application against a regional outage, you can deploy the application across multiple regions, using Azure Traffic Manager to distribute internet traffic to the different regions. Each Azure region is paired with another region. Together, these form a regional pair. With the exception of Brazil South, regional pairs are located within the same geography in order to meet data residency requirements for tax and law enforcement jurisdiction purposes.

Unlike Availability Zones, which are physically separate datacenters but may be in relatively nearby geographic areas, paired regions are typically separated by at least 300 miles. This design ensures that large-scale disasters only affect 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.

Diagram shows region pairs in Azure, where Geography contains a Region Pair, which contains two Regions, which each contain Datacenters.

Region Pairs in Azure

See also


For a listing of how services map between platforms, see GCP to Azure services comparison.

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.

Next steps