Is AKS Automatic Enterprise Ready?

A question I often hear from enterprise security teams is “Can AKS Automatic fit into our existing network architectures, or does opinionated mean inflexible?”

The common perception is that opinionated platforms trade control for convenience. Platform teams worry that adopting AKS Automatic means giving up network-level governance, hub-spoke topologies, and compliance boundaries. In practice, custom VNet integration changes this calculation entirely. AKS Automatic lets you bring your own virtual network, maintain existing security policies, and integrate with ExpressRoute or VPN connectivity while still getting the opinionated defaults that make AKS Automatic production-ready.

This combination matters for regulated environments where network topology isn’t negotiable but operational overhead is.

What AKS Automatic Provides

AKS Automatic is Microsoft’s answer to Kubernetes complexity. The value proposition is straightforward: production-ready clusters with opinionated defaults, automatic node management via Node Autoprovisioning (Karpenter-based), and hardened security configurations.

The platform makes specific choices about Networking (Azure CNI Overlay with Cilium), Node OS (Azure Linux), Autoscaling (HPA, VPA, KEDA, and Node Autoprovisioning), and Observability (Managed Prometheus and Container Insights by default when created via CLI or Portal). These decisions follow the Well-Architected Framework recommendations for AKS and seeks to reduce the complexity and configuration surface area that platform teams need to manage.

Beyond infrastructure choices, AKS Automatic enforces Kubernetes best practices through Deployment Safeguards. This Azure Policy-based feature runs in the cluster and validates workload configurations before they’re deployed. Safeguards block deployments that violate production readiness patterns - missing resource limits, privileged containers, or workloads without health probes.

What caught my attention in recent updates: Microsoft now supports mutations alongside validations. Rather than just blocking non-compliant deployments, safeguards can automatically inject missing configurations like resource requests and pod anti-affinity rules. This reduces friction with third-party Helm charts that don’t define resource limits or anti-affinity policies. The mutation approach maintains guardrails while allowing workloads to deploy.

Deployment Safeguards operate at two levels - Warning (audit only) and Enforcement (blocks violations or auto-fixes through mutations where supported). Platform teams can tune the enforcement level based on environment maturity. This matters because strict blocking in dev environments creates unnecessary friction, while production benefits from enforcement.

When the AKS Automatic preview first launched, custom Virtual Networks were not supported. In these early days, I was excited about the problems that AKS Automatic was here to solve but, in equal measure, I was concerned that uptake within the enterprise would stall due to the inability to bring your own VNets. The ability to bring a custom VNet means that the enterprise can adhere to their strict governance while keeping the opinionated defaults and pre-configurations provided by the experienced teams within Microsoft. Teams can deploy AKS Automatic into existing network topologies without sacrificing the automation that makes the platform useful.

Custom VNet Architecture Requirements

AKS Automatic with custom VNet requires two subnets: a dedicated API server subnet and a cluster subnet for node deployment.

The API server subnet must be delegated to Microsoft.ContainerService/managedClusters and be at least a /28 subnet. This delegation grants AKS permissions to inject the API server pods and internal load balancer into that subnet. The subnet reserves at least 9 IPs for the API server infrastructure. Running out of IP addresses prevents API server scaling and can cause outages, so size accordingly for production clusters.

The cluster subnet holds the worker nodes. Be sure to size your cluster subnet according to ensure that you don’t encounter any brick walls masquerading as poorly sized subnets. A bit of forethought at the design stage will save you some hassle later and ensure you can take advantage of all that autoscaling and Node Autoprovisioning goodness.

What You Gain With Custom VNet

Custom VNet integration preserves enterprise network architectures while adopting AKS Automatic.

Hub-spoke topologies work as expected. The AKS cluster deploys into a spoke VNet, peers back to the hub for shared services, and routes traffic through Azure Firewall or Network Virtual Appliances. ExpressRoute and VPN connectivity provide on-premises networks access to the cluster without any additional configuration.

Enable the Private Cluster option alongside your custom VNet to eliminate public API Server endpoints entirely. The API server remains accessible only from within the VNet or peered networks, which should satisfy compliance requirements for internet-isolated workloads.

DNS integration supports both Azure Private DNS zones and custom DNS servers. For organizations with existing DNS infrastructure, AKS Automatic works with on-premises DNS resolution without forcing Azure DNS adoption.

When I tested the custom VNet integration with enterprise teams, the conversation shifted. Network topology concerns disappeared because the cluster integrated into existing VNet designs. Security policies applied at the NSG and firewall level, not within Kubernetes. The platform team could adopt informed and intelligent defaults as well as their own opinionated networking defaults while security teams maintained existing governance boundaries.

Node Autoprovisioning Behavior With Custom VNets

Node Autoprovisioning is the AKS team’s implementation of Karpenter, originally developed by AWS before being donated to the CNCF. Node Autoprovisioning, or NAP, runs as a managed addon in your AKS cluster. It watches for unschedulable pods and dynamically provisions nodes based on resource requirements and constraints.

With custom VNets, NAP creates nodes in the cluster subnet you specify. The Network Contributor role on the VNet enables NAP to attach nodes to the subnet and assign IP addresses from your address space. This happens transparently - you define pod requirements, and NAP selects appropriate VM SKUs and provisions nodes within your network topology.

The consolidation behavior works the same way. When nodes become underutilized, NAP drains workloads and deprovisions nodes, returning IP addresses to the subnet pool. This dynamic scaling stays within your subnet boundaries and respects any IP address planning you’ve done.

Observability: Bring Your Own Workspaces

AKS Automatic defaults to managed observability when created via Azure CLI or Portal, but you’re not locked into newly created workspaces.

For Log Analytics (Container Insights), you can specify an existing workspace during cluster creation. The cluster sends logs to your workspace using the ContainerLogV2 schema, which supports Basic logs tier for cost optimization.

Azure Monitor workspace for Managed Prometheus follows the same pattern. You can create the cluster pointing to an existing Azure Monitor workspace, and multiple AKS clusters can send metrics to the same workspace. This matters for platform teams running multiple clusters - a single Azure Monitor workspace collects Prometheus metrics from all clusters, and a single Managed Grafana instance visualizes across them.

Managed Grafana integration requires granting the Grafana instance’s Managed Identity the Monitoring Reader role on your Azure Monitor workspace and Log Analytics workspace. This permission scoping happens at workspace level, not cluster level, which aligns with centralized observability patterns.

This flexibility speaks to the same enterprise blocker we touched on above. Enterprise technical teams generally don’t like giving up control when it comes to the infrastructure they look after. Teams can build their own opinionated monitoring stack and then just pass the Resource IDs to Azure via IaC, Azure CLI, or other tooling.

Managed vs Custom VNet Trade-offs

The managed VNet option creates a new VNet with AKS-managed NAT Gateway for egress. This works for greenfield deployments where network topology is flexible.

Custom VNet gives you control over egress routing. You can use Azure Load Balancer (default), a user-assigned NAT Gateway, or user-defined routing through Azure Firewall or Network Virtual Appliances. The egress type locks at cluster creation and cannot be changed later, so make sure you plan ahead of time.

The network plugin remains Azure CNI Overlay with Cilium regardless of VNet choice. You cannot use Kubenet or custom CNI implementations with AKS Automatic. This is an intentional constraint - the opinionated networking stack provides consistent behavior and integrates with features like Advanced Container Networking Services.

API Server VNet Integration is preconfigured in AKS Automatic. The API Server endpoint projects into the delegated subnet, and node-to-API-server traffic stays on the private network without tunnels or private links. This reduces complexity compared to traditional private clusters while maintaining network-level isolation.

When Custom VNet Integration Justifies AKS Automatic

Custom VNet support makes AKS Automatic viable when network governance is non-negotiable.

Regulated industries or mature enterprise technology organizations with hub and spoke network architectures benefit most. Financial services, healthcare, and government sectors already have network topologies designed around compliance requirements. AKS Automatic integrates into these topologies without forcing architectural changes, while NAP and opinionated security defaults reduce operational overhead.

Platform teams managing multiple clusters see value in standardization. Custom VNet integration lets them deploy clusters across different environments (dev, staging, prod) using the same VNet patterns while maintaining consistent Kubernetes configurations through AKS Automatic’s opinionated defaults.

The trade-off is accepting AKS Automatic’s networking stack. If your requirements mandate Kubenet (which I hope they don’t :P), custom CNI plugins, or specific network policy implementations beyond Cilium, AKS Standard provides more flexibility. Custom VNet integration doesn’t change the fundamental constraint that AKS Automatic is opinionated about the data plane.

For teams where network topology matters more than networking stack flexibility, custom VNet integration makes the opinionated model work.

One Minor Gripe: Web App Routing Cannot Be Disabled

AKS Automatic preconfigures the Web App Routing addon, which deploys a managed NGINX ingress controller. There’s no option to disable it during cluster creation or after deployment.

This becomes relevant given recent Kubernetes project announcements. The upstream Ingress NGINX project is retiring, with maintenance ending March 2026. Microsoft will continue supporting the Application Routing addon’s NGINX implementation through November 2026 for critical security patches, but the long-term direction is clear: Gateway API is the future standard for ingress and L7 traffic management.

For teams planning to adopt Gateway API from day one, the mandatory NGINX installation creates unnecessary overhead. You can install alternative Gateway implementations like Envoy Gateway alongside NGINX, but the NGINX pods run whether you use them or not. This wastes resources and creates potential confusion about which ingress controller handles traffic.

The architectural implication matters more than the resource overhead. Gateway API is becoming the primary method for configuring cluster ingress, with better support for TCP/UDP routing, traffic splitting, and policy attachment. Teams wanting to invest in Gateway API implementations like Envoy Gateway or Cilium Gateway API are forced to run NGINX in parallel.

My good friend Richard Hooper wrote a great analysis of the NGINX retirement and migration paths for AKS users at pixelrobots.co.uk. His testing covers four realistic migration options and includes hands-on validation of each path. Worth reading if you’re planning for the NGINX retirement.

The Envoy Gateway option is particularly relevant for enterprise deployments. Envoy Gateway supports Gateway API natively and can deploy with internal LoadBalancer services, keeping workloads entirely private without public endpoints. This contrasts with Application Gateway for Containers, which currently requires public frontends. For teams with zero-trust requirements or internal-only applications, Envoy Gateway enables fully private ingress without workarounds.

Microsoft’s roadmap indicates the Application Routing addon will evolve to support Gateway API in H1 2026, which provides a managed migration path. In the meantime, teams are stuck with NGINX whether they want it or not.

This is a legitimate platform feedback point. The inability to opt out of Web App Routing conflicts with teams wanting to adopt Gateway API natively from cluster inception. You can work around it by ignoring the webapprouting.kubernetes.azure.com ingress class and deploying your preferred Gateway implementation, but it’s an unnecessary complication.

Key Takeaways

AKS Automatic with custom VNet integration is production-ready for enterprise platform teams that need opinionated defaults within existing network governance.

Custom VNet support preserves hub and spoke network architectures, ExpressRoute connectivity, NSG-based security policies, and private DNS integration. Node Autoprovisioning works within your subnet boundaries. Observability integrates with existing Log Analytics and Azure Monitor workspaces.

The constraints are the opinionated networking stack (Azure CNI Overlay with Cilium, non-negotiable) and the inability to disable Web App Routing (relevant if you’re planning Gateway API adoption). Regional availability matters - validate that your deployment regions support API Server VNet Integration in GA and have three availability zones.

For teams where network topology is a compliance requirement but the operational overhead that comes with Kubernetes is a problem, custom VNet integration makes AKS Automatic worth entertaining.

Further Reading:

Check out some further reading on AKS Automatic below.

• Official AKS Automatic Documentation
• Custom VNet Quickstart
• Node Autoprovisioning Overview
• Deployment Safeguards Documentation
• Ingress NGINX Retirement Analysis

Questions, feedback, or thoughts on AKS Automatic? I’d love to hear from you. Drop me a line on LinkedIn and let’s chat about your experience with custom VNet integration or your Gateway API migration plans.