AWS IAM EU Alternative 2026: Identity, Access, and the GDPR Problem

Post #688 in the sota.io EU Compliance Series

AWS Identity and Access Management (IAM) is the access control foundation of every AWS deployment. Every API call made in your AWS account is authorized through IAM. Every S3 bucket policy, every Lambda execution role, every RDS database access, every EKS service account — all of it routes through IAM.

Here is the fundamental GDPR problem with AWS IAM: IAM is a global service. It does not have regional endpoints. All IAM data is stored and processed by AWS in the United States.

This is not a configuration issue. There is no eu-central-1 IAM endpoint you can point to. There is no Frankfurt IAM replica. When you create an IAM user, define a policy, or attach a role, that identity data is written to AWS infrastructure under direct US jurisdiction. The CLOUD Act (18 U.S.C. § 2713) compels US companies to produce data stored anywhere in the world — and for IAM, the data is not even in Europe to begin with.

This article examines what AWS IAM stores, how it interacts with GDPR obligations, and what EU-native alternatives exist for organizations that need identity management without US jurisdiction exposure.

What AWS IAM Is and Why It Cannot Be Regionalized

IAM operates as a global AWS service for a deliberate architectural reason: access control decisions must be consistent across all regions. If you deny an IAM user access to S3, that denial must hold in eu-central-1 as it does in us-east-1. Regional IAM would create access control inconsistencies that would break AWS's distributed architecture.

The practical consequence is that IAM data — users, groups, roles, policies, permission boundaries, trust relationships — lives in AWS's global control plane, which is operated from the United States. AWS's documentation confirms this: "IAM is a global service and data is stored in a global database."

Several connected services extend this US-jurisdiction footprint:

IAM Identity Center (formerly AWS SSO): AWS's managed federation service that integrates with Active Directory, Okta, Azure AD, and other identity providers. Identity Center runs in one home region you select during setup, but the service itself is managed AWS infrastructure with US-entity control. All user assignments, permission sets, and account assignments pass through AWS's systems.

IAM Access Analyzer: Analyzes your resource policies to identify external access. Analyzer runs in individual regions but is a managed AWS service processing your policy content through AWS infrastructure. Policy analysis results and findings are stored in AWS-managed storage.

IAM Access Advisor: Shows which AWS services a user, group, role, or policy has accessed and when. Access Advisor data reveals your application's access patterns — which services are used, at what frequency. This is operational intelligence about your application under US jurisdiction.

AWS Organizations Service Control Policies (SCPs): SCPs are IAM policies applied at the organizational level. An SCP attached to an organizational unit (OU) governs what API calls can be made across your entire AWS footprint. SCPs are stored in AWS Organizations, a global service with the same US-jurisdiction characteristics as IAM itself.

What IAM Data Means Under GDPR

IAM data involves personal data in several direct ways.

IAM Users represent individuals. When you create an IAM user firstname.lastname@company.com, you have created a personal data record: a name tied to an identity. IAM users have access keys, passwords, MFA device bindings, and last-used timestamps. This is personal data under GDPR Art.4(1) — information relating to an identified natural person.

CloudTrail captures IAM activity as identity logs. Every API call in your AWS account is recorded in CloudTrail, including the IAM principal (user, role, or assumed role) that made the call. CloudTrail records include: UserIdentity (IAM user ARN or role ARN), sourceIPAddress, eventTime, and the specific API action performed. CloudTrail is a regional service, but the IAM principal information embedded in CloudTrail logs is linked directly to IAM data under US jurisdiction.

IAM Roles for human access expose session data. When a developer assumes an IAM role via sts:AssumeRole, AWS STS (Security Token Service) issues temporary credentials and logs the assumption event. The AssumedRoleUser field in CloudTrail includes the session name — which organizations typically set to the employee's email address or username. Every role assumption by a human = personal data in CloudTrail.

IAM Identity Center synchronizes your user directory. If you use IAM Identity Center with an external identity provider (Azure AD, Okta, Google Workspace), IAM Identity Center synchronizes a subset of your user directory into AWS. Synchronized attributes typically include name, email address, and group membership. This is a direct transfer of personal data to AWS-managed infrastructure.

SCIM provisioning under GDPR Art.46. SCIM (System for Cross-domain Identity Management) is the protocol used to synchronize directory data into IAM Identity Center. If your organization is in the EU and you use SCIM to provision users into IAM Identity Center, you are transferring personal data to a US entity. This transfer requires a valid legal mechanism under GDPR Art.46 — Standard Contractual Clauses (SCCs) or Binding Corporate Rules (BCRs). The AWS Data Processing Agreement references the 2021 EU SCCs, but the Schrems II decision and the CLOUD Act question whether SCCs alone provide effective protection when the recipient is subject to US surveillance laws.

The Service Control Policy Problem

SCPs deserve special attention because they represent a particularly sensitive category of organizational data under US jurisdiction.

An SCP defines what AWS API calls are permitted across your entire organization. A well-designed SCP architecture embeds your organization's security posture: which services you allow, which regions you operate in, what data exfiltration controls you've implemented. This is security-architecture information under AWS's control.

SCPs are stored in AWS Organizations, a global service. If AWS were served with a US government order, your organizational security policy — the blueprint of your AWS security controls — would be accessible to US authorities. This is not a theoretical concern for organizations in regulated industries (financial services, healthcare, critical infrastructure) where security architecture is itself sensitive information.

GDPR Art.35: DPIA Obligation

AWS IAM's global nature triggers DPIA (Data Protection Impact Assessment) obligations for many organizations under GDPR Art.35. Specifically:

• Art.35(3)(b): Large-scale processing of special categories of data. If your application processes health, financial, or other sensitive data and your IAM configuration governs access to that data, the DPIA must assess the IAM layer as part of the processing chain.
• Art.35(3)(c): Systematic monitoring. IAM Access Advisor and CloudTrail IAM events constitute systematic monitoring of employee access behavior.

A DPIA for AWS IAM must document: that IAM is a global US-jurisdiction service, that personal data (user identities, access patterns) is stored outside the EU, what legal transfer mechanism applies, and what residual risks remain given CLOUD Act exposure.

EU-Native Identity Management Alternatives

Replacing AWS IAM for AWS-resource authorization is not possible — IAM is fundamental to AWS's architecture. But the human identity layer (who are your users, what roles do they have) can be managed outside AWS, with only role assumption delegated to AWS STS.

Option 1: Keycloak (Self-Hosted)

Keycloak is the leading open-source identity and access management solution, originally developed by Red Hat (now IBM). It provides:

• OpenID Connect (OIDC) and SAML 2.0 federation
• User federation to LDAP/Active Directory
• Multi-factor authentication
• Fine-grained authorization services
• SCIM provisioning

For AWS integration, Keycloak acts as a SAML/OIDC identity provider for IAM Identity Center. Users authenticate to Keycloak (on your EU infrastructure), and Keycloak issues assertions to AWS STS via the identity federation protocol. The user directory stays on your infrastructure; only the role assumption token reaches AWS.

Self-hosting Keycloak on EU infrastructure — Hetzner (Germany), OVHcloud (France), or sota.io — means the identity data never leaves your jurisdiction.

Jurisdictional status: User-controlled. Deploy on any EU infrastructure.

Option 2: Authentik

Authentik is a German identity provider company building an open-source IAM platform. The company is headquartered in Germany, making it subject to German data protection law (BDSG) and GDPR as a data processor — not the CLOUD Act.

Authentik supports:

• OAuth 2.0 / OIDC / SAML / LDAP / SCIM / Proxy providers
• Multi-factor authentication with hardware keys (FIDO2/WebAuthn)
• AWS federation via SAML for IAM Identity Center
• Policy engine for conditional access
• Self-hosted on your infrastructure

Authentik's open-source model means you can audit the codebase, deploy it on EU infrastructure, and maintain full control over identity data.

Jurisdictional status: German company (BDSG/GDPR), self-hostable on EU infra.

Option 3: Zitadel

Zitadel is a Swiss identity provider with EU GDPR alignment. Switzerland is recognized by the EU Commission as providing adequate data protection (Adequacy Decision under GDPR Art.45). Zitadel offers:

• Cloud-hosted in Switzerland (Exoscale, a Swiss cloud)
• Self-hostable anywhere (including EU infra)
• OpenID Connect, OAuth 2.0, SAML 2.0
• Fine-grained authorization with custom permission models
• Multi-tenancy for SaaS applications
• AWS federation support

Zitadel's cloud offering provides a managed service option without the operational overhead of self-hosting, while maintaining Swiss/EU jurisdiction.

Jurisdictional status: Swiss company (FADP, GDPR-adequate). Cloud option available in Switzerland.

Comparison Table

Migration Strategy: Decoupling Human Identity from AWS IAM

The practical migration path for organizations that cannot leave AWS is to decouple the human identity layer from AWS IAM while keeping service-to-service authorization in IAM roles.

Step 1: Audit IAM Users

Identify all IAM users in your account. Any IAM user that represents a human is a personal data record under US jurisdiction. The target state: zero human IAM users. All human access via federation.

aws iam list-users --query 'Users[*].[UserName,CreateDate,PasswordLastUsed]' --output table

Step 2: Deploy an EU Identity Provider

Set up Keycloak, Authentik, or Zitadel on EU infrastructure. Configure it as your authoritative user directory. This is where employee identities live — not in AWS.

Step 3: Configure AWS IAM Identity Center with External IdP

Configure IAM Identity Center to federate to your EU IdP via SAML 2.0. Map IdP groups to IAM Identity Center permission sets. Disable SCIM provisioning from the IdP to IAM Identity Center (to prevent personal data synchronization to AWS). Use just-in-time provisioning instead.

With JIT provisioning, a user account in IAM Identity Center is created only when the user logs in via SAML assertion — and it contains only what the SAML assertion provides (typically just the email address and role assignment). No bulk user sync to AWS.

Step 4: Migrate Service Accounts to IAM Roles

Service-to-service access should already use IAM roles (not IAM users with access keys). If you have application IAM users with long-term access keys, migrate them to IAM roles with sts:AssumeRole. IAM roles contain no personal data — they are architectural constructs, not person records.

Step 5: Migrate SCPs to a Policy-as-Code Framework

For Service Control Policies, the mitigation is not eliminating SCPs (they are necessary AWS controls) but treating them as infrastructure code managed in your EU-hosted Git repository. SCPs checked into Git and managed via CI/CD pipelines from your EU infrastructure means the authoritative policy definition is on your turf — even if AWS stores a copy.

What This Means for Your GDPR Article 30 Record

GDPR Art.30 requires organizations to maintain a record of processing activities. For organizations using AWS IAM, the Art.30 record must include:

• Controller: Your organization
• Purpose: Employee access management for AWS resources
• Personal data categories: Names, email addresses, access patterns, MFA device bindings
• Recipients: Amazon Web Services, Inc. (US processor under DPA)
• Third-country transfers: Yes — transfer to USA under SCCs (2021 Standard Contractual Clauses)
• Retention: Duration of employment + configurable IAM account deletion period
• Technical measures: Encryption in transit; AWS encryption at rest; no effective protection against CLOUD Act disclosure

Organizations that migrate human identity to Keycloak/Authentik/Zitadel on EU infrastructure can simplify the Art.30 record significantly: the transfer to the US is limited to temporary STS tokens (no personal data), and the personal data record stays on EU infrastructure under the organization's control.

Conclusion

AWS IAM's global architecture creates an unavoidable US-jurisdiction footprint for any organization using AWS. IAM users, group memberships, access patterns, and federated identity data all sit outside EU data protection jurisdiction. For compliance-conscious organizations, the right architecture separates human identity (managed on EU infrastructure) from AWS resource authorization (delegated to IAM roles via SAML federation).

Keycloak on EU-hosted infrastructure, Authentik (German company), and Zitadel (Swiss, GDPR-adequate) are the three credible alternatives for the human identity layer. Service-to-service authorization via IAM roles carries no personal data and requires no equivalent migration.

The complete AWS compliance picture requires examining every service in the stack: AWS RDS, AWS S3, AWS Lambda, AWS SES, AWS CloudWatch, and now AWS IAM. Identity management sits at the foundation of all of it.