AWS
Security
Tutorials
AWS IAM Identity Center with Google Workspace as an IdP: 2026 Step-by-Step Guide
TL;DR
Setting up AWS IAM Identity Center with Google Workspace involves two distinct pieces: SAML authentication (letting Google credentials sign users into AWS) and SCIM provisioning (automatically syncing Google users into Identity Center). SCIM is now officially supported for user provisioning - but group sync still doesn't work via SCIM, so groups need either manual AWS CLI commands or the ssosync tool. This guide covers both.
AWS IAM Identity Center and Google Workspace power a lot of the same companies' infrastructure. Google manages the identities, AWS manages the resources, and getting the two to talk to each other is something every platform team ends up doing sooner or later.
When we originally wrote this guide in 2021, automatic user sync between Google and AWS wasn't available. The only options were manually creating users in the Identity Center console one at a time, or running ssosync yourself. That's changed. AWS now officially supports SCIM 2.0 provisioning from Google Workspace, and there's a pre-built "Amazon Web Services (SAML)" app in Google's app catalog that takes most of the manual metadata exchange out of the initial setup.
What follows covers SAML authentication, SCIM user provisioning, the group sync workaround (because SCIM still doesn't handle groups), and a few security notes that catch people off guard if they skip them.
What You Need Before Starting #
- An AWS Organization with IAM Identity Center enabled in your home region, configured from the management account
- Google Workspace admin access with permission to add SAML apps
- A clear decision on your IAM Identity Center home region - changing it later requires re-provisioning everything attached to it
IAM Identity Center must be enabled before you can configure an external IdP. If you haven't done that yet, the AWS docs have a short enablement guide.
Part 1: SAML Authentication #
SAML handles the authentication side - when a user clicks the AWS tile in their Google apps, SAML verifies their identity and hands them a session in AWS. Provisioning (getting users into Identity Center in the first place) is separate and covered in Part 2.
Step 1: Add the Amazon Web Services App in Google Workspace #
Sign in to your Google Admin console and go to Apps > Web and Mobile Apps.
From the Add App dropdown, choose Search for apps - not "Add Custom SAML App," which was the old approach. Search for Amazon Web Services and select the Amazon Web Services (SAML) application from the results. This is the pre-built app, and Google has already populated most of the attribute mappings you'll need.
On the Google Identity Provider details page, download the IdP metadata XML file. You'll upload this to AWS in the next step. Leave the tab open.
Step 2: Configure Identity Center to Accept Google as the IdP #
Select External identity provider, then scroll to Identity Provider metadata. Upload the
GoogleIDPMetadata.xml file you downloaded. Once uploaded, copy two values from the Service Provider metadata section:- IAM Identity Center ACS URL (looks like
https://us-east-1.signin.aws/platform/saml/acs/...) - IAM Identity Center issuer URL
Step 3: Finish the Google Workspace App Configuration #
Return to Google Admin. On the Service provider details page, fill in:
- ACS URL: paste the IAM Identity Center ACS URL
- Entity ID: paste the IAM Identity Center issuer URL
- Name ID format: EMAIL
- Name ID: Basic Information > Primary email
For Attribute mapping, add a mapping for
https://aws.amazon.com/SAML/Attributes/RoleSessionName pointing to Basic Information > Primary Email. Click Finish.Step 4: Enable the App and Accept the Identity Source Change #
In Google Admin, open your AWS app's User access section and set it to ON for everyone for now. You'll want to restrict this to a specific group or OU after setup - more on that in the security section.
Back in the AWS console, review the identity source change and type ACCEPT to confirm.
SAML is now configured. Users can authenticate with Google credentials, but they don't exist in Identity Center yet. That's what SCIM handles.
Part 2: SCIM Provisioning - Automatic User Sync #
SCIM 2.0 lets Google push user account changes (creates, updates, deactivations) to Identity Center automatically. When someone joins your company, their Google account appears in Identity Center within minutes. When they leave, deprovisioning happens on a schedule you control.
Step 5: Enable Automatic Provisioning in AWS #
In IAM Identity Center > Settings, find the Automatic provisioning section and click Enable.
AWS displays a SCIM endpoint URL and an access token. Copy both immediately. The token is shown exactly once - there is no way to retrieve it again. If you close the dialog before copying it, you'll need to rotate the token and re-enter it in Google, which disrupts any active provisioning session. Store the token in AWS Secrets Manager or whichever credential store your team uses.
One-time token display
The SCIM access token is only visible when you first enable provisioning. Copy it before clicking anything else. If you miss this, go to Settings > Automatic provisioning > Rotate access token to generate a new one.
Step 6: Configure Auto Provisioning in Google Workspace #
Return to Google Admin, navigate to your AWS IAM Identity Center app, and find Auto provisioning. Click Configure auto provisioning and enter:
- Access token: the token from the previous step
- Endpoint URL: the SCIM endpoint URL from the previous step
Verify the attribute mappings on the next screen. Every Google Workspace user being synced must have all four of these populated in their profile: First name, Last name, Username, and Display name. If any field is empty for a given user, that user will fail to sync.
SCIM attribute requirements
If specific users aren't appearing in Identity Center after SCIM is configured, this is usually why. Check the user's Google Workspace profile and confirm all four required fields have values. Users with multiple values for a single attribute - like two phone numbers on record - will also fail to sync. Remove the duplicates first. For large directories where checking profiles one by one isn't practical, CloudQuery can query provisioning status across all synced users to surface which ones are in an error state.
For Deprovisioning, configure how quickly a user loses access after being removed in Google Workspace. Setting suspension to 24 hours and deletion to 30 days is a reasonable starting point: it provides a recovery window for accidental removals while ensuring departed employees don't retain access longer than necessary.
Set the toggle to Active and confirm. Google runs an initial sync, which typically completes within a few minutes for small to medium directories. For larger organizations, allow up to 24 hours for the first pass.
To verify the sync worked, go to IAM Identity Center > Users in the AWS console. You should see your Google Workspace users listed with "Provisioned by SCIM" in the source column. If a specific user is missing, the first thing to check is whether all four required attributes are populated on their Google profile.
The Group Sync Problem #
Here's what catches most people off guard: SCIM from Google Workspace only provisions users. Groups do not sync automatically. After enabling SCIM, you'll also notice the group management UI in the Identity Center console is disabled - groups must be created through the AWS CLI or API, or with ssosync.
Terminology
SCIM (System for Cross-domain Identity Management): An open protocol for syncing user accounts between identity providers. AWS IAM Identity Center supports SCIM 2.0 for inbound provisioning from Google Workspace - for users only. Group sync is not currently supported natively.
SAML (Security Assertion Markup Language): The protocol handling authentication. SAML verifies who a user is; SCIM handles getting their account into the right system.
Here's a quick comparison of the approaches available:
Option A: Create Groups via AWS CLI #
If you have a handful of groups to manage, the CLI approach works. Start by getting your Identity Store ID:
aws sso-admin list-instances
This returns your
IdentityStoreId - something like d-1234567890. Create a group:aws identitystore create-group \
--identity-store-id d-1234567890 \
--display-name "Engineering" \
--description "Engineering team"
The response includes a
GroupId. To add a SCIM-provisioned user to that group, first find their UserId:aws identitystore list-users \
--identity-store-id d-1234567890 \
--filters AttributePath=UserName,AttributeValue=[email protected]
Then add the membership:
aws identitystore create-group-membership \
--identity-store-id d-1234567890 \
--group-id "your-group-id" \
--member-id '{"UserId": "your-user-id"}'
This works fine at small scale but becomes tedious when managing more than a few groups across a large directory.
Option B: ssosync for Full Automation #
ssosync is an AWS Labs project that syncs both users and groups from Google Workspace to Identity Center. It's on v2.3.8 (released April 30, 2026) and actively maintained. The fastest deployment path is the AWS Serverless Application Repository, which walks you through deploying a Lambda with a configurable CloudWatch schedule (the SAM template defaults to
rate(15 minutes)). If you're managing more than five or six groups manually, the CLI approach becomes a real maintenance burden - ssosync is the more practical option at that scale.One note if you're running AWS Control Tower: ssosync can affect Control Tower-managed users and groups depending on your directory structure. Test it in a sandbox account first before rolling it out in production.
Assigning Access to AWS Accounts #
With users (and optionally groups) in Identity Center, you can assign them to AWS accounts. Go to IAM Identity Center > AWS accounts, select an account, and click Assign users or groups.
Permission sets define what a user or group can do once signed in. You can use AWS-managed policies like
AdministratorAccess or PowerUserAccess, or define custom inline policies. Permission sets propagate across all accounts they're assigned to, which is one of the main advantages of managing access through Identity Center rather than individual account IAM roles.For ongoing maintenance, assigning groups to accounts rather than individual users makes access management far easier as team membership changes. If you need to audit permission set assignments across accounts over time - who has what, where, and whether it drifted - the CloudQuery AWS source plugin syncs Identity Center data into SQL tables you can query across your entire organization.
Finding Your AWS Access Portal URL #
Once users are assigned to accounts, they'll need to know where to log in. Your AWS access portal URL is shown on the IAM Identity Center Dashboard in the AWS console - it looks like
https://d-xxxxxxxxxx.awsapps.com/start. You can customize the subdomain under Settings > Customize to something more memorable like https://yourcompany.awsapps.com/start. Send this URL to your team alongside instructions to sign in with their Google credentials. From there they'll see all the accounts and permission sets they've been assigned.Users can also reach the portal directly from the Google apps grid - the AWS tile shows up alongside their other Google Workspace apps once the SAML app is enabled.
Five Security Details Worth Getting Right #
A few things that are easy to skip during initial setup and cause headaches later.
1. MFA enforcement lives in Google, not AWS.
When you switch to an external IdP, AWS hands off authentication entirely to Google. That means MFA requirements, session policies, and conditional access rules are all controlled in Google Workspace - not in IAM Identity Center. If your security team asks "how do we enforce MFA for AWS access?", the answer is the 2-Step Verification settings in Google Workspace, not anything in the AWS console. Get that enforced in Google before you roll this out to your org.
3. Scope the app before you go to production.
Leaving the Google Workspace app set to "ON for everyone" means every person in your Google org can attempt SSO to AWS - even if they have no Identity Center account or permission sets. Restrict it to the users and groups who actually need AWS access by using a Google Workspace group or organizational unit in the User access settings. This takes two minutes to do and avoids a messy cleanup later.
4. Put certificate rotation on your calendar.
Google IdP certificates expire, and when they do, SSO breaks completely until you upload the updated certificate in Identity Center. AWS surfaces a warning in the console as expiration approaches, but it's easy to miss if nobody's watching the dashboard. Read through the certificate rotation docs now, before you need them. The process is straightforward - it's just unpleasant to figure out for the first time during an outage.
5. Know the multi-region limitation before it matters.
Google Workspace doesn't support SAML multiple ACS URLs, which is what IAM Identity Center uses for multi-region deployments. Your primary region functions normally, but failover behavior in secondary regions is more limited than with IdPs that support multiple ACS URLs. Most teams won't hit this, but if multi-region resiliency is a hard requirement for your org, review the IAM Identity Center multi-region considerations before committing to this IdP setup.
Key Takeaways #
- SAML handles authentication; SCIM handles provisioning. Both need to be configured for a complete setup.
- The official Amazon Web Services (SAML) app in Google's catalog replaces the old custom SAML app approach and requires less manual configuration.
- SCIM from Google Workspace only syncs users - groups require the AWS CLI or ssosync.
- The SCIM access token is shown exactly once. Copy it before closing the dialog.
- All four fields must be populated in Google Workspace for a user to sync: First name, Last name, Username, and Display name.
- ssosync v2.3.8 handles both user and group sync and is the recommended path for teams that need full automation.
What Comes Next #
Once users can sign in with Google credentials, the next practical step is configuring the AWS CLI to use IAM Identity Center so your team can run commands without managing long-lived access keys.
If you're managing access across a larger AWS organization, AWS Organizations delegation is worth reviewing - it lets you grant Identity Center administration to a non-management account, which is the recommended setup for most teams.
For auditing who has access to what across all your accounts, the CloudQuery AWS source plugin syncs Identity Center data - permission set assignments, user provisioning status, group memberships - into SQL tables. That means you can answer questions like "which users have AdministratorAccess in production?" or "which accounts have users assigned directly rather than through a group?" with a SQL query instead of clicking through each account in the console.
See Who Has Access to What Across Every AWS Account
CloudQuery syncs IAM Identity Center data - permission sets, users, groups, account assignments - into SQL tables across your entire AWS organization. If you've been clicking through accounts in the console to answer access questions, there's a better way.
Frequently Asked Questions #
What is AWS IAM Identity Center? #
AWS IAM Identity Center (formerly AWS Single Sign-On) is AWS's centralized identity management service for granting users access to multiple AWS accounts and applications through a single login. AWS renamed it from "AWS SSO" in 2022. See the official product page for current documentation.
Does Google Workspace Support SCIM with AWS IAM Identity Center? #
Yes. Google Workspace now supports SCIM 2.0 for user provisioning to IAM Identity Center, enabling automatic account sync when users are created, updated, or deactivated in Google Workspace. Group provisioning via SCIM is not currently supported - groups must be managed through the AWS CLI, IAM API, or ssosync.
Why Can't I Create Groups in the AWS Console After Enabling SCIM? #
When external SCIM provisioning is active, Identity Center disables console-based group management. This is expected behavior, not a bug. Groups must be created using the
aws identitystore create-group CLI command or the IAM API CreateGroup operation.What is ssosync and Do I Still Need It? #
ssosync is an AWS Labs tool that syncs both users and groups from Google Workspace to IAM Identity Center. If you only need user sync, native SCIM handles that without ssosync. If you need group sync (which native SCIM doesn't support), ssosync is still the most practical option. It's currently at v2.3.8.
How Long Does SCIM Provisioning Take? #
Initial provisioning after enabling SCIM typically completes within a few minutes for small to medium directories. AWS documents up to 24 hours for large directories on the first sync. Subsequent changes - new users, attribute updates, deactivations - generally sync within minutes after the change occurs in Google Workspace.
What Happens to a User's AWS Access When They Leave the Company? #
When a user is deactivated in Google Workspace, SCIM sends a deprovisioning event to Identity Center. Your deprovisioning settings control the delay before the account is suspended and then deleted. Setting suspension to 24 hours and deletion to 30 days gives you a recovery window for mistakes while keeping the access lifecycle manageable. See the AWS deprovisioning considerations for the full list of what triggers deprovisioning.
Can I Use a Google Workspace Organizational Unit to Control Who Gets AWS Access? #
Yes. In Google Admin under the app's User access settings, you can enable the service for specific organizational units or groups rather than everyone. This is the recommended approach - don't give every Google Workspace user the ability to authenticate to AWS.
Do I Need AWS Organizations to Use IAM Identity Center? #
For multi-account access management, yes. IAM Identity Center in organization mode is what lets you assign access across multiple accounts from a single place. If you're working within a single account, account instances of Identity Center are available, but most teams use it at the organization level. See the AWS Organizations getting started guide for initial setup.
