블로그 릴레이 - k8s 어느 서비스에서 배포하고 운영하는게 좋을까?

안녕하세요! 클래스메소드의 이수재입니다.

본 블로그는 당사의 한국어 블로그 릴레이의 2025년 21번째 블로그입니다.
이번 블로그의 주제는「k8s 어느 에서 배포하고 운영하는게 좋을까?」입니다.

온프레미스나 클라우드 서비스에서 제공하고 있는 서비스(EKS, AKS 등) 중 검토하는 경우가 많습니다.
이번 글에서는 온프레미스와 EKS, 그리고 그 중간이라고 생각되는 EC2 를 비교하여 봅니다.
정확하게는 k8s에 한정되었다기 보다는 다른 컨테이너 오케스트레이션 툴이나 VM 등도 통용되는 내용입니다.

각 부분 비교

장단점

온프레미스
온프레미스에서 k8s를 운영하는 경우 클라우드 서비스와는 다르게 환경에 대한 완전한 제어권을 가질 수 있습니다.
특히 하드웨어와 네트워크의 완전 관리가 필요한 경우 온프레미스 환경만 채택가능^[1] 합니다. 또한 데이터도 온프레미스의 스토리지에 저장하기에 데이터 관리의 측면에서도 외부에 노출될 가능성이 적습니다.
그리고 온프레미스로 운영중인 서버에 그대로 구축하는 경우가 많기 때문에 초기 비용이 발생하지 않습니다. ^[2]

다만 관리에 따른 오버헤드가 많이 발생하고, 느린 확장성 및 재해 복구 대비 등 가용성 및 유연성이 다른 환경에 비해 확보하기 어렵다는 단점이 있습니다.

EKS
장점으로는 우선 k8s의 컨트롤 플레인(API 서버, etcd, 스케줄러 등)의 고가용성, 백업, 패치, 업그레이드를 AWS가 관리하므로 사용자는 애플리케이션 배포 및 워커 노드 관리에 집중할 수 있습니다.
컨트롤 플레인은 자동으로 여러 가용 영역에 배포되기 때문에 높은 가용성도 확보할 수 있으며 k8s의 버전 업데이트도 AWS에서 지속적으로 배포합니다. ^[3]
노드의 스케일링 등도 간편하며 필요에 따라 서버리스(Fargate)로 운영하는 것도 가능합니다.
특히, 다른 AWS 서비스와 쉽게 연계할 수 있다는 점이 워크로드의 운영에 있어서 큰 이점을 가져다 줍니다.

단, 마스터 노드에 대한 제어권이 없기 때문에 운영 요구 사항에 따라 EKS와 같은 관리형 서비스는 도입하기 힘들 수 있습니다.
또한 컨트롤 플레인 자체의 비용이나 워커 노드 수에 따른 비용 등이 발생하기 때문에 소규모 컨테이너 환경이라면 기존의 온프레미스 환경에서 운영하는 것보다 많은 비용이 발생할 가능성이 있습니다.
또한 AWS IAM과 같은 AWS 고유의 서비스나 규칙에 제약을 받기 때문에 k8s 이외에 AWS에 대해서도 어느정도의 지식이 필요하다는 점도 고려할 점이겠네요.

EC2
AWS EC2 인스턴스를 가상 머신으로 사용하여 그 위에 k8s를 직접 설치하고 관리하는 방식을 사용합니다.

특징으로는 위에서 얘기한 온프레미스와 EKS의 중간이라고 보면 될 것 같습니다.
컨트롤 플레인의 권한을 유저가 가져오면서 환경에 대한 통제권을 어느정도 가져올 수 있는 장점이 있습니다.
또한 확장성이나 가용성과 같은 온프레미스와 대비 클라우드 서비스의 장점도 어느정도 누릴 수 있습니다.
마찬가지로 다른 AWS 서비스와 연계하는 것도 쉽게 가능합니다.

다만 EKS와 같은 관리형 서비스와 비교하여 운영 오버헤드가 비약적으로 상승하며, 운영을 위한 주변 설계 등도 훨씬 복잡해집니다.
또한, 소규모라면 EKS 보다 저렴할 수 있겠지만 규모가 커질수록 EKS보다 운영 비용이 커집니다.

운영 비용

온프레미스
하드웨어, 소프트웨어 라이선스, 데이터 센터 구축 등에 비용이 발생하기 때문에 초기 비용은 높은 편입니다.
다만 다른 워크로드를 운영하기 위해 이미 설비가 구축되어 있는 상황이라면 비교적 초기 비용이 낮을 수 있습니다.
전력, 냉각, 네트워크, 유지보수, 인건비, 부품 교체 등 지속적으로 발생하는 운영 비용도 다른 환경보다 비쌀 수 있습니다.
규모에 따라 클라우드 서비스를 이용하는 것 보다 저렴할 수 있지만 보통 k8s는 대규모 워크 로드에 사용되는 것을 생각해보면 클라우드의 운영 비용과 비슷하거나 더 많은 비용이 발생할 수 있다고 생각됩니다.
결과적으로 총 소유 비용(TCO)을 보자면 초기에는 높고, 장기적으로는 워크로드 규모와 안정성에 따라 클라우드보다 낮을 수도 있습니다.

EKS
클라우드 환경이기 때문에 초기 비용은 없습니다.
따라서 지속적인 운영 비용만 발생하게 되는데 EKS 컨트롤 플레인 비용 + EC2 인스턴스 비용 + EBS 스토리지 + 네트워크 전송 비용이 발생하며 이외에 AWS에서 추가적으로 사용하는 서비스하는 경우 추가적인 비용이 발생합니다.
총 소유 비용(TCO)으로는 대부분의 프로덕션 워크로드에서 자체 관리형보다 효율적^[4]입니다.

EC2
마찬가지로 초기 비용은 발생하지 않습니다.
운영 비용으로는 EC2 인스턴스 비용, EBS 스토리지, 네트워크 전송 비용이 발생하며 추가적으로 사용하는 AWS 서비스의 비용도 발생합니다.
다만 EKS와는 다르게 k8s 관리를 위한 오버헤드가 발생합니다.
결과적으로 총 소유 비용(TCO)은 온프레미스보다 낮을 가능성이 높지만 EKS보다 높을 수 있습니다.

주의 사항
위의 내용만 보면 클라우드 환경이 무조건적으로 온프레미스보다 저렴한것 처럼 보일 수 있지만, 기존 환경 및 워크로드의 규모에 따라 온프레미스가 더 저렴할 가능성도 있습니다.
더 구체적인 운영 비용의 비교가 필요한 경우 AWS Pricing Calculator를 사용하여 비용을 추산하거나 AWS에 문의하는 것을 권장합니다.

운영 난이도

온프레미스
이 글에서 소개하는 환경 중 가장 높은 난이도를 가집니다.
하드웨어부터 k8s 스택, 네트워크, 스토리지, 고가용성, 업그레이드 등 까지 모든 계층을 직접 관리해야 하므로 가장 높은 수준의 전문성과 노력이 필요합니다.

EKS
하드웨어 관리와 k8s 컨트롤 플레인 관리(내구성, 버전 업그레이드, 가용성 등)는 AWS에 위임되므로, 사용자는 주로 워커 노드 관리, 애플리케이션 배포, AWS 서비스 통합, 모니터링 및 로깅에 집중할 수 있습니다.

EC2
하드웨어 관리는 AWS에 위임되지만 k8s 클러스터의 모든 구성 요소(컨트롤 플레인 포함)를 직접 관리해야 하므로 높은 수준의 Kubernetes 전문 지식이 필요합니다.

정리
단순히 운영 난이도만으로 본다면 온프레미스가(가장 어려움)>EC2(어려움)>EKS(보통) 순이라고 생각합니다.

스케일링 전략

온프레미스
새로운 하드웨어를 구매, 설치 및 구성하여 워커 노드를 추가하는 등 모든 전략 및 대응을 직접 해야하니다.
따라서 매우 느리고 수동적입니다.

또한 Ansible, Puppet 등 구성 관리 도구를 사용하여 OS 및 Kubernetes 설치를 자동화할 수 있으나, 하드웨어 프로비저닝은 여전히 수동으로 대응하여야 합니다.

모든 대응이 비교적 느리고 영향이 크므로 처음부터 용량 계획에 많은 시간을 들일 필요가 있습니다.

EKS
EKS의 경우 스케일링에 영향을 받는 각 요소가 상당부분 자동화 및 간소화되어 있습니다.
따라서 비교적 스케일링 전략을 수립하기 쉽고, 변경하기도 쉽습니다.

우선 EKS의 워커 노드는 관리형 노드 그룹(Managed Node Groups)과 자체 관리형 노드(Self-managed Node Groups)가 있습니다.

관리형 노드 그룹의 경우, AWS가 워커 노드의 프로비저닝, 업데이트, 종료를 관리합니다. Auto Scaling Group과 연동하여 자동으로 스케일링됩니다.
자체 관리형 노드는 사용자가 직접 EC2 인스턴스를 관리합니다.
따라서 워크 로드에 따라 관리형 노드를 도입 가능하다면 스케일링에 필요한 오버헤드를 상당부분 줄일 수 있습니다.

컴퓨팅 리소스에는 EC2와 Fargate 중 선택할 수 있습니다.
서버리스 방식으로 운영할 수 있는 워크로드인 경우 서버리스인 Fargate를 도입하여 Pod 단위로 컴퓨팅 리소스를 프로비저닝하여 워커 노드 관리 부담을 완전히 없앨 수 있습니다.

오토 스케일링 수단으로 Cluster Autoscaler 혹은 Karpenter를 이용할 수 있습니다. 이를 통해 Pod의 리소스 요구량에 따라 자동으로 워커 노드를 추가/제거 할 수 있습니다.

Pod는 Horizontal Pod Autoscaler(HPA)를 사용하여 Pod의 CPU/메모리 사용량 또는 커스텀 메트릭에 따라 자동으로 스케일링됩니다.

EC2
워커 노드는 Auto Scaling Group(ASG)을 사용하여 EC2 인스턴스를 자동으로 프로비저닝하고, Kubernetes Cluster Autoscaler와 연동하여 노드 스케일링을 자동화할 수 있습니다.
단 컨트롤 플레인을 수동 또는 복잡한 자동화 스크립트를 통해 관리해야 한다는 점이 스케일링 전략에서 난이도가 높아지는 부분입니다.

사용 사례

온프레미스
인터넷 연결이 제한된 환경, 엄격한 규제 준수 및 데이터 주권 요구사항^[5]이 있는 산업인 경우 검토해보는 것을 권장합니다. (금융, 공공기관 등)

혹은 이미 대규모 데이터 센터 인프라를 보유하고 있으며, 클라우드 마이그레이션 비용이 더 큰 경우에는 굳이 클라우드로 이전하기 보단 온프레미스에서 운영하는 것이 적절할 수 있습니다.

특이한 레거시 시스템과의 통합이 필요한 경우 클라우드 환경을 도입하는 것 자체가 힘든 경우도 있습니다.

EKS
대부분의 프로덕션 워크로드에서 도입을 검토해볼 수 있습니다.
특히 빠른 개발 및 배포가 필요한 환경이나 높은 가용성과 안정성이 요구되는 서비스라면 가장 적합할 수 있습니다.

관리형 서비스이기 때문에 운영 부담을 최소화하고 애플리케이션 개발에 집중하고 싶은 경우나 AWS의 다른 서비스와 긴밀하게 통합해야 하는 경우에 적절합니다.
또한 담당 엔지니어가 쿠버네티스 자체의 경험이 적은 경우에도 EKS에 배포하는게 다른 환경보다 신경써야할 부분이 적기 때문에 운영 부담이 적어집니다.

EC2
EKS가 프로덕션 워크로드를 실행하는데 사용한다면 EC2에 배포하는 것은 k8s의 학습 및 개발, 실험 환경에 적합합니다.

예외적으로 EKS가 제공하지 않는 특정 k8s의 기능이나 커스텀 설정이 필요한 경우에 어쩔 수 없이 EC2를 사용해야하는 경우도 있습니다.^[6]

혹은 기존 온프레미스 또는 다른 클라우드에서 자체 관리형 k8s를 마이그레이션하는 경우, EKS로 마이그레이션 할 수 없다면 EC2가 대안이 될 수 있습니다.

정리표

GPT를 이용해 위의 내용을 표로 정리해보았습니다.

항목	On-premise Environment (온프레미스)	EKS (EKS 환경 - 관리형)	EC2 (EC2 환경 - 자체 관리)
관리 주체	모든 인프라 및 Kubernetes 스택 직접 관리	AWS가 Kubernetes 컨트롤 플레인 관리, 사용자 워커 노드 관리	AWS가 하드웨어 관리, Kubernetes 스택 직접 관리
초기 투자	매우 높음 (CAPEX)	없음	없음
운영 비용	매우 높음 (OPEX)	중간 (EKS 컨트롤 플레인 비용 + EC2 비용 + 낮은 관리 인건비)	중간 (EC2 비용 + Kubernetes 관리 인건비)
운영 난이도	최상	상	중
확장성	매우 느림 (하드웨어 구매/설치)	매우 빠름 (관리형 노드 그룹, Fargate, Cluster Autoscaler)	중간 (EC2 ASG 활용, 컨트롤 플레인 수동)
제어 수준	완전한 제어	중간 (컨트롤 플레인 제한적)	높음 (컨트롤 플레인 포함)
주요 장점	완전한 제어, 데이터 주권, 장기적 비용 절감 가능성 (대규모)	운영 오버헤드 대폭 감소, 고가용성, AWS 서비스 통합, 빠른 배포/확장	유연성, AWS 인프라 활용, 하드웨어 관리 불필요
주요 단점	높은 초기/운영 비용, 느린 확장, 복잡한 DR, 전문 인력 필수	컨트롤 플레인 제어 제한, 비용 (소규모), AWS 종속성	높은 운영 오버헤드, 복잡한 관리, EKS 대비 낮은 편의성
사용 사례	엄격한 규제, 기존 대규모 인프라, 특수 하드웨어 요구사항	대부분의 프로덕션 워크로드, 빠른 개발, 운영 부담 최소화, AWS 통합 필수	학습/실험, 특정 커스텀 요구사항, 기존 자체 관리 클러스터 마이그레이션

마무리

이상, 한국어 블로그 릴레이의 2025년 21 번째 블로그「「k8s 어느 환경에서 배포하고 운영하는게 좋을까?」편이었습니다. 다음 22 번째 블로그 릴레이는 7월 첫째 주에 공개됩니다.

끝까지 읽어주셔서 감사합니다! 이상, 클래스메소드의 이수재였습니다.

문의 사항은 클래스메소드 코리아로!

클래스메소드 코리아에서는 다양한 세미나 및 이벤트를 진행하고 있습니다.
진행중인 이벤트에 대해 아래 페이지를 참고해주세요.

https://classmethod.kr/board/library

AWS에 대한 상담 및 클래스 메소드 멤버스에 관한 문의사항은 아래 메일로 연락주시면 감사드립니다!
Info@classmethod.kr

脚注

1. 클라우드 서비스에서 제공하는 서비스에 따라서 하드웨어 컨트롤이 가능한 경우도 있습니다 ↩︎

2. 스펙 향상이 불필요한 경우 ↩︎

3. 단 업데이트를 적용할지 여부는 사용자가 결정합니다 ↩︎

4. 자체 관리형보다 인건비가 절감되기 때문 ↩︎

5. 민감한 데이터를 다루는 경우 ↩︎

6. 특이한 경우라고 생각합니다 ↩︎