The Governed AKS Migration Stack: 6 Control Layers and the Tools That Cover Each One

Key points

• A governed AKS migration needs six control layers, not one tool. (1) Provisioning-as-code with Terraform or Bicep, (2) admission-time policy with Azure Policy for AKS, Kyverno, or OPA Gatekeeper, (3) GitOps delivery with Flux v2 (shipped by Microsoft as a supported AKS cluster extension) or Argo CD, (4) backup and tested restore with Velero or Azure Backup for AKS, (5) identity and RBAC with Microsoft Entra ID plus Kubernetes RBAC, and (6) a developer-facing self-service layer.
• Assign guardrails before the first workload lands. Azure Policy for AKS supports Audit and Deny effects, and Azure landing zone guidance is to assign policy at the management group level before workloads deploy. Retrofitting policy onto running namespaces is where enterprise AKS migrations stall.
• Pick one primary policy engine. Azure Policy for AKS for subscription-wide governance and regulatory compliance dashboards (it is built on OPA Gatekeeper), Kyverno for YAML policies with mutation, generation, and Cosign image signature verification, OPA Gatekeeper directly only if you already standardize on Rego outside Kubernetes.
• Policy engines govern the cluster and GitOps governs how manifests reach it. Neither governs humans: who may create an environment, who may deploy to production, who approved it, and what idle non-prod costs you every night. That is a separate layer.
• Qovery is that developer-facing layer, not a policy engine. It runs inside your own Azure subscription (BYOC) on your own AKS cluster with per-environment RBAC, audited git-push deployments, preview environments per pull request, auto-stop for non-production, and managed cluster upgrades, and it works identically on AWS, GCP, Scaleway, or an existing Kubernetes cluster.

In hundreds of conversations with CTOs and platform leads, one mistake keeps repeating: compliance gets scheduled as a phase that starts after the migration. That sequencing is exactly why AKS migrations slip. McKinsey's research on cloud migration found that most programs run over budget and a meaningful share slip their timelines, and governance bolted on after cut-over is a large part of why. Build the guardrails first, and compliance becomes a property of the platform instead of a remediation backlog.

What does a "governed" AKS migration actually require on day one?

A governed AKS migration requires six control layers in place before the first production workload moves: provisioning-as-code (Terraform or Bicep), admission-time policy (Azure Policy for AKS, optionally with Kyverno or OPA Gatekeeper), GitOps-based auditable delivery (Flux v2 or Argo CD), tested backup and restore (Velero or Azure Backup for AKS), identity and RBAC (Microsoft Entra ID plus Kubernetes RBAC), and a developer self-service path. Miss one and compliance becomes a post-migration remediation project instead of something the platform enforces on its own.

Auditors keep asking for two artifacts that teams keep forgetting to produce. The first is proof of change control: who deployed what, when, and who approved it. The second is proof of a tested restore, not a configured backup, because a backup job that has never been restored is a hope, not a control.

Underneath the six layers sits the Azure baseline: management groups, Azure landing zones, Azure Policy initiatives, Microsoft Defender for Containers, and Azure Monitor with a Log Analytics retention window long enough to cover your control-plane audit logs. Assign that foundation at the management group level and every subscription below it inherits the same rules.

The sequencing rule is blunt: guardrails first, workloads second. Assign policy in Audit mode, read the violation report, fix what breaks, then flip to Deny. The failure mode I see most often is governance designed by the platform team and then quietly routed around by developers, because nobody built a self-service path and a ticket queue is slower than kubectl. The stakes are not theoretical either: Red Hat's 2024 State of Kubernetes Security report found 89% of respondents hit at least one container or Kubernetes security incident in the previous 12 months. The rest of this guide covers what each tool does, what it does not, and the order to install them.

Which Azure-native tools cover compliance and governance for AKS?

Microsoft ships most of the compliance primitives natively: Azure Policy for AKS for admission control, built-in regulatory compliance initiatives mapped to frameworks like CIS, ISO 27001, PCI DSS, and NIST SP 800-53, Microsoft Defender for Containers for image scanning and runtime detection, Flux v2 as a first-party GitOps extension, and Azure Backup for AKS for namespace-scoped restore. For infrastructure and cluster governance, Azure-native tooling is usually enough on its own.

Azure Policy for AKS extends Gatekeeper v3, the Open Policy Agent admission controller, installed as a managed cluster add-on. It supports Audit, Deny, and Mutate effects, and ships built-in initiatives including "Kubernetes cluster pod security baseline standards for Linux-based workloads" and the stricter "restricted standards" equivalent. Because it inherits Gatekeeper, you get admission control without operating Gatekeeper yourself.

The regulatory compliance initiatives are the part auditors care about. Azure Policy offers built-in initiatives for the CIS Microsoft Azure Foundations Benchmark, ISO 27001, PCI DSS 4.0, NIST SP 800-53 Rev. 5, and the Microsoft cloud security benchmark, and reports every assignment into a compliance dashboard. That dashboard is the auditor-ready evidence that replaces a spreadsheet of screenshots.

Defender for Containers adds agentless image vulnerability assessment for Azure Container Registry, benchmark-style hardening assessments, and runtime threat detection mapped to MITRE ATT&CK for Containers. It is billed per vCore-hour based on your worker-node vCores, so cost scales with cluster size rather than a flat fee.

For delivery, Flux v2 is a Microsoft-supported cluster extension for both AKS and Azure Arc-enabled Kubernetes, which means the same GitOps configuration can govern clusters that stay on-prem or on another cloud under one set of policy assignments. Argo CD has no equivalent first-party extension. You can run it, but you own the operation of it.

Azure Backup for AKS is a managed service built on Velero. It backs up cluster resources and persistent-volume snapshots at namespace granularity, with an operational (snapshot) tier in your own subscription and a vaulted tier for long-term, cross-region-capable copies. It is billed per protected instance, sized by the number of namespaces you back up.

The honest limit: Azure-native tooling governs the cluster well and gives developers nothing. There is no self-service deployment path, no environment lifecycle, and no per-environment approval flow in any of these services. That gap is real, and it is where the sixth layer earns its place.

Kyverno vs OPA Gatekeeper vs Azure Policy for AKS: which policy engine should you pick?

Start with Azure Policy for AKS, because it inherits your subscription-level governance and reports into the same compliance dashboard your auditors already read. Add Kyverno when you need YAML-native policies with mutation, resource generation, and Cosign image signature verification. Choose OPA Gatekeeper directly only if you already standardize on Rego across systems beyond Kubernetes.

The reason this ordering works: Azure Policy for AKS is itself built on Gatekeeper, so running Gatekeeper separately on the same cluster means two admission chains and often duplicated constraint templates. Keep Azure Policy as the corporate baseline, and if you need a second engine, pick one that adds capabilities rather than duplicating them.

That second engine is usually Kyverno, which graduated in the CNCF in March 2026. It writes policies as Kubernetes YAML instead of Rego, and it does three things Azure Policy does not do natively: mutate resources, generate resources (a default NetworkPolicy for every new namespace, for example), and verify container image signatures with Cosign. OPA Gatekeeper, part of the CNCF-graduated Open Policy Agent project, is the right pick when Rego is already your policy language elsewhere.

The split rule is simple: Azure Policy for AKS is the corporate baseline, Kyverno is team-level rules and mutation. A concrete starter set to enforce before cut-over:

• No privileged containers, and a read-only root filesystem where the workload tolerates it
• Required CPU and memory requests and limits on every pod
• Allowed container registries only (your ACR, not arbitrary public registries)
• Required cost-center and owner labels on every namespace
• No :latest image tags in production
• A NetworkPolicy required in every application namespace

One clarification, because it comes up in every review: Pod Security Admission is the built-in Kubernetes baseline that went GA in v1.25, the same release that removed PodSecurityPolicy. It enforces three fixed pod-security levels and nothing else. It is a floor, not a policy engine, and it does not replace Azure Policy or Kyverno.

How do you prove change control, approvals, and restore during an AKS audit?

You prove change control with GitOps plus platform-level audit logs, and you prove disaster recovery with a documented restore drill, not a backup schedule. Flux v2 or Argo CD turn every production change into a reviewed Git commit with a reconciliation record; Velero or Azure Backup for AKS produce restore evidence only once you have actually restored a namespace into a clean cluster and timed it.

The change-control evidence chain is a straight line: a pull request with required reviewers and branch protection, a Git commit SHA, a Flux or Argo reconciliation status showing that exact SHA applied, and an Azure control-plane audit log entry retained in Log Analytics. Any auditor can follow that chain from "who approved this" to "what actually ran."

The thing that breaks the chain is kubectl apply from a laptop. Close it by removing direct write access to production, mapping Microsoft Entra ID groups to Kubernetes RBAC roles, and keeping a break-glass account that fires an alert whenever it is used. If a human can change production without a commit, your audit trail has a hole in it.

Backups are the other half. Velero (a CNCF project with an official Azure plugin) is portable across clouds and gives you full control; Azure Backup for AKS is the managed, Velero-based option that stays inside Azure. Whichever you pick, the evidence is the same: restore into a fresh cluster, measure the RTO, verify data integrity, record the result, and repeat quarterly.

One standing obligation people forget: running an unsupported Kubernetes version is itself an audit finding. Each upstream minor version gets about 14 months of patch support (12 months plus 2 months of maintenance), and AKS gives roughly 12 months of community support per version, extended to about 24 months on the Premium tier's long-term support. A managed upgrade cadence is a compliance control, not just hygiene.

Where does an internal developer platform fit, and what does it not replace?

An internal developer platform sits above the cluster and governs the humans: who can create an environment, who can deploy to production, who approved it, and when idle non-prod shuts down. It does not replace Azure Policy for AKS, Kyverno, Flux, or Velero. Those enforce what may run inside the cluster; the IDP governs who ships and at what cost, and the two layers compose.

Azure-native tooling leaves three governance gaps open: environment lifecycle (spinning up and tearing down non-prod), per-environment RBAC and approvals (who can deploy to staging versus production), and non-production cost control. None of those are admission-time or delivery-time concerns, so no policy engine or GitOps controller addresses them.

Be honest about build-versus-buy here. Backstage gives you a developer portal, but you still build and own the deployment and RBAC backend behind it. Humanitec and Port focus on platform orchestration and portals. Qovery ships the deployment and environment layer itself, so there is no backend to assemble.

This is where Qovery fits, and it is worth being precise about what it is. Qovery runs inside your own Azure subscription under a bring-your-own-cloud model on your own AKS cluster, so the Azure bill, your reservations, your data residency, and your existing Azure Policy assignments all stay untouched. On top of that cluster it provides the developer-facing controls: git-push deployments with an audit trail, preview environments per pull request, auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.

Two things to state plainly. Qovery works identically on AWS, GCP, Scaleway, or an existing self-managed Kubernetes cluster through bring-your-own-Kubernetes, which matters because most enterprises are Azure-first, not Azure-only. And Qovery is not a policy engine, not a CNAPP, and not a replacement for Flux or Velero. It is the self-service layer that keeps developers from routing around the governance you just built.

In what order should you install these tools, and how long does a governed AKS migration take?

Install the stack in five phases over roughly three to six months for a mid-size enterprise estate: landing zone and policy in Audit mode first, then GitOps and RBAC, then backup with a real restore drill, then developer self-service, then flip policies to Deny and onboard teams. The order matters more than the calendar, because every phase produces the audit evidence the next phase depends on.

• Phase 1 - Foundation. Azure landing zone, management groups, Terraform or Bicep modules, Azure Policy initiatives assigned in Audit mode, Defender for Containers enabled.
• Phase 2 - Delivery and identity. Flux v2 or Argo CD bootstrapped, Entra ID groups mapped to Kubernetes RBAC, direct production write access removed.
• Phase 3 - Recoverability. Velero or Azure Backup for AKS configured, the first restore drill executed and timed, RTO and RPO documented.
• Phase 4 - Self-service. Environment templates, preview environments per pull request, auto-stop for non-prod, per-environment approvals.
• Phase 5 - Enforce and onboard. Review Audit violations, remediate, flip policies to Deny, onboard remaining teams, and set the Kubernetes upgrade cadence.

What actually slows these migrations is rarely the tooling. It is unresolved data residency questions, stateful workloads, network topology and private endpoints, and developers waiting on tickets. That last one compounds: Rafay's 2023 survey of platform teams and developers found 61% call environment provisioning a major roadblock to shipping. The payoff for closing it is well documented: DORA's 2019 State of DevOps report measured elite performers deploying 208 times more often, with 106 times faster lead times, than low performers.

The one-line rule I give every platform lead: give developers a self-service path before you flip policies to Deny, otherwise they will route around governance the first time a deploy is blocked with a deadline close.

The whole point of this order is that governance and developer speed stop fighting each other. Assign the guardrails first, give developers a self-service path second, and enforce Deny last, and your AKS migration lands governed from day one instead of remediated after the fact.

What platforms and tools help with a governed enterprise Kubernetes migration to Azure AKS?

Six layers, each with a canonical tool: Terraform or Bicep for provisioning, Azure Policy for AKS (optionally Kyverno or OPA Gatekeeper) for admission policy, Flux v2 or Argo CD for GitOps delivery, Velero or Azure Backup for AKS for backup and restore, Microsoft Entra ID with Kubernetes RBAC for identity, and an internal developer platform for self-service. Azure-native tooling covers the first five well; the sixth is a separate layer. Install them in that order, guardrails before workloads.

Is Azure Policy for AKS enough for compliance, or do I also need Kyverno or OPA Gatekeeper?

For most enterprises Azure Policy for AKS is enough to start, because it is built on OPA Gatekeeper and reports into the Azure compliance dashboard your auditors read. Add Kyverno when you need mutation, resource generation, or Cosign image signature verification, which Azure Policy does not do natively. Use OPA Gatekeeper directly only if Rego is already your policy language outside Kubernetes.

How do I prove change control and approval chains for AKS deployments during an audit?

Route every production change through GitOps with Flux v2 or Argo CD so each change is a reviewed Git commit with a reconciliation record, then retain the matching Azure control-plane audit logs in Log Analytics. Remove direct kubectl write access to production and map Entra ID groups to Kubernetes RBAC so no change happens off the record. The evidence chain runs from pull request to commit SHA to reconciliation status to audit log.

How do Velero and Azure Backup for AKS differ for disaster recovery compliance?

Velero is the portable, self-operated CNCF tool that works across clouds; Azure Backup for AKS is the managed service built on Velero that stays inside Azure and bills per protected instance. Both back up cluster resources and persistent-volume snapshots at namespace granularity. Neither is compliance evidence until you actually restore into a clean cluster and time the result.

Can I use an internal developer platform like Qovery on AKS without giving up Azure governance or data residency?

Yes. Qovery runs in your own Azure subscription under a bring-your-own-cloud model on your own AKS cluster, so the Azure bill, reservations, data residency, and existing Azure Policy assignments stay intact. It adds the developer-facing layer (self-service deployments, preview environments, per-environment RBAC, and auto-stop) without touching your admission policies or GitOps setup.

Does a governed AKS setup lock us into Azure if we later add AWS, GCP, or on-prem Kubernetes?

The Azure-native pieces (Azure Policy, Defender for Containers, Azure Backup for AKS) are Azure-specific, but the portable layers travel: Terraform, Flux v2, Kyverno, and Velero all run anywhere. Qovery also works identically on AWS, GCP, Scaleway, or an existing self-managed cluster, so the self-service layer is not Azure-bound even though your first cluster is.

How long does a governed enterprise AKS migration usually take, and what should happen first?

Plan on roughly three to six months for a mid-size estate, in five phases. Foundation comes first (landing zone, Terraform or Bicep, and Azure Policy in Audit mode) because every later phase depends on the evidence it produces. Flip policies to Deny only at the end, after developers have a working self-service path.