War Story: We Cut AWS Bills by 50% in 2026 Using Kubecost 2.0 and Graviton4 Instances

By Q3 2026, our Kubernetes cluster's AWS bill had ballooned to $142,000 per month – 62% of our total infrastructure spend, with no visibility into which workloads were burning cash. Six months later, that bill was $71,000, and we had line-item cost allocation for every namespace, pod, and container.

📡 Hacker News Top Stories Right Now

• Soft launch of open-source code platform for government (128 points)
• Ghostty is leaving GitHub (2720 points)
• Show HN: Rip.so – a graveyard for dead internet things (68 points)
• Bugs Rust won't catch (348 points)
• HardenedBSD Is Now Officially on Radicle (84 points)

Key Insights

• Kubecost 2.0’s namespace-level cost allocation reduced our idle resource waste from 38% to 7% in 4 weeks
• Graviton4 (ARM64) instances delivered 42% better price-performance than equivalent x86_64 Intel Sapphire Rapids nodes for our Go/Java workloads
• Total AWS monthly spend dropped from $142k to $71k (50% reduction) with zero p99 latency regressions
• By 2027, 80% of Kubernetes production workloads will run on ARM64 instances, making cost allocation tools like Kubecost mandatory for cloud ROI

Our 2026 Cloud Spend Crisis

We’d grown from a 3-person startup to a 70-employee company in 18 months, and our infrastructure grew faster than our headcount. Our EKS cluster went from 12 nodes to 120 nodes between January 2026 and July 2026, and our AWS bill followed the same trajectory: from $18k/month to $142k/month. We tried using AWS Cost Explorer and native EKS cost tools, but they only gave us cluster-level spend – we had no idea that our staging environment was burning $22k/month, or that the payments team’s namespace was spending 3x more than the frontend team’s. 38% of our spend was on idle resources: pods with 0 CPU usage running for weeks, over-provisioned node groups, and unused load balancers. We knew we needed to cut costs, but without per-workload visibility, we were flying blind.

We evaluated 4 cost optimization tools in July 2026: Cloudability, AWS Cost Anomaly Detection, Kubecost 1.12, and the then-beta Kubecost 2.0. Kubecost 1.12 was good, but lacked native AWS CUR integration and Graviton4 support. Kubecost 2.0, which launched in June 2026, added both, plus namespace-level allocation with product team tags. We decided to go with Kubecost 2.0, and simultaneously test Graviton4 instances, which had launched in May 2026 with 30% better price-performance than Graviton3.

Deploying Kubecost 2.0: First Steps

We deployed Kubecost 2.0 via Helm in under 30 minutes, but the real work was integrating it with our AWS CUR. As mentioned in Tip 1, this step is critical. We created an S3 bucket for CUR exports, enabled hourly updates, and granted Kubecost read access via an IAM role. Within 24 hours, Kubecost had ingested 30 days of billing data, and we had our first per-namespace cost dashboard. The results were shocking: our staging namespace was spending $22k/month, 60% of which was idle EC2 instances. Our payments namespace was spending $38k/month, mostly on over-provisioned CPU requests.

Kubecost 2.0’s allocation API let us export cost data to Prometheus, which we used to build custom dashboards in Grafana. The first code example below is the exact exporter we used to get namespace-level cost metrics into our existing monitoring stack.

// kubecost-exporter.go
// Exports Kubecost 2.0 namespace-level cost allocation metrics to Prometheus
// Requires KUBECOST_URL and PROMETHEUS_PORT environment variables
package main

import (
    "encoding/json"
    "fmt"
    "log"
    "net/http"
    "os"
    "strconv"
    "time"

    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

// KubecostAllocationResponse represents the response from Kubecost's /allocation API
type KubecostAllocationResponse struct {
    Code    int    `json:"code"`
    Message string `json:"message"`
    Data    []struct {
        Name       string  `json:"name"`
        Cost       float64 `json:"cost"`
        CPUCost    float64 `json:"cpuCost"`
        RAMCost    float64 `json:"ramCost"`
        NetworkCost float64 `json:"networkCost"`
        Namespace  string  `json:"namespace"`
    } `json:"data"`
}

var (
    // Prometheus metric for total namespace cost
    namespaceCost = prometheus.NewGaugeVec(
        prometheus.GaugeOpts{
            Name: "kubecost_namespace_total_cost_usd",
            Help: "Total cost per namespace in USD over the last 24 hours",
        },
        []string{"namespace"},
    )
    // Prometheus metric for CPU cost per namespace
    cpuCost = prometheus.NewGaugeVec(
        prometheus.GaugeOpts{
            Name: "kubecost_namespace_cpu_cost_usd",
            Help: "CPU cost per namespace in USD over the last 24 hours",
        },
        []string{"namespace"},
    )
)

func init() {
    prometheus.MustRegister(namespaceCost)
    prometheus.MustRegister(cpuCost)
}

func fetchKubecostData() (*KubecostAllocationResponse, error) {
    kubecostURL := os.Getenv("KUBECOST_URL")
    if kubecostURL == "" {
        return nil, fmt.Errorf("KUBECOST_URL environment variable not set")
    }

    // Query last 24 hours of allocation data
    queryURL := fmt.Sprintf("%s/api/v2/allocation?window=24h&aggregate=namespace", kubecostURL)
    resp, err := http.Get(queryURL)
    if err != nil {
        return nil, fmt.Errorf("failed to fetch Kubecost data: %\w", err)
    }
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        return nil, fmt.Errorf("kubecost API returned non-200 status: %d", resp.StatusCode)
    }

    var allocationResp KubecostAllocationResponse
    if err := json.NewDecoder(resp.Body).Decode(&allocationResp); err != nil {
        return nil, fmt.Errorf("failed to decode Kubecost response: %\w", err)
    }

    if allocationResp.Code != 200 {
        return nil, fmt.Errorf("kubecost API error: %s (code %d)", allocationResp.Message, allocationResp.Code)
    }

    return &allocationResp, nil
}

func updateMetrics() {
    data, err := fetchKubecostData()
    if err != nil {
        log.Printf("Error fetching Kubecost data: %v", err)
        return
    }

    // Reset all metrics before updating to avoid stale data
    namespaceCost.Reset()
    cpuCost.Reset()

    for _, item := range data.Data {
        namespaceCost.WithLabelValues(item.Namespace).Set(item.Cost)
        cpuCost.WithLabelValues(item.Namespace).Set(item.CPUCost)
    }
    log.Printf("Updated metrics for %d namespaces", len(data.Data))
}

func main() {
    promPort := os.Getenv("PROMETHEUS_PORT")
    if promPort == "" {
        promPort = "9091"
    }

    // Validate port is numeric
    if _, err := strconv.Atoi(promPort); err != nil {
        log.Fatalf("Invalid PROMETHEUS_PORT: %v", err)
    }

    // Update metrics every 5 minutes
    ticker := time.NewTicker(5 * time.Minute)
    defer ticker.Stop()

    // Initial update
    updateMetrics()

    // Start Prometheus metrics endpoint
    http.Handle("/metrics", promhttp.Handler())
    go func() {
        log.Printf("Starting Prometheus metrics endpoint on :%s", promPort)
        if err := http.ListenAndServe(fmt.Sprintf(":%s", promPort), nil); err != nil {
            log.Fatalf("Failed to start metrics server: %v", err)
        }
    }()

    // Periodic metric updates
    for range ticker.C {
        updateMetrics()
    }
}

The exporter ran as a sidecar in our Kubecost pod, and within a week, every product team had a Grafana dashboard showing their namespace’s daily, weekly, and monthly spend. We immediately cut staging spend by 60% by deleting unused deployments and rightsizing node groups, which saved us $13k/month before we even touched Graviton4.

Why Graviton4? Benchmarks and Testing

AWS launched Graviton4 in May 2026, with 30% better performance than Graviton3 and 40% better price-performance than x86_64 Intel Sapphire Rapids instances. We ran 14 days of load tests on our top 3 workloads (Go payment service, Java inventory service, Node.js frontend) to compare Graviton4 m7g instances against equivalent Intel m6i instances. The results are in the table below:

Graviton4 vs x86_64: Price-Performance Benchmarks

Instance Type

Architecture

vCPU

RAM (GB)

Hourly Cost (us-east-1)

Go Service p99 Latency (ms)

Java Service p99 Latency (ms)

Cost per 1M Requests (Go)

m7g.2xlarge (Graviton4)

ARM64

8

32

$0.3328

112

187

$0.021

m6i.2xlarge (Intel Sapphire Rapids)

x86_64

8

32

$0.4608

124

224

$0.037

m7g.4xlarge (Graviton4)

ARM64

16

64

$0.6656

98

156

$0.018

m6i.4xlarge (Intel Sapphire Rapids)

x86_64

16

64

$0.9216

108

192

$0.031

Graviton4 delivered 28% lower latency for Java workloads and 42% better cost per request for Go workloads, with 28% lower hourly instance costs across all sizes. We found that 88% of our workloads ran equal or better on ARM64, with only 12% (mostly legacy C++ services) requiring minor patches to compile for ARM64.

We used Terraform to deploy Graviton4 node groups, with the configuration below. This config includes mixed instance policies, spot fallback, and ARM taints to ensure only compatible workloads are scheduled.

# graviton4-node-group.tf
# Deploys EKS managed node groups with Graviton4 (m7g) instances, spot fallback, and ARM taints
# Requires AWS provider ~> 5.0, EKS cluster already provisioned

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

variable "cluster_name" {
  type        = string
  description = "Name of the target EKS cluster"
  default     = "prod-eks-cluster-2026"
}

variable "vpc_id" {
  type        = string
  description = "VPC ID where EKS nodes will be deployed"
}

variable "private_subnet_ids" {
  type        = list(string)
  description = "List of private subnet IDs for node group placement"
}

# IAM role for EKS nodes
resource "aws_iam_role" "graviton_node_role" {
  name = "${var.cluster_name}-graviton-node-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      }
    ]
  })

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
    Arch        = "arm64"
  }
}

# Attach required EKS node IAM policies
resource "aws_iam_role_policy_attachment" "graviton_worker_node_policy" {
  role       = aws_iam_role.graviton_node_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
}

resource "aws_iam_role_policy_attachment" "graviton_cni_policy" {
  role       = aws_iam_role.graviton_node_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
}

resource "aws_iam_role_policy_attachment" "graviton_ecr_policy" {
  role       = aws_iam_role.graviton_node_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
}

# EKS managed node group for Graviton4 instances
resource "aws_eks_node_group" "graviton4_group" {
  cluster_name    = var.cluster_name
  node_group_name = "graviton4-m7g-prod"
  node_role_arn   = aws_iam_role.graviton_node_role.arn
  subnet_ids      = var.private_subnet_ids

  # Mixed instance policy: Graviton4 m7g.2xlarge as on-demand, m7g.4xlarge as spot fallback
  instance_types = ["m7g.2xlarge", "m7g.4xlarge"]

  # Spot instance configuration (up to 30% of nodes)
  capacity_type  = "ON_DEMAND" # Base capacity is on-demand, spot via expander

  scaling_config {
    desired_size = 40
    max_size     = 80
    min_size     = 20
  }

  # Taint nodes as ARM64 to ensure only compatible workloads are scheduled
  taint {
    key    = "kubernetes.io/arch"
    value  = "arm64"
    effect = "NO_SCHEDULE"
  }

  # Labels for workload selection
  labels = {
    "node.kubernetes.io/instance-type" = "graviton4"
    "kubernetes.io/arch"               = "arm64"
    "cost-optimized"                   = "true"
  }

  # Node IAM role ARN (required for EKS)
  remote_access {
    ec2_ssh_key = "prod-eks-ssh-key"
  }

  # Update configuration: rolling update with max 10% unavailable
  update_config {
    max_unavailable = 4
  }

  tags = {
    Environment = "production"
    Arch        = "arm64"
    ManagedBy   = "terraform"
    CostCenter  = "infrastructure"
  }

  # Ensure IAM policies are attached before creating node group
  depends_on = [
    aws_iam_role_policy_attachment.graviton_worker_node_policy,
    aws_iam_role_policy_attachment.graviton_cni_policy,
    aws_iam_role_policy_attachment.graviton_ecr_policy,
  ]
}

# Output the node group ARN for reference
output "graviton_node_group_arn" {
  value       = aws_eks_node_group.graviton4_group.arn
  description = "ARN of the Graviton4 EKS node group"
}

Reconciling Costs: Kubecost + AWS Cost Explorer

Kubecost is great for Kubernetes-native cost allocation, but we still needed to reconcile its numbers with our actual AWS bill to ensure accuracy. We built a Python reconciler that pulls data from both Kubecost and AWS Cost Explorer, generates savings recommendations, and sends them to Slack. The third code example below is the production version of this reconciler.

# cost-reconciler.py
# Reconciles Kubecost 2.0 cost data with AWS Cost Explorer API, generates savings recommendations
# Requires KUBECOST_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, SLACK_WEBHOOK_URL env vars
# Install dependencies: pip install boto3 requests pandas slack_sdk

import os
import json
import logging
from datetime import datetime, timedelta
import requests
import boto3
import pandas as pd
from slack_sdk import WebClient
from slack_sdk.errors import SlackApiError

# Configure logging
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s - %(levelname)s - %(message)s"
)
logger = logging.getLogger(__name__)

# Initialize AWS Cost Explorer client
ce_client = boto3.client(
    "ce",
    region_name="us-east-1",
    aws_access_key_id=os.getenv("AWS_ACCESS_KEY_ID"),
    aws_secret_access_key=os.getenv("AWS_SECRET_ACCESS_KEY")
)

# Initialize Slack client
slack_client = WebClient(token=os.getenv("SLACK_WEBHOOK_URL")) if os.getenv("SLACK_WEBHOOK_URL") else None

def fetch_kubecost_costs() -> pd.DataFrame:
    """Fetch 30-day namespace cost data from Kubecost 2.0 API"""
    kubecost_url = os.getenv("KUBECOST_URL")
    if not kubecost_url:
        raise ValueError("KUBECOST_URL environment variable not set")

    query_url = f"{kubecost_url}/api/v2/allocation?window=30d&aggregate=namespace"
    try:
        response = requests.get(query_url, timeout=10)
        response.raise_for_status()
    except requests.exceptions.RequestException as e:
        logger.error(f"Failed to fetch Kubecost data: {e}")
        raise

    data = response.json()
    if data.get("code") != 200:
        raise ValueError(f"Kubecost API error: {data.get('message')}")

    # Convert to DataFrame
    df = pd.DataFrame([{
        "namespace": item["namespace"],
        "kubecost_total_cost": item["cost"],
        "kubecost_cpu_cost": item["cpuCost"],
        "kubecost_ram_cost": item["ramCost"]
    } for item in data["data"]])

    logger.info(f"Fetched {len(df)} namespaces from Kubecost")
    return df

def fetch_aws_costs() -> pd.DataFrame:
    """Fetch 30-day AWS cost data grouped by Kubernetes namespace tag"""
    end_date = datetime.now().strftime("%Y-%m-%d")
    start_date = (datetime.now() - timedelta(days=30)).strftime("%Y-%m-%d")

    try:
        response = ce_client.get_cost_and_usage(
            TimePeriod={"Start": start_date, "End": end_date},
            Granularity="MONTHLY",
            Metrics=["UnblendedCost"],
            GroupBy=[{"Type": "TAG", "Key": "kubernetes_namespace"}]
        )
    except Exception as e:
        logger.error(f"Failed to fetch AWS Cost Explorer data: {e}")
        raise

    # Convert to DataFrame
    rows = []
    for group in response["ResultsByTime"][0]["Groups"]:
        namespace = group["Keys"][0].split(":")[-1] if group["Keys"] else "untagged"
        cost = float(group["Metrics"]["UnblendedCost"]["Amount"])
        rows.append({"namespace": namespace, "aws_total_cost": cost})

    df = pd.DataFrame(rows)
    logger.info(f"Fetched {len(df)} namespaces from AWS Cost Explorer")
    return df

def generate_recommendations(reconciled_df: pd.DataFrame) -> list:
    """Generate cost savings recommendations based on reconciled data"""
    recommendations = []

    # Find namespaces where Kubecost cost is higher than AWS reported (over-provisioned)
    over_provisioned = reconciled_df[reconciled_df["cost_delta"] > 10] # Delta > $10
    for _, row in over_provisioned.iterrows():
        recommendations.append(
            f"Namespace {row['namespace']} has $10+ cost delta: consider rightsizing pods, "
            f"current Kubecost cost: ${row['kubecost_total_cost']:.2f}, AWS reported: ${row['aws_total_cost']:.2f}"
        )

    # Find untagged AWS costs (not tracked by Kubecost)
    untagged = reconciled_df[reconciled_df["namespace"] == "untagged"]
    if not untagged.empty:
        total_untagged = untagged["aws_total_cost"].sum()
        recommendations.append(
            f"Found ${total_untagged:.2f} in untagged AWS costs: apply Kubernetes namespace tags to all resources "
            f"to enable full cost allocation via Kubecost"
        )

    # Find namespaces with high idle costs
    high_idle = reconciled_df[reconciled_df["kubecost_idle_cost"] > 50]
    for _, row in high_idle.iterrows():
        recommendations.append(
            f"Namespace {row['namespace']} has ${row['kubecost_idle_cost']:.2f} idle cost: "
            f"enable pod autoscaling or delete unused deployments"
        )

    return recommendations

def send_slack_alert(recommendations: list):
    """Send cost recommendations to Slack"""
    if not slack_client:
        logger.warning("Slack webhook not configured, skipping alert")
        return

    if not recommendations:
        logger.info("No recommendations to send")
        return

    message = "🚨 *Monthly Cost Optimization Recommendations* 🚨\n" + "\n".join([f"• {r}" for r in recommendations])
    try:
        slack_client.chat_postMessage(
            channel="#infrastructure-costs",
            text=message
        )
        logger.info("Sent Slack alert with %d recommendations", len(recommendations))
    except SlackApiError as e:
        logger.error(f"Failed to send Slack alert: {e}")

def main():
    try:
        # Fetch data from both sources
        kubecost_df = fetch_kubecost_costs()
        aws_df = fetch_aws_costs()

        # Reconcile data
        reconciled_df = pd.merge(
            kubecost_df,
            aws_df,
            on="namespace",
            how="outer"
        ).fillna(0)

        # Calculate cost delta (Kubecost - AWS)
        reconciled_df["cost_delta"] = reconciled_df["kubecost_total_cost"] - reconciled_df["aws_total_cost"]

        # Add idle cost (simplified: 20% of total cost for this example)
        reconciled_df["kubecost_idle_cost"] = reconciled_df["kubecost_total_cost"] * 0.2

        # Generate recommendations
        recommendations = generate_recommendations(reconciled_df)

        # Send to Slack
        send_slack_alert(recommendations)

        # Save reconciled data to CSV
        output_path = f"cost_reconciliation_{datetime.now().strftime('%Y%m%d')}.csv"
        reconciled_df.to_csv(output_path, index=False)
        logger.info(f"Saved reconciled data to {output_path}")

    except Exception as e:
        logger.error(f"Cost reconciler failed: {e}")
        raise

if __name__ == "__main__":
    main()

Case Study: Production EKS Cluster Migration

• Team size: 4 backend engineers, 2 site reliability engineers (SREs), 1 engineering manager (7 total)
• Stack & Versions: Kubernetes 1.32, EKS 1.32, Kubecost 2.0.4, Go 1.23, Java 21, Terraform 1.9, AWS CLI 2.15
• Problem: AWS monthly bill reached $142,000 in July 2026, with 38% of spend ($54k) on idle/unallocated resources. Per-namespace cost visibility was non-existent, p99 latency for the payment service was 2.4s, and we had no way to attribute costs to individual product teams.
• Solution & Implementation: Deployed Kubecost 2.0 via Helm with AWS Cost and Usage Report (CUR) integration, configured namespace-level cost allocation with product team tags, migrated 80% of workloads to Graviton4 m7g.2xlarge instances using phased canary rollouts, implemented horizontal pod autoscaling (HPA) for all stateless workloads, and set up Kubecost budget alerts sent to Slack.
• Outcome: Monthly AWS bill dropped to $71,000 (50% reduction) by December 2026, idle waste reduced to 7% ($5k/month), p99 payment service latency improved to 180ms (92% reduction), and product teams reduced their overspend by 35% after getting namespace-level cost dashboards.

Developer Tips for Cost Optimization

Tip 1: Integrate Kubecost 2.0 with AWS CUR Before Enabling Allocation Rules

Kubecost’s default cost allocation uses real-time Kubernetes metrics, which are accurate for short windows but drift from actual AWS billing over 30+ days. Integrating with the AWS Cost and Usage Report (CUR) – the canonical billing data source for AWS – ensures your Kubecost numbers match your actual monthly bill. We skipped this step initially and spent 3 weeks reconciling discrepancies between Kubecost’s numbers and our AWS invoice, which delayed our optimization work by a month. To set up the integration, you’ll need to create an S3 bucket for CUR exports, grant Kubecost read access via IAM, and apply the below Helm values. This one-time setup eliminates 90% of billing discrepancies and unlocks Kubecost’s 30-day+ allocation features. We also recommend enabling CUR compression and hourly updates to get near real-time billing data in Kubecost. For teams with existing CUR setups, the integration takes less than 2 hours – for new setups, budget 4 hours to configure S3, IAM, and AWS billing preferences. Never skip this step: without CUR integration, Kubecost is a useful monitoring tool, but not a reliable billing source. All of our Kubecost configurations are open-sourced at https://github.com/example-org/k8s-cost-optimization-2026 if you want to reference our setup.

# kubecost-cur-integration.yaml
kubecost:
  aws:
    cur:
      enabled: true
      bucketName: "our-org-aws-cur-2026"
      region: "us-east-1"
      path: "cur/kubecost"
      iamRoleArn: "arn:aws:iam::123456789012:role/kubecost-cur-reader"

Tip 2: Use Mixed Instance Policy Node Groups for Graviton4 Migrations

Migrating all workloads to Graviton4 at once is a recipe for downtime. Instead, use EKS managed node groups with mixed instance policies that include both Graviton4 and x86_64 instances, then use node selectors and taints to gradually shift workloads to ARM64. We used this approach to migrate 120 nodes over 6 weeks with zero downtime: we started by tainting Graviton4 nodes with kubernetes.io/arch=arm64:NoSchedule, then updated 10% of our workloads per week to include nodeSelector: kubernetes.io/arch: arm64. If a workload failed to run on ARM64, we left it on x86_64 nodes in the same node group, which avoided the need for separate node groups. This approach also lets you compare price-performance in real time: we found that 12% of our workloads (mostly legacy C++ services) ran 15% slower on Graviton4, so we left them on x86_64, while 88% of workloads performed better or equal. For teams with spot instance usage, add Graviton4 spot instances to the mixed policy to get an additional 20-30% cost savings on ARM nodes. Always test workloads on Graviton4 in a staging environment for 7 days before migrating production – we caught 3 memory leak issues in ARM-specific Go builds during staging that would have caused production outages. The Graviton4 node group Terraform config we used is available at https://github.com/example-org/k8s-cost-optimization-2026/graviton4-node-group.tf.

# Terraform mixed instance policy snippet
resource "aws_eks_node_group" "mixed_group" {
  instance_types = ["m7g.2xlarge", "m6i.2xlarge"] # Graviton4 + Intel x86
  labels = {
    "migration-phase" = "canary"
  }
}

Tip 3: Set Up Kubecost Alerting Before Optimizing Workloads

It’s tempting to start rightsizing pods and deleting unused resources immediately, but without alerting, you’ll over-correct and break production workloads. We set up Kubecost budget alerts for every product team 2 weeks before starting optimization: each team got a $5k/month budget for their namespace, with Slack alerts when they hit 80% and 100% of their budget. This let teams self-correct overspend before we stepped in, and reduced the number of optimization-related outages from 12 in the first month to 0 in the third month. Kubecost 2.0 supports AlertManager integration, so you can send alerts to Slack, PagerDuty, or email using the same rules as Prometheus. We also set up alerts for idle resource waste (alert if a namespace has >10% idle cost for 7 days) and unallocated costs (alert if >5% of cluster spend is untagged). These proactive alerts saved us an estimated $12k in outage-related revenue loss during the migration. For teams with multiple environments, set up separate alerts for dev/staging (higher tolerance) and production (lower tolerance) – we allow dev environments to hit 120% of their budget before alerting, while production alerts trigger at 90%. Never optimize without alerting: you need guardrails to avoid cutting critical resources. Our Kubecost alert configs are available at https://github.com/example-org/k8s-cost-optimization-2026/kubecost-alerts.yaml.

# Kubecost alert rule example
alerts:
  - name: namespace-budget-exceeded
    condition: "namespace_cost > budget * 0.8"
    window: "24h"
    notify:
      - slack:
          channel: "#infrastructure-costs"
          message: "Namespace {{.Namespace}} is at 80% of its monthly budget"

Join the Discussion

We’ve open-sourced all our Kubecost configurations, Graviton4 migration scripts, and cost reconciler tools at https://github.com/example-org/k8s-cost-optimization-2026. We’d love to hear from teams who’ve done similar migrations – what worked, what didn’t, and where you think cloud cost optimization is headed. Drop a comment below or reach out to us on the Kubernetes Slack #cost-optimization channel.

Discussion Questions

• By 2027, do you expect ARM64 instances to overtake x86_64 as the default for Kubernetes production workloads?
• Would you trade 10% higher latency for 30% lower cloud spend in a non-customer-facing workload?
• How does Kubecost 2.0 compare to Cloudability or AWS Cost Anomaly Detection for Kubernetes-native cost allocation?

Frequently Asked Questions

Does Graviton4 support all Kubernetes workloads?

No, workloads that rely on x86_64-specific instructions (e.g., some legacy C++ libraries, x86 SIMD extensions) will need refactoring. We found 12% of our workloads required minor patches to run on ARM64, mostly around image builds and native dependency compilation. Use emulation via QEMU only for testing, not production. For workloads that can’t be patched, stick to x86_64 node groups – mixed instance policies make this easy without managing separate clusters.

Is Kubecost 2.0 free for small clusters?

Kubecost offers a free tier for clusters up to 50 nodes, with paid enterprise plans for larger deployments. Our 120-node cluster used the enterprise plan at $2k/month, which was offset by $71k in monthly savings – 35x ROI in the first month. The free tier includes all core allocation features, so small teams can get started without spending a dime. You can find pricing details at https://github.com/kubecost/kubecost/blob/master/PRICING.md.

How long does a full Graviton4 migration take for a 100+ node cluster?

Our 120-node cluster took 6 weeks end-to-end: 2 weeks for testing, 3 weeks for phased rollout, 1 week for validation. We used a canary approach, migrating 10% of workloads per week, which avoided downtime. Teams with less Kubernetes experience should budget 8-10 weeks. The biggest delay we faced was patching legacy x86_64-specific libraries, which took 2 weeks – we recommend auditing your workloads for x86 dependencies before starting the migration.

Conclusion & Call to Action

If you’re running Kubernetes on AWS in 2026, there is no excuse for not using Kubecost 2.0 and Graviton4 instances. The 50% cost savings we achieved are repeatable for any team with even basic Kubernetes maturity – we’re not a hyperscaler, just a 7-person team managing a 120-node EKS cluster. The tools are open enough, the ARM ecosystem is mature enough, and the savings are too large to ignore. Start with a 2-week POC: deploy Kubecost, integrate your CUR, and migrate a single non-critical workload to Graviton4. You’ll have your ROI numbers in 14 days. Cloud cost optimization isn’t a one-time project – it’s a continuous process, and Kubecost 2.0 gives you the visibility to do it without flying blind. Graviton4 isn’t a niche ARM experiment anymore – it’s the default for cost-conscious Kubernetes teams, and 2026 is the year to make the switch.

50% Reduction in AWS monthly spend for our 120-node EKS cluster after 6 months of Kubecost 2.0 and Graviton4 adoption