Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article helps Google Cloud experts understand the basics of Microsoft Azure accounts, services, and resources. It also covers key similarities and differences between the Google Cloud and Azure platforms.
Note
Google Cloud was previously known as Google Cloud Platform (GCP).
In this article, you learn:
- How accounts and resources are organized in Azure.
- How available solutions are structured in Azure.
- How the major Azure services differ from Google Cloud services.
Azure and Google Cloud built their capabilities independently over time, so they have significant implementation and design differences.
Similarities between Azure and Google Cloud
Like Google Cloud, Microsoft Azure is built around a core set of compute, storage, database, and networking services. In many cases, both platforms offer comparable capabilities and support highly available solutions on Linux or Windows hosts. If you're used to development using Linux and open-source software, both platforms can do the job.
Although the platforms share similar capabilities, the resources that provide those capabilities are often organized differently. Direct service-to-service mappings aren't always clear, and some services are available only on one platform.
Manage accounts and subscriptions
Azure provides a hierarchy of management groups, subscriptions, and resource groups to help you manage resources effectively. This hierarchy is similar to the folders and project structure for resources in Google Cloud. The following diagram shows the hierarchy of management scope in Azure:
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 those user accounts create. Each subscription has limits or quotas on the number of resources you can create and use. Organizations can use subscriptions to manage costs and the resources that users, teams, or projects create.
You can create an unlimited number of Azure subscriptions. Each subscription links to a single Microsoft Entra tenant (an account, in Google Cloud terms). A tenant can contain an unlimited number of subscriptions, whereas Google Cloud has a default soft limit that varies per account and can be increased through a request.
A Google Cloud project is conceptually similar to the Azure subscription, in terms of billing, quotas, and limits. However, in function, a Google Cloud project more closely resembles an Azure resource group—a logical container into which cloud resources are deployed.
Resource groups: A resource group is a logical container into which you deploy and manage Azure resources like web apps, databases, and storage accounts.
Resources: Resources are instances of services that you create, like virtual machines (VMs), storage, or SQL databases.
Azure offers several purchasing options to fit organizations of different sizes and needs. For more information, see the pricing overview.
You manage access to Azure resources through Azure role-based access control (Azure RBAC), which includes more than 100 built-in roles. You can also create your own custom roles.
Each subscription also has an account administrator, which represents the subscription owner and the account billed for the resources used in the subscription. You can only change the account administrator by transferring ownership of the subscription.
Beneath the subscription level, you can assign user roles and individual permissions to specific resources. In Azure, all user accounts are associated with either a Microsoft Account or Organizational Account (an account managed through Microsoft Entra ID).
Subscriptions have default service quotas and limits. For a full list of these limits, see Azure subscription and service limits, quotas, and constraints. You can increase some of these limits by filing a support request in the management portal.
To learn more about managing accounts and subscriptions, see the following resources:
Resource management
In Azure, a resource is any compute instance, storage object, networking device, or other entity that you can create or configure within the platform.
You can deploy and manage Azure resources by using Azure Resource Manager.
Resource groups
Azure also provides resource groups that organize resources such as VMs, storage, and virtual networking devices. You always associate an Azure resource with one resource group. You can move a resource from one resource group to another, but it can only be in one resource group at a time. For more information, see Move Azure resources to a new resource group or subscription. Azure Resource Manager uses resource groups as the fundamental grouping.
You can also organize resources by using tags. Tags are key-value pairs that you can use to group resources across your subscription regardless of resource group membership.
Management interfaces
Azure offers several ways to manage your resources:
- Azure portal: 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 macOS.
- PowerShell: You can use the Azure modules for PowerShell to run automated management tasks by using a script. PowerShell is available for Windows, Linux, and macOS.
- Templates: Azure Resource Manager templates provide template-based resource management capabilities. These templates are typically written in Bicep or Terraform.
- Azure SDKs: The SDKs are a collection of libraries that you can use to programmatically manage and interact with Azure services.
Across all these interfaces, the resource group is central to creating, deploying, and managing Azure resources.
In addition, many non-Microsoft management tools, like HashiCorp's Terraform and Spinnaker, are available on Azure.
Regions and availability zones
Cloud failures vary widely in scope and severity. Localized hardware failures or configuration problems can affect individual resources or groups of resources in a workload. Less common are failures that disrupt a whole datacenter, such as loss of power in a datacenter. In rare situations, an entire region can become unavailable.
One of the main ways to make an application resilient is through redundancy. However, 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 Google Cloud, 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 zones and paired regions.
The following table summarizes each option.
| Availability zone | Paired region | |
|---|---|---|
| Scope of failure | Datacenter | Region |
| Request routing | Cross-zone Azure Load Balancer | Azure Traffic Manager |
| Network latency | Low | Mid to high |
| Virtual networking | Virtual network | Cross-region virtual network peering |
Availability zones
Like Google Cloud, Azure regions can have availability zones, which are physically separate zones within an Azure region. Each availability zone has a distinct power source, network, and cooling. Deploying VMs across availability zones helps protect an application against datacenter-wide failures.
To learn more about availability zones and regions, see Architecture strategies for using availability zones and regions.
Paired regions
To protect an application against a regional outage, deploy the application across multiple regions and use Azure Traffic Manager to distribute internet traffic to different regions. Each Azure region pairs with another region. Together, these regions form a region pair. Except for Brazil South, region pairs are located within the same geography to meet data residency requirements for tax and law enforcement jurisdiction purposes.
Unlike availability zones, which are physically separate datacenters but might 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. You can set neighboring pairs to sync database and storage service data. They're configured so that platform updates roll out to only one region in the pair at a time.
Azure geo-redundant storage automatically backs up to the appropriate paired region. For all other resources, you need to deploy a complete copy of your solution in each region to achieve full redundancy.
Diagram that shows the nested containment hierarchy of Azure region pairs. The outermost rectangle represents a geography. Nested inside the geography is a region pair. Inside the region pair, two regions sit side by side. Within each region is a datacenter. The nesting of the shapes illustrates the containment relationships: datacenters are physically located inside regions, two regions together form a region pair, and a region pair belongs to a single geography.
Reliability guides by service
To explore reliability recommendations for each Azure service, see Reliability guides by service.
To learn more, see the following resources:
Services
To see how Google Cloud services map to their Azure equivalents, see Google Cloud to Azure services comparison.
Not all Azure products and services are available in all regions. For more information, see Products by region. You can find the uptime guarantees and downtime credit policies for each Azure product or service in the Service-level agreements for online services document.