EKS 클러스터를 몇 개라도 굴리고 있으면 요즘 받은편지함에 "[조치 필요] Amazon EKS Kubernetes 1.34 표준 지원 종료" 제목의 AWS Health 알림이 하나 들어와 있을 것이다. 이런 메일은 늘 그렇듯 읽고 나서도 "그래서 지금 당장 뭘 눌러야 하나"가 잘 안 잡힌다. 3분기 지나 연말로 갈수록 변경 작업 창을 잡기가 어려워지는 시기라, 지금 한 번 정리해 두고 일정에 박아 두는 게 편하다.
요약하면 이렇다. Amazon EKS의 Kubernetes 1.34 표준 지원은 2026년 12월 2일에 끝나고, 그날부터 업그레이드 정책이 EXTENDED인 1.34 클러스터는 확장 지원으로 넘어간다. 확장 지원 요금은 클러스터당 시간당 0.60달러로, 표준의 0.10달러보다 시간당 0.50달러가 더 붙는다. 730시간 기준으로 클러스터 한 개당 월 약 365달러가 추가되는 셈이니, 12월 2일 전에 1.35 이상으로 올리는 것이 기본 답이다.
1. 표준 지원과 확장 지원이 무엇인가
EKS는 마이너 버전 하나를 EKS 출시일로부터 14개월 동안 표준 지원(Standard Support)한다. 이 기간이 끝나면 그 버전은 곧바로 확장 지원(Extended Support)으로 넘어가고, 확장 지원은 다시 12개월 지속된다. 합쳐서 한 버전을 26개월 쓸 수 있다는 뜻이다.
확장 지원은 "돈을 더 내고 옛 버전에 더 머무를 수 있는 기간"이다. 이 기간에도 Kubernetes 컨트롤 플레인 보안 패치는 계속 나오고, Amazon VPC CNI와 kube-proxy, CoreDNS 애드온, AWS가 배포하는 Amazon Linux/Bottlerocket/Windows용 EKS 최적화 AMI, EKS Fargate 노드에 대한 중요 패치도 제공된다. AWS 기술 지원도 그대로 받는다. 기본 구도는 기능이 줄어드는 게 아니라 요금이 붙는 쪽이다. 다만 제약이 아주 없지는 않다. 쿠버네티스 외 구성 요소 패치는 AWS가 게시한 EKS 최적화 AMI에 한정되고, 그 AMI의 OS나 커널은 더 새 버전으로 바뀔 수 있다.
중요한 건 확장 지원이 기본 활성화라는 점이다. 새로 만든 클러스터든 예전부터 돌던 클러스터든, 별도로 손대지 않았으면 업그레이드 정책은 EXTENDED다. 아무것도 안 하면 12월 2일에 알아서 비싼 쪽으로 넘어간다.
2. Health 알림이 실제로 말하는 것
메일 본문을 뜯어보면 날짜가 두 개 나온다.
- 2026년 12월 2일: 1.34 표준 지원 종료. 정책이 EXTENDED인 클러스터는 이 날부터 확장 지원으로 전환되고 확장 요금이 붙기 시작한다. 확장 지원 과금은 표준 지원 종료일 시작(UTC+0 기준)부터다.
- 2027년 12월 2일: 1.34 확장 지원 종료. 이 시점까지 올리지 않은 1.34 클러스터는 Kubernetes 1.35로 자동 업데이트된다.
확장 지원을 옵트아웃한 클러스터, 그러니까 정책이 STANDARD인 클러스터는 확장 지원으로 넘어가지 않고 표준 지원 종료 시점에 컨트롤 플레인이 자동 업그레이드된다.
어떤 클러스터가 걸렸는지는 메일이 아니라 대시보드에서 봐야 정확하다. AWS Health Dashboard의 Affected resources 섹션, EventBridge로 받은 이벤트의 affectedEntities 필드, Health의 DescribeAffectedEntities API 응답의 entities 필드에 대상 클러스터가 들어 있다. 계정이 여러 개면 메일만 보고 세지 말고 이쪽을 훑는 게 낫다.
3. 그대로 두면 요금이 얼마나 늘어나나
EKS 클러스터 요금은 컨트롤 플레인 기준으로 이렇게 갈린다.
- 표준 지원 버전: 클러스터당 시간당 0.10달러
- 확장 지원 버전: 클러스터당 시간당 0.60달러 (표준 요금 + 시간당 0.50달러)
한 달을 730시간으로 잡고 단순 계산하면 표준은 약 73달러, 확장은 약 438달러다. 차액이 클러스터 한 개당 월 약 365달러. 확장 지원 12개월을 꽉 채우면 클러스터 하나에 약 4,380달러가 더 나간다. dev, staging, prod로 계정마다 클러스터를 쪼개 놓은 조직이라면 여기에 클러스터 개수를 그대로 곱하면 된다. EC2 노드 비용은 별개이고, 여기서 말하는 건 컨트롤 플레인 요금만이다.
재무 쪽에 설명할 때는 "업그레이드를 미루는 비용이 월 365달러 곱하기 클러스터 수"라고 말하면 대화가 빨리 끝난다. 업그레이드 작업 공수보다 이쪽이 대체로 크다.
4. 내 클러스터 상태부터 확인한다
먼저 버전을 본다. 리전을 여러 개 쓰면 --region을 꼭 붙여라. 리전 하나만 보고 "우린 없네" 하고 넘어갔다가 나중에 다른 리전에서 걸리는 경우가 꽤 있다.
$ aws eks list-clusters --region ap-northeast-2 --output text CLUSTERS prod-apne2 CLUSTERS stage-apne2 $ aws eks describe-cluster --name prod-apne2 --query cluster.version --output text 1.34
kubectl로도 서버 버전을 볼 수 있다. 패치 번호와 -eks- 뒤 빌드 문자열은 클러스터마다 다르다.
$ kubectl version Client Version: v1.34.x Kustomize Version: v5.x.x Server Version: v1.34.x-eks-xxxxxxx
그다음이 업그레이드 정책이다. 여기가 요금이 갈리는 지점이다.
$ aws eks describe-cluster \ --name prod-apne2 \ --query "cluster.upgradePolicy.supportType" \ --output text EXTENDED
EXTENDED면 표준 지원이 끝날 때 확장 지원으로 들어가고 확장 요금을 낸다. STANDARD면 확장 지원에 들어가지 않고 표준 지원 종료 시점에 자동 업그레이드 대상이 된다. 기본값이 EXTENDED이므로 손댄 적 없으면 십중팔구 EXTENDED가 찍힌다.
버전별 지원 종료일은 CLI로도 확인할 수 있어서, 문서를 안 열고도 대조가 된다.
$ aws eks describe-cluster-versions \
--query "clusterVersions[?clusterVersion=='1.34'].{ver:clusterVersion,eos:endOfStandardSupportDate,eoe:endOfExtendedSupportDate,status:status}" \
--output table
endOfStandardSupportDate에 2026-12-02, endOfExtendedSupportDate에 2027-12-02가 나오고 status는 아직 STANDARD_SUPPORT다. 타임스탬프는 UTC+0 날짜를 CLI가 로컬 오프셋으로 렌더링하기도 하니 시각까지 그대로 비교하지는 마라.
5. 릴리스 캘린더로 보는 선택지
공식 릴리스 캘린더에서 지금 관련 있는 부분만 옮기면 이렇다. 날짜는 모두 UTC+0 기준이다.
- 1.34: EKS 출시 2025-10-02, 표준 종료 2026-12-02, 확장 종료 2027-12-02
- 1.35: EKS 출시 2026-01-27, 표준 종료 2027-03-27, 확장 종료 2028-03-27
- 1.36: EKS 출시 2026-06-02, 표준 종료 2027-08-02, 확장 종료 2028-08-02
여기서 1.35에서 멈출지 1.36까지 갈지가 갈린다. 1.34에서 1.35로만 올리면 표준 지원이 2027년 3월 27일에 끝난다. 12월에 작업하고 넉 달 만에 같은 메일을 다시 받는다는 뜻이다. 1.36까지 올리면 2027년 8월 2일까지 벌어 놓는다. 1.35를 골랐을 때보다 다음 만료까지 넉 달가량 더 버는 셈이다.
그래서 권장은 1.36까지다. EKS는 마이너 버전을 한 단계씩만 올리므로 1.34에서 1.36으로 바로는 못 가고 1.34 -> 1.35 -> 1.36 순서로 두 번 돌려야 한다. 컨트롤 플레인 업그레이드 자체는 몇 분이면 끝나지만, 두 번 사이에 애플리케이션 검증 시간을 넣어야 하니 일정은 두 배 이상으로 잡아라. 1.35에서 멈추는 게 타당한 경우는 특정 애드온이나 오퍼레이터가 아직 1.36을 지원하지 않을 때 정도다. 참고로 상위 Kubernetes에서 무엇이 바뀌고 있는지는 쿠버네티스 1.37 릴리스 정리를 같이 보면 감이 잡힌다.
6. 요금을 피하려고 정책을 STANDARD로 바꾸는 선택
업그레이드 일정을 못 잡겠고 확장 요금만은 피하고 싶다면, 업그레이드 정책을 STANDARD로 바꿔 두는 방법이 있다. 콘솔은 EKS 클러스터 > Overview 탭 > Kubernetes version settings 섹션 > Manage > Standard support 선택 후 저장이다. CLI는 이거 한 줄이다.
$ aws eks update-cluster-config \ --name prod-apne2 \ --upgrade-policy supportType=STANDARD
대신 대가가 있다. 표준 지원이 끝나는 시점에 컨트롤 플레인이 자동으로 다음 버전으로 올라간다. 우리가 고른 시각에, 우리가 지켜보는 앞에서 올라가는 게 아니다. 폐기된 API를 아직 쓰고 있거나 노드 버전이 뒤처져 있으면 그 상태 그대로 컨트롤 플레인만 올라간다. 자동 업그레이드가 올려 주는 건 컨트롤 플레인뿐이고, 자체 관리 노드와 관리형 노드 그룹은 이전 버전에 남는다. 예외는 EKS Auto Mode로, Auto Mode 노드는 컨트롤 플레인을 따라 자동으로 갱신될 수 있다.
그래서 STANDARD 전환은 "업그레이드를 안 해도 되는 방법"이 아니라 "확장 요금을 안 내는 대신 시점 선택권을 포기하는 방법"으로 이해해야 한다. prod에는 권하지 않는다. 오래 방치된 검증용 클러스터처럼 깨져도 상관없는 대상에만 쓴다.
여기서 한 번 걸리는 지점이 있다. 이미 확장 지원에 들어간 클러스터는 확장 지원을 비활성화할 수 없다. 정책 변경은 표준 지원 상태인 클러스터에만 먹는다. 12월 2일이 지나고 나서 요금 청구서를 보고 STANDARD로 바꾸려 해도 안 된다는 뜻이다. 바꿀 거면 12월 2일 전에 바꿔라.
7. 업그레이드 전에 확인할 것
노드와 컨트롤 플레인의 버전 차이
컨트롤 플레인을 올리기 전에 관리형 노드와 Fargate 노드의 마이너 버전이 컨트롤 플레인과 같은지 확인한다. 공식 문서가 관리형 노드와 Fargate에 대해서는 전제 조건으로 못 박는 항목이고, 자체 관리 노드는 권장 수준이지만 이쪽도 맞춰 두는 편이 안전하다.
$ kubectl get nodes NAME STATUS ROLES AGE VERSION ip-10-0-1-23.ap-northeast-2.compute.internal Ready <none> 21d v1.34.x-eks-xxxxxxx ip-10-0-2-45.ap-northeast-2.compute.internal Ready <none> 21d v1.34.x-eks-xxxxxxx
Kubernetes 1.28부터는 kubelet이 kube-apiserver보다 최대 세 마이너 버전까지 낮아도 동작하지만, 그 여유에 기대는 건 좋지 않다. 컨트롤 플레인과 노드 버전을 맞춰 두고 올리는 게 문서 권장이다. Fargate 파드는 컨트롤 플레인 버전보다 낮으면 해당 파드를 먼저 지우고, 컨트롤 플레인을 올린 뒤 다시 배포하면 새 kubelet 버전으로 뜬다.
클러스터 인사이트로 폐기 API 확인
EKS 클러스터 인사이트는 폐기된 Kubernetes API 사용 같은 업그레이드 방해 요소를 자동으로 스캔해 준다. 콘솔의 upgrade insights에서 본다. 여기서 알아 둘 점이 두 가지 있다. 인사이트는 "last refresh time" 기준 24시간마다 갱신되고, 폐기 API 사용은 30일 롤링 윈도로 집계하기 때문에 매니페스트를 고친 뒤에도 상태가 정상으로 바뀌는 데 최대 30일이 걸릴 수 있다. 12월 마감을 두고 11월 말에 인사이트를 처음 열면 늦다.
서브넷 여유 IP
업그레이드 과정에서 EKS는 클러스터 생성 시 지정한 서브넷에 새 네트워크 인터페이스를 만든다. 최대 5개의 여유 IP가 필요하고, 지정했던 서브넷이 없어졌거나 IP가 말랐거나 보안 그룹 규칙이 통신을 막으면 업데이트가 실패한다. 파드가 IP를 잔뜩 먹고 있는 좁은 서브넷에서 자주 걸리는 부분이다.
8. 업그레이드 순서
컨트롤 플레인은 CLI 한 줄로 올린다.
$ aws eks update-cluster-version \
--name prod-apne2 \
--kubernetes-version 1.35 \
--region ap-northeast-2
{
"update": {
"id": "<update-id>",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": "1.35"
},
...
시작하면 중간에 멈추거나 취소할 수 없다. 헬스 체크가 실패하면 EKS가 알아서 되돌리고 클러스터는 이전 버전에 남는다. 진행 상태는 update-id로 확인한다.
$ aws eks describe-update \ --name prod-apne2 \ --region ap-northeast-2 \ --update-id <update-id>
Successful이 뜨면 컨트롤 플레인은 끝이다. 여기서 작업이 끝났다고 착각하기 쉬운데, 남은 게 더 많다. 순서대로 노드(관리형 노드 그룹, 자체 관리 노드, 하이브리드 노드)를 컨트롤 플레인과 같은 마이너 버전으로 올리고, cluster-autoscaler처럼 버전에 맞춰야 하는 애플리케이션을 올리고, Amazon VPC CNI와 CoreDNS, kube-proxy 애드온을 갱신하고, 마지막으로 로컬 kubectl을 맞춘다. kubectl은 컨트롤 플레인과 한 마이너 버전 이내여야 한다.
롤백 조건도 미리 알아 두면 마음이 편하다. 인플레이스로 업그레이드한 클러스터는 완료 후 7일 이내에 이전 마이너 버전으로 되돌릴 수 있다. 단, 확장 지원 버전으로 롤백하려면 먼저 클러스터의 업그레이드 정책을 EXTENDED로 바꿔야 한다. 그리고 확장 지원 종료로 자동 업그레이드된 클러스터는 롤백할 수 없다. 7일이 지나면 남는 선택지는 이전 버전으로 새 클러스터를 만들고 워크로드를 옮기는 것뿐이다.
9. 12월 2일에서 역산한 일정
1.36까지 두 단계를 올린다고 보면 이 정도 배분이 현실적이다.
- 이번 주: 전 리전, 전 계정의 클러스터 버전과
upgradePolicy.supportType목록화. 확장 요금이 붙을 클러스터 개수 곱하기 월 365달러를 계산해서 공유. - 지금 바로: 클러스터 인사이트 열어 폐기 API 확인. 30일 윈도가 있으니 여기가 제일 앞에 와야 한다.
- 9월에서 10월: dev, staging에서 1.34 -> 1.35 -> 1.36을 한 번 완주. 애드온과 노드 그룹까지 포함해서.
- 10월에서 11월 중순: prod 1.34 -> 1.35, 안정화 후 1.35 -> 1.36.
- 11월 말: 남은 클러스터 정리. 어차피 안 쓰는 클러스터면 업그레이드 대신 삭제가 답이다.
연말에 변경 동결이 걸리는 조직이라면 실제 가용한 작업 창은 11월 중순까지다. 12월 2일까지 시간이 넉넉해 보여도 검증과 롤백 여유를 빼면 그렇지 않다.
10. 정리
1.34 표준 지원은 2026년 12월 2일에 끝나고, 아무것도 안 하면 클러스터당 월 약 365달러가 더 붙는다. 확장 지원에 한 번 들어가면 그 클러스터는 정책을 되돌릴 수 없으니 정책을 손볼 거면 그 전에 해야 한다. 1.35로만 올리면 2027년 3월에 같은 일이 반복되므로 여건이 되면 1.36까지 가는 것을 권한다. 컨트롤 플레인만 올라간다는 점, 노드와 애드온은 별도라는 점, 롤백은 7일이라는 점만 기억하고 일정에 넣으면 된다.