Danone, one of the world’s leading food and beverage companies, operates a global cloud infrastructure supporting critical workloads across research and innovation, supply chain, and digital platforms. Their Cloud-Native Engineering team manages a growing fleet of Amazon Elastic Kubernetes Service (Amazon EKS) clusters across multiple AWS accounts and regions.
As their Kubernetes footprint expanded, so did the operational burden—and the team needed a way to simplify without sacrificing control. In this post, we walk through how Danone adopted Amazon EKS Auto Mode to reduce operational overhead, strengthen security, and optimize costs.
The challenge: running Kubernetes at scale
Danone’s Cloud-Native Engineering team had built a mature, production-grade Kubernetes platform. Their clusters ran hundreds of pods serving public-facing and enterprise applications, including a Digital Health and R&I platform running front-end applications and APIs that support their medical studies ecosystem. The team had invested heavily in Terraform modules, CI/CD pipelines, and operational runbooks to keep everything running smoothly. But as the number of clusters and workloads grew, the team found itself spending more time maintaining the platform than improving it. What had started as manageable infrastructure work was becoming a bottleneck—every new cluster meant more node groups to tune, more add-ons to track, and more security configurations to audit. The challenges were clear:
- Manual add-on management—The AWS Load Balancer Controller, Amazon EBS CSI Driver, and Amazon EKS Pod Identity Agent each had their own upgrade cycle and compatibility matrix. These add-ons consumed node capacity and required constant attention.
- Kubernetes upgrades were a project, not a routine—Upgrading clusters was a multi-week effort. Some clusters had fallen behind into extended support—at six times the cost of standard support.
- Security compliance required manual effort—Meeting Danone’s cybersecurity standards meant manually configuring and auditing node settings, runtime policies, and patching schedules across every cluster.
- Node optimization was difficult with Managed Node Groups—Managed Node Groups made it hard to adapt instance types and scaling to the actual needs of each workload. The team couldn’t easily right-size nodes per application, resulting in clusters that were not optimized and consistently underutilized.
- Complex infrastructure as code—Each cluster required extensive Terraform to manage node groups, networking, IAM roles, and add-on versions. Changes were slow and error-prone.
The platform team wanted to focus on enabling development teams—but the operational tax of running Kubernetes kept pulling them back.
How EKS Auto Mode changes the equation
Amazon EKS Auto Mode fundamentally shifts the operational boundary. Instead of managing node groups, add-ons, and scaling policies, the platform team defines what their applications need—and Auto Mode handles the infrastructure underneath.
At the compute layer, Auto Mode manages nodes through Karpenter, which provisions right-sized instances on demand, bin-packs workloads efficiently, and consolidates underutilized capacity automatically. Critical add-ons—the Load Balancer Controller, EBS CSI Driver, and Pod Identity Agent—become AWS-managed, eliminating manual version tracking entirely. Nodes are based on Bottlerocket, a purpose-built, immutable, and security-hardened operating system designed specifically for running containers. With SELinux in enforcing mode, read-only root file systems, and a 21-day maximum node lifetime, the security baseline is built into the platform rather than layered on top.
For Danone, this meant a dramatically reduced operational scope—instead of managing infrastructure, add-ons, and scaling, the team could concentrate on their workloads, freeing them to invest in developer experience, application reliability, and business value.
From exploration to production
Danone’s migration to EKS Auto Mode took approximately nine months, from initial exploration to full production rollout across their cluster fleet.
The journey started with a hands-on immersion day where the platform team evaluated Auto Mode’s capabilities in a controlled environment—testing node provisioning, add-on management, and security defaults against their existing Terraform-managed setup. The team came away with a clear understanding of what migration would involve and confidence that Auto Mode could meet their production requirements.
Some of the production clusters to migrate had several hundred pods, which required a careful, incremental approach rather than a big-bang cutover. The team migrated applications one by one from legacy Auto Scaling Groups to Auto Mode nodes, controlling the blast radius at each step and validating behavior before proceeding. During the transition, they ran the legacy ALB Ingress Controller alongside the Auto Mode-managed controller simultaneously, shifting traffic gradually before decommissioning the old load balancers—avoiding any disruption to production. The Load Balancer Controller, EBS CSI Driver, and Pod Identity Agent were consolidated into their Auto Mode managed equivalents, freeing up node capacity that these components had previously consumed.
Figure 1—Danone’s EKS architecture before and after Auto Mode
In Figure 1, on the left, Danone administers Managed Node Groups with a fixed fleet of M6i instances, along with critical add-ons (EKS Pod Identity, EBS CSI Driver, AWS Load Balancer Controller). On the right, Managed Node Groups are replaced by Karpenter, which automatically selects and right-sizes a diverse set of instance types (C6a, M6i, C7g). Add-ons are now AWS-managed and updated automatically. Danone’s responsibility shrinks to application pods only.
Once the migration approach was validated, the team rolled Auto Mode across their remaining clusters. Terraform configurations for node groups and scaling policies were replaced with simple YAML manifests, and the extended support backlog was cleared entirely. The new architecture enables the platform team to concentrate on application-level concerns—deployment strategies, observability, and developer self-service—rather than infrastructure plumbing.
The benefits
By offloading node management, add-on lifecycle, and scaling to Auto Mode, the platform team reclaimed over 20% of their operational capacity. Kubernetes version upgrades went from multi-week projects to routine operations, and infrastructure as code went from complex Terraform modules to straightforward YAML manifests. The team now spends that recovered time on capabilities that directly serve their development teams.
On the security front, Auto Mode’s Bottlerocket-based nodes align with Danone’s cybersecurity standards out of the box. The team no longer maintains a separate hardening playbook for each cluster—immutable AMIs, SELinux enforcing, and automatic node rotation provide a compliant baseline from the moment a cluster is created.
Cost optimization came through Karpenter’s automated bin-packing, which drives node utilization to 80–90%, up from variable and often underutilized levels. Combined with Savings Plans and the elimination of extended support costs, the team achieved all the operational and security benefits of Auto Mode with no additional cost—the efficiency gains fully offset the Auto Mode management fee.
The migration also produced improvements beyond the primary goals: certificate autodiscovery using AWS Certificate Manager (ACM)—eliminating the need to hardcode certificate ARNs in Ingress manifests and simplifying pipeline management—better resource tagging and security group integration through Kubernetes manifests, and a cleaner ingress architecture with clear separation between application and infrastructure concerns.
Conclusion
In nine months, Danone went from managing every layer of their Kubernetes infrastructure—node groups, add-ons, scaling policies, security hardening—to a model where the platform team focuses almost entirely on applications and developer experience. EKS Auto Mode eliminated the undifferentiated heavy lifting that had consumed over 20% of the team’s capacity, while Karpenter’s automated bin-packing pushed node utilization to 80–90% and Bottlerocket-based nodes delivered a security baseline that meets enterprise compliance standards out of the box.
Any organization running Amazon EKS at scale—whether managing a handful of clusters or dozens across multiple accounts and regions—can follow a similar incremental path. The migration doesn’t require a big-bang cutover: start with one cluster, move workloads application by application, and expand once the approach is validated. The operational and security benefits compound with every cluster migrated—without increasing costs.
Get started with EKS Auto Mode
Ready to simplify your Kubernetes operations? Start here:
To discuss how EKS Auto Mode fits your Kubernetes strategy, reach out to your AWS account team or contact AWS.
The authors would like to thank Alberto Colombo, Lead Platform Engineer at Danone, who led the hands-on implementation of the EKS Auto Mode migration across Danone’s cluster fleet.