FinOps for AWS EKS & Azure AKS: Proven Strategies to Cut Kubernetes Cloud Spend by 40%–60%

Kubernetes FinOps (Cloud Financial Operations) is the operational and cultural discipline of bringing rigorous financial accountability to containerized cloud infrastructure, enabling engineering, platform, and finance leaders to optimize the business value derived from every cloud dollar. In enterprise Amazon Elastic Kubernetes Service (AWS EKS) and Azure Kubernetes Service (Azure AKS) environments, organizations routinely waste between 40% and 65% of their total cloud spend due to unmonitored container over-provisioning, inefficient node autoscaling, and orphaned infrastructure primitives.

When organizations migrate from monolithic virtual machines to Kubernetes, finance teams anticipate dramatic cost reductions through container density. In practice, the opposite occurs. AWS and Azure monthly invoices skyrocket because Kubernetes abstracts infrastructure into an opaque, shared resource pool. Traditional cloud billing tools (such as AWS Cost Explorer or Azure Cost Management) only report costs at the virtual machine (EC2 / Azure VM) level; they possess zero visibility into which microservice, product squad, or customer tenant is consuming CPU and memory inside the cluster.

This dynamic creates what the FinOps Foundation categorizes as the Two-Tier Cloud Waste Phenomenon:

• Pod-Level Slack (Request vs. Actual Usage Gap): Application developers, fearing Out-Of-Memory (OOMKilled) errors or latency spikes, aggressively pad container requests (e.g., requesting 4 CPU cores and 8GB RAM for a Java service that averages 200m CPU and 700MB RAM). Kubernetes schedules nodes based strictly on requests, not actual usage, reserving expensive compute that remains 85% idle 24 hours a day.
• Node-Level Slack (Cluster Bin-Packing Inefficiency): Legacy autoscalers (like the standard Kubernetes Cluster Autoscaler) provision rigid, homogeneous virtual machine sizes within Auto Scaling Groups. When pods cannot cleanly fit into existing nodes, the autoscaler launches an entire extra m5.2xlarge instance ($0.384/hour) just to schedule a single 250m CPU pod, stranding the remaining 85% of the host capacity.
• Orphaned Cloud Storage & Load Balancers: When developers delete transient test namespaces or pull request preview environments, Kubernetes deletes the Deployment but frequently abandons persistent volume claims (EBS volumes), unattached elastic IPs, and idle Network Load Balancers (NLBs) costing thousands in recurring monthly waste.

For years, the standard mechanism for scaling Kubernetes nodes was the Cluster Autoscaler (CA). While functional for homogeneous workloads, Cluster Autoscaler was fundamentally designed around cloud vendor Auto Scaling Groups (AWS ASGs) or Virtual Machine Scale Sets (Azure VMSS). When unschedulable pods appear, CA triggers the cloud provider ASG API, which boots pre-configured instance types regardless of whether the pending pod actually needs that specific shape.

In contrast, Karpenter—an open-source, high-performance node auto-provisioner originally incubated by AWS and now part of the CNCF—completely bypasses Auto Scaling Groups. Karpenter observes the aggregate resource constraints, volume topologies, node affinities, and architecture requirements of pending pods, directly calling the cloud provider EC2/Azure Fleet APIs to synthesize the exact right-sized instance in seconds.

To achieve maximum cost efficiency without compromising enterprise SLA guarantees, Karpenter should be configured to exploit AWS Graviton (ARM64) Spot Instances for stateless workloads while maintaining automated fallback to On-Demand capacity.

The manifest below illustrates an enterprise-ready Karpenter v1 NodePool and EC2NodeClass pairing, featuring automated consolidation, disruption budgeting, and multi-architecture scheduling:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general-compute-spot
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default-nodeclass
      requirements:
        # Favor 70% cheaper Spot instances with On-Demand fallback
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        # Prioritize AWS Graviton3/4 (arm64) for 40% better price-performance
        - key: kubernetes.io/arch
          operator: In
          values: ["arm64", "amd64"]
        # Restrict to cost-effective modern compute families
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["c7g", "m7g", "r7g", "c6i", "m6i"]
        - key: karpenter.k8s.aws/instance-size
          operator: NotIn
          values: ["nano", "micro", "small"]

  # Active consolidation continuously replaces expensive nodes with cheaper options
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 1m
    budgets:
      # During business hours, limit disruption to max 10% of nodes
      - nodes: "10%"
        schedule: "0 9 * * 1-5"
        duration: "9h"
  limits:
    cpu: "1000"
    memory: "4000Gi"
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default-nodeclass
spec:
  amiFamily: AL2023
  role: "KarpenterNodeRole-Production"
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "production-eks-cluster"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "production-eks-cluster"
  # Handle Spot 2-minute interruption notices via SQS
  interruptionQueue: "Karpenter-Interruption-Queue"

With this configuration, Karpenter handles Spot termination warnings transparently. When AWS emits a 2-minute Spot Rebalance recommendation via Amazon EventBridge, Karpenter consumes the message from the SQS queue, immediately provisions replacement nodes, taints the expiring node, and evicts pods gracefully before the host is reclaimed.

Optimizing nodes with Karpenter solves half the equation. However, if application engineers continue setting excessive CPU and memory requests in their Deployment YAML, Karpenter will still be forced to provision more nodes than necessary. To fix this at the root cause, platform teams implement Vertical Pod Autoscaler (VPA) paired with Fairwinds Goldilocks and KEDA.

The Vertical Pod Autoscaler continuously analyzes historical container CPU and memory consumption, calculating recommended request and limit boundaries based on actual P95 and P99 consumption trends over 8-day rolling evaluation windows. By eliminating the developer tendency to over-allocate out of fear of OOMKills, clusters reclaim up to 45% of allocated memory.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: payment-api-rightsizing
  namespace: payments-production
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: payment-processing-engine
  updatePolicy:
    # 'Initial' adjusts requests only when pods are created, preventing unexpected restarts
    updateMode: "Initial"
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        minAllowed:
          cpu: "100m"
          memory: "256Mi"
        maxAllowed:
          cpu: "2000m"
          memory: "4Gi"
        controlledResources: ["cpu", "memory"]

By enforcing updateMode: "Initial", VPA injects right-sized CPU and memory values into pods during deployment rollouts without terminating running instances in the middle of production traffic. When combined with KEDA (Kubernetes Event-driven Autoscaling), non-production staging environments scale to zero replicas outside business hours (7:00 PM to 7:00 AM and weekends), eliminating 71% of non-production compute bills overnight.

To avoid race conditions between VPA and Horizontal Pod Autoscaler (HPA), platform teams configure HPA to scale exclusively on custom business metrics (such as SQS queue depth or HTTP requests per second via KEDA) while delegating vertical resource boundaries exclusively to VPA. This prevents the classic "flapping loop" where HPA adds pods while VPA simultaneously resizes them.

You cannot optimize what you cannot measure. The primary impediment to FinOps maturity is the inability to assign costs back to specific business units, product owners, or engineering squads. In a shared multi-tenant cluster, a $50,000 monthly AWS EKS bill typically sits as an unallocated line item in the IT infrastructure budget.

OpenCost—a vendor-neutral CNCF project that forms the core of Kubecost—bridges this visibility gap by joining Kubernetes resource usage metrics (from Prometheus) with real-time cloud provider pricing APIs (AWS Pricing API, Azure Retail Rates API). OpenCost computes exact costs down to:

• Per-Namespace Allocation: Identifies which product domain (e.g., payments, analytics, search) is driving cluster costs.
• Per-Label & Owner Showback: Aggregates costs by team label (team: checkout-squad) and cost-center metadata, generating automated monthly showback reports for department heads.
• Idle Cost Quantification: Separates active compute cost from unallocated cluster waste, showing executives exactly how much money is burned on stranded memory.
• Cross-Cloud Multi-Cluster Telemetry: Unifies cost tracking across AWS EKS and Azure AKS into a single Prometheus/Grafana dashboard, exposing cross-cloud price differentials per vCPU-hour.

By exposing PromQL metrics such as container_cpu_allocation, container_memory_allocation_bytes, and node_total_hourly_cost, platform teams build executive Grafana dashboards that calculate Unit Economics: cost per customer transaction, cost per API request, or cost per active subscriber. This shifts engineering conversations from vague complaints about high bills to measurable efficiency ratios.

To build an irrefutable business case for FinOps engineering, cloud architects must quantify total cluster waste using a mathematically rigorous model:

Consider an enterprise running 200 nodes (m5.4xlarge, 16 vCPUs, 64GB RAM) on AWS EKS with an unoptimized Cluster Autoscaler:

• Unoptimized State (19% Utilization): 200 nodes × $0.768/hr × 730 hrs = $112,128/month on raw compute, plus $25,000 in unattached EBS volumes and data transfer fees ($137,128 total).
• Optimized State with Karpenter + Graviton3 + VPA (76% Utilization): Replacing m5.4xlarge with a dynamic mix of c7g.2xlarge and m7g.4xlarge Graviton3 Spot instances ($0.23/hr average) reduces the node footprint from 200 to 58 nodes. Monthly compute spend drops to $44,280/month.
• Net Monthly Savings: $92,848 per month (a 67.7% reduction), generating over $1.11 million in annual bottom-line savings.

Achieving sustainable cloud cost reduction is not a one-time script execution; it requires an operational rhythm that aligns engineering incentives with corporate financial goals.

MetaDesign Solutions implements the following 5-phase FinOps playbook for enterprise clients:

1. Phase 1: Telemetry & Tagging Audit (Days 1–10): Deploy OpenCost and Prometheus. Enforce mandatory Kubernetes labels (owner, cost-center, env) via Kyverno admission controllers. Establish baseline cost per business transaction.
2. Phase 2: Purge Zombie Infrastructure (Days 11–20): Run automated cleaners to identify and terminate unattached Amazon EBS volumes, orphaned Azure Managed Disks, idle load balancers, and unreferenced ConfigMaps.
3. Phase 3: Deploy Karpenter Just-In-Time Provisioning (Days 21–35): Replace legacy Auto Scaling Groups with Karpenter. Enable active consolidation with WhenUnderutilized policies and integrate Amazon EventBridge for Spot termination handling.
4. Phase 4: Multi-Arch Graviton / ARM64 Migration (Days 36–48): Update CI/CD pipelines (Docker Buildx) to compile multi-arch container images. Transition stateless microservices to AWS Graviton3/4 or Azure Ampere Altra instances for immediate 20%–40% price-performance gains.
5. Phase 5: Automated Rightsizing & Budgets (Days 49–60): Implement Vertical Pod Autoscaler recommendations. Configure KEDA to scale non-production environments to zero on nights and weekends. Integrate Slack alerting for namespace budget overruns.

Optimizing Kubernetes cloud economics requires deep systems engineering and cloud financial architecture. Review our specialized DevOps consulting services, evaluate our cloud infrastructure scaling capabilities in our AWS cloud consulting company practice, and learn how we stress-tested distributed high-concurrency cloud environments in our cinema chain API load spike testing case study.