DelightRoom's Case Study on Streamlining Multi-Cluster Operations with Amazon EKS Auto Mode

DelightRoom is a global app company that operates Alarmy and DARO. In November 2025, it migrated its existing 5 EKS clusters to Amazon EKS Auto Mode, and now operates 10 or more clusters, all on Auto Mode.

Under the previous EKS operations, upgrade burden was heavy. Even after upgrading the Control Plane, Add-ons had to be adjusted separately, requiring individual management of a total of 7 components: VPC CNI, kube-proxy, CoreDNS, EBS CSI driver, nodes, and self-managed Karpenter. In particular, Karpenter had to go through CRD changes in v0.32.0 and schema changes in v1.0.0 to reach v1.1, and combined with blue-green transitions and compatibility matrix checks, this took 4-6 hours per cluster. Auto Mode has AWS manage networking, storage, and compute, greatly reducing this burden, and it also changed the Shared Responsibility Model, shifting Data Plane management and AMI patching—previously the customer's direct responsibility—over to AWS.

• They used Pulumi to manage the in-place migration, and instead of upgrading Karpenter to v1.1, they took a workaround strategy of cleaning up the Helm release, CRDs, and SQS Interruption Queue before enabling Auto Mode. Taking advantage of the fact that existing nodes and Pods were preserved and only new scaling was temporarily paused, they completed the migration in about under 1 hour during low-traffic early morning hours.
• In the development environment, they first checked the label differences between karpenter.k8s.aws/* and eks.amazonaws.com/* to catch nodeSelector and toleration conflicts, and before production, they automatically identified and fixed workloads using the old labels.
• Observability was reinforced with CloudWatch Vended Logs and the NodeDiagnostic CRD. After first enabling AUTO_MODE_COMPUTE_LOGS and AUTO_MODE_IPAM_LOGS, they built a Python automation script to collect diagnostic logs based on NodePool labels (karpenter.sh/nodepool) or instance IDs, blocked consolidation with karpenter.sh/do-not-disrupt, and then collected the logs via S3 pre-signed URLs. The retention period was set to 30 days.

Initially, there was also a race condition where Pods on new nodes would run before CoreDNS was fully up, causing DNS lookups to fail with read: connection refused. After tracing the cause together with AWS Support, it turned out to be a specific AMI issue, which was resolved once the fixed AMI was automatically applied. At the same time, they added a wait-for-dns init container as a defense line to prevent recurrence.

After adoption, upgrade time was reduced to under 30 minutes, and the number of directly managed components went from 7 to 0. With fewer repetitive upgrade and diagnostic tasks, it has become much easier for a small infrastructure team to operate multiple clusters.