This guide outlines the process for establishing single sign-on between AWS and Google Workspace through a series of configuration steps.
Step 1: Create AWS User Groups
Begin by establishing an "AWS Users" group within Google Workspace. Additional groups may be created as needed, with permissions allocated on a group-by-group basis within AWS.
Step 2: Configure Google Workspace Integration
Configure the AWS side of the Google Workspace integration by following the official AWS documentation at https://docs.aws.amazon.com/singlesignon/latest/userguide/gs-gwp.html through step 3. The key modification involves restricting access to the "AWS Users group" rather than enabling it organization-wide.
SSO setup secures access. Compliance requires proving it continuously.
Share your work email and turn your AWS identity controls into audit-ready evidence.
Step 3: Set Up Google Cloud Project
Within a new Google Cloud project, complete the following:
- Enable the Admin SDK API
- Create a service account and export JSON credentials (no additional roles required)
- Configure domain-wide delegation with these scopes:
https://www.googleapis.com/auth/admin.directory.group.readonlyhttps://www.googleapis.com/auth/admin.directory.group.member.readonlyhttps://www.googleapis.com/auth/admin.directory.user.readonly
Step 4: Enable AWS Identity Center Provisioning
Navigate to AWS Identity Center and activate automatic provisioning. Document the SCIM endpoint URL and access token for later use.
Step 5: Deploy SSOSync Application
Deploy the AWS Serverless Application Repository (SAR) application via: https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-2:004480582608:applications/SSOSync
Configure the following parameters:
- GoogleAdminEmail: An email with full Google Workspace administrative privileges
- GoogleGroupMatch:
name:AWS* - DeployPattern: App + secrets
- SyncMethod: groups
- SCIMEndpointAccessToken: Your token from Step 4
- SCIMEndpointUrl: Your endpoint from Step 4
- IdentityStoreID: Your Identity Store ID
- GoogleCredentials: JSON credentials from Step 3
AWS and Google Workspace SSO FAQs
Common questions about running AWS SSO off Google Workspace: why SSOSync is needed, which directory scopes it requires, and how group matching decides who reaches AWS.
The AWS-documented setup handles authentication, not provisioning. Google Workspace does not push group membership into AWS on its own, so without SSOSync you end up creating and removing users in IAM Identity Center by hand. SSOSync reads your Google groups through the Admin SDK and writes them to the Identity Center SCIM endpoint, which is what makes group-based permission assignment actually maintainable.
Three read-only directory scopes, configured as domain-wide delegation: admin.directory.group.readonly, admin.directory.group.member.readonly, and admin.directory.user.readonly. The service account itself needs no additional IAM roles in the Google Cloud project — only the exported JSON credentials and the Admin SDK API enabled.
Scope it to an "AWS Users" group rather than enabling it organization-wide. That is the one meaningful deviation from the AWS documentation in this guide, and it matters for both blast radius and audit: a named group makes "who can reach AWS" a question with a single, reviewable answer, instead of defaulting to everyone with a mailbox.
It is a filter that decides which Google groups SSOSync syncs. The value name:AWS* matches every group whose name starts with "AWS", so creating AWS Engineering or AWS Billing in Google Workspace is enough to have it appear in Identity Center for permission assignment. Groups outside that prefix are ignored, which keeps unrelated mailing lists out of your AWS identity store.
Partly. Centralising authentication is the groundwork; auditors then want proof that access is reviewed, that leavers lose it promptly, and that MFA is enforced at the identity provider. Because MFA for IAM Identity Center is not supported with external identity providers, with this setup that enforcement and its evidence live in Google Workspace, not AWS.
Turn identity controls into audit evidence
Book a demo and we'll show how Konfirmity turns AWS identity and access controls like this SSO setup into evidence your next SOC 2 or ISO 27001 auditor accepts.
Book a demo
