AKS networking and ingress patterns — Cost Optimization — Practical Guide (Nov 14, 2025)

body { font-family: -apple-system, BlinkMacSystemFont, “Segoe UI”, Roboto, Oxygen,
Ubuntu, Cantarell, “Open Sans”, “Helvetica Neue”, sans-serif; line-height:1.6; max-width:800px; margin:auto; padding:1em;}
h2, h3 { color:#005A9C; }
pre { background:#f5f7fa; border:1px solid #ddd; padding:1em; overflow-x:auto; }
p.audience { font-weight:bold; font-style:italic; color:#333; }
p.social { margin-top:2em; font-size:0.9em; color:#666; }

AKS Networking and Ingress Patterns — Cost Optimisation

Level: Intermediate

As of November 14, 2025 — focusing on AKS versions ≥ 1.30, current Azure networking capabilities and stable ingress controller patterns.

Introduction

Azure Kubernetes Service (AKS) is a powerful managed container orchestration platform where networking choices are crucial not only for performance and security but also for cost optimisation. Network traffic, load balancing, ingress patterns, and node scaling directly impact your Azure bill. Optimising AKS networking requires understanding both the cluster network models and the ingress configurations best suited for your workload and traffic patterns.

Prerequisites

• Familiarity with Kubernetes fundamentals (services, ingress, pods).
• Basic knowledge of Azure networking resources — Virtual Networks, Load Balancers (Standard SKU preferred for production), Azure Application Gateway.
• AKS cluster v1.30 or above recommended since it includes improvements in node scaling and new networking features (e.g. IPv6 dual stack preview is available but not recommended for production).
• Azure CLI (latest stable version) configured with contributor access to your subscription.
• Helm 3 or kubectl installed for deploying ingress controllers.

Hands-on Steps

1. Choose the Right Cluster Networking Model

AKS supports two primary network models:

• Basic (kubenet): Uses Azure-provided networking, easy to set up but limited IP address flexibility and often defaults to NAT and LoadBalancer IPs.
• Azure CNI (Container Networking Interface): Pods get IPs from the VNet subnet; better for more advanced networking but can increase subnet size requirements and IP utilisation.

Cost consideration: Azure CNI clusters typically require larger VNet subnet allocations due to IP assignment per pod, potentially leading to higher network-related costs and capacity planning challenges. Use kubenet if scaling pod density or IP exhaustion is a concern, while Azure CNI is ideal if you need full VNet integration, like for network policies or NSGs.

2. Select an Efficient Ingress Pattern

Ingress controls external access into AKS. The choice of ingress implementation impacts not just operational complexity but also ongoing costs.

• Azure Load Balancer (Standard SKU) + Kubernetes Ingress Controllers (e.g., NGINX, Traefik): Common and flexible; Cost largely depends on number of Load Balancer rules and outbound data. Standard SKU LB supports availability zones and is recommended.
• Azure Application Gateway Ingress Controller (AGIC): Azure-native, supports WAF and SSL offloading but has hourly costs based on throughput units.
• Internal Ingress with Private Link or API Gateway: For internal-only access, reduces exposure and potentially lowers costs by limiting expensive outbound data.

When to choose: Choose NGINX or Traefik with Azure LB if you want Kubernetes-native config, lower fixed ingress costs, and simpler use cases. Opt for AGIC if you need Azure WAF, path-based routing at scale, and tighter MSI integration despite higher hourly costs.

3. Enable Ingress Controller Autoscaling to Match Load

Autoscale ingress controller nodes (or pods) based on CPU, memory, or custom metrics to reduce overprovisioning.

Example: Horizontal Pod Autoscaler for NGINX ingress deployed via Helm:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-ingress-controller
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Autoscaling reduces costs by running fewer ingress pods during off-peak hours.

4. Use Efficient Load Balancer and Ingress Annotations

Cost savings can come from simplifying load balancer rules and limiting unnecessary public IPs.

• Use a single Standard Load Balancer with multiple rules rather than multiple LBs where possible.
• Leverage annotations to reduce Azure resource consumption, e.g., service.beta.kubernetes.io/azure-load-balancer-internal for internal services.

5. Optimise Node and Pod Networking Capacity

Overprovisioning node subnet capacity or inefficient pod IP usage leads to Azure vNet address space exhaustion and additional subnet expansions, which can be expensive and complex. Use virtual node (Azure Container Instances) for occasional bursting, or IP masquerading for outbound traffic minimisation.

# Enable IP masquerade to reduce IP usage on Azure CNI cluster
kubectl apply -f https://raw.githubusercontent.com/Azure/aks-engine/master/examples/ip-masq-agent.yaml

6. Consider Egress Traffic Optimisation

Outbound internet traffic from AKS clusters is billed separately. Use Azure NAT Gateway or Azure Firewall with careful rules to reduce data transfer costs, and configure egress only for required destinations.

Common Pitfalls

• Ignoring subnet IP limits: Azure subnets have hard limits on IP addresses, impacting pod density. Overlooking this causes scaling failures.
• Multiple public IPs per service: Using one public IP per ingress service unnecessarily increases resource cost.
• Not enabling autoscaling for ingress controllers: Results in overprovisioned infrastructure and wasted compute cost.
• Using Basic SKU load balancer: Limited features and no SLA; not recommended for production and may cause stability issues.
• Uncontrolled outbound internet traffic: Leads to unexpected network egress charges.

Validation

Confirm costs and networking setup with these checks:

• Use kubectl get svc -A to verify your services use Standard Load Balancer and correct IP types.
• Azure Portal -> Networking -> Load balancers to verify Azure resources and their usage.
• Monitor autoscaling logs and metrics for ingress controller pods with Azure Monitor or Prometheus.
• Check subnet size and used IP addresses using Azure CLI:

az network vnet subnet show --resource-group myResourceGroup --vnet-name myVnet --name mySubnet --query "{addressPrefix:addressPrefix,ipConfigsCount:ipConfigurations | length(@)}"

Checklist / TL;DR

• Choose kubenet for simpler cost-sensitive scenarios; Azure CNI for comprehensive VNet integration.
• Use Standard SKU Load Balancer, avoid Basic SKU in production.
• For ingress, default to NGINX or Traefik with autoscaling unless advanced WAF needed (then AGIC).
• Consolidate ingress to minimise number of public IPs and load balancer rules.
• Enable autoscaling on ingress controllers to scale with traffic.
• Monitor pod IP usage and subnet capacity carefully to avoid expensive subnet enlargements.
• Optimise outbound egress with NAT Gateway or Firewall to control costs.

References

• Azure AKS networking overview
• Use an NGINX ingress controller with AKS
• Azure Application Gateway Ingress Controller (AGIC)
• AKS ingress controller autoscaling
• <a