Kubernetes Rightsizing
The Kubernetes Rightsizing agent finds pods on AWS EKS that request more CPU and memory than they use. It compares each container's requests against its actual usage from your observability integration, then recommends new requests and the annual savings. The agent never changes your running cluster.
What it detects
- Over-provisioned CPU requests: containers whose CPU request is higher than their P95 CPU usage over the lookback window.
- Over-provisioned memory requests: containers whose memory request is higher than their P95 memory usage over the lookback window.
The agent groups workloads by namespace, so one finding can cover several workloads in the same namespace.
How recommendations are calculated
The agent sizes each container's request to its P95 usage over a 14-day lookback window. P95 covers normal traffic spikes while still capturing savings, and avoids the under-provisioning risk of sizing to average usage.
Usage comes from the Datadog kubelet check. Current requests and limits come from kube-state-metrics.
You can change the lookback window, and set floors or limits on recommendations, in the agent's Additional context. See Tuning the agent.
What it investigates
A request above usage is not a confirmed finding. For each candidate, the agent:
- Checks the workload's usage history over the lookback window.
- Explains why the request is higher than the workload needs.
- Proposes new CPU and memory requests per container, with the expected annual savings and an effort rating.
How fixes are delivered
The agent runs in Notify mode, so every action needs your approval. For each finding you can:
- Fix it yourself with your AI coding assistant through Infracost Dev, using
/infracost fix-findings. - Hand it to an engineer as a Jira ticket or GitHub issue.
Tuning the agent
Add guidance in Additional context when a recommendation doesn't fit your environment. Examples:
| Goal | Example Additional context |
|---|---|
| Longer lookback | "Use a 30-day lookback window for all rightsizing analysis, not the default 14 days." |
| Task grouping | "Group all workloads in the same namespace into a single task. Keep workloads in different namespaces or owned by different teams in separate tasks." |
| Floors | "Never recommend below 100m CPU or 128Mi memory per container." |
| Max reduction per change | "Cap any single reduction at 50% of the current request. Step down over multiple changes." |
While you refine a new agent, delete and re-create it with the new Additional context, so all findings are reinvestigated with the new context immediately.
To stop findings for specific workloads, dismiss the finding and use Stop creating findings like this one. See Tuning your agents.
Prerequisites
- AWS Integration connected for the accounts that run your EKS clusters. The existing read-only role covers EKS. No extra permissions are needed.
- Datadog integration connected, with the Datadog Agent running on your clusters and the kubelet and kube-state-metrics checks enabled.
- Jira or the GitHub App connected, only if you want to send findings as tickets or issues.
Limitations
- Supports AWS EKS only.
- Supports Datadog only as the source of usage data.
- Recommends changes to requests. It does not change the running cluster.