AWS EKS 비용 구조 완전 이해하기
AWS EKS를 사용하고 계신가요? 혹시 "분명히 계산했는데, 왜 요금이 더 나왔지?" 하는 생각, 한 번쯤 해보셨을 겁니다. EKS 요금은 단순히 서버 비용만 생각하면 큰코다치기 쉽습니다. ‘숨은 비용’들이 여기저기서 튀어나오기 때문이죠.
이 글에서는 EKS 비용 구조를 직관적으로 분해해서 보여드립니다. 관리비 격인 Control Plane, 실제 일꾼인 Data Plane(EC2 vs Fargate), 그리고 자기도 모르게 지갑을 털어가는 각종 부가 비용까지 한번 살펴보겠습니다.
AWS EKS 이해하기
AWS EKS에 대한 개념을 비유와 함께 설명해보겠습니다.
쉽게 이해하는 비유: 오케스트라와 지휘자
애플리케이션(연주자)
우리가 만든 앱이나 프로그램은 각자의 악기를 연주하는 '연주자'입니다.
컨테이너(악보 보면대)
각 연주자에게는 연주에 필요한 모든 것(악기, 악보, 의자)이 담긴 '보면대'가 주어집니다. 이것이 바로 '컨테이너' 기술입니다. 컨테이너는 애플리케이션과 그 실행에 필요한 모든 것을 하나로 묶어 어디서든 동일하게 실행되도록 보장합니다.
쿠버네티스(지휘자)
연주자가 수십, 수백 명으로 늘어나면 혼란이 생깁니다. 이때 등장하는 것이 '지휘자(쿠버네티스)'입니다. 지휘자는 어떤 연주자가 어떤 파트를 연주할지, 언제 쉬고 언제 연주할지, 한 연주자가 지치면 다른 연주자로 교체하는 등 전체 오케스트라를 조율합니다.
AWS EKS(콘서트홀과 스태프)
그런데 훌륭한 지휘자(쿠버네티스)가 있더라도, 공연을 위한 무대, 조명, 음향 시설, 대기실 같은 '콘서트홀'과 이 모든 것을 관리해 줄 '스태프'가 필요합니다. AWS EKS는 바로 이 '콘서트홀과 스태프'의 역할을 합니다. 즉, 지휘자(쿠버네티스)가 오케스트라를 최고의 환경에서 지휘할 수 있도록 모든 인프라와 관리 업무를 대신 해주는 서비스입니다.
그래서 AWS EKS가 정확히 뭔가요?
AWS EKS(Amazon Elastic Kubernetes Service)는 한마디로 "아마존(AWS)이 대신 관리해주는 쿠버네티스 서비스"입니다.
사용자가 직접 쿠버네티스를 설치하고 관리하려면 매우 복잡하고 어려운 설정 과정(지휘자를 섭외하고, 콘서트홀을 짓고, 스태프를 고용하는 일)을 거쳐야 합니다. EKS는 이 모든 번거로운 일을 AWS가 대신 처리해주므로, 사용자는 자신의 애플리케이션(오케스트라 연주)에만 집중할 수 있게 해줍니다.
EKS의 핵심 구성 요소: Control Plane과 Data Plane
EKS는 크게 두 부분으로 나뉩니다. 바로 '지휘자석'과 '연주자석'이죠.
Control Plane (지휘자석, 관리 영역)
Contorl Plane은 클러스터 전체를 관리하고 지시하는 두뇌 영역입니다. 지휘자가 연주 전체를 조율하듯, Control Plane은 어떤 애플리케이션을 어디에 배치할지, 문제가 생기면 어떻게 복구할지 등을 결정하고 명령합니다.
이 영역은 AWS가 전적으로 관리합니다. 사용자는 이 영역에 직접 접근할 필요가 없으며, AWS가 고가용성(High Availability)과 보안 업데이트 등을 모두 책임져 줍니다. 사용자는 이 편리함에 대한 비용을 지불합니다.
Data Plane (연주자석, 실행 영역)
실제 애플리케이션(컨테이너)들이 배치되어 실행되는 작업 공간입니다. 오케스트라 단원들이 실제로 연주하는 무대와 같습니다. 이 공간은 '워커 노드(Worker Node)'라고 불리는 가상 서버들로 구성됩니다.
이 영역은 사용자가 선택하고 관리합니다. 필요에 따라 연주자석의 크기(서버 사양)나 개수(서버 대수)를 조절할 수 있습니다. AWS는 이 공간을 구성할 두 가지 선택지를 제공합니다.
EC2 방식: 사용자가 직접 가상 서버(EC2 인스턴스)의 종류와 개수를 정해 '연주자석'을 만드는 방식입니다. 유연성이 높고, 대규모 환경에서는 비용 효율적일 수 있습니다.
Fargate 방식: 서버를 직접 관리할 필요 없이, 앱을 실행할 때마다 AWS가 알아서 필요한 만큼의 '임시 좌석'을 내어주는 방식입니다. 관리가 매우 편리하지만, 경우에 따라 비용이 더 나올 수 있습니다.
EKS를 사용하면 뭐가 좋은가요?
관리 부담 감소
가장 큰 장점입니다. 복잡한 쿠버네티스 설치, 설정, 업데이트, 보안 관리 등을 AWS에 맡기고 핵심 비즈니스에 집중할 수 있습니다.
높은 안정성과 확장성
AWS의 검증된 인프라 위에서 작동하므로, Control Plane이 여러 데이터 센터(AZ)에 걸쳐 자동으로 구축되어 장애가 발생해도 서비스가 중단될 위험이 적습니다. 사용량이 늘어나면 Data Plane의 서버를 손쉽게 확장할 수 있습니다.
AWS 서비스와 완벽한 연동
AWS의 다른 서비스들(네트워킹, 데이터베이스, 보안 등)과 매우 긴밀하게 연동됩니다. 이를 통해 더 강력하고 안전한 클라우드 네이티브 애플리케이션을 쉽게 구축할 수 있습니다.
강력한 커뮤니티와 표준
EKS는 표준 쿠버네티스를 사용하므로, 특정 클라우드에 종속되지 않고 방대한 쿠버네티스 생태계의 도구와 자료를 그대로 활용할 수 있습니다.
AWS EKS 비용 구조 완벽 분석
AWS EKS(Elastic Kubernetes Service)는 강력한 관리형 Kubernetes 서비스이지만, 비용 구조가 다각적이어서 정확한 이해가 필요합니다. 이 글에서는 EKS의 핵심 비용 요소인 Control Plane, Data Plane, 그리고 기타 부가 비용에 대해 최신 정보를 바탕으로 상세히 설명합니다
EKS Control Plane 비용
EKS Control Plane은 Kubernetes 클러스터의 두뇌(API 서버, etcd, 컨트롤러 매니저 등) 역할을 하며, AWS가 이 구성 요소의 설치, 관리 및 고가용성을 책임집니다. 사용자는 이 관리 기능에 대한 비용을 지불하게 됩니다.
표준 지원 (Standard Support)
클러스터당 시간당 $0.10 (월 약 $73)이 부과됩니다. 클러스터를 생성하는 순간부터 워크로드 실행 여부와 관계없이 고정적으로 부과됩니다. 예를 들어, 테스트와 운영 클러스터를 포함해 총 3개의 클러스터를 운영하면 Control Plane 비용만으로 매달 약 $219가 발생합니다.
확장 지원 (Extended Support)
클러스터당 시간당 $0.60이 부과됩니다. Kubernetes 표준 지원 기간이 종료된 버전을 계속 사용해야 할 경우 적용되는 요금입니다. 확장 지원은 버전당 14개월간 제공되며, 이를 통해 사용자는 더 많은 시간을 갖고 업그레이드를 계획할 수 있습니다.
불필요한 클러스터는 비용을 빠르게 증가시키는 주범입니다. 꼭 필요한 만큼의 클러스터만 생성하고, 테스트용 클러스터는 사용 후 즉시 삭제하거나 자동 종료 스크립트를 적용하는 것이 비용 절감의 핵심입니다.
Data Plane 비용: EC2 vs. Fargate
EKS에서 실제 워크로드(Pod)를 실행하는 인프라를 Data Plane이라고 하며, 주로 EC2와 Fargate 두 가지 방식 중 선택할 수 있습니다.
EC2 Data Plane
EC2 인스턴스를 클러스터의 워커 노드로 직접 등록해 사용하는 전통적인 방식입니다. EC2 요금(온디맨드, 스팟, RI, Savings Plan 등), EBS 스토리지 요금, 네트워크 전송 요금 등이 청구됩니다. 주로 EC2 인스턴스의 크기와 개수, 사용 시간에 따라 비용이 결정됩니다. EKS Control Plane 비용 외에는 EC2 인스턴스 요금이 핵심입니다. EC2 요금제(온디맨드, 스팟 인스턴스, Savings Plans, RI 등)를 활용해 비용을 최적화할 수 있습니다.
Fargate Pod
EC2를 사용하지 않고, AWS가 관리하는 서버리스 인프라에서 Pod를 실행하는 방식입니다. Fargate는 vCPU와 메모리 사용량 기준으로 과금되며, vCPU 1개당 약 $0.04048/시간, 메모리 1GB당 약 $0.004445/시간 수준으로 책정됩니다. Fargate는 워커 노드 관리가 필요 없어 운영 부담이 적고, Pod 단위로 리소스가 격리되어 보안에 유리합니다. 사용량이 적거나 예측 불가능한 워크로드에 적합합니다.
다만 리소스 활용률을 높여도 비용 절감 효과가 없습니다. 각 Pod마다 개별적으로 비용이 산정되므로, 수백, 수천 개의 Pod를 상시 운영하는 대규모 워크로드에서는 EC2 방식보다 훨씬 비쌀 수 있습니다.
Q. 왜 대규모 워크로드에서 EC2 Data Plane이 더 저렴할 수 있을까요?
EC2는 인스턴스 단위로 과금되며, 인스턴스에 탑재된 모든 리소스(vCPU, 메모리)에 대해 '인스턴스 실행 시간' 기준으로 비용을 지불합니다. 즉, 인스턴스의 크기(예: t3.large)와 개수에 따라 비용이 결정됩니다. 인스턴스 내의 리소스를 100% 활용하든, 10%만 활용하든 동일한 비용이 청구됩니다.
Fargate와 동일하게 1000개의 Pod를 운영하는 상황을 다시 생각해 봅시다. EC2의 경우, 이 Pod들을 수용하기 위해 적절한 크기의 EC2 인스턴스를 여러 대 운영해야 합니다. 예를 들어, Pod들을 수용하기 위해 m5.xlarge (4 vCPU, 16GB 메모리) 인스턴스 63대를 사용한다고 가정하면, 비용은 63대의 인스턴스 비용으로 계산됩니다. 이 인스턴스에 Pod가 꽉 차지 않더라도(예: CPU 점유율이 50%만 되더라도) 인스턴스 전체에 대한 비용을 지불해야 합니다.
대규모 워크로드에서는 EC2의 '규모의 경제'가 Fargate의 비용 효율을 앞지를 수 있습니다. EC2 인스턴스는 일반적으로 리소스 활용률이 60~80%에 달할 때 가장 비용 효율적입니다. 대규모 워크로드는 수많은 Pod를 하나의 인스턴스에 밀집시켜 배치할 수 있어 인스턴스 리소스를 높은 비율로 활용할 수 있습니다.
반면, Fargate는 각 Pod마다 별도로 과금되므로, 리소스 활용 효율성이 높아지더라도 비용이 감소하지 않습니다.
즉, EKS의 워크로드 비용은 EC2 Data Plane 또는 Fargate 선택, 그리고 실행되는 Pod 수와 리소스 크기에 따라 결정되며, 어떤 방식을 선택하느냐에 따라 전체 EKS 비용 구조가 크게 달라질 수 있습니다.
ENI, EBS, ALB, CloudWatch 부가 비용
EKS 클러스터를 운영하면 Control Plane과 Data Plane 비용 외에도 여러 부가 비용이 함께 발생합니다. 이 부분은 간과하기 쉽지만, 실제 청구서에서 예상치 못한 비용의 상당 부분을 차지할 수 있으므로 반드시 주의해야 합니다.
ENI (Elastic Network Interface)
EKS는 VPC CNI를 통해 Pod마다 IP 주소를 할당하며, 이때 ENI가 사용됩니다. Pod 수가 늘어나면 ENI 사용도 증가하며, ENI 개수와 Public IP 할당 여부에 따라 요금이 발생할 수 있습니다.
EBS
워커 노드의 루트 볼륨 외에도, PVC(PersistentVolumeClaim)를 통해 Pod가 사용하는 스토리지에 대한 비용입니다. 스토리지 타입(gp3, io2 등), 디스크 크기, IOPS/처리량 설정에 따라 비용이 크게 달라질 수 있습니다.
ALB/NLB
Kubernetes Ingress Controller 또는 Service Type LoadBalancer를 사용할 경우, AWS ALB 또는 NLB 리소스가 자동 생성되며, 이때 로드밸런서 시간당 요금, LCU(Load Capacity Unit) 기반 요금이 부과됩니다. 특히 ALB는 다수의 Ingress 리소스를 만들면 불필요하게 여러 개가 생성되므로, 관리하지 않으면 비용이 빠르게 증가합니다.
CloudWatch Logs
EKS의 로그 및 메트릭(예: Container Insights, Fluent Bit 로그 수집 등)은 CloudWatch Logs로 전송되며, 저장량(GB 단위)과 조회/수집 요청 수에 따라 비용이 발생합니다. 로그 Retention 기간이 길거나, 수집 항목이 과도하면 CloudWatch 비용이 급증할 수 있습니다.
NAT Gateway
Private Subnet의 워커 노드가 외부 인터넷(예: 컨테이너 이미지 레지스트리)과 통신해야 할 경우 NAT Gateway를 사용하게 되며, 시간당 요금 및 데이터 처리 요금이 발생합니다.
성공적인 EKS 비용 최적화를 위해서는 단순히 Control Plane과 워커 노드 비용만 고려해서는 안 됩니다. 네트워킹(ENI, ALB), 스토리지(EBS), 모니터링(CloudWatch) 등 클러스터와 연관된 모든 부가 서비스 비용을 종합적으로 추적하고 관리해야 합니다. 워크로드의 특성에 맞춰 EC2와 Fargate를 전략적으로 선택하고, Savings Plans나 스팟 인스턴스 같은 할인 모델을 적극 활용하여 전체 클러스터의 TCO(총소유비용)를 절감하는 것이 중요합니다.
결론
자, 이제 EKS 비용의 전체 그림이 보이시나요? 정리해 보겠습니다.
Control Plane: 클러스터 개수만큼 내는 월세. 일단 만들면 무조건 나갑니다.
Data Plane: EC2로 규모의 경제를 만들지, Fargate로 편리함을 살지 결정하는 핵심 변수.
부가 비용: 네트워크(ENI, ALB), 스토리지(EBS), 로그(CloudWatch) 등. 이 친구들이 바로 예고 없는 ‘추가 요금’의 주범입니다.
결론은 간단합니다. EKS 비용 최적화는 단순히 EC2 인스턴스 몇 개를 끄고 켜는 문제가 아닙니다. 클러스터와 연결된 모든 자원을 한눈에 꿰뚫어 보고 종합적으로 관리해야만 진정한 비용 절감이 가능합니다.
