EKS Auto Mode 도입 가이드

작년 말 GA 된 EKS Auto Mode를 우리 팀도 새 클러스터에 적용했다. 몇 주 굴려보고 운영에서 부딪힌 부분들이 꽤 있어서, 도입을 고민하는 분들에게 도움이 될 만한 실무 가이드를 정리했다. 마케팅 문구가 아닌 "현실에서 뭐가 좋고 뭐가 아픈가" 관점이다.

처음 듣는 분을 위해 간단히 설명하면, EKS Auto Mode는 컴퓨트(노드), 네트워킹(VPC CNI/로드밸런서), 스토리지(EBS CSI), Karpenter, Pod Identity Agent 같은 클러스터 구성요소를 AWS가 관리형으로 묶어서 제공하는 모드다. 우리가 직접 Helm chart를 깔고 IRSA를 매핑하던 작업이 거의 사라진다. 대신 자유도는 줄어든다.

1. 사전 준비: 우리 클러스터가 적합한가

도입 전에 다음 체크리스트를 먼저 돌렸다. 하나라도 걸리면 일단 보류하는 게 낫다.

• 써드파티 CNI 의존성이 있나? Calico/Cilium을 CNI로 쓰고 있다면 Auto Mode는 못 쓴다. VPC CNI 외에는 지원하지 않는다. NetworkPolicy만 Cilium으로 쓰는 정도면 우회 가능하지만, eBPF 기반 데이터 패스가 필요하면 답이 없다.
• Windows 노드가 있나? Linux only다.
• IMDSv2 hop limit이 필요한 워크로드가 있나? Auto Mode는 hop limit 1로 하드코딩돼 있다. Datadog agent나 일부 AWS SDK 설정처럼 컨테이너 내부에서 IMDS에 접근해야 하는 경우 깨질 수 있다. 우리는 Pod Identity로 전환하면서 자연스럽게 해결됐지만, 레거시 코드가 IRSA + IMDS에 의존하면 사전 점검이 필수다.
• 노드 수명이 길어야 하는 워크로드가 있나? Auto Mode는 노드 최대 수명 21일을 강제한다. StatefulSet 기반 DB나 캐시는 PDB와 graceful node shutdown을 미리 검증해두지 않으면 21일마다 재기동 폭탄을 맞는다.
• 셀프 매니지드 Karpenter를 쓰고 있나? 공존 불가다. Auto Mode를 켜기 전에 기존 Karpenter를 완전히 제거해야 한다.

우리 팀의 경우 새 클러스터라 위 조건들이 다 통과했다. 기존 운영 클러스터를 옮긴다면 마이그레이션 비용이 꽤 클 수 있다.

2. Terraform으로 클러스터 생성

terraform-aws-modules/eks 모듈이 v20.31부터 Auto Mode를 깔끔하게 지원한다. 우리가 쓰는 설정의 핵심만 옮기면 이렇다.

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.31"

  cluster_name    = "platform-prod"
  cluster_version = "1.32"

  cluster_compute_config = {
    enabled    = true
    node_pools = ["general-purpose", "system"]
  }

  cluster_endpoint_public_access = false
  vpc_id     = var.vpc_id
  subnet_ids = var.private_subnet_ids

  # Auto Mode는 addons를 직접 관리한다. 직접 vpc-cni 같은 addon 블록 넣지 말 것
  cluster_addons = {}

  enable_cluster_creator_admin_permissions = true
}

여기서 두 가지 함정이 있다.

첫째, cluster_addons에 VPC CNI나 EBS CSI를 명시하면 충돌난다. Auto Mode가 알아서 관리하므로 비워두거나 CoreDNS 같은 일부만 명시하는 게 맞다.

둘째, node_pools에는 기본 제공되는 두 가지 풀(general-purpose, system)만 지정할 수 있다. 우리 팀처럼 GPU 노드나 ARM 전용 풀이 필요하면, 별도의 NodePool 리소스를 추후 kubectl로 따로 생성해야 한다(Karpenter의 NodePool CRD를 Auto Mode가 그대로 노출한다).

3. 첫 워크로드 띄우기: 노드는 어떻게 뜨는가

기본 풀에 워크로드를 띄우면 Karpenter가 알아서 노드를 띄운다. 처음에 신기했던 건, 노드가 떴다 사라지는 사이클이 매우 공격적이라는 점이다. 빈 노드가 5분만 있어도 통합(consolidation)이 일어나 사라진다.

장점은 비용이 무섭게 줄어든다는 것. 단점은 짧은 잡 위주 워크로드가 많으면 노드 부팅 오버헤드가 누적된다. 이런 경우 별도 NodePool을 만들어 consolidationPolicy: WhenEmpty와 disruption.consolidateAfter: 30m 같은 식으로 더 보수적인 정책을 줘야 한다.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: batch-pool
spec:
  template:
    metadata:
      labels:
        workload: batch
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30m
  limits:
    cpu: "200"

여기서 주의할 점은 nodeClassRef.kind가 EC2NodeClass가 아니라 NodeClass라는 것. Auto Mode가 자체 CRD를 쓴다. 셀프 매니지드 Karpenter 매니페스트를 그대로 가져오면 절대 안 된다.

4. 운영 중 부딪힌 것들

관측성 — 로그 접근이 막혔다가 풀린 이야기

Auto Mode 노드는 SSH가 막혀 있다. SSM도 안 된다. 처음엔 "이거 디버깅을 어떻게 하라는 거지" 싶었다. 다행히 2026년 2월부터 Karpenter 로그를 Managed Capability Logging으로 CloudWatch / S3 / Firehose에 보낼 수 있게 됐다. 활성화 안 해두면 사실상 노드 스케줄링 이슈가 났을 때 깜깜이다. 우리는 CloudWatch Logs로 보내고 있다.

빠른 트러블슈팅에는 여전히 kubectl get events -n kube-system 그리고 eks-auto-mode/compute 네임스페이스의 이벤트가 가장 효율적이다.

비용 — 9~12%의 프리미엄을 어떻게 볼 것인가

Auto Mode는 EC2 비용에 약 9~12%를 더 받는다. 클러스터당 환산하면 대략 월 $52 정도 추가다(소규모 기준). 처음엔 "이거 좀 비싸지 않나" 했는데, 우리 팀이 직전 분기에 Karpenter 업그레이드하다가 NodePool migration v1beta1 → v1으로 며칠 까먹은 걸 생각하면, 이 정도 비용으로 그 고통을 안 겪는 건 솔직히 싸다.

21일 노드 강제 재기동

PDB가 제대로 안 박혀 있으면 21일째 되는 날 새벽에 PagerDuty가 울 수 있다. 우리는 도입 첫 달에 한 번 데여서, 그 후로 모든 Deployment/StatefulSet에 PDB와 terminationGracePeriodSeconds를 명시적으로 점검하는 체크리스트를 만들었다.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: api

Pod Identity로 전환

Auto Mode는 IRSA보다 Pod Identity를 권장한다. 둘 다 동작은 하지만, Auto Mode 노드는 Pod Identity Agent를 빌트인으로 띄우기 때문에 후자가 더 자연스럽다. IRSA에서 옮기는 데 자체 스크립트를 짜서 ServiceAccount annotation을 다 갈아엎었다. 이 부분은 별도 글로 한번 정리해볼 예정이다.

5. 도입을 권장하는 케이스 / 권장하지 않는 케이스

권장: 새 클러스터, 인프라 전담 인력이 부족한 팀, 표준화된 워크로드(스테이트리스 API, 일반적인 배치) 중심, 자유도보다 운영 부담 감소가 더 중요한 팀.

권장하지 않음: Cilium eBPF를 데이터플레인으로 깊게 쓰는 팀, 노드에 커스텀 데몬셋을 깔아서 kernel-level 작업을 하는 팀, GPU 워크로드 비중이 크고 노드 풀 커스터마이징이 많이 필요한 팀, 노드 수명이 길어야 하는 레거시 워크로드.

써본 결론은 "괜찮다, 다만 자유도를 일부 양보할 각오는 있어야 한다"는 정도. 우리 팀 같은 일반적인 SaaS 백엔드 워크로드라면 시간을 굉장히 많이 아껴주는 도구다. 반대로 인프라 자체가 제품인 팀이라면 셀프 매니지드 Karpenter가 여전히 답이라고 본다.

혹시 마이그레이션이나 NodePool 설계 관련해서 다른 경험 있으신 분 있으면 댓글이나 이메일로 공유 주시면 감사하겠다.