[AEWS4] EKS Auto Mode 살펴보기

1. EKS Auto Mode란

EKS Auto Mode는 컨트롤 플레인뿐 아니라 데이터 플레인까지 AWS가 관리하는 EKS 운영 모드다. 2024년 12월 1일 re:Invent 2024에서 GA로 발표됐고, 쿠버네티스 1.29 이상 클러스터에서 쓸 수 있다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/automode.html

 

EKS를 운영해 본 사람이라면 "컨트롤 플레인만 매니지드"라는 표현이 충분하지 않다고 느낀 경험이 있을 것이다. 컨트롤 플레인 아래에는 운영자가 직접 챙겨야 할 영역이 두텁게 쌓여 있다. 노드 그룹 운영, OS 패치, Karpenter Helm 차트 관리, VPC CNI와 CoreDNS와 EBS CSI 데몬셋, AWS Load Balancer Controller 설치와 IRSA 매핑, 보안 패치 주기마다의 노드 교체 같은 일이다.

 

Auto Mode는 이 영역까지 AWS가 들고 간다. AWS 공식 한국 블로그가 한 줄로 요약했다. "EKS 컨트롤 플레인 외에도 AWS는 애플리케이션을 실행하는 데 필요한 EKS 클러스터의 AWS 인프라를 구성, 관리 및 보호합니다." 쉽게 말하면 운영자가 챙기던 데몬셋과 컨트롤러를 AWS가 가져가서, 사용자는 Pod과 워크로드 정의에만 집중하게 만든 모드다.

 

자동화되는 항목을 풀어서 보면 다음과 같다.

• 노드 라이프사이클 (생성, 패치, 교체)
• 컴퓨트 오토스케일링 (Karpenter)
• Pod과 서비스 네트워킹 (VPC CNI)
• 클러스터 DNS (CoreDNS)
• 블록 스토리지 (EBS CSI)
• 애플리케이션 로드 밸런싱 (ALB Controller)
• Pod 단위 IAM 자격 (Pod Identity Agent)

기존 EKS에서 위 항목을 각각 Helm 차트나 EKS Addon으로 운영했던 사람이라면, Auto Mode가 무엇을 가져갔는지 바로 감이 잡힌다. 본문은 이 항목들 가운데 변화가 큰 네 컴포넌트(노드, CNI/CSI, 로드밸런서, IAM)를 차례로 살펴본다.

2. 일반 EKS와의 차이 한눈에 보기

본격적으로 들어가기 전에 일반 EKS와 Auto Mode가 어디서 갈리는지를 표 하나로 정리해 둔다.

영역	일반 EKS	EKS Auto Mode
컨트롤 플레인	AWS 매니지드	AWS 매니지드
노드 OS와 패치	사용자 (NodeGroup, AMI 선택)	AWS 매니지드 (Bottlerocket variant)
Karpenter	사용자 (Helm 설치)	AWS 매니지드 (클러스터 밖에서 실행)
VPC CNI	사용자 (DaemonSet)	AWS 매니지드 (AMI 빌트인)
Cluster DNS (CoreDNS)	사용자 (Deployment)	AWS 매니지드 (노드 systemd 서비스)
EBS CSI Driver	사용자 (Addon)	AWS 매니지드
AWS Load Balancer Controller	사용자 (Helm + IRSA)	AWS 매니지드
EKS Pod Identity Agent	사용자 (Addon)	AWS 매니지드
Pod 워크로드	사용자	사용자
노드 SSH/SSM 접근	가능	불가능
IAM 매핑	aws-auth ConfigMap	EKS access entries 자동 매핑

 

표에서 굵게 시선이 가는 행이 사용자가 챙기던 영역이 AWS 매니지드로 옮겨간 줄이다. 3장에서 그 가운데 가장 변화가 큰 네 영역을 풀어서 살펴본다.

 

한 가지 흥미로운 점은, Auto Mode 클러스터를 만들고 kubectl get pods -A를 치면 결과가 거의 비어 있다는 사실이다. AWS Best Practices Guide의 설명을 보면 새로 만든 Auto Mode 클러스터에 떠 있는 Pod은 Metrics Server뿐이다. 일반 EKS에서 익숙했던 aws-node, coredns, ebs-csi-controller, aws-load-balancer-controller가 모두 클러스터 밖에서 AWS가 돌리는 형태로 바뀌었기 때문이다. 처음 보면 "어, 진짜 비어 있네"라는 인상을 받게 된다.

3. 자동화 영역 살펴보기

3.1 노드

일반 EKS에서 노드는 사실상 EC2 인스턴스였다. NodeGroup이든 Karpenter든 운영자가 챙길 항목이 많다. AMI 선택(Amazon Linux 2, Bottlerocket, Ubuntu, Windows), OS 패치 주기, 노드 그룹 인스턴스 타입, ASG 설정, Karpenter Helm 차트 버전, NodePool과 NodeClass YAML, SSH 키나 SSM 권한, 커널 튜닝과 보안 에이전트 같은 것들이다. 노드 자체를 사용자가 들고 있었으니 그 위에 얹히는 거의 모든 것에 사용자의 손이 닿았다.

 

Auto Mode에서 노드는 EC2 Managed Instance라는 새로운 인스턴스 종류로 동작한다. 표준 EC2와 어떻게 다른지 정리하면 이렇다.

표준 EC2	Auto Mode Managed Instance
사용자가 패치/업데이트 책임	AWS가 자동 패치·업데이트
EC2 API로 종료 가능	EKS가 워크로드에 맞춰 인스턴스 수 결정
SSH 접근 가능	Pod와 컨테이너만 배포 가능
사용자가 OS/AMI 선택	AWS가 OS/AMI 결정
Windows/Ubuntu 가능	Linux 컨테이너만
사용자가 인스턴스 타입 선택	AWS가 결정 (NodePool로 제한 가능)

 

쉽게 말하면 Auto Mode의 노드는 "어플라이언스"처럼 다뤄진다. 사용자가 직접 만지지 않고 AWS가 알아서 관리하는 가전제품 같은 존재가 된다. AWS 공식 문서도 "nodes are designed to be treated like appliances"라는 표현을 쓴다.

Bottlerocket variant

Auto Mode가 쓰는 OS는 표준 Bottlerocket이 아니라 그 위에 잠금을 더 건 variant다. 루트 파일시스템에 무결성 검사가 강제되고 SELinux Enforcing 모드가 동작한다. SSH와 SSM 같은 원격 접근 서비스는 아예 노드에 들어 있지 않다. 사용자가 노드에 진입할 길이 막혀 있다는 의미다.

 

이 잠금이 얼마나 단단한지는 보안 백서의 한 줄에서 드러난다. "Even the AWS account root user is unable to circumvent these constraints." AWS 계정 root user조차 우회하지 못한다. 보안은 강해지지만 사용자의 노드 접근권은 같이 사라진다. 이 부분은 4장에서 한 번 더 언급한다.

노드는 주기적으로 교체된다

Auto Mode의 노드는 패치하지 않고 교체한다. 새 AMI가 나오면 새 인스턴스를 띄우고 기존 인스턴스를 종료하는 방식이다. 두 개의 수치를 알아두면 좋다.

• 기본 NodePool(general-purpose)의 노드 만료 주기: 14일
• Auto Mode 전체의 강제 상한: 21일 (PDB가 막아도 강제 교체)

평균 2주에 한 번, 늦어도 3주에 한 번 노드가 새 AMI로 갈아엎어진다. AMI 자체는 일주일에 한 번 정도 새 버전이 나오고, 출시 전에 CVE 스캔과 노드 컨포먼스 테스트, Pod Identity 자격 획득 검증, GPU 호환성 테스트가 끝난 뒤에야 배포된다.

이 모델 덕분에 사용자는 OS 패치 주기와 CVE 대응 일정을 따로 잡지 않아도 된다. 사용자가 챙기던 일을 AWS가 가져간 대표적인 사례다.

Karpenter는 클러스터 밖에서 돈다

Auto Mode의 Karpenter는 클러스터 안에 Pod로 떠 있지 않다. AWS가 클러스터 외부에서 직접 운영한다. 사용자는 NodePool과 NodeClass 객체로 "어떤 워크로드를 어떤 종류의 노드에 띄울지"만 표현하면 된다. Karpenter Helm 차트 버전을 따라가거나 controller Pod의 리소스 limit을 조정하는 일이 사라진다.

 

Spot 인스턴스 중단 알림과 EC2 health event 처리도 AWS가 자동으로 처리한다. Spot 인스턴스를 적극 활용하던 팀이라면 이쪽의 자동 처리가 꽤 편하게 다가올 것이다.

3.2 CNI와 CSI

일반 EKS에서 kubectl get ds -n kube-system을 치면 데이터 플레인 컴포넌트가 줄지어 떴다. aws-node(VPC CNI), ebs-csi-node, kube-proxy 같은 DaemonSet과 coredns Deployment가 모두 클러스터 안에서 동작했다. 사용자가 버전과 권한과 리소스 limit을 관리했다.

 

Auto Mode에서는 같은 컴포넌트가 두 가지 방식으로 자리를 옮겼다. 노드 측 컴포넌트는 AMI 안에 systemd 서비스로 들어간다. 컨트롤러 측 컴포넌트는 클러스터 밖에서 AWS가 돌린다. 데몬셋도 컨트롤러 Pod도 사용자 클러스터에 보이지 않는다.

VPC CNI

가장 큰 변화는 설정 방식이다. 기존에 aws-node DaemonSet 환경 변수로 조정하던 설정(WARM_IP_TARGET, ENABLE_PREFIX_DELEGATION 같은 것)은 더 이상 동작하지 않는다. AWS 공식 문서가 "Configuration options for the previous AWS VPC CNI will not apply to EKS Auto Mode"라고 못 박는다. 대신 NodeClass 객체에서 통합 관리한다.

 

기본값도 바뀌었다. Prefix Delegation이 기본이 됐고, /28 prefix를 쓴다. Pod 수에 따라 IP 워밍 풀이 자동으로 늘었다 줄었다 한다. ENIConfig 같은 커스텀 네트워킹과 Security Groups per Pod 옛 방식, Warm IP/Warm prefix 직접 설정 등은 모두 미지원이다.

CoreDNS

CoreDNS는 더 이상 kube-system/coredns Deployment로 떠 있지 않다. 대신 각 노드의 systemd 서비스로 동작한다. DNS 응답이 노드 안에서 처리되니 네트워크 홉이 줄고 안정성이 좋아진다. CoreDNS Pod을 HPA로 스케일하던 작업이 사라진다.

EBS CSI

EBS CSI에서 알아둘 점은 두 가지다. 첫째, provisioner 이름이 바뀌었다. 기존 ebs.csi.aws.com이 아니라 ebs.csi.eks.amazonaws.com이다. 한 글자가 아니라 도메인 자체가 다르다. 둘째, Auto Mode는 StorageClass를 자동으로 만들어 주지 않는다. 사용자가 직접 만들어야 한다.

 

기본 동작은 더 안전한 쪽으로 옮겨갔다. 루트와 데이터 볼륨이 기본 암호화되고 KMS CMK 옵션도 지원한다. 단, EBS Detailed Performance Metrics를 Prometheus로 직접 수집하던 모니터링 스택은 Auto Mode에서 접근이 막혀 있다.

짧은 비교표

항목	일반 EKS	EKS Auto Mode
VPC CNI 배포	aws-node DaemonSet	AMI 빌트인 (systemd)
VPC CNI 설정	DaemonSet env var / ENIConfig	NodeClass 객체
Prefix Delegation	옵션	기본값
CoreDNS	Deployment	노드 systemd 서비스
EBS CSI provisioner	ebs.csi.aws.com	ebs.csi.eks.amazonaws.com
EBS 기본 암호화	옵션	기본값

3.3 로드밸런서

일반 EKS에서 Ingress로 ALB를 띄우는 과정은 단계가 길었다. aws-load-balancer-controller Helm 차트를 설치한 뒤 IRSA로 controller에 ALB·EC2·WAF 권한을 부여한다. webhook 인증서를 관리하고 controller 버전도 따라가야 한다. Ingress YAML에는 kubernetes.io/ingress.class: alb와 다수의 alb.ingress.kubernetes.io/* 어노테이션을 붙였다.

 

Auto Mode에서는 controller 자체가 매니지드다. Ingress 매니페스트만 들어오면 AWS가 ALB를 만들어 준다. 단, 매니페스트가 새 IngressClass를 가리켜야 한다.

• IngressClass controller: eks.amazonaws.com/alb
• API version: eks.amazonaws.com/v1

가장 주의할 부분은 어노테이션 호환성이다. 기존에 자주 쓰던 어노테이션 가운데 일부는 더 이상 동작하지 않거나 다른 방식으로 대체됐다.

기존 어노테이션	Auto Mode 대응
kubernetes.io/ingress.class: alb	미지원, spec.ingressClassName 사용
alb.ingress.kubernetes.io/group.name	IngressClass 안에서 지정
alb.ingress.kubernetes.io/waf-acl-id	미지원, WAF v2로 대체
alb.ingress.kubernetes.io/auth-type: oidc	미지원

 

기본 타겟팅 모드도 Instance Mode가 아니라 IP Mode다. 기본값으로 IP Mode를 쓰니까 Instance Mode에 의존하던 워크로드는 어노테이션으로 명시해야 한다.

 

한 가지 마이그레이션 함정이 있다. 기존 ALB Controller가 만들어 둔 ALB를 Auto Mode 관리로 옮기는 경로는 지원되지 않는다. 새 IngressClass로 새 Ingress를 만들어 트래픽을 옮기는 방식만 가능하다.

3.4 IAM과 Pod Identity

5주차 글(EKS IRSA 트러블슈팅 가이드)에서 IRSA가 깨질 수 있는 6가지 패턴을 정리했다. IRSA는 OIDC Provider 등록, ServiceAccount annotation, MutatingWebhook, SDK 호출, IAM Trust Policy 검증 5단계 위에서 동작한다. 그 5단계 가운데 하나라도 깨지면 AccessDenied가 떨어진다.

 

Auto Mode는 Pod Identity를 기본으로 쓴다. AWS 공식 문서에 "You do not have to install the EKS Pod Identity Agent on EKS Auto Mode clusters"라고 적혀 있다. Pod Identity Agent를 Addon으로 따로 깔지 않아도 자동으로 들어 있다.

 

더 큰 변화는 IAM 매핑이다. 일반 EKS에서는 IAM Role을 쿠버네티스 권한과 연결하려면 aws-auth ConfigMap을 수정해야 했다. Auto Mode에서는 EKS access entries로 자동 매핑된다. ConfigMap을 만지는 일이 사라진다.

 

Auto Mode는 두 개의 핵심 IAM Role을 사용한다.

• Cluster IAM Role: AmazonEKSComputePolicy, AmazonEKSBlockStoragePolicy, AmazonEKSLoadBalancingPolicy, AmazonEKSNetworkingPolicy, AmazonEKSClusterPolicy 5종 자동 부착
• Node IAM Role: AmazonEKSWorkerNodeMinimalPolicy + AmazonEC2ContainerRegistryPullOnly만 부여

노드 자체가 IAM 권한을 폭넓게 가지고 있던 기존 모델과 다르게, Node Role은 "Pod Identity Role을 가져올 수 있는 권한"과 "ECR pull 권한"만 남긴다. 사용자 워크로드가 필요로 하는 권한은 PodIdentityAssociation 객체로 SA에 붙인다.

 

4. Auto Mode 쓰기 전에 알아두면 좋은 점

Auto Mode가 가져간 책임이 많아진 만큼 사용자가 양보한 부분도 있다. 학습 정리를 위해 알아두면 좋은 제약사항을 정리한다.

노드에 직접 들어갈 수 없다

3.1에서 본 것처럼 SSH도 SSM도 막혀 있다. 노드에 진입해서 journalctl을 보거나 crictl ps로 컨테이너 상태를 확인하던 디버깅 방식이 통째로 사라진다. AWS는 그 빈자리를 네 가지 도구로 대체한다.

• NodeDiagnostic CRD: 노드의 시스템 로그와 네트워크 트래픽을 S3로 비동기 업로드
• aws ec2 get-console-output: 부팅·커널 단계의 콘솔 출력 확인
• kubectl debug node/<id>: debug Pod을 노드 namespace에 띄워 라이브 디버깅
• VPC Reachability Analyzer: 노드가 클러스터에 조인 못 할 때 경로 추적

라이브 디버깅이 필요할 때는 kubectl debug node가 가장 자주 쓰인다. debug Pod이 같은 노드의 namespace를 공유하므로 nsenter -t 1 -m journalctl -f -u kubelet 같은 명령으로 호스트의 kubelet 로그를 라이브로 따라갈 수 있다. SSH 대체 작업의 거의 모든 경우를 이 패턴으로 처리하면 된다.

 

Karpenter 이벤트 로그도 평소처럼 kubectl logs -n karpenter로 볼 수 없다. Karpenter가 클러스터 밖에 있기 때문이다. CloudWatch Logs Insights에서 kube-apiserver-audit 로그를 쿼리해야 한다. 자주 등장하는 이벤트 키워드는 DisruptionBlocked, Unconsolidatable, FailedScheduling, InsufficientCapacityError 같은 것들이다.

IRSA의 trust policy 길이 한계

학습 메모에는 "IRSA 512KB" 같은 표현이 있었는데 1차 자료로 다시 확인해 보니 정확한 단위가 다르다. AWS IAM trust policy의 길이 한계는 기본 2,048자, 상한 4,096자(증가 요청 가능)다. KB가 아니라 글자 단위다.

 

IRSA는 한 IAM Role을 여러 EKS 클러스터에서 공유하려면 그 Role의 trust policy에 클러스터마다 OIDC Provider URL을 모두 적어야 한다. 각 항목이 글자 수를 잡아먹다 보니 멀티클러스터 환경에서 8~12개쯤에서 4,096자 한계에 부딪힌다는 보고가 자주 보인다. Rafay의 분석이 12개 클러스터를 한계로 명시한다.

 

Pod Identity는 이 문제를 비켜 간다. trust policy를 만지지 않고 PodIdentityAssociation 객체로 어느 클러스터의 어느 SA가 어느 Role을 쓰는지 표현하기 때문이다. Auto Mode는 Pod Identity가 기본이라 멀티클러스터 운영에서 trust policy 길이 압박이 자연스럽게 풀린다.

MSK 같은 일부 워크로드는 Pod Identity가 안 통한다

학습 메모에 "Kafka 4시간 키 로테이션"이라고 적어 둔 부분도 1차 자료로 보면 정확하지 않다. 실제 동작은 "MSK IAM 인증이 Pod Identity의 동적 STS session name과 호환되지 않아 재인증에 실패"하는 쪽이다.

 

원리는 이렇다. MSK IAM 인증은 클라이언트가 보낸 STS session name을 토대로 권한을 확인한다. Pod Identity는 매 호출마다 새로운 무작위 session name을 만든다. 처음 인증할 때 쓰던 session name과 15분 뒤 자격 갱신 시점의 session name이 달라서 MSK가 "다른 신원"으로 보고 재인증에 실패한다. aws-msk-iam-auth 라이브러리의 Issue #143이 같은 현상을 그대로 적어 두었다.

consumer가 15분 동안 잘 동작하다가 자격 만료 시점에 떨어진다는 보고다.

 

IRSA는 고정된 session name을 쓰기 때문에 같은 문제가 발생하지 않는다. Auto Mode 클러스터에서도 IRSA는 함께 사용 가능하니, MSK 워크로드만 IRSA로 별도 설정하는 패턴을 쓰면 된다.

AMI 커스터마이징은 불가능하다

Auto Mode 노드의 AMI는 AWS가 제공하는 Bottlerocket variant로 고정되어 있다. 사용자가 자기 AMI로 바꿀 수 없다. AWS Best Practices Guide의 FAQ도 "currently the only supported AMIs are for Amazon-provided Bottlerocket"이라고 답한다.

 

호스트 레벨에서 동작해야 하는 보안 스캐너나 EDR 같은 에이전트는 AMI에 굽거나 노드에 직접 설치할 수 없다. AWS의 권장은 같은 기능을 쿠버네티스 DaemonSet으로 옮기는 방식이다. Pod 경계 안에서 동작 가능한 에이전트라면 큰 문제가 없지만, 노드 OS에 직접 깔려야만 동작하는 에이전트는 Auto Mode에 들어올 수 없다.

 

IMDS 설정도 잠겨 있다. IMDSv2와 hop limit 1이 강제고 변경 불가다. IMDSv1을 가정한 구버전 SDK는 Auto Mode 환경에서 자격을 가져올 수 없다.

5. 학습 정리

Auto Mode는 운영 부담을 크게 덜어 주는 매력적인 모드라고 느꼈다. 다만 노드 접근 차단과 AMI 고정처럼 사용자가 볼 수 있는 영역이 좁아지는 트레이드오프는 분명하다. 본인 워크로드가 호스트 레벨 접근이나 커스터마이징을 얼마나 요구하느냐가 결국 도입 가능 여부를 가른다고 본다.

6. 참고 자료

AWS 공식 문서

• Automate cluster infrastructure with EKS Auto Mode
• Learn about EKS Auto Mode Managed instances
• Learn about identity and access in EKS Auto Mode
• Learn about VPC Networking and Load Balancing in EKS Auto Mode
• Create an IngressClass to configure an Application Load Balancer
• Create a storage class
• Troubleshoot EKS Auto Mode
• Security Overview of EKS Auto Mode (Whitepaper)
• EKS Auto Mode Best Practices

AWS 공식 블로그

• Streamline Kubernetes cluster management with the new Amazon EKS Auto Mode (AWS News)
• Amazon EKS Auto Mode 출시 (한국 블로그)
• Amazon EKS Pod Identity