EKS Extended Support 비용을 줄이려면 어디까지 점검해야 할까

이 글은 2026년 8월 수행한 지원 기록을 바탕으로 작성했다. 고객사와 인프라 식별 정보는 익명화했다.

시작은 Extended Support 비용이었다

고객사 A는 Amazon EKS에서 모니터링 플랫폼을 운영하고 있었다. 서비스는 실행 중이었지만 Kubernetes 버전이 표준 지원 기간을 지나 Extended Support에 진입한 상태였다.

EKS의 버전 지원 요금은 표준 지원 시 클러스터당 시간당 0.10달러, Extended Support 시 0.60달러다. 동일한 클러스터를 운영해도 지원 단계에 따라 시간당 0.50달러가 추가된다.¹

우리는 고객사의 요청에 따라 표준 지원 버전으로 전환하는 작업을 진행했다. 다만 컨트롤 플레인 버전만 변경하는 것으로 끝낼 수 있는 환경은 아니었다.

초기 점검에서 컨트롤 플레인은 Kubernetes 1.32였지만 워커 노드는 1.29와 Amazon Linux 2 기반으로 운영했다. 여기에 데이터베이스와 영구 볼륨을 사용하는 워크로드가 함께 배치돼 있었다.

비용을 줄이려면 먼저 이 환경을 새 노드에서도 다시 실행할 수 있는지 확인해야 했다.

업그레이드 전에 복구 수단부터 준비했다

첫 단계에서는 실행 중인 워크로드, 영구 볼륨, 애드온, 노드 구성을 정리했다. 특히 단일 인스턴스로 운영되는 구성요소와 노드 이동 시 스토리지 재연결이 필요한 서비스를 확인했다.

이후 관련 EBS 볼륨 9개의 스냅샷을 생성하고 모두 완료된 것을 확인했다. 일부 스냅샷은 임시 볼륨으로 복원해 볼륨 생성이 가능한지도 점검했다.

여기서 검증 범위는 구분했다. EBS 스냅샷과 볼륨 복원 확인은 복구 준비의 일부이지, 데이터베이스의 애플리케이션 일관성이나 전체 서비스 복구를 보장하는 시험은 아니다.

복구 계획은 버전을 되돌리는 절차만으로 완성되지 않는다. 현재 AWS 문서는 클러스터가 조건을 충족하면 업그레이드 완료 후 7일 이내 직전 마이너 버전으로 롤백할 수 있다고 안내한다. 애드온과 일반 관리형 노드 그룹은 별도로 처리해야 한다. 이 기능의 현재 안내와 이번 작업에서 검증한 EBS 복원 범위는 구분해야 한다.²

새 노드에서 드러난 컨테이너 이미지 문제

기존 Amazon Linux 2 노드 그룹을 대신할 Amazon Linux 2023 기반 노드 그룹을 구성하고 워크로드를 순차적으로 이동했다.

이 과정에서 일부 컨테이너가 이미지를 내려받지 못했다. 기존 노드에서는 정상 실행되던 데이터베이스와 캐시 관련 이미지였다.

기존 노드에 남아 있던 이미지 캐시가 문제를 가리고 있었다. 새 노드가 같은 태그로 이미지를 요청하자, 레지스트리에서 해당 태그를 가져올 수 없었다.

우리는 기존 실행 이미지의 digest와 레지스트리에서 접근 가능한지 확인했다. 확보 가능한 digest로 배포 설정을 고정한 뒤, 새 노드에서 실제 이미지 다운로드와 실행을 검증했다. GitOps로 관리하는 구성에도 변경을 반영했다.

운영 중인 컨테이너가 정상이어도 장애 후 같은 컨테이너를 다시 배포할 수 있는지는 별도로 확인해야 한다.

다만 digest 고정은 배포 재현성을 확보하는 조치다. 이미지의 보안 취약점을 해결하거나 장기적인 보관을 보장하지는 않는다. 자체 레지스트리 보관과 이미지 갱신 정책은 별도의 후속 과제로 남겼다.

Kubernetes는 한 단계씩, 스토리지는 실제 동작으로 확인했다

노드 기반을 정비한 뒤 Kubernetes를 다음 순서로 업그레이드했다.

1.32 → 1.33 → 1.34 → 1.35 → 1.36

EKS는 한 번에 하나의 마이너 버전씩 업그레이드해야 한다. 각 단계에서 호환성 점검 결과를 확인하고 컨트롤 플레인과 워커 노드, 관련 애드온의 상태를 검증했다.³

Extended Support 해소 자체에 최종 목표 버전까지의 업그레이드가 모두 필요한 것은 아니었다. 이번 작업에서는 표준 지원 진입 이후에도 고객사와 진행한 범위에 따라 1.36까지 전환했다.

스토리지 드라이버인 EBS CSI도 목표 버전에 맞춰 업데이트했다. 드라이버 Pod가 실행되는지만 보는 대신, 임시 볼륨으로 다음 동작을 시험했다.

• 업그레이드 전 기록한 데이터가 이후에도 동일하게 읽히는지
• Pod를 같은 가용 영역의 다른 노드로 옮겼을 때 볼륨이 재연결되는지
• 업데이트 이후 새 볼륨을 생성하고 읽기·쓰기를 수행할 수 있는지

시험에 사용한 임시 리소스는 정리하고 기존 영구 볼륨과 백업 스냅샷은 유지했다.

표준 지원으로 복귀하고 운영 기반을 정비했다

아래는 업그레이드 후 점검 시점에 확인한 인프라 상태다.

요금표 기준으로는 클러스터 1개당 월 730시간을 가정할 때 365달러, 연 8,760시간을 가정하면 4,380달러의 지원 요금 차이를 줄이는 효과가 있다. 해당 요금 항목 기준 약 83% 감소다.¹

이 차이는 전체 AWS 비용의 절감률이나 실제 청구서로 확정한 절감 실적은 아니다. EC2, EBS, 네트워크, 백업 보관 비용과 전환 중 발생한 비용은 별도로 계산해야 한다. 전체 비용을 조정한 AWS 계정 라이트사이징 사례와도 절감 범위를 구분해서 읽어야 한다.

Pod가 정상이어도 외부 수집은 별도 검증이 필요했다

이번 지원에서는 후속 확인 사항도 발견됐다. 클러스터 업그레이드 이후 외부에 설치된 Grafana Agent 일부가 Agent Down으로 표시된다는 신고가 있었다.

조사 과정에서는 노드 롤링 중 Cortex의 메트릭 수신 요청에 HTTP 500이 발생한 기록을 확인했다. 로그에는 쓰기 처리에 필요한 정상 복제본 수가 부족하다는 내용이 남아 있었다.

다만 이 기록만으로 이후에도 표시되는 Agent Down의 원인을 확정할 수는 없다. Agent 상태 판정 조건, 마지막 수집 시각, 전송 재시도와 실제 데이터 유입 회복 여부를 추가로 확인해야 한다.

따라서 이번 결과를 ‘무중단 전환’이나 ‘전체 수집 경로 정상화 완료’로 표현하지 않는다. 확인한 성과는 표준 지원 복귀와 인프라 상태 검증이며, 외부 Agent의 종단 간 수집 검증은 별도 과제다.

Kubernetes가 보여주는 정상 상태와 고객이 기대하는 정상 상태는 같지 않다. Pod가 실행되는 것을 넘어, 외부 데이터가 들어오고 저장되며 대시보드에 반영되는 지점까지 확인해야 한다.

다음 업그레이드를 더 작게 만들기 위해

Extended Support 비용은 버전 관리가 늦어진 결과이지만 실제 전환을 어렵게 만드는 요소는 노드 운영체제, 이미지 공급 경로, 스토리지, 서비스 가용성 곳곳에 있었다.

고객사 A의 후속 개선 과제도 이 지점에 맞췄다. 지원 종료 일정의 사전 관리, 컨테이너 이미지 보관 정책, 단일 인스턴스 구성의 가용성 보완, 외부 Agent부터 대시보드까지 이어지는 수집 검증이 필요하다.

우리는 고객사 A의 EKS를 표준 지원 버전으로 전환하고, 다음 유지보수 전에 보완해야 할 운영 과제를 구체화했다.

EKS 업그레이드를 앞두고 있다면 현재 버전뿐 아니라 새 노드에서 다시 배포할 수 있는지, 데이터를 복구할 수 있는지, 외부 서비스 경로를 검증할 수 있는지를 함께 점검해야 한다.

EKS 지원 종료 일정과 업그레이드 준비 상태를 확인하려면 클라우드 & 인프라 서비스에서 진단·전환 지원 범위를 살펴볼 수 있다.

참고 자료