EC2·ECS·EKS 선택 기준

AWS에는 코드를 실행시킬 수 있는 컴퓨트 엔진이 매우 다양합니다. 단순히 EC2에 배포하면 될 것 같다가도, 다른 조직들이 EKS를 사용한다는 소식에 뒤처지는 기분이 들기도 합니다. 하지만 모든 도구에는 각자에게 맞는 용도가 있습니다

워크로드의 성격과 팀의 인프라 역량에 따라 가장 적합한 컴퓨트(Compute) 옵션을 고르는 기준을 정리해 보겠습니다

책임 모델에 따른 스펙트럼

AWS의 컴퓨트 옵션은 “누가 서버(인프라)를 관리할 것인가”에 따라 나열할 수 있습니다

컴퓨트 옵션	실행 형태	관리 주체 (OS 패치 등)	인프라 자유도	언제 쓰는가?
EC2	가상 머신(VM)	개발자/운영자 (100% 본인 책임)	가장 높음	레거시, 특정 OS 환경 필요, 윈도우 워크로드
ECS (EC2 Mode)	컨테이너	개발자 (인스턴스) + AWS (스케줄러)	높음	도커가 친숙하고 커스텀 인스턴스가 필요한 도메인
EKS	쿠버네티스	클러스터 운영팀	매우 높음	대규모 마이크로서비스, 기존 쿠버네티스 자산 재사용
Fargate (ECS/EKS)	서버리스 컨테이너	AWS가 서버리스로 프로비저닝	중간	인프라 운영 없이 “컨테이너만” 실행하고 싶을 때
Lambda	함수 (Function)	AWS 100% 관리	낮음 (언어 종속)	이벤트 기반 비동기 작업, 짧은 트리거 작업

자유도가 높을수록 운영자가 보안 패치와 디스크 알람에 더 많이 신경 써야 하며, 자유도가 낮을수록 서비스 로직에만 집중할 수 있습니다

ECS vs EKS (컨테이너 오케스트레이션)

도커 기반 워크로드로 넘어왔다면 대부분 이 두 가지 사이에서 고민하게 됩니다

flowchart LR
    subgraph _ecs [Amazon ECS]
        ECS_CP["ECS Control Plane<br/>(완전 관리형, 무료)"]
        ECS_Task[["Tasks (Containers)"]]
        
        ECS_CP -->|"Run"| ECS_Task
    end

    subgraph _eks [Amazon EKS]
        EKS_CP["EKS Control Plane<br/>(과금 발생, 오픈소스 K8s)"]
        EKS_Pod[["Pods (Containers)"]]
        
        EKS_CP -->|"Schedule"| EKS_Pod
    end
    
    classDef primary fill:#2563eb,stroke:#1e40af,color:#ffffff
    classDef success fill:#059669,stroke:#047857,color:#ffffff
    classDef warn fill:#d97706,stroke:#b45309,color:#ffffff
    classDef danger fill:#dc2626,stroke:#991b1b,color:#ffffff
    classDef info fill:#0891b2,stroke:#0e7490,color:#ffffff
    classDef neutral fill:#475569,stroke:#334155,color:#ffffff
    classDef muted fill:#e2e8f0,stroke:#94a3b8,color:#0f172a

    class _ecs primary
    class ECS_CP,ECS_Task success
    class _eks info
    class EKS_CP,EKS_Pod info

ECS는 AWS가 자체 개발한 스케줄러입니다. Control Plane 비용이 없으며, ALB(로드밸런서)나 IAM 같은 다른 AWS 서비스와 매우 긴밀하게 통합되어 있습니다. 중소 규모 조직이거나 AWS 생태계를 주로 사용한다면 ECS가 압도적으로 효율적입니다
EKS는 오픈소스 Kubernetes를 AWS가 매니지드 형태로 제공하는 서비스입니다. 강력하지만 러닝 커브가 꽤 가파릅니다. 오픈소스 생태계(Helm, Istio, ArgoCD)를 활용하고자 하는 플랫폼 조직에게 필수적입니다

Fargate의 위력과 한계

ECS든 EKS든 백엔드에 EC2를 직접 구성해야 한다면(EC2 Mode), 결국 해당 인스턴스의 패치와 확장은 개발자가 책임져야 합니다. 하지만 데이터 플레인을 **Fargate**로 설정하면 서버라는 개념 자체가 사라집니다. "CPU 2코어, 4GB 메모리 컨테이너를 실행해줘!"라고 요청하면 AWS가 이를 처리하고 초 단위로 과금합니다. 단, EC2보다 시간당 단가가 높고 특수한 스토리지 레이어를 연결하기 까다롭다는 트레이드오프가 있습니다

컴퓨트 마이그레이션 진화 경로

일반적으로 조직의 클라우드 성숙도에 따라 컴퓨트 자원 활용은 다음과 같이 진화합니다

Phase 1: Lift and Shift — 기존 온프레미스 서버를 있는 그대로 EC2로 마이그레이션
Phase 2: Containerization — 애플리케이션 코드를 도커 이미지로 제작하여 ECS(또는 EKS)로 배포
Phase 3: Serverless — 이벤트 중심 아키텍처나 API 모듈을 Lambda 단위로 분할하여 서버리스로 전환 (또는 완전 관리형 Fargate 전환)

모든 워크로드를 한 번에 EKS로 이전하는 것은 운영 부담이 클 수 있습니다. 현재 팀의 역량과 유지보수 비용을 충분히 고려하여 선택해야 합니다

정리

EC2는 높은 수준의 제어권이 필요할 때 여전히 효과적입니다
복잡한 관리 없이 컨테이너를 손쉽게 운영하고자 한다면 ECS를 추천합니다
대규모 MSA 환경과 풍부한 오픈소스 K8s 생태계가 필요하다면 EKS가 적합합니다
운영 부담을 줄이기 위해 가능한 한 Fargate나 Lambda 같은 서버리스 모델 도입을 적극적으로 검토해야 합니다

컴퓨트를 통해 애플리케이션을 구동했다면, 이제 생성된 데이터와 파일들을 안전하게 보관해야 합니다. 다음 글에서는 가장 대중적인 저장소인 S3 스토리지와 RDS 데이터베이스의 운영 포인트를 살펴보겠습니다