Google Cloud for AWS Professionals: Management

Updated March 17, 2017

Compare the management services that Amazon and Google provide in their respective cloud environments. If you're already familiar with the Amazon Web Services (AWS) implementation of identity and access management (IAM), this article provides you with a comprehensive introduction to Google's Identity and Access Management (IAM). Google Cloud and AWS offer similar IAM solutions. You can use these tools to create and manage permissions for cloud resources, including for data and applications.

Both AWS and Google Cloud enable you to grant permissions to users, groups, and applications. These permissions let the granted entity have clearly defined access to your cloud resources.

The following table provides a general mapping of AWS terms and concepts to their Google Cloud equivalents.

Concept AWS Google Cloud
Programmatic identity IAM role and instance profile IAM service account
User identity Managed in IAM. Identity federated to external identity management system. Managed outside IAM. Identity federated to external identity management system.
Policy A document that explicitly lists permissions. A list of bindings. A binding binds a list of members to a role.
Policy attachment Policy attached to an IAM user or group or a resource. Policy attached to resource.

Policy evaluation Deny by default. Deny by default.
Permission collection Policy Role
Predefined set of permissions Managed policies Predefined roles
Auditing IAM calls AWS CloudTrail Audit logging
Versioning Yes No

Resource management and encapsulation

This section helps you understand how each cloud provider manages resources.

Multiple accounts in AWS

With AWS, the best practice is to set up multiple accounts for each team. You can then assign permissions and policies under each account. You can reduce the complexity of managing multiple AWS accounts by setting up consolidated billing and implementing AWS Organizations.

Organizing projects and policies in Google Cloud

Google Cloud provides container resources, such as organizations, folders, and projects, that let you group and hierarchically organize other Google Cloud resources, such as Pub/Sub topics and Compute Engine virtual machine instances (VMs). This hierarchical organization lets you manage common aspects of your resources, such as access control and configuration settings.

All Google Cloud resources belong to a project resource, and an individual Google Account can manage multiple projects. You can manage the projects individually. You can group similar or related projects into folders and manage them from there. Furthermore, you can manage both folders and projects under an organization resource.

The following diagram shows an example of various resources and their hierarchical organization in Google Cloud. In order to interact with most Google Cloud resources, you must provide the identifying project information for every request.

Example of a Google Cloud resource hierarchy.

Policy inheritance

With AWS, you can specify resource-based permissions, which apply directly to resources, or you can specify permissions for specific actions that can be performed against a given resource. Which way the permissions can be specified depends on the service.

Google Cloud's IAM policy inheritance is complemented by its resource organization. In Google Cloud, resources are organized hierarchically, so you can set IAM policies that flow from the organization node downwards. If you want to have organization-wide IAM policies, you can assign those policies on the organization resource. If you want to set policies across multiple teams and projects, you can use Google Cloud folders to do so. You can then assign permissions at the project level, and finally at the resource level within the project for a more granular level of control.


Identities used to access cloud resources break down into two groupings:

  • End-user identities, represented by their usual corporate logins. In the case of AWS, end users can also be represented by using IAM accounts.
  • Programmatic identities, which enable application code to access cloud resources.

End-users identities in AWS

AWS manages the root account that is a requirement for every account created. AWS provides a list of best practices to help protect your AWS account's root access keys.

To allow access to your AWS resources, you can set up IAM users, which are identities created within AWS, or you can set up federation from your corporate directory. You can use a third-party identity provider. When configuring a third-party identity provider to use with AWS, you need to create an IAM role and then define permissions for the role. When a federated user signs in to AWS, the user is associated with the role and is granted the permissions that are defined in the role.

End-user access in Google Cloud

With Google Cloud, you have two main options for assigning project ownership:

  • You can create a project with one or more owners who have full access to the project's resources.
  • You can have projects that don't have an explicit owner. This approach can be useful when the project is part of an organization and you want all your projects to be owned by that organization.

IAM doesn't enable you to manage end-user identities; it enables you to grant access to users who you create and manage by other means. When using IAM, by default you can grant access to the following types of identities:

  • Google Account
  • Service account
  • Google Group
  • Google Workspace domain

Google Groups are convenient and the recommended way to apply an access policy to a collection of users. You can grant and change access controls for a whole group at once, instead of granting or changing access controls one at a time for individual users or service accounts. You can also easily add members to and remove members from a Google Group, instead of updating an IAM policy to add or remove users.

If you don't already use a Google Workspace domain to manage your users, then you can federate your existing subset of operational users from many popular user directories such as Active Directory. This approach lets you use your existing corporate identities. You must first verify your domain name with Google.

The following table lists and describes the ways you can federate users into Google Cloud.

Federation technique Description
Google Cloud Directory Sync Tool provided by Google that works with most commercial and enterprise LDAP directory services. Google Cloud Directory Sync lets you add, modify, and delete users, groups, and non-employee contacts to synchronize the data in your Google Cloud domain with your LDAP directory server by using LDAP queries. The data in your LDAP directory server is never modified or compromised.
Third-party identity connectors Native connectors with an identity provider for those who provide it. Directly connects an identity provider to the domain provisioned in Google Cloud. Examples include:

  • Ping Federate
  • Okta
  • CA Siteminder
  • Azure AD
  • OpenIAM
  • Auth0
  • Oracle IAM
Google Apps API Gives an organization programmatic control of user and group management.

You can then add the identities, in the form of email addresses, to Google Groups to grant them access to Google Cloud resources.

Programmatic identities in AWS

With AWS, if you want to call the AWS APIs from an application that is not running on AWS compute resources, you create an IAM user. Then, you download the appropriate keys and use them with your app to make calls to the AWS APIs.

If you want to use a programmatic identity on an EC2 instance, you must also create an instance profile that is attached to the instance. This profile contains an IAM role, and it can provide the role's credentials to an application that runs on the instance.

An IAM role allows an IAM user, group, or an application that could be running on EC2 or on a mobile device assume the permissions defined by the role. Temporary credentials are created and supplied to the entity that is assuming the role.

The use of IAM roles also allows IAM users to switch to a role to temporarily use the permissions of that role when using the console. When this happens, users give up their original permissions and take on the permissions assigned to the role. When the users exit the role, they surrender those permissions.

Programmatic identities in Google Cloud

With Google Cloud, a service account is a special Google Account that applications can use to programmatically access Google services. This account belongs to your application or a Compute Engine instance rather than to an individual end user.

A service account can contain pairs of service account keys, which are used to authenticate to Google. A service account key is a public-private key pair generated by Google. Google retains the public key, while the user is given the private key.

You can create custom service accounts in Google Cloud projects using the Google Cloud Console, the Identity and Access Management API, or the gcloud command- line tool.

If you only intend to use the service account with applications running on Google Cloud computing services, you don't need to download the private keys, because you can use Google Cloud-managed keys.

One of the features of IAM service accounts is that you can treat it as a resource or an identity. The service account has an identity, and you give it permissions by granting it a role to access a resource, such as a project.

When looking at a service account as a resource, you can grant permission to a user to access that service account as you would for other Google Cloud resources. You can grant an owner, editor, viewer, or a serviceAccountUser undefined role to a user to access the service account. A user who is a serviceAccountUser for a service account can access all the resources with the same permissions for which the service account has access. This is similar functionality to the IAM role usage discussed in the previous section.

Service account keys can be either user-managed keys, which are managed by you, or Google Cloud-managed keys, which are managed by Google Cloud.

You can create and manage user-managed keys by using the Cloud Console, the IAM API, or the gcloud command-line tool. You are responsible for keeping the keys safe and rotating them.

Google Cloud-managed keys are used by services such as App Engine and Compute Engine. You cannot explicitly create or download a Google Cloud-managed key; Google manages the keys and rotates them for you once a day.

Permission attribution

Both Google Cloud and AWS use the terms role and policy, but the usages are subtly different. These differences can cause confusion in the mapping from AWS IAM to IAM. A collection of permissions in Google Cloud is called a role, but with AWS it's called a policy .

AWS permission example

With AWS, you specify the permissions as an action, resource, and effect in the policy definition. For example, an AWS policy that allows (the effect) someone to list all buckets (the action) in an account (the resource) looks like this:

  "Version": "2012-10-17",
  "Statement": {
  "Effect": "Allow",
  "Action": "s3:ListAllMyBuckets",
  "Resource": "*"

Standalone AWS IAM policies that can be attached to multiple users, groups, and roles are called managed policies. Managed policies can be either AWS managed policies, which are created and managed by AWS, or customer-managed policies, which you create and manage in your AWS account.

Google Cloud permission example

Google Cloud has a predefined, role-first approach, so a common use case such as listing all buckets in a project is simply a matter of using the Viewer role. This role then needs to be assigned to the user or group, and the resulting document that binds users or groups to the role is called a policy. The definition of a policy looks similar to the following example:

  "bindings": [
     "role": "roles/viewer",
     "members": [""]

AWS policies

With AWS, in addition to being able to attach policies to an identity, you can attach a policy to a resource. For policies that you attach to a resource, you need to embed an identity or role that is able to access the resource within the policy.

In most cases, AWS recommends using managed policies. Recommendations for choosing between managed policies and inline policies are stated in the AWS documentation.

Google Cloud policies

Now look at a Google Cloud policy declared in a JSON file, named iam-gcs-access.json,, which grants the viewer role to a group of users and the objectCreator role to a service account. An application uses the service account to add objects to buckets in a project. The following example illustrates how you can create multiple member-to-role bindings in a single policy.

    "bindings": [
        "members": [
        "role": "roles/viewer"
        "members": [
        "role": "roles/storage.objectCreator"
    "etag": "BwUjMhCsNvY=",
    "version": 1

This policy can then then be bound to the resource, which in this case is a project, by using the Cloud Console, the set-iam-policy command in the gcloud tool, or the API, to assign the policy to the project. For this example, the gcloud command looks like this:

gcloud projects set-iam-policy [PROJECT_ID] iam-gcs-access.json

where [PROJECT_ID] represents your Google Cloud project ID.

This is similar to how you embed an identity or role that is able to access the resource within the policy in AWS.

Managing policies in Google Cloud

You should treat your policies as you do your code: keep them in a version control system with the rest of the assets you use to define your cloud environment. If you update your policies, then create a new version.

While AWS has the two types of policies previously discussed, Google Cloud has only one type of policy, and you have the flexibility to manage your policies using whatever version control system you deem appropriate. Google Cloud offers Cloud Source Repositories, which are fully featured, private Git repositories hosted on Google Cloud.

If you already have a repository on GitHub or Bitbucket, you can connect it to your Cloud Source Repositories. Connected repositories and the Cloud Source Repositories stay automatically synchronized. Cloud Source Repositories also provide a source editor that you can use to browse, view, edit, and commit changes to repository files from the Cloud Console.

If you prefer to use your current version control solutions, you can do that on Google Cloud.

Testing and checking permissions

When using AWS, you can use the IAM policy simulator, which lets you test and validate any new and existing policies and see what policies have been set for a user, group, or resource.

With Google Cloud, you can use the get-iam-policy gcloud command to return the policy definition:

gcloud projects get-iam-policy [PROJECT_ID]

You can use the definition returned to help check which policies are attached to the resource. You can also use the Cloud Console to go to a specific resource and check the permissions.

To check the permissions assigned to an identity, you can select the identity in the Cloud Console and view the roles that identity is bound to. You could also sign in as that identity, or as a test identity that has the same permissions, to check what the identity can access in the Cloud Console.

Permission propagation

With AWS, all policies are evaluated. The order in which the policies are defined has no discernible impact, as the end result is either "allowed" or "denied". By using an explicit denial, you can override a broad policy that might allow access to a wide set of resources. This is described in detail in Determining Whether a Request Is Allowed or Denied Within an Account.

With Google Cloud, the effective policy for a resource is the union of the policy set at that resource and the policy inherited from its parent. Because roles are concentric, granting multiple roles to the same user gives the user the permissions of the broadest role granted. You can read some example scenarios in Using resource hierarchy for access control.

IAM auditing

For auditing IAM activity, Amazon offers AWS CloudTrail, which records and logs AWS API calls for your account. CloudTrail sends these logs to an Amazon S3 account you specify.

Google Cloud offers Cloud Audit Logs, which records admin activity and data access. These two streams are generated by Google Cloud services to help you answer the question of "who did what, where, and when?" within your Google Cloud projects.

Individual audit log entries are kept for a specified length of time in Google Cloud's operations suite, so you can have at-a-glance dashboard views for recent activities. These entries are deleted from Google Cloud's operations suite after a specified period of time. The Cloud Logging quota policy explains the length of time that log entries are retained. You cannot otherwise delete or modify audit logs.

Logging IAM roles let you restrict access to only the logging-related resources in a project or organization.

For longer retention, you can export audit log entries to a Cloud Storage bucket, a BigQuery dataset, a Pub/Sub topic, or any combination of the three.

What's next

Check out the other Google Cloud for AWS Professionals articles: