This is a revised version of the original post Leveraging AWS SSO (aka Identity Center) with Google Workspaces based on the new announcement AWS IAM Identity Center now supports automated user provisioning from Google Workspace The original post is still valid, and in someways may be better, but this version has it’s own advantages.
Setting up AWS IAM Identity Center (successor to AWS Single Sign-On), hereafter called AWS SSO (because I have to pay AWS for egress on this site), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.
Companies using Google Workspaces for email and collaboration can also leverage their Google accounts to access AWS via AWS SSO. The process isn’t clearly documented, and the provisioning support isn’t integrated, so here is a post to help you set it all up.
We assume you already signed up for Google Workspaces or configured Google for Cloud Identity. The person performing this must be a SuperAdmin and have access to admin.google.com. This post also assumes you’ve set up AWS SSO.
What about Second Note: Throughout this document, I refer to Google Workspace users, but users do not need a Workspace license. Google Cloud Identity users work the same as Workspace users.
Go ahead and open three browser windows/tabs. One with this post, one for the AWS Console, and one for the Google Admin page.
Make sure you’re doing this as an IAM User, or you might get locked out of your AWS account





RoleSessionName should be Primary Email. While Role can be any value, since that’s not required by AWS SSO.


GoogleIDPMetadata.xml as the Identity provider metadata in AWS SSO
Here is where the difference between the two versions of this post diverge greatly. With the AWS provide ssosync tool, you needed to do all sorts of GCP service account creation, key generation, and domain-wide delegation. With the Amazon Web Services Google Workspace App, all of that is now handled for you.
The problem with the new app is that it only syncs users it doesn’t sync groups! And when you enable SCIM provisioning in AWS Identity Center, all of the console mechanisms for creating groups and managing group membership go away. You can still manage groups via the CLI and API, but that’s not a trivial process since the CLI wants user & group IDs rather than human readable names.
Additionally, the Google app only syncs users that are members of existing AWS SSO Groups (or is a member of the “Provisioning scope” group.) So this newer way of autoprovisioning is only useful if you want to manually assign users to accounts / permission sets, or if you plan to automate authorization via terraform, and manually create groups in both Google Workspaces and AWS SSO.




Unlike AzureAD, Google Workspaces promptly triggers a sync when this is configured or users are changed.
The new Google App can still be used with the old provisioning method. And frankly that’s how I think I’m going to proceed going forward.
The autoprovisioning in the new App is too immature to be useful, but might get there someday. What I hope is there is a method by which I can specify a prefix of Groups which would be sync’ed to AWS SSO, rather than all Google groups being synced.