AWS EKS 버전 유지 시 확장지원 비용 리스크 (2024년 이후 변경)

 

목차

 

 

EKS를 운영하다 보면 “버전 업그레이드를 꼭 지금 해야 하나?”라는 질문보다 더 중요한 게 하나 있다.

바로 Kubernetes 버전 지원 정책과 비용 변화다.

결론부터 말하면, EKS는 예전(2024.04.01)과 달리 버전이 오래되면 비용이 급격히 증가한다.

이 변화는 비교적 최근(에 도입되었고, 많은 운영 환경에서 체감 비용 차이를 만들고 있다.

---

1. 과거 EKS 버전 정책: “비용 차이 없음”

과거에는 EKS Kubernetes 버전이 지원 종료(EOL) 되기 전까지:

• 클러스터 비용은 항상 동일
• “표준 지원 / 확장 지원” 같은 요금 구분이 존재하지 않음
• 운영팀 입장에서는
  → “조금 늦게 올려도 큰 문제 없다”는 판단이 가능했음

즉, 업그레이드는 안정성·기능 관점의 문제였지, 비용 문제는 아니었다.

---

2. 정책 변화: Extended Support 도입

AWS는 EKS 운영 부담과 보안 책임을 명확히 하기 위해

Kubernetes 버전 지원 정책을 다음과 같이 변경했다.

현재 EKS 버전 지원 구조

표준지원(StandardSupport) :14개월
확장지원(ExtendedSupport) :12개월
총지원기간:26개월

이 구조 자체는 Kubernetes 생태계 흐름과 맞지만,

문제는 ‘확장 지원’에 비용이 붙었다는 점이다.

---

3. 비용은 얼마나 늘어났나?

EKS Control Plane 요금 비교

구분	비용
표준 지원	$0.10 / 클러스터·시간
확장 지원	$0.60 / 클러스터·시간

👉 6배 증가

이 비용은:

• 노드 수와 무관
• 트래픽과 무관
• 클러스터가 존재하는 시간만큼 무조건 발생

즉,

“버전만 오래됐을 뿐인데 운영비가 6배로 증가”

라는 상황이 실제로 발생한다.

---

4. 자동 업그레이드 리스크까지 존재

확장 지원 기간(12개월)마저 종료되면:

• AWS가 자동으로 클러스터 버전을 업그레이드
• 운영자가 제어하지 못한 상태에서:
  • 애드온 비호환
  • 워크로드 장애
  • CNI / CSI 문제
  • deprecated API 이슈
  • 가 동시에 터질 수 있다.

즉, 비용 + 안정성 리스크가 동시에 증가한다.

---

5. 그래서 언제 업그레이드해야 하나?

운영 관점에서 가장 합리적인 기준은 다음이다.

권장 전략

• 표준 지원 종료 전에 업그레이드
• 현실적으로는
• → 종료 2~3개월 전까지 완료

이렇게 하면:

• 확장 지원 비용 회피
• 자동 업그레이드 방지
• 애드온/워크로드 테스트 여유 확보

---

6. 정리

• ✅ 예전에는 버전이 오래돼도 비용 차이가 없었다
• ❌ 지금은 표준 지원이 끝나면 비용이 6배 증가
• ❌ 확장 지원까지 넘기면 자동 업그레이드 리스크 발생
• ✅ 따라서 EKS 운영에서는
• “버전 업그레이드 = 비용 관리”

이라는 인식이 필수가 되었다.

---

한 줄 요약

EKS 버전 업그레이드는 더 이상 선택이 아니라, 비용과 안정성을 동시에 관리하기 위한 운영 필수 작업이다.