Skip to main content

EKS Pod Resource Optimization Guide

Published 2026-02-12Updated 2026-06-305 min read

Reference Environment: EKS 1.30+, Kubernetes 1.30+, Metrics Server v0.7+

Overviewโ€‹

Pod resource configuration directly impacts cluster efficiency and cost. 50% of containers use only 1/3 of requested CPU, resulting in 40-60% average resource waste. This guide provides practical strategies for 30-50% cost reduction through Pod-level resource optimization.

Resource Requests & Limits Deep-diveโ€‹

Requests vs Limitsโ€‹

  • Requests: Minimum guaranteed resources for scheduling and QoS
  • Limits: Maximum enforced resources โ€” CPU throttling, Memory OOM Kill
PropertyCPUMemory
Over-limitThrottling (slowdown)OOM Kill (forced termination)
CompressibleYesNo

CPU Deep-diveโ€‹

CFS Bandwidth Throttling, millicore units (1 CPU = 1000m). Consider not setting CPU limits (Google/Datadog approach) โ€” CPU is compressible, throttling causes unnecessary degradation.

Memory Deep-diveโ€‹

Always set memory limits โ€” memory is incompressible, exhaustion causes node instability. Guaranteed QoS (requests = limits) recommended for databases. JVM apps: heap = 75% of limits. Node.js: --max-old-space-size = 70% of limits.

QoS Classesโ€‹

  • Guaranteed (requests = limits): Highest priority, never evicted first
  • Burstable (requests < limits): Middle priority
  • BestEffort (no requests/limits): Lowest priority, evicted first

VPA (Vertical Pod Autoscaler)โ€‹

Modes: Off (recommendations only), Initial (set at creation), Auto (live updates). Safe coexistence with HPA: VPA manages memory, HPA manages CPU-based scaling.

Right-Sizing Methodologyโ€‹

P95-based resource calculation with 20% buffer. Tools: Goldilocks, Kubecost recommendations, VPA Off mode.

EKS Auto Mode Resource Optimizationโ€‹

Auto Mode automates infrastructure but Pod-level requests/limits remain developer responsibility. Graviton + Spot automatic optimization for up to 90% cost savings.