Comparing AWS, Azure, and Google Cloud IAM services

Comparing the big three cloud providers often means deep dives into the latest and greatest compute nodes, or which platform has the best performing NoSQL database.

Something that's often overlooked as a "service" is how access and authorization are handled for a given cloud resource. Robust security controls are a critical element for any organization with a cloud presence, and access management is no exception.

This article will take a look at the Identity and Access Management (IAM) services of Amazon Web Services (AWS), Google Cloud, and Microsoft Azure and offer some helpful cloud IAM comparison charts. Three cloud providers enter; one blog post leaves. Let's dig in!

Interested in upscaling or beginning your journey with Cloud Security? A Cloud Guru's AWS Security Learning Paths offers custom courses fit for beginners and advanced gurus! 

What is IAM? Each cloud provider uses the "IAM" moniker to describe their collection of services and APIs around managing access and authorization for their cloud resources. Azure is somewhat of an exception: IAM is used to generally describe the features of Azure Active Directory.

Before exploring the features of capabilities of each provider, it will be helpful to understand the problem domain, and what these services aim to solve for customers.

So what does IAM solve? A useful starting point is the concept of "least privilege." The Principle of Least Privilege (PLOP) is an information security concept that effectively states that any user for a given system or resource should only be granted the minimum amount of permissions and access needed to successfully carry out a given task.

Thinking about this in the context of cloud services, the PLOP can apply to virtually any resource. Things like storage objects, compute nodes, databases, and logging dashboards all contain potentially sensitive critical data. Should all employees and users have the same, broad access to these resources? According to PLOP, the answer is "no." Meeting the bare-minimum requirements for most compliance frameworks also means that organizations must show they are enforcing PLOP, and cloud resources are no different.

How do the cloud platforms provide customers a way to enforce PLOP in an efficient, scalable way? Managing separate access and authorization controls for each service or resource would quickly become a logistical nightmare, and would not be scalable for anything but very small deployments. With their respective IAM offerings, each cloud provider offers a unified, centralized service for managing access and authorization.

Get the Cloud Dictionary of Pain
Speaking cloud doesn't have to be hard. We analyzed millions of responses to ID the top terms and concepts that trip students up. In this cloud guide, you’ll find succinct definitions of some of the most painful cloud terms

For each of the big 3, with a slight exception, IAM services are considered foundational and are offered as a free service with normal account usage. Azure is the exception with its Active Directory IAM offering, requiring a subscription or license to a separate product to unlock the free tier.

For AWS and GCP, some of the key differentiators originate in how each platform defines quotas and service limits. 

In the case of AWS, the term "quota" and "limit" are interchangeable. Some quotas can be increased via request, while some are fixed values and cannot be increased. GCP, on the other hand, defines a quota as something that can be increased, while limits cannot. Extending further on the differences in how quotas and limits are treated: GCP defines some quotas and limits by "projects," while the logical boundary in AWS is always within an AWS account. Azure utilizes the "limits" designation for limits/quotas that can be extended, as well as those that cannot. In Azure's case, there is also the distinction of having certain limits and capabilities gated by the service tier that the customer has access to. Pricing tiers are described here. For Azure Active Directory, there are no limits that can be extended via request — they are all fixed.

This page describes quotas for AWS IAM. Quotas and limits for GCP can be found here. For Azure AD, the limits are described here. Although each service makes different choices on which values are fixed or can be extended, there are some equivalent resources limits that help provide at least a high-level comparison:

The values in the table highlight some of the underlying differences in technical architecture and target customer demographic for each provider. For instance, Google Cloud depends on Google groups and Google account infrastructure for user management, whereas AWS is self-contained within an AWS account. Owing to its enterprise focus, Azure depends on Active Directory, treating users as the traditional Active Directory object, and enforcing limits on total object count.

The next section will provide a deeper dive into the features of each provider's IAM offering, including a comparison and contrast of equivalent features and dimensions.

State of Cloud 2021 Webinar
No one can predict the future, but we asked a panel of very smart cloud pros to try anyway. What does Jassy moving up to Amazon CEO mean for AWS? Is this the year of multi-cloud? Our lively, unfiltered panel weighs in on the year ahead in this free, on-demand webinar.

At its core, IAM is about managing access and authorization. Each provider has a similar aim: providing a robust, scalable way to manage access and authorization for its cloud-based resources and services. 

Each of the three providers implements some variant of a Role-Based Access Control (RBAC) system. Users assume "roles," which are typically pre-defined groupings of access and authorization policies that define what resources they do and do not have access to.

How each provider handles the various aspects of user management, quotas, and logical organization is where the customer experience will vary. AWS and GCP both have a cloud-first focus, while Azure's enterprise roots are obvious in the technical jargon and design models around Azure IAM/AD.

In any IAM system, there will always be logical boundaries and operating domains for a given user or service entity. AWS, GCP, and Azure all handle this slightly differently.

The table below describes each provider and their "fundamental organizational domain," a term that will be used to describe the basic organizational construct around which limits and quotas are built, as well as the most common logical boundary that users are likely to commonly interact with:

For AWS, quotas/limits and access boundaries typically fall within a single account. While it is typical for many organizations to maintain multiple AWS accounts that roll up under a unified billing and management account, the API and service limits still apply per account. Access and authorization policies typically apply only to resources and services within that specific account, unless defined using specific cross-account role mechanisms.

In GCP, organizations can act as a logical boundary, but the most common organizational model is the "project." Customers can deploy all of their Google Cloud resources under a single project, or they can elect to create separate projects to organize resources into logical groupings based on whatever schema makes the most sense. IAM can then be used to define access and authorization for each project.

Within Azure, the fundamental unit is the Active Directory organization. Engineers who have worked in enterprise and corporate IT will instantly be familiar with the nomenclature and conventions. Active Directory has its roots in end-user computing, and much of its design owes to that. The Azure cloud offering still depends on a functioning Active Directory system to issue access to users and other entities.

Look for a deep dive in IAM (Identity and Access Management? ACG has courses covering IAM for Azure, GCP IAM, and AWS IAM. Get started for free!

Interactive (human) user access will be one of the most common usage patterns for cloud services. Engineers need to deploy services and provision resources, analysts might need to access dashboards or analyze datasets, and business administrators likely need access to billing APIs and services. 

The table below compares each provider on IAM users and their respective capabilities, looking at what the primary source directory is for user accounts, whether user accounts can enable non-interactive access, and whether groups can be used to apply IAM policy:

Google maintains a fairly diverse spectrum of services from which user identities can originate. Organizations will commonly use Google Suite user accounts to define users for GCP resources, while individual Google accounts can also be used for identity. For non-interactive, credential access, GCP requires a separate service account be defined.

Amazon ties IAM users to a specific AWS account. Specific roles and permissions can be granted which allow for access to resources in separate AWS accounts, but generally the access for a single IAM user is bounded at the account level.

Although organizations will typically assign a root user identity to a top-level account in their organizational tree that does not have resources provisioned, individual users can actually use their Amazon.com account as the root identity for an AWS account. Unlike both GCP and Azure, AWS makes no distinction between "service accounts" and regular IAM users: configuration options can be enabled to only allow non-interactive access, and fixed credentials can be assigned to any IAM user.

Azure obviously leans on Active Directory for user accounts and identity management. The general expectation is that Microsoft customers who are transitioning into the cloud will already have on-premises licensing for an Active Directory solution — and will move to a hybrid solution in the future. However, user accounts can also originate from other Azure and Microsoft products, such as GitHub, Windows Live, and Office 365.

Each provider offers groups for user accounts, allowing for both logical organization as well as policy application. Rather than having to attach policies to each user account, groups like "development" or "administrators" can be created with the correct access and authorization policies attached, after which users can be added and removed from groups as needed.

Fixing 5 Common AWS IAM Errors
Get insights into the cause and resolution for 5 common AWS IAM errors in this blog post by Kesha Williams.

Roles are a powerful concept in any IAM system. In an RBAC, user identities do not, by default, have access or authorization for a given resource. By some authentication mechanism, user accounts will "assume" a role, and with that assumption comes all of the access and authorization policies that are tied to the role.

In some cases, after a predetermined amount of time (typically configurable), users will be required to authenticate for the role again. If they do not, their token will expire, and the user-role relationship will terminate until re-authentication. Some role assignments last until manual revocation.

The table below compares maximum roles count and role session length available for a given platform:

IAM roles are the primary identity mechanism in AWS, and are employed in a variety of use cases in which permissions need to be utilized by an entity. IAM policies referred to as "trust policies" are used to control which principals are allowed to assume roles. In this case, a principal generally refers to any identity, such as a user or service, that might need to assume a role.

Interactive IAM users can assume roles to carry out whatever actions are needed. Special roles — referred to as "Instance Profiles" — can be attached to EC2 compute instances, eliminating the need for hard-coded credentials for any application that runs on the instance. If any user or service needs to access resources in another AWS account, cross-account role access can be configured to issue fine-grained permissions to only the resources and services needed in the second account.

GCP differs somewhat from AWS in how it handles roles. Prior to the launch of their IAM service, GCP had basic roles like "Owner," "Editor,", and "Viewer." With their IAM service, they offer both predefined and custom roles. Unlike AWS, GCP roles aren't fungible between interactive and non-interactive access: a user principal assumes a role for interactive access that cannot be delegated to a non-interactive user, conversely, a service account must be the assuming principal for non-interactive access and role assumption.

Azure's model for roles more closely mirrors that of GCP than AWS. Azure provides both pre-defined roles, as well as the ability to create custom ones. Similar to GCP, roles are assumed separately by users and service principals for interactive and non-interactive access respectively. Built-in roles come with predefined policies, whereas custom roles have user-defined policies written inline with the role definition.

The next section will cover the similarities and differences around policy configuration in more depth.

Cloud Migration: The Role-Playing Game
A successful cloud migration campaign takes strategy, knowledge of the lore, and a little bit of improv — kind of like a game of Dungeons & Dragons. Join this unique role-playing exercise where expert panelists gameplay through realistic cloud migration scenarios.

In an IAM service, policies are the actual definitions of what a given identity can and cannot do in terms of access and authorizations. The providers share some commonalities in how policies are written and utilized, but also have some significant differences as well.

A key similarity to make note of: all three providers utilize the JSON language for policy definition. While there are different opinions around the user experience of having to "write" JSON, it provides a consistent, widely accepted model for policy definition, and can easily integrate third-party tools for linting and automation.

The table below provides some additional feature comparisons:

Azure does not consider policy documents as separate resources from role identities: they are defined directly inline with a role, referred to as a "role definition." Roles are then assigned directly to a user, group, or service principal.

Policies are scoped at four hierarchical levels in Azure: Management Group, Subscription, Resource Group, and Resource. Generally, each level up is a broader access definition. A management group-level definition will assign everything, whereas a resource level will only allow access to a specific named resource.

As described in the table notes, GCP does not actually allow for the creation of custom policy. Policies are pre-defined according to various GCP resources and services, and policies are attached to users, groups, and service accounts in a policy binding. Multiple policies can be bound to a single entity, if multiple permission scopes are needed. Depending on the use case, a pre-defined policy may be adequate, or a custom binding might be needed. However, in either case, the customer is dependent on pre-defined policy and permission scopes.

AWS IAM policies generally tend to have a broader set of use cases across the AWS ecosystem, and there is more freedom in the creation of policy definitions. AWS IAM has multiple policy types: identity-based policy, resource-based policy, permissions boundaries, organizations SCPs, ACLs, and session policies.

The most commonly-used policy is identity-based: these are the typical policy objects attached to traditional IAM entities like roles and AWS resource groups. Resource-based policies are defined against things like S3 buckets. The AWS Policy Generator is a tool that enables you to create policies that control access to AWS resources. Additional policy types have more granular applications, but identity and resource policies are where customers will spend most of their time.

Need to create policies that control access to Amazon Web Services (AWS) products and resources, like preventing deletion of an Amazon S3 Bucket Using a Resource-Based Policy

So which platform “wins” in this IAM showdown? Honestly, it's a three-way tie. A bit anticlimactic? Maybe, but IAM for each provider is designed to best fit with their respective offering of services and resources.

Organizations looking to choose a cloud provider are probably not spending a lot of cycles evaluating IAM capabilities. They're instead focusing on which provider has the best-fitting and best-priced product portfolio. 

• More traditional corporate IT environments will likely find an easier transition into the cloud through Azure's focus on enterprise and hybrid deployments. 
• Organizations looking to deploy highly-available web-facing infrastructure will need to closely evaluate which offerings best fit their use case. For example, organizations looking to utilize managed Kubernetes will generally want to give a strong look to GCP, while those looking for a robust serverless offering will likely choose AWS’s more mature offering.

At the end of the day, choosing IAM is more about choosing which provider's product offerings align the closest with their infrastructure and scaling goals.

Mike Vanbuskirk is a Lead DevOps engineer and technical content creator. He's worked with some of the largest cloud, e-commerce, and CDN platforms in the world. His current focus is cloud-first architecture and serverless infrastructure.