Security Across the Three Clouds
The concepts in this chapter — identity, permissions, encryption, secrets, compliance — are universal. Every cloud uses them. What differs is the names of the services, some details of how they work, and the history behind their design choices. That is what this topic maps out.
Security is the area where the terminology gap between clouds is largest. Someone who learned on AWS will see unfamiliar names when they look at Azure documentation, and vice versa. This topic provides the translation layer: same idea, different console, different name.
One important note before the mapping: Azure's identity system has deeper roots than the others. AWS and Google Cloud built their identity management specifically for the cloud. Azure's identity system, Microsoft Entra ID (formerly known as Azure Active Directory), grew out of decades of enterprise directory software used to manage millions of corporate users in on-premises systems. It is not just a way to control cloud access — it is a full identity directory capable of managing all of an organization's employees, devices, and applications, including ones that have nothing to do with the cloud. That broader scope is a genuine difference, not just a different name.
The Mapping: Identity, Keys, and Secrets
Each cloud has a dedicated service for each of the three core security capabilities. The names differ; the purpose is the same in each case.
For identity and access management, AWS calls its service IAM. Google Cloud calls it Cloud IAM. Azure uses a combination: Microsoft Entra ID handles who the user is (their identity across the whole organization), and Azure RBAC (Role-Based Access Control) handles what they can do inside Azure specifically. In practice you work with both together.
For key management — creating, storing, and controlling the encryption keys that protect data — AWS has KMS (Key Management Service), Google Cloud has Cloud KMS, and Azure has Azure Key Vault. Azure Key Vault is a single service that handles both encryption keys and secrets, while AWS and Google Cloud have separate services for each.
For secrets — storing passwords, API tokens, database credentials, and other sensitive values — AWS offers Secrets Manager, Google Cloud offers Secret Manager (note the singular), and Azure handles this through the same Azure Key Vault that manages keys.
Heritage Differences Worth Knowing
The three identity systems arrived at similar capabilities from different directions, and the differences in approach are real. AWS built IAM from scratch for the cloud, with an emphasis on very fine-grained JSON-based policy documents. You can write a policy that says "allow reading from exactly this S3 bucket, only between 9 a.m. and 5 p.m., only from these IP addresses" — the granularity is exceptional, and so is the complexity. Google Cloud's Cloud IAM is organized around a resource hierarchy: an organization contains folders, folders contain projects, and permissions flow downward through that structure. Azure's approach is built on Entra ID's enterprise roots: roles and groups from the corporate directory carry directly into Azure resource access. Each approach reflects where the company's strengths and customers came from.
The Shared Model: A Universal Constant
Despite these differences, all three clouds publish and follow the same shared-responsibility model. The split — provider covers infrastructure, customer covers accounts, access, configuration, and data — is identical across AWS, Google Cloud, and Azure. The documentation names differ; the principle does not. Any security posture review at any of the three providers starts from the same division of responsibilities.
The Constant: Concepts Travel; Names Don't
The most important takeaway from this chapter: the concepts — identity, least privilege, encryption, secrets vault, compliance posture — are universal and portable. The service names are provider-specific. Someone who understands what IAM does on any cloud can learn what Cloud IAM or Entra ID + Azure RBAC do in an afternoon. The concepts travel; the console labels require a dictionary lookup, not a new education.
- "Each cloud's security is a completely different discipline." Same concepts, different console names. Identity, least privilege, encryption, secrets vaults, and the shared-responsibility split work the same way on all three. Learning the concepts once transfers.
- "Microsoft Entra ID is just Azure's version of IAM." It is much broader. Entra ID is a full enterprise identity directory — it manages employees, devices, and applications across an entire organization, including things that have nothing to do with Azure. AWS IAM and Google Cloud IAM are cloud-access tools; Entra ID is an organizational identity system that also integrates with cloud access.
- "Least privilege is a per-cloud feature." It is a universal security principle, not something any specific cloud invented or that you can turn on. Every cloud supports it through its IAM system; actually applying it is always the customer's job.
- Security terminology varies more between clouds than almost any other area. This map makes any provider's security documentation approachable: you know what you are looking for; you just need the right name.
- Understanding that Entra ID is broader than an IAM equivalent explains why Azure's identity architecture often looks different — and why enterprises already using Microsoft's directory can integrate Azure more tightly than the other providers.
- The concept portability point is practical career advice: cloud security skills transfer across providers. An engineer who understands these ideas on one cloud can orient on a different one quickly.
Knowledge Check
Which service does AWS use to control who can access what in a cloud account?
- Cloud IAM — the identity and access management service for Google Cloud
- IAM — Identity and Access Management
- Microsoft Entra ID — the enterprise identity directory
- Azure RBAC — role-based access control for cloud resources
How is Microsoft Entra ID different from AWS IAM or Google Cloud IAM?
- It is designed specifically for cloud-native container and microservice applications
- It is always included at no extra cost with any Azure subscription
- A full identity directory — broader than cloud access control alone
- A simpler system with fewer features than the other providers' identity services
Where should a database password be stored in a cloud application?
- In an environment variable inside the application's Dockerfile
- In a secrets service such as Secrets Manager, Secret Manager, or Azure Key Vault
- In a configuration file that is committed directly to the version-control repository
- In the IAM policy attached to the application's service account
You got correct