IAM / Multi-cloud landing zones
Identity-centric multi-cloud landing zone architecture
A practical reference architecture for using Microsoft Entra ID as the identity control plane across Azure and AWS landing zones, covering federation, user authentication, workload identity, JIT access, logging, Microsoft Sentinel monitoring, governance and assurance.
Quick Verdict
A strong multi-cloud IAM architecture should avoid separate identity silos in each cloud. The better pattern is to use Entra ID as the workforce identity control plane, federate access into Azure and AWS landing zones, enforce least privilege locally, monitor activity centrally and use governance evidence to prove that access remains appropriate over time.
Multi-cloud landing zones create a common foundation for cloud adoption, but they can also introduce identity sprawl if every platform is managed in isolation. A user may have one identity for Microsoft 365, another for Azure, another for AWS, separate local roles, separate privileged access processes and inconsistent logging. That creates security risk and operational friction.
This reference architecture shows how an identity-centric approach can support Azure and AWS landing zones by centralising authentication, Conditional Access, identity governance, privileged access workflows, security monitoring and assurance evidence around Entra ID, while still respecting the native controls needed inside each cloud platform.
Business context: why multi-cloud landing zones need identity at the centre
A managed cloud landing zone gives organisations a repeatable foundation for deploying workloads, networks, security controls, policies, logging and governance. In a multi-cloud environment, the challenge is that Azure and AWS each have their own control plane, identity model, role system and logging pattern.
Without a clear multi-cloud IAM architecture, teams can end up with inconsistent user access management, duplicated administrator roles, unclear ownership, stale entitlements and weak evidence for audit or client assurance. That matters for organisations that need to show how access is requested, approved, provisioned, monitored, reviewed and revoked.
Business goal
Enable secure Azure and AWS delivery while giving teams a consistent way to access cloud platforms, workloads and shared services.
Security goal
Reduce credential risk, standing privilege, unmanaged workload identities, access drift and gaps in cloud-native security visibility.
Assurance goal
Produce evidence that identity, access, monitoring, logging, risk treatment and governance controls are operating consistently.
Reference architecture: Entra ID as the identity control plane
In this model, Entra ID acts as the workforce identity control plane for cloud access. Azure and AWS remain separate technical environments, but user authentication, risk signals, access governance and privileged access workflows are anchored in a central identity service.
Cloud-native security controls still matter. Azure roles, AWS roles, network controls, logging services, endpoint security signals, Microsoft compliance security features and Microsoft Sentinel all form part of the overall control environment. The point is not to flatten the clouds into one platform. The point is to make access consistent enough to govern.
Reference diagram
Multi-cloud landing zone identity architecture diagram
This large architecture view shows how Entra ID acts as the identity control plane across Azure and AWS landing zones, with federation, JIT access, workload identity, logging, risk, governance and assurance connected into one operating model.
↓
↓
↓
↓
Identity-centric landing zone architecture layers
Use the layers below to move from business governance through identity, cloud platform controls, workload identity and assurance. This structure helps keep the architecture readable for security, platform engineering, IAM, GRC and leadership stakeholders.
Layer 1 — Business and governance view
Purpose: enable secure cloud adoption across Azure and AWS while keeping accountability, risk ownership and assurance evidence clear.
Actors: cloud platform teams, IAM administrators, workload owners, security operations, risk teams, data owners and auditors.
Governance focus: who can access what, under which conditions, for how long, with what approval and what evidence.
↓
↓
Layer 2 — Entra ID identity control plane
Identity: workforce users, administrators, groups, dynamic groups, external identities where required and privileged roles.
Controls: MFA, Conditional Access, Identity Governance, access reviews, entitlement management, PIM and risk-based sign-in policies.
Outcome: consistent authentication and user access management before access reaches Azure or AWS.
↓
↓
↓
Layer 3 — Azure landing zone view
Platform controls: management groups, subscriptions, Azure RBAC, policy, logging, key management, networking, private access and resource guardrails.
Identity controls: Entra ID users and groups mapped to Azure roles, PIM for privileged role activation and Conditional Access for sign-in risk.
Monitoring: Azure activity, identity events, endpoint security signals and cloud-native security alerts routed into monitoring and governance processes.
↓
↓
↓
Layer 4 — AWS landing zone view
Platform controls: AWS accounts, organisational units, IAM roles, permission boundaries, service control policies, network segmentation and logging.
Federation pattern: Entra ID authenticates the user and federates access into AWS roles or permission sets based on approved assignment.
Workload identity: machine-to-machine access should avoid long-lived secrets where federation, temporary credentials or managed identities can be used.
↓
↓
↓
Layer 5 — Logging, risk and assurance view
Logging: identity events, privileged access activation, Azure activity, AWS activity, workload access, policy changes and security alerts.
Monitoring: Microsoft Sentinel can help correlate identity, endpoint, cloud and workload signals where telemetry is integrated.
Assurance: evidence should show who accessed what, what approved the access, what risk signals were evaluated and when the access was reviewed.
↓
↓
↓
Entra ID, identity governance and user access management
A multi-cloud landing zone needs more than single sign-on. It needs a clear identity governance model that defines how access is requested, approved, provisioned, activated, reviewed and removed across cloud platforms.
| Control area | Architecture position | Assurance evidence |
|---|---|---|
| User authentication | Use Entra ID for workforce authentication with MFA and Conditional Access before cloud access is granted. | Sign-in logs, MFA status, Conditional Access results and risky sign-in review. |
| Access assignment | Map users to groups, roles, permission sets or entitlements based on role, project, environment and approval. | Assignment records, approval history, access request logs and role mapping documentation. |
| Privileged access | Use just-in-time activation for administrator roles and sensitive landing zone operations. | PIM activation logs, justification, approver, duration and privileged activity records. |
| Access reviews | Review high-risk roles, cloud administrators, dormant accounts and cross-cloud assignments on a defined cadence. | Review completion, removed access, exceptions and overdue owner actions. |
| Leavers and movers | Remove or adjust Azure and AWS access when a user changes role, project, client or employment status. | Lifecycle workflow records, deprovisioning completion and exception reports. |
Cloud workload identity federation
Human users are only one part of the architecture. Modern cloud environments also depend on workloads, pipelines, APIs, automation jobs and services that need to authenticate to other systems. If those workloads rely on long-lived secrets, static access keys or shared credentials, the landing zone can become difficult to secure.
Cloud workload identity federation creates a stronger pattern by allowing a workload or pipeline to exchange a trusted identity assertion for temporary access rather than storing permanent credentials. The exact implementation depends on the platforms involved, but the principle is consistent: authenticate the workload, scope the permission and keep access temporary.
Identify the workload
Know which application, pipeline, API, function, container or service is requesting access.
Trust the assertion
Use federation or managed identity patterns where supported instead of embedding long-lived secrets.
Limit the action
Grant only the permission needed for the workload, environment, resource and time window.
Multi-cloud IAM is not only about users. The architecture also has to govern workloads, pipelines, service accounts, API clients and automation identities.
Logging, Microsoft Sentinel and assurance evidence
A managed cloud landing zone should be auditable. Security teams need to understand which users accessed which cloud accounts or subscriptions, which privileged roles were activated, which workload identities accessed sensitive resources and whether policies were bypassed or changed.
Microsoft Sentinel can support this by correlating identity, endpoint security, Microsoft cloud-native security signals, Azure activity, AWS activity and other telemetry where connectors and data sources are integrated. The goal is not just alerting. The goal is traceability from identity decision to cloud action.
| Evidence area | What to capture | Why it matters |
|---|---|---|
| Authentication | Sign-in events, MFA result, Conditional Access decision, user risk and session information. | Shows whether access was verified before cloud entry. |
| Privileged access | Role activation, justification, approver, duration, target platform and administrator activity. | Shows whether privileged actions were time-bound and accountable. |
| Cloud control plane | Azure activity, AWS activity, policy changes, IAM changes, network changes and key security events. | Shows what happened after access was granted. |
| Workload identity | Service identity use, token exchange, API access, pipeline activity and secret access patterns. | Shows whether machine access is controlled and traceable. |
| Compliance security | Control status, policy exceptions, remediation actions, risk acceptance and review outcomes. | Shows whether the landing zone can stand up to assurance, audit and client scrutiny. |
Implementation roadmap for identity-centric multi-cloud landing zones
The architecture should be implemented in phases. Start with visibility and identity hygiene before expanding into privileged access, workload federation, logging, automation and assurance.
| Phase | Focus | Practical actions | Useful output |
|---|---|---|---|
| 1. Discover | Current cloud identity and landing zone access. | Map Azure subscriptions, AWS accounts, administrators, groups, permission sets, service identities and logs. | Identity and cloud access inventory. |
| 2. Standardise | Authentication and access assignment. | Define Entra ID groups, role mappings, Conditional Access policies, naming standards and ownership. | Multi-cloud IAM control baseline. |
| 3. Privilege | JIT access and administrator controls. | Move sensitive admin roles into PIM or equivalent JIT workflows with approval, duration and logging. | Privileged access operating model. |
| 4. Workloads | Workload identity federation and secret reduction. | Identify pipelines, APIs and automation jobs that can move away from static secrets or long-lived keys. | Workload identity roadmap. |
| 5. Monitor | Logging, Sentinel and cloud-native security telemetry. | Integrate identity, Azure, AWS, endpoint and workload logs into monitoring and incident response workflows. | Detection and assurance dashboard. |
| 6. Govern | Access reviews, risk acceptance and compliance evidence. | Run regular access reviews, exception expiry, control testing and reporting to leadership or assurance teams. | Governance pack and review cadence. |
Common multi-cloud IAM architecture mistakes
Duplicating identity per cloud
Separate identity processes in Azure and AWS create access drift, inconsistent controls and weaker evidence.
Leaving admin roles permanently active
Standing privilege increases the blast radius of credential compromise and weakens accountability.
Ignoring workload identities
Cloud landing zones often secure users before securing pipelines, APIs, service accounts and automation jobs.
Collecting logs without assurance questions
Logging only creates value when it can answer who accessed what, why, when, from where and with which approval.
Using one access model for every environment
Production, development, shared services and sensitive workloads need different access patterns and review cadences.
Forgetting the operating model
The architecture needs owners for policy, access reviews, exceptions, break-glass, incidents and governance reporting.
Multi-cloud IAM and landing zone architecture FAQs
What is the best architecture for multi-cloud IAM?
A strong multi-cloud IAM architecture uses a central identity control plane for workforce authentication, federates access into each cloud platform, enforces least privilege locally, uses just-in-time privileged access and collects audit evidence across identity and cloud activity.
How can Entra ID support Azure and AWS landing zones?
Entra ID can centralise workforce authentication, Conditional Access, identity governance and privileged access workflows, while Azure and AWS enforce platform-specific roles, permissions, policies and logging.
What is cloud workload identity federation?
Cloud workload identity federation allows workloads, pipelines or services to use a trusted identity assertion to obtain temporary access instead of relying on long-lived secrets or static credentials.
What should be included in a managed cloud landing zone?
A managed cloud landing zone should include identity and access controls, network structure, logging, policy guardrails, security monitoring, workload identity patterns, privileged access controls, governance ownership and assurance evidence.
How does Microsoft Sentinel fit into a multi-cloud security architecture?
Microsoft Sentinel can help correlate identity, endpoint, Azure, AWS and cloud-native security telemetry where data sources are integrated. This supports detection, investigation, response and assurance reporting.
Why is identity governance important for multi-cloud?
Identity governance keeps access aligned to business need by managing requests, approvals, role assignments, access reviews, leaver processes, privileged access and exceptions across cloud environments.
How do you reduce standing privilege in cloud landing zones?
Reduce standing privilege by using just-in-time activation, approval workflows, time-bound access, break-glass controls, access reviews and strong logging for administrator actions.
Need help shaping a multi-cloud IAM or landing zone security architecture?
I can help you map your Azure and AWS access model, strengthen Entra ID governance, reduce standing privilege, design workload identity patterns and turn cloud security controls into assurance-ready evidence.