Production-ready.
By design.

Compare AKS with Azure Container Apps, App Service, and other managed platforms against portability, orchestration, networking, team skills, operational cost, and compliance needs. Record the decision and the workload owner before provisioning a cluster.

Evaluate AKS Automatic for managed production defaults and Standard for infrastructure customization. Verify feature, region, networking, Windows, and operational constraints. Validate service-managed defaults rather than assuming either mode makes applications production-ready.

Review reliability, security, cost optimization, operational excellence, and performance efficiency using the AKS baseline architecture and Well-Architected guidance. Record design trade-offs, owners, residual risks, and evidence for each applicable control.

Define ownership for cluster configuration, workload patching, identities, data protection, upgrades, monitoring, incident response, and costs. AKS manages the control plane; customers still own application resilience, workload configuration, and service dependencies.

Place clusters in the intended management group, subscription, and network architecture. Define Azure Policy, resource naming and tags, budget ownership, data residency, and separation of production from nonproduction access and change paths.

For each applicable check, record an owner, evidence, status, and a time-bound remediation or risk acceptance. Priorities are review guidance, not a universal risk score. Explicitly mark nonapplicable items and revisit the assessment after major changes.

Prefer generally available supported features for production. Review preview terms, SLA exclusions, region and cloud availability, Kubernetes minimums, and exit plans before any approved exception. Feature names alone do not establish production support.

Integrate cluster sign-in with AKS-managed Microsoft Entra ID. Use group-based access, Conditional Access where applicable, and kubelogin; do not use the retired legacy Entra integration.

Choose Azure RBAC for Kubernetes authorization or Kubernetes RBAC with Microsoft Entra groups. Distinguish Azure management-plane roles from in-cluster data-plane permissions, avoid routine cluster-admin access, and test denied operations.

Grant the kubelet identity AcrPull for a non-ABAC registry. For an ABAC-enabled registry, assign Container Registry Repository Reader at the appropriate scope; --attach-acr is not supported in that permissions mode. Keep the ACR admin account disabled.

Use managed identities rather than service principals for the AKS control plane and kubelet. Scope permissions separately; workloads must use their own federated identities, not inherit node permissions.

To limit who can get that Kubernetes configuration (kubeconfig) information and to limit the permissions they then have, you can use Azure role-based access control (Azure RBAC).

Use the supported kubelogin authentication flow for Microsoft Entra-integrated clusters. Prefer workload identity federation or managed identity for CI/CD instead of long-lived client secrets, and validate noninteractive access from the deployment runner.

Disable local Kubernetes accounts on Microsoft Entra-integrated clusters. Document an audited emergency-access procedure, restrict who can change the setting, and rotate previously issued cluster certificates where required.

Use Microsoft Entra Privileged Identity Management for eligible group or Azure role assignments. Require approval and MFA for privileged operations, log activation, and test access expiry.

Use a pre-created user-assigned kubelet identity when permissions must exist before cluster creation. Grant only the registry and infrastructure access it needs; account for role-assignment propagation delays.

Evaluate Microsoft Entra Conditional Access for administrators, including MFA and device requirements. Test the chosen kubelogin flow and document separate controls for workload and automation identities.

Map controls to the current regulatory standard, such as PCI DSS 4.x, and validate the AKS shared-responsibility model. Use supported FIPS-enabled images where mandated; an architecture example or Azure certification does not itself make an application compliant.

AKS encrypts data at rest using platform protection. If customer-managed keys are required, assess supported KMS options and Key Vault availability, permissions, purge protection, rotation, and recovery. The newer KMS data-encryption experience is documented as preview; do not treat it as a production default.

Distinguish legacy etcd KMS from the newer KMS data-encryption configuration. Check Kubernetes version, regional availability, and support status before enabling either; loss of a required key can make encrypted secrets unrecoverable.

Scan images in CI and continuously in the registry. Enforce approved registries, digest-based releases, and risk policy through supported admission controls. Verify the support status and actual enforcement of any vulnerability-aware integration, define time-bound exceptions with owners, and do not assume that registry scanning alone blocks deployment.

Use the AKS Azure Key Vault provider with Microsoft Entra Workload ID. Enable rotation where required and test that applications reload mounted secrets. Environment variables do not automatically refresh; synchronizing to a Kubernetes Secret creates an additional stored copy.

Review Defender for Cloud recommendations and assign remediation owners. Connect security posture to Azure Policy and your incident workflow; distinguish posture assessment from the paid Defender for Containers runtime protection plan.

Evaluate AKS Image Cleaner for unused images on nodes. It does not patch images or remove vulnerable containers that are currently running: rebuild the image and redeploy affected workloads to remediate those risks.

Microsoft Defender for Containers provides protections for your Kubernetes clusters wherever they're running (AKS and on-premises)

Azure Policy integrates with the Azure Kubernetes Service (AKS) to apply at-scale enforcements and safeguards on your clusters in a centralized, consistent manner.

In AKS Standard, dedicate appropriately sized Linux system pools to critical cluster components and run applications on user pools. Use the CriticalAddonsOnly taint where appropriate and provide production redundancy. System pools are not the managed control plane.

Migrate cluster infrastructure to managed identities. Where a legacy service principal remains, rotate credentials before expiry under an audited policy and test the change; a fixed quarterly interval alone does not manage credential risk.

Azure Container Registry allows you to build, store, and manage container images and artifacts in a private registry

Run supported CIS-aligned configuration assessments and review drift in RBAC, network exposure, admission policy, and workload permissions. Record accepted risks and remediation dates rather than treating an assessment score as proof of compliance.

Evaluate the supported AKS confidential-computing options against your workload and compliance needs. Distinguish application enclaves from confidential virtual machines and confidential containers; verify SKU, region, attestation, OS, and feature support rather than assuming every container automatically runs inside an enclave.

Plan for multi-tenant clusters and separation of resources and use logical or physical isolation in your AKS clusters

Use Azure Dedicated Hosts when dedicated physical capacity is required and supported for the node configuration. Plan host capacity, failure domains, maintenance, and additional cost; this does not remove application-level security responsibilities.

Apply Pod Security Admission or equivalent Azure Policy controls. Progress from audit to enforcement; for Linux workloads prefer restricted settings, non-root users, seccomp RuntimeDefault, dropped capabilities, read-only filesystems, and no privilege escalation. Document narrowly scoped exceptions.

Minimize node managed-identity permissions and use federated workload identities. AKS IMDS restriction is documented as preview, applies to non-host-network pods, and requires assessment of support terms and compatibility. Do not assume a generic NetworkPolicy blocks all metadata or host-network access.

Combine namespaces, scoped RBAC, resource quotas, admission policy, and network policies for trusted tenants. A namespace alone is not a security boundary and does not isolate cluster-scoped resources or a shared kernel.

Choose separate clusters or subscriptions where tenants are untrusted, compliance demands stronger isolation, or lifecycle and blast-radius requirements differ. Balance operational cost against the risk of a shared control plane and nodes.

With Azure Kubernetes Service (AKS), you can set Azure tags on an AKS cluster and its related resources by using Azure Resource Manager, through the Azure CLI.

Prefer Azure CNI Overlay for efficient address use, or Azure CNI Pod Subnet when directly routable pod addresses are required. Validate OS and policy-engine compatibility. Kubenet is a legacy model retiring on 31 March 2028; do not select it for new deployments.

Size address space for the actual network model, maximum nodes, maxPods, scale-out, and concurrent surge upgrades. Overlay separates pod and node address space; flat networking consumes VNet pod addresses. Include private endpoints, load balancers, peering, and future growth.

Use a supported ingress or Gateway API implementation for HTTP routing, TLS, and policy. Upstream Ingress NGINX maintenance ended in March 2026; AKS application routing NGINX critical-security-patch support runs through November 2026. Evaluate application routing Gateway API, Application Gateway for Containers, or Istio ingress against feature and support requirements.

Choose a supported WAF architecture, such as Azure Front Door Premium or Application Gateway WAF, when required by the threat model. Tune managed rules, restrict origin access, validate TLS and health probes, and test that the origin cannot bypass the WAF.

Constrain approved hostnames, cross-namespace references, and who can attach routes to shared gateways. Use admission controls and Gateway API allowedRoutes/ReferenceGrant rules as appropriate; test that tenants cannot claim another application hostname.

Use internal load balancers for private services and public endpoints only for intentional internet-facing applications. An internal load balancer still needs authentication, network controls, DNS, and a tested access path.

Apply and test ingress and egress policies with explicit DNS and dependency allowances. Azure CNI Powered by Cilium is recommended for supported Linux configurations; validate Windows support separately. A configured policy engine without effective policies does not isolate workloads.

Start by creating a deny all policy in each namespace and then add specific policies.

Use Azure Firewall to secure and control all egress traffic going outside of the cluster.

When possible, use private link to only allow private network to reach your registry.

Explicitly test access to 169.254.169.254 and host-network workloads from ordinary application pods. Network policy behavior depends on the data plane and host-network semantics. AKS IMDS restriction is documented as preview and does not restrict host-network pods; assess support terms before adoption and minimize node identity permissions.

In a private cluster, the control plane or API server has internal IP addresses and is not exposed to Internet

Plan private DNS and an approved network path for administrators and deployment runners, such as a connected management host, VPN, or ExpressRoute. Azure Bastion provides access to a management VM rather than acting as a direct Kubernetes API proxy. Review command invoke permissions separately because that management-plane path can reach a private cluster without direct client network connectivity.

Use Azure Front Door for global HTTP(S) edge routing and WAF integration, or Traffic Manager for DNS-based routing of supported endpoints. Configure health checks, TLS, DNS TTLs, origin restrictions, and failover tests; neither service automatically replicates application state.

Check the default and supported maximum pod density for the actual OS, network model, VM size, and provisioning method. Do not assume a universal default of 30. Account for DaemonSets, system reservations, IP capacity, and storage attachment limits.

To improve the security of your clusters and minimize the risk of attacks, we recommend limiting the IP address ranges that can access the API server.

Choose a supported outboundType such as NAT gateway, load balancer, or user-defined routing based on throughput and inspection requirements. Size SNAT capacity and allow AKS dependencies. NAT Gateway is not a firewall; private clusters still need an explicit egress plan.

For VNet-routable pod IPs, evaluate Azure CNI Pod Subnet dynamic or static block allocation against supported features and scale limits. Plan separate node and pod subnet capacity; use Overlay when direct pod reachability is not required.

For PaaS dependencies, select private endpoints or supported service endpoints based on service capability and trust boundaries. Configure private DNS and public-access restrictions explicitly; a private AKS API endpoint does not make workload dependencies private.

Evaluate a supported mesh, such as the AKS Istio add-on, when service identity, mutual TLS, traffic policy, or detailed telemetry justify its operational cost. Validate supported revisions, upgrades, resource overhead, and failure behavior; a mesh is not a prerequisite for every microservice application.

Use bring-your-own CNI only when its capabilities are necessary and the team can operate and support it. Review AKS support boundaries, Kubernetes and OS compatibility, IPAM, policy enforcement, upgrades, and recovery; Azure does not operate a third-party CNI on your behalf.

Evaluate separate node-pool subnets for address-space organization, routing, or security requirements. Validate support for the selected Azure CNI mode and subnet delegation, private DNS, and policy behavior; subnet separation alone is not tenant isolation.

Validate service, pod, node-subnet, peered-VNet, VPN, and on-premises address ranges before deployment. Apply the rules of the selected network model, including Overlay routing and masquerading behavior, and test reachability to all dependencies. Address conflicts can make destinations unreachable.

Test cluster DNS, upstream DNS, private endpoints, and cross-network name resolution from pods and deployment runners. Monitor DNS latency and failures, scale CoreDNS when needed, and evaluate LocalDNS only against current feature availability and workload requirements.

Use the supported managed Cilium data plane for compatible Linux workloads. Validate NetworkPolicy behavior and migration constraints; advanced L7, FQDN, and observability features can require Advanced Container Networking Services and additional cost.

Inventory external and internal certificates, automate issuance and renewal through a supported integration, and alert before expiry. Validate trust chains, TLS policy, secret rotation, and application reload behavior without relying on manual certificate replacement.

Choose Azure Disk, Azure Files, object storage, or an external data service based on latency, throughput, IOPS, concurrent access, consistency, backup, and recovery requirements. Validate the selected CSI driver and storage tier under realistic load.

Each node size supports a maximum number of disks. Different node sizes also provide different amounts of local storage and network bandwidth. Plan for your application demands to deploy the appropriate size of nodes.

Different types and sizes of nodes are available. Each node (underlying VM) size provides a different amount of core resources such as CPU and memory. These VM sizes have a maximum number of disks that can be attached. Storage performance also varies between VM sizes for the maximum local and attached disk IOPS (input/output operations per second). If your applications require Azure Disks as their storage solution, plan for and choose an appropriate node VM size. The amount of CPU and memory isn't the only factor when you choose a VM size. The storage capabilities are also important.

Use supported CSI drivers and dynamic provisioning where appropriate. Set access modes, expansion, binding mode, encryption, and Delete versus Retain reclaim policy deliberately; deleting a PVC can delete the underlying volume under a Delete policy.

Use Azure Backup for AKS or another supported, workload-aware backup solution. Confirm supported volume types, access modes, region, retention, and restore paths. Azure Site Recovery is not a general AKS cluster backup solution; snapshots alone may not be application-consistent.

Where possible, don't store service state inside the container. Instead, use an Azure platform as a service (PaaS) that supports multiregion replication.

Service state refers to the in-memory or on-disk data that a service requires to function. State includes the data structures and member variables that the service reads and writes. Depending on how the service is architected, the state might also include files or other resources that are stored on the disk. For example, the state might include the files a database uses to store data and transaction logs.

Evaluate ephemeral OS disks for supported VM sizes and node-image requirements. Local OS-disk data is disposable across reimage or node replacement; keep durable workload data on persistent storage or external services and validate capacity for images and logs.

Azure ultra disks offer high throughput, high IOPS, and consistent low latency disk storage for your stateful applications.

One major benefit of ultra disks is the ability to dynamically change the performance of the SSD along with your workloads without the need to restart your agent nodes. Ultra disks are suited for data-intensive workloads.

Use WaitForFirstConsumer where appropriate so volume provisioning follows scheduling constraints. LRS disks are zonal; evaluate supported ZRS disks for cross-zone attachment requirements. Test failover and attach times, because a replicated disk alone does not guarantee application availability.

Size managed OS disks and node storage for image layers, writable layers, temporary files, and logs. Monitor disk pressure and log rotation. Larger disk size alone is not a universal performance fix; validate the selected disk tier and VM I/O limits.

Inventory PVs, StorageClasses, and automation for in-tree Azure Disk and Azure File provisioners. Use supported CSI drivers, test snapshots and restores, and review migration behavior before a Kubernetes upgrade.

Virtual nodes use Azure Container Instances and have different networking, identity, storage, OS, and feature constraints from regular AKS nodes. Verify the current support matrix, cold-start behavior, regional quota, and cost before adopting this burst path.

Choose node sizes and counts using CPU, memory, pod density, network throughput, storage limits, and failure-domain needs. Reserve capacity for system components and upgrades, and benchmark cost and latency rather than optimizing only VM price.

Benchmark supported Arm64 VM sizes for price/performance. Publish multi-architecture images and verify every sidecar, DaemonSet, driver, and security agent supports the target architecture before scheduling workloads there.

Plan and apply resource quotas at the namespace level. If pods don't define resource requests and limits, reject the deployment. Monitor resource usage and adjust quotas as needed.

Resource requests and limits are placed in the pod specification. These limits are used by the Kubernetes scheduler at deployment time to find an available node in the cluster. But developers can forget them and thus impact other applications by over-consuming resources of the cluster

A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace. It's useful to ensure that pods don't forget to declare request limits

Set CPU and memory requests based on observed demand; requests drive scheduling and autoscaling. Set memory limits to bound risk and choose CPU limits deliberately because throttling can increase latency. Limits do not prevent memory leaks, and containers exceeding memory limits can be OOM-killed.

Use policy/v1 PodDisruptionBudgets for replicated workloads and ensure replicas can satisfy them during drains and upgrades. PDBs constrain voluntary evictions, not node failures or every rollout; overly strict budgets can block upgrades and scale-down.

Use AKS cost analysis, OpenCost, or an appropriately operated cost-allocation tool to attribute spend to teams and workloads. Account for shared capacity, storage, networking, and monitoring costs; validate labels and allocation assumptions.

Nvidia's A100 GPU can be divided in up to seven independent instances. Each instance has their own memory and Stream Multiprocessor (SM).

Your AKS workloads may not need to run continuously, for example a development cluster that has node pools running specific workloads.

Node pool snapshots capture supported node pool configuration for reuse. They do not back up application data, Kubernetes resources, or an entire cluster; ensure the referenced Kubernetes version and image remain supported.

Azure VMs/nodes have quotas per subscription. Ensure that you have planned for these quota and proactively prepare to request for more if needed

Scale-down Mode allows you to decide whether you would like to delete or deallocate the nodes in your Azure Kubernetes Service (AKS) cluster upon scaling down.

Evaluate node auto-provisioning for supported workloads and regions, or configure the cluster autoscaler for explicit node pools. Respect coexistence restrictions, quota, disruption settings, consolidation behavior, and capacity limits; do not enable competing node scalers blindly.

Set realistic requests, min/max replicas, stabilization windows, and metric availability. Avoid competing controllers for the same resource signal. Use VPA recommendations or supported update modes deliberately and load-test burst and scale-to-zero behavior.

Benchmark before using proximity placement groups. Review compatibility with availability zones, capacity, and node-pool constraints; tighter placement can reduce placement flexibility and resilience. Do not trade away failure-domain separation without a documented reason.

Inventory installed extensions and add-ons, their supported Kubernetes versions, permissions, upgrade policies, costs, and operational owners. Remove unused components and validate lifecycle compatibility before upgrades.

Set a node resource group name if required by naming policy, and document AKS ownership. Its name is not a security control; protect access and avoid manually modifying AKS-managed infrastructure.

Keep node SSH/RDP endpoints off the public internet. Use supported AKS debug access or approved private management connectivity with time-bound permissions, audit logs, and incident ownership. Do not expose nodes merely to make troubleshooting easier.

Use AKS diagnostics, Azure Monitor, and maintained troubleshooting tools. Validate tool provenance and permissions before execution. Use policy and manifest validation to detect missing requests and limits; do not install an unmaintained scanner as a production prerequisite.

To keep up with application demands in Azure Kubernetes Service (AKS), you may need to adjust the number of nodes that run your workloads. The cluster autoscaler component can watch for pods in your cluster that can't be scheduled because of resource constraints.

You can enable autoscaling module per node pool but only create one mutual autoscale profile

GitOps works by using Git as a single source of truth for declarative infrastructure and applications

On Azure you can for instance use Azure Arc for Kubernetes but also directly GitOps addon for AKS

Instead of GitOps (or in addition) you can use CI/CD to deploy workloads/tools in your cluster

The Kubernetes ecosystem is strengthened by many tools that make operating it easier. Here's a few

It's recommended to keep all applications in a namespace other than default

A common set of labels allows tools to work interoperably, describing objects in a common manner that all tools can understand. For instance, resources should have technical, business and security labels.

Customizing your node configuration allows you to configure or tune your operating system (OS) settings, node pools or the kubelet parameters to match the needs of the workloads.

When you create an AKS cluster or add a node pool to your cluster, you can customize a subset of commonly used OS and kubelet settings.

AKS command invoke runs through the Azure management API and can reach a private cluster without direct network connectivity. Restrict its Azure RBAC actions, audit use, and disable it when policy requires all administration through approved private paths.

Optimizing node size can lead to lots of benefits including cost optimization, optimized performance and proper resource allocation

Azure advisor can enhance environment monitoring and can help improve the operations of your cluster by reducing costs, etc

There are various tools that can make creating k8s manifest files much easier and can help with operational efficiency

Understand AKS-managed certificate rotation and monitor cluster health and certificate expiry. Use the documented certificate rotation procedure when necessary and assess its disruption. Workload ingress certificates need a separate renewal process.

If using ACI-backed virtual nodes, validate monitoring, security policy, service connectivity, storage, scheduling, and application recovery end to end. Do not assume virtual nodes are equivalent to ordinary VM-backed node pools.

Spot nodepools can help with cost management

AKS emits certain events that enable it to subscribe to EventGrid which can be used for automation

Manage nodes through supported AKS APIs and infrastructure as code, not by manually editing VM scale sets, load balancers, or networking in the node resource group. Evaluate node resource group lockdown and restrict unnecessary write access.

Document diagnostics, ephemeral debug containers, log access, escalation contacts, and time-bound privileged access. Use approved images and audit actions; do not permanently install privileged debugging toolboxes across production nodes.

Before upgrading, validate regional VM quota, subnet IP space, maxSurge, PDBs, drain timeout, soak time, and deprecated APIs. Rehearse workload rollback or cluster replacement; Kubernetes control-plane downgrades are not a supported rollback strategy.

Pin supported resource-provider API versions and provider/module versions. Review plan or what-if output, apply changes through code review, and detect drift. Use deployment identities scoped to the environment rather than persistent cluster-admin credentials.

Select a supported Ubuntu or Azure Linux release after testing drivers, agents, and application dependencies. Azure Linux 2.0 support ended on 30 November 2025 and its node images were removed starting 31 March 2026; migrate to Azure Linux 3.0 or another supported OS.

Track the AKS release calendar and the versions available in each deployment region with az aks get-versions. Standard support follows the supported minor-version window; eligible LTS versions require the Premium tier. Platform support is reduced support, not a substitute for an upgrade plan.

Choose a supported node OS upgrade channel, such as NodeImage, and test it with a dedicated maintenance window. Node OS upgrades and cluster version upgrades are separate controls. Track image rollout availability, disruption budgets, surge capacity, and completion.

Select a supported cluster auto-upgrade channel and planned maintenance windows with enough duration. Validate application compatibility in lower environments first. Maintenance windows are not an absolute guarantee that every emergency platform action is deferred.

Use AKS Premium tier with the AKSLongTermSupport plan for eligible versions when extended support is required. Check the published support end date and OS/add-on compatibility; LTS does not extend an independently retired node OS or remove the need for patches and upgrades.

The open-source pod-managed identity project was deprecated in 2022 and archived in 2023; AKS managed add-on patch support ended in September 2025. Migrate applications and SDKs to Microsoft Entra Workload ID, test token refresh, then remove obsolete identity bindings and components.

AKS support for Basic Load Balancer and Availability Sets ended on 30 September 2025. Follow the documented migration paths to Standard Load Balancer and supported node-pool infrastructure; validate public IPs, DNS, routes, downtime, and recovery.

AKS kubenet retirement is scheduled for 31 March 2028. Inventory affected clusters, validate the supported migration path to Azure CNI Overlay, and rehearse changes to pod addressing, network policies, routes, and external dependencies.

Upstream Ingress NGINX maintenance ended in March 2026, and AKS application routing NGINX critical-security-patch support runs through November 2026. Test a supported Gateway API replacement in parallel, translate annotations and policy, validate TLS and traffic behavior, and plan DNS cutover and rollback.

Subscribe to AKS releases, retirement notices, Service Health, and the regional release tracker. Microsoft documents platform-initiated upgrades beginning 1 June 2027 after the unsupported-version grace period; these do not follow your maintenance window. Keep clusters supported rather than relying on that safeguard.

Enable Container insights or a supported log platform with an explicit data collection rule. Define namespace filters, sensitive-data handling, retention, access control, and a cost budget. Confirm that logs are queryable during node and application failure.

Use Azure Monitor managed service for Prometheus or an operated Prometheus deployment. Configure scraping, recording and alerting rules, cardinality limits, retention, and Grafana dashboards. Container log collection is separate from Prometheus metric ingestion.

Choose propagation standards, instrumentation ownership, sampling, retention, and sensitive-data controls for distributed traces. Verify that representative requests can be correlated across services and dependencies before relying on tracing in an incident.

With Container insights, you can use the performance charts and health status to monitor the workload of Kubernetes clusters hosted on AKS

Configure AKS diagnostic settings for the required control-plane and audit categories. Choose audit versus audit-admin deliberately, route logs to an approved destination, and validate access, retention, query availability, and collection costs.

Provide documented queries and dashboards for application failures, restarts, and dependency issues. Use supported Container insights or another operated platform, define retention and access controls, and verify diagnostic data is available during an incident.

Migrate legacy ContainerLog collection and the retired Log Analytics agent to supported Container insights collection using Azure Monitor Agent and ContainerLogV2. Validate queries, alerts, data collection rules, multiline logging, retention, and ingestion costs.

Alerts can provide early warnings of issues, etc in your cluster

Monitor SNAT utilization, dropped connections, and outbound failure rates for the actual egress path. Tune connection reuse, idle timeouts, outbound IPs, and NAT gateway capacity; SNAT monitoring is primarily an availability and capacity control, not a replacement for egress filtering.

Learn how to troubleshoot resource health issues

Measure user-visible availability and latency, set service objectives, and page on actionable symptoms or error-budget burn. Include pending pods, failed scheduling, persistent-volume attachment, DNS, certificate expiry, and failed upgrades in platform alerts.

Maintain dashboards, runbooks, escalation paths, audit-log access, and diagnostic retention for the investigation window. Run an incident exercise and verify alerts reach an accountable responder. Protect logs from leaking secrets and excessive collection costs.

Instrument application request paths with OpenTelemetry or a supported Application Insights integration. Preserve correlation IDs, control sampling and cardinality, and validate that dependency failures can be traced across service boundaries without exposing sensitive data.

Before going to production, it is very important to decide the target of availability and recovery time you are looking for. This will help you to decide the right backup strategy but also the architecture of your solution.

Regularly rebuild the platform from infrastructure as code in an isolated recovery environment. Restore application configuration and data, measure RTO/RPO, and test dependencies and access. Never delete production merely to conduct a recovery rehearsal.

Use supported zonal node pools and topology spread constraints to separate replicas across nodes and zones. Validate sufficient surviving capacity, zonal storage behavior, load balancing, and failure recovery; availability zones are separate datacenter failure domains within a region.

Choose active-active or active-passive regions based on RTO/RPO, data residency, latency, dependencies, and available capacity. Regions need not be an Azure region pair; validate service support, replication, quota, and independence explicitly.

Select Front Door or Traffic Manager according to protocol and routing needs. Test health probes, DNS caching, TLS, session behavior, regional dependencies, and failback. Routing changes do not recover or synchronize application data.

Your applications might use Azure Storage for their data. Because your applications are spread across multiple AKS clusters in different regions, you need to keep the storage synchronized

Use Standard or Premium tier for the financially backed Kubernetes API-server uptime SLA. Microsoft documents 99.95% with availability zones and 99.9% without; Free tier has no financially backed SLA. These are control-plane commitments, not an end-to-end application SLA; verify current contractual terms.

Use topology spread constraints or appropriate anti-affinity to keep replicas in separate failure domains. Balance strict scheduling rules against available recovery capacity, and test both node loss and zone loss under representative load.

Companies that want a local presence, or a hot backup, choose to run services from multiple Azure regions.

As a best practice, placing a container registry in each region where images are run allows network-close operations, enabling fast, reliable image layer transfers. Geo-replication enables an Azure container registry to function as a single registry, serving multiple regions with multi-master regional registries.

Use Azure availability zones to create a resilient and high availability Azure container registry within an Azure region.

Because container registries are resources that are used across multiple container hosts, a registry should reside in its own resource group.

Although you might experiment with a specific host type, such as Azure Container Instances, you’ll likely want to delete the container instance when you’re done. However, you might also want to keep the collection of images you pushed to Azure Container Registry. By placing your registry in its own resource group, you minimize the risk of accidentally deleting the collection of images in the registry when you delete the container instance resource group.

Where supported, evaluate ACR soft delete to recover accidentally deleted artifacts within the configured retention period. Check current feature status, limitations, and costs; soft delete does not replace immutable release retention, replication, or tested disaster recovery.

Configure Azure Backup for AKS or a supported alternative with explicit scope, retention, and recovery objectives. Check the current support matrix for Azure Disk/Azure Files, snapshot versus vaulted backup, regions, and cross-region restore. Back up external databases separately.

Perform full restore drills, including identities, CRDs, secrets, application dependencies, and data consistency. A successful backup job does not prove that the application can be recovered.

Rehearse pod, node, zone, DNS, registry, egress, and dependency failures in a controlled environment. Use fault injection only with explicit scope and safety controls, verify service objectives, and track remediation actions from each exercise.

Validate the supported Windows host/container compatibility matrix. Windows Server 2019 node-pool support ended on 1 March 2026 and images are scheduled for removal on 1 April 2027. Migrate to a supported LTSC release such as Windows Server 2022 or 2025 after compatibility testing.

Test SIGTERM-equivalent Windows shutdown behavior, preStop hooks, terminationGracePeriodSeconds, and actual application cleanup on supported Windows images. Avoid blanket claims that graceful termination is unavailable; design for abrupt failure and verify behavior during upgrades.

Run applications as a non-administrative identity where supported. Windows does not use Linux privileged-container semantics, but HostProcess containers can access the host and require tightly restricted admission, identities, and namespaces.

Size Windows nodes and container memory using measured working sets and system reservations. Validate eviction and OOM behavior for the actual Windows/runtime version, alert on pressure, and test recovery rather than assuming Linux memory-management behavior.

Use a Windows-supported Azure CNI configuration, including Overlay where supported for the selected versions. Kubenet and the Linux Cilium data plane are not Windows networking options. Validate policy-engine and IPAM support before provisioning.

Windows Server nodes in AKS must be upgraded to get the latest patch fixes and updates. Windows Updates are not enabled on nodes in AKS. AKS releases new node pool images as soon as patches are available, it is the customers responsibility to upgrade node pools to stay current on patches and hotfix.

Do not assume Linux and Windows share the same network policy capabilities. Azure NPM on Windows is unsupported from 30 September 2026; select a supported alternative such as Calico after validating the exact OS, network model, and version matrix.

Group Managed Service Accounts (GMSA) is a managed domain account for multiple servers that provides automatic password management, simplified service principal name (SPN) management and the ability to delegate the management to other administrators.

HostProcess / Privileged containers extend the Windows container model to enable a wider range of Kubernetes cluster management scenarios.

Adding taints, tolerations and node selectors will help avoid having pods scheduled in the wrong OS node pool

Inventory Windows pools using Azure Network Policy Manager, whose AKS Windows support ended on 30 September 2026. Follow supported migration guidance and test positive and negative connectivity cases with the replacement engine.

Select a supported Windows VM size and verify accelerated networking availability and actual enablement. Benchmark throughput and latency, and include driver and node-image compatibility in upgrade testing.

Windows Server Annual Channel preview support ended on 15 May 2026, with image removal scheduled for 15 May 2027. Windows Server 2022 AKS support is scheduled to end on 30 June 2028, with image removal on 30 June 2029. Plan LTSC migration against current version and OS support matrices.

Use a liveness probe only when restarting the container can resolve a failure. Avoid coupling liveness to a shared downstream dependency, which can trigger restart storms during an outage. Test thresholds under load.

Configure a startup probe with a failure budget covering the measured worst-case startup. Liveness and readiness probes do not run until the startup probe succeeds; test image pulls and cold initialization separately.

Sometimes, applications are temporarily unable to serve traffic. For example, an application might need to load large data or configuration files during startup, or depend on external services after startup. In such cases, you don't want to kill the application, but you don't want to send it requests either. Kubernetes provides readiness probes to detect and mitigate these situations. A pod with containers reporting that they are not ready does not receive traffic through Kubernetes Services.

Handle termination signals, configure terminationGracePeriodSeconds, and use preStop only where needed. Allow in-flight requests to drain and test rolling updates and node drains. Hooks are not guaranteed during every failure, so persist critical state safely.

Use multiple replicas for services that require high availability, and spread them across nodes and zones. Test that the remaining replicas can serve peak demand during failure or maintenance; replica count alone does not establish resilience.

Ensure that your components are tagged, it could be business, security or technical tags and these tags will help to assess or apply relevant policies.

Configure HPA or KEDA with appropriate metrics, requests, replica bounds, and stabilization windows. Test metric outages, burst traffic, dependency limits, and scale-down; ensure node scaling and regional capacity can satisfy demand.

Store application secrets in Key Vault and retrieve them with a supported integration and least-privilege identity. AKS provides encryption at rest, but Kubernetes Secrets are still accessible to authorized API clients and are not an external vault. Never commit secrets to source or bake them into images.

Enable the OIDC issuer and Workload ID, then federate a dedicated Kubernetes service account to a least-privilege managed identity. Use supported SDKs and the required workload identity label. Replace the retired pod-managed identity add-on; do not give applications node identity permissions.

Use dedicated namespaces for workloads and apply scoped RBAC, quotas, and network/admission policy. Avoid deploying applications into default or system namespaces. Namespaces provide logical separation, not a complete security boundary.

When Containers have resource requests specified, the scheduler can make better decisions about which nodes to place Pods on. And when Containers have their limits specified, contention for resources on a node can be handled in a specified manner.

Use platform-appropriate least-privilege settings. For Linux, prefer non-root, RuntimeDefault seccomp, dropped capabilities, no privilege escalation, and a read-only root filesystem. Disable automatic service account token mounting where the workload does not need it; validate projected tokens required by Workload ID.

Best practices inside the cluster start with the configuration of your manifests. Ensure that they respect good practices

Validate base-image provenance, pinned versions, non-root execution where supported, build secrets, dependency installation, and unnecessary packages. Use maintained linters and policy checks without exposing build credentials in layers or logs.

Scan OS packages and application dependencies during image builds with maintained tools. Retain reports linked to immutable digests, define remediation targets, and rescan deployed versions as new vulnerabilities are disclosed.

Define policy using exploitability, exposure, severity, and available fixes. Block unacceptable risk, record owners and expiry for exceptions, and rescan continuously. An unfixed critical vulnerability is not automatically acceptable simply because the vendor has not published a fix.

Validate approved base images, non-root execution where supported, exposed services, secret handling, and required labels. Apply rules based on the threat model; opening port 80 alone is not proof of noncompliance.

Validate runtime support, licensing, state, external dependencies, health probes, and operational ownership before moving an application to AKS. Choose supported migration tooling based on the workload rather than assuming a point-and-containerize conversion produces a production-ready service.

There are a variety of techniques to deploy new applications to production so choosing the right strategy is an important decision that needs to be made to leverage the impact of change on the consumer.

Manage long-running applications through Deployments or StatefulSets, and finite work through Jobs or CronJobs. A standalone pod is not recreated after node loss by a workload controller; test replacement and application recovery.

Use immutable digests for reproducible deployments and choose imagePullPolicy deliberately. Always checks registry resolution but can reuse cached layers; IfNotPresent reuses cached images. Do not rely on mutable latest tags, and test registry failure behavior.

Use Bicep, ARM templates, or Terraform modules with pinned versions, environment-specific configuration, least-privilege deployment identities, and reviewed changes. Keep state protected, detect drift, and rehearse rebuilding the platform.

This will help ensure your workloads remain online during cluster upgrades.

Dapr can provide service invocation, pub/sub, state management, and other distributed application APIs. Adopt it when those capabilities justify additional sidecars, control-plane components, security configuration, and lifecycle management; it is not an upgrade-availability mechanism.

Check release notes, API-server warnings, manifests, CRDs, Helm charts, operators, and admission webhooks for APIs removed in the target version. Upgrade dependencies first and test conversion and rollback paths in a representative environment.

Use OIDC federation from the CI platform to Azure, protect release environments, pin reviewed actions and build dependencies, and scope deployment identities to the required namespaces and resources. Keep production credentials and kubeconfig files out of logs and artifacts.

Scan operating-system packages and application dependencies in container images during build and continuously after publication. Triage findings using exploitability and exposure, enforce remediation targets, and verify deployed image digests. A clean scan does not prove that an image is free of vulnerabilities.

One of the most common custom policies that you might want to consider is to restrict the images that can be deployed in your cluster. But it can also be addressed with a proper egress lockdown or using an admission controller

Enable supported runtime threat detection, such as Microsoft Defender for Containers, and route alerts into incident response. Validate required sensors and permissions, investigate suspicious process and network activity, and rehearse containment without assuming a sensor prevents every attack.

Continuously rescan stored images and block release promotion or admission when they violate approved risk policy. Verify that quarantine tooling is supported and enforced by every pull path; a registry scan alone does not block deployment.

Separate image push, pull, delete, signing, and administrative permissions. For ABAC-enabled registries, use supported repository roles and conditions rather than assuming AcrPull/AcrPush applies. Audit assignments and keep the registry admin user disabled.

Limit access to a registry by assigning virtual network private IP addresses to the registry endpoints and using Azure Private Link. Network traffic between the clients on the virtual network and the registry's private endpoints traverses the virtual network and a private link on the Microsoft backbone network, eliminating exposure from the public internet. Private Link also enables enables private registry access from on-premises through Azure ExpressRoute private peering or a VPN gateway.

Choose supported, regularly patched minimal or distroless images compatible with the application. Do not use end-of-life Debian 10 examples. Removing a shell reduces attack surface but does not prevent exploitation; retain a controlled debug workflow.

As you use base images for application images, use automation to build new images when the base image is updated. As those base images typically include security fixes, update any downstream application container images.

Generate an SBOM for each release, retain build provenance, and sign immutable artifacts using supported OCI signing tools. Verify signatures and trusted identities during release or admission; signing without verification does not establish a supply-chain control.

Keep known-good image digests, Helm charts, manifests, and signatures available for the recovery window. Test pulls from the recovery region, registry private DNS, retention rules, and access identities; avoid deleting an image still referenced by production or rollback plans.

Use AKS cost analysis where supported or a maintained allocation tool. Combine Azure tags and Kubernetes labels with ownership, budgets, and chargeback rules. Include idle capacity, monitoring ingestion, network egress, storage, licenses, and managed add-ons.

Review requests, limits, node utilization, autoscaler behavior, and cost per business transaction. Reduce waste without removing failure headroom, disrupting latency objectives, or creating unschedulable workloads.

Model measured compute commitments against expected VM families, regions, and utilization. Use Spot capacity only for interruption-tolerant workloads with checkpointing and fallback; never rely on Spot for essential system components.

Schedule nonproduction shutdown or scale-down when supported and acceptable. Review unused disks, public IPs, snapshots, images, and workspaces with owners and retention policies before deletion; never treat an unattached disk as automatically disposable.

Measure utilization and workload efficiency, evaluate compatible Arm64 compute, and select regions within latency and residency constraints. Consider the total operational footprint rather than assuming one VM architecture is always cheaper or lower-carbon.