Azure Hybrid Reality: Where Arc + Identity Governance Pays Off

Hybrid cloud is not a strategy—it is a reality. Most organisations have workloads they cannot or will not move to the cloud: on-premises databases with latency-sensitive consumers, edge compute for manufacturing, legacy systems that would cost more to migrate than to operate. Azure Arc is Microsoft’s answer to managing these environments from a single control plane. The promise is compelling. The reality is more nuanced.

What Arc Does Well

Arc extends Azure’s management plane to non-Azure resources. Register an on-premises server or a Kubernetes cluster in another cloud, and it appears in the Azure portal alongside your native Azure resources. You get Azure Policy for compliance, Azure Monitor for observability, and Microsoft Defender for Cloud for security posture—applied consistently across environments.

For organisations already invested in Azure tooling, this is genuinely valuable. A single policy that enforces tag compliance, disk encryption, and endpoint protection across Azure VMs, AWS EC2 instances, and on-prem servers reduces the management overhead that hybrid environments create.

Where Arc Falls Short

Arc’s data services (SQL Managed Instance, PostgreSQL) running on Arc-enabled Kubernetes are still maturing. Performance tuning options are limited compared to native Azure services. Failover and backup are more manual. If you need production-grade managed databases, native Azure or the target cloud’s managed services remain the better choice.

The networking requirements catch teams off guard. Arc agents need outbound HTTPS to Azure endpoints. In air-gapped or restricted networks, proxying this traffic requires careful configuration. And the agent itself adds a dependency—if it loses connectivity, the resource falls out of compliance view until it reconnects.

Identity Governance: The Missing Piece

Hybrid environments amplify identity sprawl. Engineers have Active Directory accounts on-prem, Entra ID (Azure AD) accounts in the cloud, and possibly IAM users in AWS. Without governance, access accumulates: joiners get accounts, leavers keep them, role changes do not trigger permission reviews.

Entra ID Governance (formerly Azure AD Identity Governance) addresses this with access reviews, entitlement management, and lifecycle workflows. Quarterly access reviews force managers to confirm or revoke access. Entitlement management bundles permissions into packages that users request and approvers grant—with automatic expiry. Lifecycle workflows automate provisioning and deprovisioning when HR systems trigger joiner/leaver events.

Decision Framework

Adopt Arc when you have at least 20 non-Azure servers or clusters that need consistent policy and monitoring. Below that threshold, the operational overhead of managing Arc agents may exceed the management benefit. Invest in Entra ID Governance when your organisation exceeds 50 identities or operates in a regulated industry where access reviews are audited.

Implementation Notes

Start with inventory. Register non-Azure resources in Arc before applying policies—you need visibility before governance. Use resource groups to mirror your organisational structure (by team, by environment). Enable Azure Policy in audit mode first; switch to enforce after reviewing compliance reports for false positives.

For identity governance, begin with access reviews for privileged roles (Global Admin, Subscription Owner). Expand to application access once the review process is established. Configure Privileged Identity Management (PIM) for just-in-time access to sensitive roles—permanent standing access to admin roles is the hybrid equivalent of leaving the front door open.

Failure Modes

The biggest failure: deploying Arc without aligning on what “managed” means. If operations teams expect Arc to provide the same automation as native Azure (auto-patching, scaling, failover), they will be disappointed. Arc extends management, not capability. The underlying infrastructure is still your responsibility.

Identity governance fails when it is implemented as a compliance exercise rather than an operational practice. Quarterly reviews that rubber-stamp existing access do not reduce risk. Make reviews meaningful by including last-login data: if an account has not been used in 90 days, the default should be revocation.