CH01-02: Mapping Azure from AWS and GCP Experience

Goal

If you already know AWS or GCP, you do not need to start from zero. You already understand many of the problems cloud platforms solve: identity, permissions, networking, compute, storage, databases, logging, policy, automation, billing, and operations.

This section helps you translate those instincts into Azure.

The previous section introduced Azure as a set of responsibilities: identity, governance, organization, networking and security, workload services, and operations. This section continues from there. The goal is not to repeat the overview. The goal is to show how familiar cloud concepts map into Azure's control points.

Start With Responsibilities, Then Map Services

Service mapping is useful. A familiar first question is:

What is the Azure equivalent of this AWS or GCP service?

That question gives you vocabulary. For example, if you know Amazon S3 or Google Cloud Storage, it helps to learn that Azure Blob Storage is Azure's object storage service for storing files, images, backups, logs, and other unstructured data. You do not need the details yet; the important point is that the service name gives you a bridge into Azure conversations.

But service mapping is not enough for architecture.

A better translation question is:

Where does Azure place the responsibility I already understand from AWS or GCP?

For object storage, the design still needs familiar questions:

• Who owns the storage?

• Who can read, write, delete, or administer it?

• Which environment does it belong to?

• Should access be public, private, or limited to selected networks?

• Which policies apply to encryption, regions, tags, and public access?

• How will cost, monitoring, retention, backup, and lifecycle management work?

These questions are not unique to Azure. What changes is the Azure vocabulary and the scope where each decision is applied.

Operating Model Translation

Service names help you recognize familiar capabilities. The operating model shows where each cloud places identity, governance, billing, workload boundaries, and resources.

The diagrams below are simplified. They are visual starting points, not exact equivalence maps.

Azure                               AWS
Microsoft Entra Tenant              AWS Organization
|-- Management Group                |-- Organizational Unit
    |-- Subscription                    |-- AWS Account
        |-- Resource Group                  |
            |-- Resources                   |-- Resources

Azure                               GCP
Microsoft Entra Tenant              GCP Organization
|-- Management Group                |-- Folder
    |-- Subscription                    |-- Project
        |-- Resource Group                  |
            |-- Resources                   |-- Resources

Azure makes resource groups a visible layer between subscriptions and resources. AWS and GCP usually place resources directly inside account or project boundaries, then use mechanisms such as tags, stacks, folders, labels, or service-level grouping for additional organization.

The table below maps the same idea by responsibility.

Do not worry if several Azure terms are still new. The chapter will return to the hierarchy in more detail. For now, notice the pattern: Azure makes tenant, management groups, subscriptions, and resource groups very visible in everyday architecture decisions.

What AWS Users Should Notice

If you come from AWS, the closest starting comparison is usually this:

The subscription is the first Azure boundary AWS users usually try to map to an AWS account. That comparison is useful, but not complete. A subscription works together with Microsoft Entra ID, management groups, resource groups, Azure RBAC, Azure Policy, and networking boundaries.

The resource group is especially important. In AWS, teams often use tags, CloudFormation stacks, naming conventions, or service-specific groupings to organize resources. Azure makes one grouping layer visible and required: every resource belongs to a resource group.

That does not make Azure better or AWS worse. It means Azure expects you to include resource groups in the design conversation.

What GCP Users Should Notice

If you come from GCP, Azure subscriptions may feel similar to GCP projects in some ways. Both are important boundaries for billing, permissions, quotas, service usage, and workload organization.

The mapping is still not exact.

The main Azure layer for GCP users to notice is the resource group. In GCP, the project is often the main place you think about workload boundaries and resources. In Azure, the subscription is a major boundary, but resources are still grouped inside resource groups.

That extra layer affects deployment, cleanup, ownership, access assignment, policy scope, and operational organization.

Service Mapping as Vocabulary

Service mapping helps when you read documentation, join architecture discussions, or translate an existing design. Use it as vocabulary, not as the design method.

Each Azure service in this table will be explained later when it becomes part of a decision or example. For now, use the table to translate conversations, not to choose an architecture by name matching alone.

Be careful with the word equivalent. Two services may solve a similar problem but differ in identity integration, networking behavior, pricing model, scaling limits, operational features, or governance controls.

Integration Services Are a Good Warning

Integration is where direct mapping can become especially misleading.

Azure Event Grid, Azure Event Hubs, and Azure Service Bus all help systems exchange information, but they are not interchangeable. You do not need to know their full details yet. For now, notice that Azure separates several communication patterns that may look similar at first.

Knowing the service name is only the beginning. A strong design still asks what kind of communication is needed: event notification, stream ingestion, durable command, workflow coordination, or integration between business systems.

Example: Moving Object Storage to Azure

Imagine a team has an application that stores uploaded documents in Amazon S3 or Google Cloud Storage. The quick translation is Azure Blob Storage.

Azure Blob Storage is Azure's object storage service. It is used for data such as documents, images, backups, logs, and static files. You do not need to know its configuration details yet.

The service mapping is only the first step. The Azure design still needs answers to questions such as:

• Which subscription should own the storage account?

• Which resource group should contain it?

• Who can upload, read, delete, or administer documents?

• Should access be public, private, or restricted through private networking?

• Which policies should prevent accidental public exposure?

• Which tags identify owner, environment, cost center, and data classification?

• How long should documents be retained?

• Which logs, metrics, and alerts are required?

• How should backup, recovery, and regional availability be handled?

This is the difference between translation and design. Translation says, "S3 maps roughly to Azure Blob Storage." Design says, "Here is where ownership, access, policy, network exposure, monitoring, cost, and lifecycle management belong in Azure."

Common Mistakes

• Assuming equivalents behave the same way. Similar services can differ in identity integration, networking behavior, scaling limits, pricing, monitoring, security features, and operational controls.

• Mapping AWS accounts or GCP projects too casually to subscriptions. The comparison is useful, but Azure subscriptions also work with management groups, resource groups, Azure RBAC, Azure Policy, and Microsoft Entra ID.

• Ignoring resource groups. Resource groups are not just labels. They are practical containers for deployment, permissions, lifecycle management, cleanup, and operations.

• Using service mapping as the architecture. A service table can translate names, but it cannot decide ownership, access, network exposure, resilience, compliance, or cost control.

• Treating integration services as interchangeable. Event routing, streaming ingestion, and durable messaging solve different problems even when the service names sound related.

• Skipping governance because the service looks familiar. Familiar compute, storage, or database choices still need Azure policy, access, tagging, monitoring, and operational decisions.

If Someone Asks You

If someone asks, "How should an AWS or GCP user start learning Azure?" a useful answer is:

Start by mapping responsibilities, not only services. The cloud problems are familiar: identity, access, policy, billing, ownership, networking, deployment, monitoring, and operations. Azure places those responsibilities in tenant, management groups, subscriptions, resource groups, Azure RBAC, Azure Policy, virtual networks, and Azure Monitor. Service names help you translate, but boundaries help you design.

This answer shows that you can use existing cloud knowledge without pretending the platforms are identical.

What You Should Remember

AWS, GCP, and Azure solve many of the same architecture problems. The important difference is where each platform places the control points.

The most important idea is this:

Service names help you translate. Boundaries help you design.

When you move from AWS or GCP to Azure, keep your existing architecture instincts. Then learn the Azure places where those instincts apply: Microsoft Entra tenant, management groups, subscriptions, resource groups, Azure RBAC, Azure Policy, virtual networks, and Azure Monitor.

Questions to Check Your Understanding

1. Why is direct service mapping useful but incomplete?

2. How is an Azure subscription similar to, and different from, an AWS account?

3. How is an Azure subscription similar to, and different from, a GCP project?

4. Why are resource groups important for AWS and GCP users to notice?

5. What questions should you ask after mapping S3 or Cloud Storage to Azure Blob Storage?