# Amazon EKS

Sedai continuously right-sizes Amazon EKS pods, nodes, and purchasing — eliminating waste while protecting availability, with cluster compaction built in.

## Optimize Amazon EKS Without the Guesswork

Most EKS teams set resource requests once, based on worst-case estimates, and never revisit them, leaving clusters chronically overprovisioned and expensive to run. Sedai continuously right-sizes pods, nodes, and purchasing to eliminate waste while protecting availability.

Sedai is an autonomous cloud optimization platform that continuously right-sizes Amazon EKS pods, nodes, and purchasing based on real workload behavior — not static rules or manual estimates. It works alongside Karpenter or Cluster Autoscaler, improving the signal quality your autoscaler relies on while eliminating the overprovisioning that drives up costs and corrupts scaling decisions. Sedai writes every change back to your Terraform, Helm, or Kustomize configs as a PR, so optimizations persist across deployments instead of drifting back.

## EKS Optimization Isn't a One-Time Task. It's a Compounding Problem.

EKS removes control plane management — but node sizing, pod resource requests, and scaling configuration still fall on your team. Most clusters get provisioned for worst-case estimates and never revisited, creating downstream consequences that compound over time.

### Overprovisioned pods corrupt your autoscaler's signals.

When resource requests are too high, Cluster Autoscaler adds nodes based on phantom demand — so oversized workloads drive an oversized cluster, and the two problems reinforce each other.

### Manual optimization at cluster scale isn't sustainable.

Rightsizing pods across dozens of services requires ongoing analysis of actual behavior, not a one-time pass. By the time you finish, the workloads you started with have already drifted.

### Getting it wrong has direct reliability consequences.

Too-low requests risk CPU throttling and OOM kills. Too-tight limits cause latency spikes under burst traffic. There's no safe direction to guess.

## How We Help

### Workload Right-Sizing

Sedai autonomously tunes pod CPU and memory requests based on real consumption patterns — P95/P99, not worst-case estimates. Changes are applied during safe maintenance windows with rollback if error rates spike. No VPA required.

### Node & Cluster Optimization

Selects optimal instance types, redistributes workloads across nodes, and applies cluster compaction to eliminate underutilized nodes. Works with both Cluster Autoscaler and Karpenter — improving their decisions by feeding accurate pod requests upstream.

### Cost Visibility & Purchasing

Maps workload-level cost attribution across compute, GPU, storage, and network. Recommends the right mix of on-demand, Savings Plans, Reserved Instances, and Spot based on actual usage stability — not blanket commitments.

### IaC-Native Changes

Every optimization is written back to Terraform, Helm, or Kustomize as a pull request. Changes persist across deployments. No config drift. No "optimization that disappears on the next rollout."

## Sedai vs Karpenter/EKS Auto Mode

| Karpenter/EKS Auto Mode | Sedai |
| --- | --- |
| Provisions nodes based on pod requests. If those requests are wrong (and they usually are), Karpenter scales the wrong infrastructure — efficiently. It doesn't analyze actual workload behavior, adjust pod resources, or optimize purchasing. Node-level provisioning without pod-level intelligence compounds overprovisioning. | Continuously right-sizes pod CPU and memory based on real consumption, then feeds accurate requests to Karpenter so it provisions the right nodes. Adds cluster compaction, purchasing optimization (Spot, Savings Plans, Reserved), and writes every change back to IaC as a PR. Karpenter handles where pods run. Sedai handles what they actually need — and keeps it current. |

## Stop Setting It and Forgetting It.

## Frequently Asked Questions

### Does Sedai support both managed node groups and self-managed nodes?

Yes. Sedai works with EKS managed node groups, self-managed EC2 node groups, and clusters using Karpenter for node provisioning. Optimization recommendations and autonomous actions adapt based on how your cluster is configured. Note: this refers to Sedai's core optimization capabilities, which adapt to your node provisioning setup. The Karpenter Migration Assistant, which automates migrating existing node groups to Karpenter, currently supports EKS Managed Node Groups only — self-managed node groups and Fargate aren't yet supported.

### How does Sedai interact with Cluster Autoscaler or Karpenter?

Sedai complements your autoscaler rather than replacing it. By ensuring pod resource requests accurately reflect actual consumption, Sedai improves the signal quality that Cluster Autoscaler and Karpenter use to make scaling decisions — reducing over-provisioning at the node level as a result. For EKS teams still on Cluster Autoscaler and Managed Node Groups, the Karpenter Migration Assistant can also automate the move to Karpenter itself — handling compatibility checks and a safe, phased cutover so you don't have to do it manually.

### Will Sedai's changes affect running workloads or cause pod restarts?

Resource request and limit changes in Kubernetes do require pods to be restarted to take effect. Sedai schedules these changes to minimize disruption — respecting PodDisruptionBudgets, replica counts, and traffic patterns — and monitors stability after each change. If a restart causes instability, Sedai rolls back automatically.

### Do you support Fargate profiles on EKS?

Yes. Sedai supports EKS clusters using Fargate profiles alongside EC2 node groups. Optimization behavior adapts to the Fargate execution model, where node-level configuration isn't applicable and right-sizing focuses on pod-level resource allocation.

### How long does it take before Sedai starts making changes?

Sedai observes your cluster before acting. The profiling period typically runs 2–4 weeks, during which Sedai builds behavioral baselines for your workloads. Recommendations become visible within the first week; autonomous actions begin once confidence thresholds are met.