AWS EKS Study(AEWS) 4기 9주차 Amazon EKS AutoMode와 GPU/AI 워크로드

AWS EKS Study(AEWS) 4기 9주차 Amazon EKS AutoMode와 GPU/AI 워크로드

1. 개요

이 게시물은 9주차 정용준님이 진행하신 Amazon EKS AutoMode와 GPU/AI 워크로드의 내용과 GKE Autopilot의 비교를 기록한 게시글입니다.

2. 두 서비스가 등장한 배경과 Managed K8s 진화 흐름

Managed Kubernetes의 진화는 Data Plane을 얼마나 추상화할 것인가의 문제였습니다. 초기 EKS와 GKE는 Control Plane만 관리했고, Cluster Autoscaler 시대를 거쳐 Karpenter가 인스턴스 다양성과 동적 프로비저닝의 표준이 되었습니다. 다음 단계는 Data Plane 전체를 사용자 시야에서 지우는 것이었는데, 두 회사가 이 단계에 진입한 시점이 다릅니다.

GKE Autopilot은 2021년 2월 출시되었고, EKS Auto Mode는 약 3년 10개월 뒤인 2024년 12월 re:Invent에서 GA로 발표되었습니다. 이 시점 차이는 단순한 후발 진입 이상의 의미가 있습니다. AWS는 그 사이에 자사 OSS인 Karpenter를 업계 표준으로 키워냈고, Auto Mode를 만들 때 Karpenter를 Managed화하는 길을 택했습니다. 이는 사용자가 NodePool/NodeClass를 통해 인스턴스 선택에 관여할 수 있는 여지를 남기는 결과로 이어졌습니다. 반면 Google은 출발부터 Pod 중심 모델을 고수했고, 노드라는 개념을 사용자 시야에서 지우는 방향으로 일관되게 진화시켰습니다.

여기서 기억해야 할 것은 "어느 쪽이 더 성숙한가"가 아니라 "두 회사가 다른 출발선에서 다른 시점에 시작했다"는 사실입니다. 이 차이가 뒤의 모든 비교 항목, 특히 GPU 워크로드에서 크게 벌어집니다.

3. 동작 원리

TL;DR: EKS Auto Mode는 노드가 보이지만 만질 수 없고, GKE Autopilot은 노드 자체가 사용자 시야에서 사라진다

3.1 EKS Auto Mode 아키텍처

Karpenter 컨트롤러가 사용자 클러스터의 Data Plane이 아니라 AWS 관리 영역에서 동작하고, Karpenter pod 자체를 운영할 필요가 없습니다. 컴퓨트 자동 스케일링뿐 아니라 ALB Controller, EBS CSI Driver, VPC CNI, kube-proxy까지 Control Plane에서 함께 Managed됩니다. 이 컴포넌트들은 사용자 Data Plane의 pod로 보이지 않으며, 업그레이드 책임도 AWS가 집니다. CoreDNS는 별도로 다뤄야 하는데, Auto Mode는 전통적인 CoreDNS Deployment 대신 각 노드의 시스템 서비스로 CoreDNS를 실행합니다. Auto Mode와 일반 Managed Node Group이 공존하는 클러스터라면 기존 CoreDNS Deployment는 그대로 유지해야 합니다.

노드는 Bottlerocket 기반 커스텀 AMI를 강제 사용하고, SELinux 강제 접근 제어와 읽기 전용 루트 파일시스템이 적용됩니다. SSH/SSM 직접 접근은 차단되며, 디버깅이 필요한 경우 NodeDiagnostic CRD로 시스템 로그를 수집합니다. 호스트 레벨 도구가 필요하면 DaemonSet으로 배포해야 합니다.

가장 중요한 제약은 노드 최대 수명입니다. Auto Mode가 생성한 노드는 21일 후 자동 교체되며, 이 값은 NodePool의 spec.template.spec.expireAfter로 줄일 수만 있고 늘릴 수는 없습니다. NodePool 단위 disruption budget으로 voluntary disruption은 차단할 수 있지만, 21일 만기 교체는 차단되지 않습니다. 그리고 Auto Mode 노드는 pod 수가 (110개 하드 캡)과 (인스턴스별 max pods 계산값) 중 작은 값으로 제한됩니다. 큰 인스턴스라고 해서 늘 110개가 보장되는 게 아니라, 신세대 Nitro v6 이상에서는 계산값이 110에 접근하지만 그 이하 세대에서는 더 낮을 수 있습니다. 어느 쪽이든 110 이상은 절대 넘지 못하므로, 큰 인스턴스로 노드 수를 줄이려는 흔한 패턴은 통하지 않습니다.

사용자에게 남는 컨트롤은 NodePool과 NodeClass 정의, 인스턴스 패밀리/크기/구매옵션(On-Demand, Spot, Reserved, Capacity Blocks) 선택, 그리고 Control Plane 버전 업그레이드 트리거입니다. Control Plane 업그레이드가 트리거되면 노드는 롤링으로 교체됩니다.

3.2 GKE Autopilot 아키텍처

사용자는 Pod 스펙만 다룹니다. GKE 1.32.3-gke.1927002 이후의 Autopilot은 container-optimized compute platform 위에서 동작하는데, 이 플랫폼은 실행 중인 노드를 동적으로 리사이즈하면서 fraction 단위 CPU(최소 50m)부터 28 vCPU까지 스케일합니다. 1.33부터는 in-place pod resize까지 지원되어, 디스럽션 없이 pod 리소스를 조정할 수 있습니다. GKE는 사용자에게 보이지 않는 사전 프로비저닝된 컴퓨트 풀을 유지하므로 스케일아웃 시 새 노드를 부팅하는 대기시간이 거의 사라지고, 공식 자료 기준 pod 스케줄링이 기존 Autopilot 대비 최대 7배 빨라졌다고 보고됩니다.

하드웨어 요구사항(GPU, TPU, Arm, 특정 머신 시리즈)은 ComputeClass로 표현합니다. 기본 ComputeClass는 autopilot(x86)과 autopilot-spot이고, 추가로 Balanced, Scale-Out, Accelerator 같은 빌트인 클래스 또는 사용자 정의 클래스를 쓸 수 있습니다. 이 메커니즘이 1.33.1-gke.1107000 이후 Standard 클러스터에서도 부분적으로 도입되어, "전체 클러스터 Autopilot"과 "Autopilot ComputeClass를 선택한 워크로드만 Autopilot"이라는 두 가지 운영 모델이 공존하게 되었습니다.

보안 기본값으로 Pod Security Standards가 admission controller로 강제됩니다. Privileged 컨테이너, hostNetwork, hostPID는 기본적으로 금지되고, kube-system 네임스페이스 수정도 막혀 있습니다. 클러스터는 release channel에 강제 등록되며, Control Plane과 노드 업그레이드를 사용자가 선택적으로 트리거할 수 없습니다. Pod uptime SLO가 포함된 SLA가 Control Plane뿐 아니라 pod 컴퓨트 용량에도 적용됩니다.

3.3 구조 비교 다이어그램

flowchart LR
    subgraph EKS["EKS Auto Mode"]
        direction TB
        subgraph EU["사용자 영역"]
            E1["Pod spec"]
            E2["NodePool / NodeClass<br/>(Bottlerocket 고정)"]
        end
        subgraph EV["가시성 영역 — 조회만 가능"]
            E3["노드 메타데이터"]
            E4["SSH/SSM 차단<br/>NodeDiagnostic CRD"]
        end
        subgraph EM["Managed 영역 — AWS 운영"]
            E5["Karpenter (off-cluster)"]
            E6["ALB Controller · EBS CSI<br/>VPC CNI · kube-proxy"]
            E7["CoreDNS (노드 시스템 서비스)"]
            E8["NVIDIA device plugin · DCGM"]
            E9["Node Monitoring Agent<br/>Neuron Monitor"]
        end
        EU --> EV --> EM
    end

    subgraph GKE["GKE Autopilot"]
        direction TB
        subgraph GU["사용자 영역"]
            G1["Pod spec"]
            G2["ComputeClass (선택)"]
        end
        subgraph GV["가시성 영역 — 사실상 없음"]
            G3["노드 접근 불가<br/>노드 객체 거의 노출 안 됨"]
        end
        subgraph GM["Managed 영역 — Google 운영"]
            G4["Container-optimized<br/>compute platform"]
            G5["동적 노드 리사이즈<br/>+ 사전 프로비저닝 풀"]
            G6["Pod Security Standards<br/>admission 강제"]
            G7["Release channel<br/>자동 업그레이드"]
        end
        GU --> GV --> GM
    end

    classDef user fill:#cfe2ff,stroke:#0d6efd,color:#000
    classDef vis  fill:#e9ecef,stroke:#6c757d,color:#000
    classDef mgmt fill:#495057,stroke:#212529,color:#fff

    class EU,GU user
    class EV,GV vis
    class EM,GM mgmt

다이어그램에서 읽어야 할 메시지는 세 영역의 비율입니다. EKS Auto Mode는 사용자 영역에 NodePool이 남아 있고 노드 메타데이터가 조회 가능한 가시성 영역에 들어가지만, GKE Autopilot은 사용자 영역이 사실상 Pod spec과 ComputeClass뿐이고 가시성 영역은 비어 있다시피 합니다. Mermaid가 영역 크기를 비율로 강제할 수는 없으니 이 점은 텍스트로 보완합니다.

4. 제약사항 비교

두 서비스 모두 노드 레벨 접근을 보안 경계로 인정하지 않는다는 공통 전제 위에 서 있습니다. 그러나 그 전제를 구현하는 방식이 달라서 운영 시점에 부딪히는 제약이 다릅니다.

항목	EKS Auto Mode	GKE Autopilot
노드 OS	Bottlerocket 커스텀 변형 (고정)	Container-Optimized OS (Google 관리)
커스텀 AMI/이미지	불가	불가
노드 SSH/SSM 접근	차단, NodeDiagnostic CRD 사용	차단
최대 노드 수명	21일 강제, 단축만 가능	명시적 21일 제한 없음, release channel 기반 자동 업그레이드
노드당 pod 수	110 하드 캡 (max pods 계산값과의 최솟값)	빌트인 ComputeClass에 따라 다름
호스트 레벨 도구 배포	DaemonSet	DaemonSet, 단 hostNetwork/hostPID 제한
Privileged Pod	제한적 허용	기본 금지 (Pod Security Standards)
kube-system 수정	제한	차단
리소스 요청 자동 보정	없음	있음 (최소값/CPU:메모리 비율 강제)
노드 0까지 스케일 다운	가능	가능
버전 업그레이드	사용자 트리거 (Control Plane)	release channel 자동
GPU 공유 (time-slicing/MIG)	미지원	지원
대규모 운영 제약	150 노드 초과 시 AWS 사전 협의 권장	명시적 제한 없음

표에서 가장 자주 발목 잡는 항목은 세 가지입니다. 첫째는 EKS Auto Mode의 21일 노드 수명. 둘째는 EKS Auto Mode의 노드당 pod 110 캡. 셋째는 GKE Autopilot의 Pod Security Standards 강제. 1번과 3번은 뒤의 7번에서 더 다루고, 2번은 마이그레이션 시 노드 수 증가로 비용 모델을 흔들 수 있어 사전 검토가 필요합니다.

5. 과금 모델

5.1 두 모델의 구조

EKS Auto Mode는 세 가지 항목의 합산입니다. 클러스터당 Control Plane $0.10/hr(standard support 기준), EC2 인스턴스 비용, 그리고 인스턴스 타입별로 산정되는 Auto Mode 관리 수수료. 관리 수수료는 인스턴스 타입별로 다르지만 On-Demand 가격의 약 12% 수준이고, 초 단위로 1분 최소 과금이 적용됩니다. 중요한 디테일은 EC2 구매옵션(Reserved, Savings Plans, Spot)을 적용해도 관리 수수료에는 할인이 들어가지 않는다는 점입니다. 수수료는 인스턴스 라이프사이클 그 자체에 붙는 비용이라 EC2 가격과 별개로 계산됩니다.

Kubernetes 마이너 버전이 standard support 14개월을 넘기면 Control Plane 비용이 $0.60/hr로 6배 점프하는 extended support 함정은 Auto Mode에서도 동일하게 작동합니다. 함정의 디테일 하나를 더하자면, CLI나 Terraform 같은 IaC로 생성한 클러스터는 기본값이 EXTENDED로 설정되어 14개월이 지나는 순간 자동 점프합니다. 자동 업그레이드를 원한다면 명시적으로 STANDARD로 바꾸거나, 그냥 분기별 업그레이드를 일정에 묶어두는 편이 안전합니다.

GKE Autopilot은 두 가지 과금 모델이 공존합니다. 기본은 Pod 기반 모델로, container-optimized compute platform이나 Balanced/Scale-Out ComputeClass를 쓰는 Pod는 리소스 요청량 기준으로 vCPU-시, GB-시, ephemeral storage GB-시 단가로 과금됩니다. 2026년 기준 us-central1에서 약 $0.0445/vCPU-hr, $0.0049/GiB-hr 수준이고 1초 단위로 빌링됩니다. Control Plane 비용은 동일하게 $0.10/hr이지만, 빌링 계정당 월 $74.40 무료 크레딧이 적용되어 단일 클러스터 운영 시 사실상 Control Plane 비용이 상쇄됩니다.

특정 하드웨어(GPU, TPU, 특정 머신 시리즈)를 요청하는 워크로드는 Pod 기반이 아닌 노드 기반 모델로 자동 전환됩니다. 이 경우 Compute Engine 인스턴스 가격에 Autopilot 관리 프리미엄이 추가되어 청구됩니다. 이 분기점이 5.3에서 다룰 GPU 워크로드 과금의 핵심입니다.

5.2 시나리오를 이용한 가격 비교

추상적 비교는 의미가 없으므로 세 가지 시나리오로 따져봅니다.

시나리오 A: 24/365 안정 운영 웹 서비스, Pod 리소스 요청이 일정

GKE Autopilot은 Pod 요청 그대로가 청구 단위가 되어 노드 빈 패킹 손실이 없습니다. EKS Auto Mode는 Karpenter가 적정 인스턴스를 골라 빈 패킹을 잘 해주지만, 110 pod 캡과 21일 노드 교체 시 일시적인 over-provisioning이 발생할 수 있습니다. 안정 트래픽에서는 GKE Autopilot이 약간 유리한 경향이지만, 결론은 Pod 리소스 요청을 얼마나 정확하게 설정했는지에 전적으로 달려 있습니다. 요청을 과도하게 잡으면 Autopilot이 더 비싸집니다.

시나리오 B: 트래픽 변동이 큰 가변 워크로드

container-optimized compute platform 도입 이후 GKE Autopilot의 스케일링 반응 속도는 크게 빨라졌습니다. 동적 노드 리사이즈와 사전 프로비저닝된 컴퓨트 풀 덕분에 새 노드 부팅 대기가 거의 사라집니다. EKS Auto Mode는 Karpenter의 just-in-time 프로비저닝이라 새 인스턴스 부팅 시간을 그대로 떠안습니다. 가변 워크로드에서는 GKE Autopilot이 분명히 유리합니다.

시나리오 C: Spot/Preemptible 활용 가능한 배치 워크로드

EKS Auto Mode는 Spot을 NodePool 레벨에서 자유롭게 섞을 수 있고, Karpenter의 인스턴스 다양성 알고리즘이 Spot 가용성을 잘 활용합니다. 다만 관리 수수료는 Spot 할인을 받지 못해 절감 폭이 줄어듭니다. GKE Autopilot은 Spot Pod로 Pod 단위 Spot 활용이 가능하지만, 일반 Pod 가격 대비 60~91% 할인이 들어가는 식이라 워크로드가 중단을 견딜 수 있다는 전제 하에 가장 큰 절감이 나옵니다. Spot 절감을 핵심 KPI로 잡는다면 두 서비스 모두 유효하지만, Spot 인스턴스 다양성을 극대화하려면 EKS Auto Mode 쪽이 컨트롤이 약간 더 많습니다.

여기서 반드시 피해야 할 표현은 "X가 Y보다 저렴하다"는 단정입니다. 위 시나리오별 결론은 모두 전제 조건이 깨지면 뒤집힙니다.

5.3 GPU 워크로드 과금

이 영역은 두 서비스의 과금 철학이 가장 크게 갈리는 지점입니다.

EKS Auto Mode에서 GPU 인스턴스(G, P, Trn 시리즈)를 띄우면 일반 인스턴스와 동일한 구조로 청구됩니다. 즉 EC2 GPU 인스턴스 가격 + 인스턴스 타입에 해당하는 Auto Mode 관리 수수료가 합산됩니다. 관리 수수료 비율은 인스턴스 패밀리마다 다르므로 pricing 페이지에서 직접 확인이 필요합니다. Spot/Capacity Blocks를 적용하면 EC2 부분은 할인되지만 관리 수수료는 그대로입니다.

GKE Autopilot에서 GPU(또는 TPU, 특정 머신 시리즈)를 요청하면 자동으로 노드 기반 빌링으로 전환됩니다. 이 모드에서는 Compute Engine 인스턴스 가격에 Autopilot 관리 프리미엄이 붙어 청구됩니다. 즉 GPU 워크로드의 과금 구조는 두 서비스가 사실상 같은 형태(인스턴스 가격 + 관리 수수료)로 수렴합니다.

본질적 차이는 다음 절에서 다룰 GPU 공유 가능 여부입니다. GPU 한 장을 여러 워크로드가 나눠 쓸 수 있느냐가 동일 GPU 비용 대비 실효 활용률을 결정하므로, GPU 단가 비교만으로는 전체 비용을 가늠할 수 없습니다.

6. GPU/AI 워크로드 비교

6.1 GPU 지원 범위와 갱신 속도

EKS Auto Mode는 NodePool에 eks.amazonaws.com/instance-gpu-manufacturer: nvidia 같은 라벨로 GPU 인스턴스를 요청합니다. Bottlerocket Accelerated AMI가 자동 선택되어 NVIDIA 드라이버, NVIDIA device plugin, DCGM Exporter가 모두 사전 설치된 상태로 부팅됩니다. Trainium/Inferentia용 Neuron 드라이버도 같은 방식으로 자동 관리됩니다. 2025년 가을부터 SOCI 병렬 풀이 G/P/Trn 패밀리(로컬 NVMe 보유)에 자동 활성화되어 별도 설정 없이 컨테이너 이미지 풀 시간이 최대 60% 단축됩니다. ODCR 및 Capacity Blocks for ML 지원이 NodeClass에 통합되어 사전 예약된 GPU 캐파를 우선 사용하도록 강제할 수 있습니다.

GKE Autopilot도 워크로드가 GPU를 요청하면 GKE가 드라이버 설치를 관리하고 자동으로 적절한 노드를 프로비저닝합니다. 지원 가속기 폭이 더 넓은데, NVIDIA GPU(L4, A100, H100, H200, B200, GB200 NVL72 기반 A4X 등)뿐 아니라 Google 자체 TPU(v5e, v5p, Trillium/v6e, Ironwood/TPU7x)까지 동일한 ComputeClass 메커니즘으로 요청할 수 있습니다. GB200 NVL72 기반 A4X는 2025년 5월 GA로 제공되고 있고, GKE Autopilot에서는 1.33.4-gke.1036000 이상에서 사용 가능합니다. 최신 가속기 갱신 속도에서는 GKE 쪽이 한 발 앞서 있다고 평가하는 것이 사실에 부합합니다.

6.2 GPU 공유와 활용률

이 부분이 GPU 워크로드 비교의 결정적 분기점입니다.

GKE Autopilot은 GPU 공유 전략 세 가지를 모두 지원합니다. Time-sharing(소프트웨어 레벨, 메모리/오류 격리 없음), Multi-instance GPU(하드웨어 레벨 파티셔닝, A100/H100/H200/B200/RTX PRO 6000 등에서 최대 7개 슬라이스), NVIDIA MPS. GKE 1.29.3-gke.1093000 이후 Autopilot에서 워크로드 스펙에 노드 셀렉터를 추가하는 것만으로 사용할 수 있습니다. MIG와 time-sharing을 결합해 단일 물리 GPU에서 최대 21개 GPU 디바이스를 노출하는 구성까지 가능합니다.

EKS Auto Mode는 2026년 5월 현재 GPU 공유를 지원하지 않습니다. AWS re:Post의 공식 응답 기준으로 time-slicing이나 MIG를 Auto Mode에서 활성화하는 경로가 없으며, 같은 기능이 필요하면 EKS Standard 클러스터에서 NVIDIA GPU Operator를 직접 운영하는 방식을 권장합니다. 추론처럼 GPU 활용률이 낮은 워크로드를 여러 pod가 한 GPU에서 공유하려는 시나리오에서는 이 차이가 실효 단가를 수 배 단위로 벌릴 수 있습니다.

이 항목은 위 5.3의 과금 비교가 단순 단가 비교로 끝나면 안 되는 이유입니다. GPU 한 장당 단가가 비슷하다고 해도 한 장을 4~7개 워크로드가 공유할 수 있는 쪽과 한 장당 한 pod만 쓸 수 있는 쪽은 실효 비용 구조가 다릅니다. 단, GKE의 time-sharing은 메모리/오류 격리가 없어 SLA가 중요한 워크로드에는 적합하지 않고, MIG는 지원 GPU가 한정된다는 전제는 양쪽 모두에 동일하게 걸립니다.

6.3 노드 수명과 장기 학습 워크로드

이 항목이 EKS Auto Mode가 ML 학습 워크로드와 충돌하는 가장 큰 지점입니다. 21일 강제 노드 교체는 보안 패치 적용 보장이 목적이지만, 그 결과로 21일을 넘기는 단일 학습 job은 사실상 불가능합니다. 체크포인트와 재시작이 잘 설계된 분산 학습이면 회피할 수 있지만, GPU 메모리/로컬 NVMe에 상태가 누적되는 워크로드는 21일 만기 시점에 강제로 끊깁니다. NodePool disruption budget으로 voluntary disruption을 막아도 mandatory expiration은 막을 수 없습니다.

회피 경로는 두 가지입니다. 하나는 mixed-mode 클러스터를 구성해 장기 학습은 Auto Mode가 아닌 일반 Managed Node Group에 배치하는 것이고, 다른 하나는 처음부터 21일 제약이 없는 환경(EKS Standard, GKE Standard, GKE Autopilot)을 선택하는 것입니다. GKE Autopilot은 명시적 21일 제한이 없어 release channel의 업그레이드 일정과 maintenance window 안에서 운영 가능하고, TPU 워크로드는 extended run time pod를 사용해 최대 7일까지 종료를 유예할 수 있는 별도 메커니즘이 있습니다. 다만 GKE도 release channel 강제 업그레이드 자체를 막을 수는 없으므로, 21일이 아니라는 것이지 무한정이라는 뜻은 아닙니다.

6.4 AI 가속기 별도 언급

GPU 외 가속기에서 두 서비스의 색깔이 분명히 드러납니다. EKS Auto Mode는 AWS 자체 실리콘인 Trainium과 Inferentia를 Neuron 드라이버 자동 설치 형태로 1급 시민으로 다룹니다. Neuron Monitor가 Node Monitoring Agent에 통합되어 가속기 헬스 체크가 자동화되고, ODCR/Capacity Blocks for ML로 P5 같은 고희소성 인스턴스의 캐파 확보가 워크로드 스케줄링에 연결됩니다.

GKE Autopilot 쪽은 Google TPU가 1급 시민입니다. Trillium(v6e)과 Ironwood(TPU7x)가 모두 GA이고, Autopilot에서는 머신 타입을 직접 지정하지 않고 cloud.google.com/gke-tpu-accelerator: tpu-v6e-slice 같은 가속기 타입과 topology만 지정하면 GKE가 알맞은 머신 타입으로 노드를 만듭니다. Ironwood는 GKE Autopilot 1.34.1-gke.3084001 이상에서 사용 가능하고, 9216-chip superpod까지 확장됩니다. Multislice 학습은 Autopilot 1.29.2-gke.1521000부터 지원되고, JetStream/vLLM 기반 LLM 서빙 레퍼런스도 Autopilot에 정렬되어 있습니다. JAX 기반 학습이거나 TPU 가성비에 의존하는 워크로드라면 GKE Autopilot이 사실상 단독 선택지입니다.

NVIDIA만으로 한정한다면 두 서비스 격차는 좁아지지만, 가속기 갱신 속도와 옵션 폭에서는 GKE Autopilot이 일관되게 앞서 있습니다.

7. 사용 사례별 선택 기준

7.1 EKS Auto Mode가 합리적인 경우

이미 AWS 생태계 위에 있고 IAM, VPC, ALB, Route53과의 통합 비용을 다시 지불하기 싫은 조직이라면 Auto Mode가 자연스러운 선택입니다. EKS Pod Identity로 IRSA 대비 단순화된 자격증명 모델을 쓸 수 있고, ALB Ingress와 Service annotation이 그대로 작동합니다. Karpenter 기반 인스턴스 다양성을 살려 Spot을 적극 활용하는 비용 최적화 전략이 핵심 KPI라면 Auto Mode 쪽이 컨트롤 폭이 더 넓습니다. Trainium/Inferentia 기반 추론 비용 최적화를 노린다면 Auto Mode가 사실상 단독 선택지입니다.

7.2 GKE Autopilot이 합리적인 경우

운영팀 규모가 작고 Day-2 운영 부담을 최소화하려는 조직이라면 GKE Autopilot이 더 멀리 갑니다. release channel 강제 업그레이드, admission policy 기본 강제, Pod 단위 빌링이 합쳐져 "운영하지 않는다"는 약속이 가장 잘 지켜집니다. 멀티 테넌트 SaaS처럼 Pod 단위로 비용을 추적해 내부 청구(showback)에 사용해야 한다면 Pod 기반 빌링이 그대로 청구 단위가 됩니다. AI/ML 워크로드 중심, 특히 TPU 또는 GPU 공유(time-slicing, MIG)로 활용률을 끌어올려야 하는 환경이라면 6.1과 6.2에서 본 격차 때문에 다른 선택지를 진지하게 고려할 이유가 거의 없습니다.

7.3 둘 다 부적합한 경우

커스텀 AMI가 필요한 환경은 두 서비스 모두에서 차단됩니다. 자체 컴플라이언스 도구나 보안 에이전트를 OS 이미지에 빌드해 넣어야 하는 규제 산업, 또는 커널 모듈 수준의 튜닝이 필요한 워크로드는 EKS Standard나 GKE Standard로 가야 합니다.

노드 SSH 접근이 규정상 필수인 환경, hostNetwork/hostPID/Privileged 컨테이너에 의존하는 레거시 모니터링 에이전트나 네트워크 스니퍼를 운영해야 하는 환경도 둘 다 부적합합니다. GKE Autopilot은 Pod Security Standards Baseline 강제로 막히고, EKS Auto Mode는 SSH 차단과 Bottlerocket 제약으로 막힙니다.

21일 이상 단일 노드를 유지해야 하는 장기 학습 워크로드는 EKS Auto Mode에서 명확히 부적합합니다. 체크포인트 기반 분산 학습이 잘 설계되어 있고 21일마다 재시작을 견딘다면 사용 가능하지만, 단일 GPU 노드에 상태를 누적하는 학습 코드를 그대로 옮길 수는 없습니다. 같은 워크로드를 GKE Autopilot으로 가져가도 release channel의 업그레이드 일정에 매여 있으므로, 진짜로 장기 단일 노드가 필요한 경우라면 두 서비스 모두 답이 아니고 EKS Standard나 GKE Standard에서 직접 운영하는 쪽이 정확한 선택입니다.

스테이트풀 데이터베이스를 로컬 NVMe 위에서 직접 운영하려는 경우도 둘 다 권장하지 않습니다. EKS Auto Mode의 21일 노드 교체가 PV 라이프사이클을 흔들고, GKE Autopilot은 노드 추상화로 인해 로컬 SSD 활용 패턴이 제한됩니다. 이런 워크로드는 Managed 데이터베이스 서비스로 분리하거나, K8s 위에서 운영해야 한다면 Standard 모드를 선택하는 편이 운영 비용 총합을 낮춥니다.

마지막으로 150 노드를 넘어가는 대규모 운영은 EKS Auto Mode에서 AWS와 사전 협의가 필요한 영역으로 명시되어 있습니다. 협의 자체가 차단을 의미하지는 않지만, 추가 가격 조건과 운영 제약이 붙을 수 있다는 점을 도입 단계에서 인지하고 있어야 합니다.