# Azure AKS Sedai continuously rightsizes AKS pods and node pools together, then attributes cost by team — all through small, validated changes with no disruption. ## From Pods to Node Pools, Optimized Together AKS workloads are provisioned once against worst-case estimates, and the node pools underneath inherit that waste — running oversized, mismatched, or underutilized. Sedai continuously rightsizes pods and containers, then optimizes node type, count, and segregation to match, while attributing cost back to the teams responsible. ## Rightsizing Pods Doesn't Fix a Cluster on Its Own Kubernetes workloads and the infrastructure underneath them are two separate optimization problems, and most teams only have the bandwidth to guess at one — usually with static, worst-case requests that ripple all the way down to the node pool. ### Static resource requests set the ceiling for everything above and below them. Teams size pods for worst-case load and rarely revisit it, and manually rightsizing dozens of clusters on an ongoing basis is guesswork that carries risk of causing performance issues or outages if done too aggressively. ### Node pools inherit whatever inefficiency the workloads create — and add their own. VM instance types that don't match the workload profile, underutilized pools that never get consolidated, and mixed workloads sharing infrastructure they shouldn't all compound the waste from oversized pods. ### Shared clusters obscure who's actually spending what. Without workload-level attribution, the costs of compute, storage, GPU, and network usage in a shared cluster are difficult to trace back to the team or business unit responsible for them. ## How We Help ### Autonomous Workload Optimization Sedai analyzes real-time CPU and memory data and continuously adjusts pod scaling through small, validated changes, moving workloads to their optimal state without disruption. ### Node & Cluster Optimization After rightsizing workloads, Sedai recommends better-matched instance types, resizes or consolidates node pools, and suggests splitting mixed workloads onto more specialized infrastructure. ### Cost Attribution & Application-Aware Tuning Get workload-level cost attribution across compute, storage, and network, with trade-offs tuned to whether a workload is latency-sensitive or cost-sensitive. ## Stop Guessing at Every Layer of Your Cluster. ## Frequently Asked Questions ### Does Sedai optimize node pools, or just the pods running on them? Both, in sequence. Sedai first rightsizes pod-level CPU and memory requests, then analyzes the collective needs of each node pool to recommend better-matched instance types, resizing, consolidation, or splitting mixed workloads onto specialized pools. ### How does Sedai avoid causing performance issues while making changes? Sedai applies a series of small, validated changes rather than large, aggressive shifts, moving workloads toward their optimal configuration gradually and monitoring for issues along the way. ### Can Sedai tell the difference between a latency-sensitive service and a batch job? Yes. Sedai's application-aware intelligence factors in what kind of workload it's optimizing, making different cost-versus-performance trade-offs for latency-sensitive services than it would for cost-sensitive batch workloads. ### We run shared clusters across multiple teams — can Sedai help with cost attribution? Yes. Sedai attributes compute, GPU, storage, and network costs down to the individual workload, so teams and business units can see the true cost of what they're running, even in a shared cluster. ### Does Sedai work alongside Azure's Cluster Autoscaler? Yes. Sedai doesn't replace the autoscaler — it acts as an intelligence layer that makes it more efficient. Sedai analyzes your workload profile and refines the set of choices the autoscaler has to work with, such as narrowing a range of 15 eligible VM instance types down to the five with the best cost-performance fit, without disrupting your existing operational setup.