컨테이너 서비스

ECR 이미지 저장소에서 ECS, EKS, Fargate 실행 환경으로 배포하는 흐름

컨테이너 이미지가 같아도 실행 환경을 누가 관리하는지에 따라 운영 작업은 달라진다. 기존 Kubernetes 생태계를 이어갈지, AWS 관리형 오케스트레이션을 사용할지, 노드 관리까지 줄일지부터 판단한다. 이 기준으로 ECS·EKS와 Fargate·EC2의 조합을 비교한다.

1. 컨테이너 기초 개념

Docker 핵심 용어

이미지 (Image)     — 컨테이너 실행을 위한 읽기 전용 템플릿
컨테이너 (Container) — 이미지를 실행한 인스턴스
레지스트리 (Registry) — 이미지 저장소 (ECR, Docker Hub)

AWS 컨테이너 서비스 전체 구조

이미지 저장: ECR
컨테이너 오케스트레이션:
  ├── ECS — AWS 관리형 오케스트레이터
  └── EKS — 관리형 Kubernetes
컨테이너 실행 환경:
  ├── Fargate — 서버리스 (인프라 관리 불필요)
  └── EC2     — EC2 클러스터 직접 관리
완전 관리형 플랫폼:
  └── App Runner — 소스코드/이미지 → 자동 배포

2. ECR (Elastic Container Registry)

핵심 개념

ECR은 AWS의 완전 관리형 Docker 이미지 레지스트리다.

개발자
  → docker build → 로컬 이미지
  → docker tag   → ECR 리포지토리 URI 태그
  → docker push  → ECR에 이미지 저장
    → ECS / EKS  → ECR에서 이미지 pull

주요 기능

리포지토리 유형 | 유형 | 특성 | |------|------| | 프라이빗 | 기본, IAM 권한으로 접근 제어 | | 퍼블릭 | ECR Public Gallery, 누구나 pull 가능 |

이미지 스캔

기본 스캔: 푸시 시 CVE 취약점 자동 스캔
고급 스캔: Amazon Inspector 연동, 지속적 스캔

수명 주기 정책 (Lifecycle Policy)

규칙: 태그 없는 이미지 30일 초과 시 자동 삭제
규칙: latest 외 태그 10개 초과 시 오래된 것부터 삭제

→ 스토리지 비용 자동 관리

교차 계정 접근

리소스 기반 정책으로 다른 계정에 pull 권한 부여
프로덕션 계정이 빌드 계정의 ECR에서 이미지 pull

VPC 내에서 ECR 접근

인터넷 없이 ECR 사용: VPC Endpoint (com.amazonaws.{region}.ecr.api / .dkr)
S3 Gateway Endpoint도 필요 (이미지 레이어가 S3에 저장)

3. ECS (Elastic Container Service)

핵심 구성 요소

클러스터 (Cluster)
  └── 서비스 (Service)
        └── 태스크 (Task) × N개
              └── 컨테이너 (Container) × N개

개념	설명
태스크 정의 (Task Definition)	컨테이너 설정 명세 (이미지, CPU, 메모리, 포트, 환경변수)
태스크 (Task)	태스크 정의로 실행된 컨테이너 인스턴스
서비스 (Service)	태스크 수 유지, 로드 밸런서 연동, 배포 관리
클러스터 (Cluster)	태스크·서비스의 논리적 그룹

실행 모드: Fargate vs EC2

항목	Fargate	EC2
인프라 관리	불필요 (AWS 관리)	EC2 인스턴스 직접 관리
비용	vCPU·메모리 사용량 기반	EC2 인스턴스 비용
확장성	자동 (태스크 단위)	EC2 + 태스크 모두 확장
GPU	미지원	지원 (p3, g4dn 등)
커스텀 AMI	불가	가능
사용 시나리오	서버리스, 관리 최소화	GPU, 특수 인스턴스, 비용 최적화

SAP 핵심: 인프라 관리 최소화 = Fargate / GPU·특수 요구사항 = EC2 모드

ECS 네트워크 모드

모드	설명	사용 환경
awsvpc	태스크마다 ENI 할당, 보안 그룹 적용 가능	Fargate 필수, EC2 권장
bridge	Docker 브리지 네트워크, 동적 포트 매핑	EC2, 레거시
host	EC2 호스트 네트워크 직접 사용	고성능 필요 시
none	네트워크 없음	배치 작업

SAP 핵심: Fargate = awsvpc 모드만 지원 / 태스크별 보안 그룹 = awsvpc

ECS 서비스 배포 전략

롤링 업데이트

최소 정상 비율: 100% → 최대 비율: 200%
→ 기존 태스크 유지하며 새 태스크 추가 후 순차 교체

Blue/Green 배포 (CodeDeploy 연동)

현재 (Blue): 구버전 태스크
신규 (Green): 새 버전 태스크
  → 트래픽 전환 (즉시 or 단계적)
  → 문제 시 즉시 롤백

ECS Auto Scaling

서비스 Auto Scaling (태스크 수 조정)
  ├── 타겟 추적: CPU 70% 유지
  ├── 단계적 조정: 조건별 증감
  └── 예약: 스케줄 기반

EC2 Auto Scaling (EC2 모드, 클러스터 용량)
  → Capacity Provider로 연동 권장

ECS 태스크 역할 vs 실행 역할

역할	용도
태스크 실행 역할 (Execution Role)	ECS가 ECR pull, CloudWatch Logs 전송하는 권한
태스크 역할 (Task Role)	컨테이너 내 애플리케이션이 AWS 서비스에 접근하는 권한

태스크 실행 역할: ECR:GetAuthorizationToken, logs:CreateLogStream 등
태스크 역할:     DynamoDB:GetItem, S3:PutObject 등 (앱 비즈니스 로직)

사이드카 패턴

태스크 정의
  ├── 메인 컨테이너 (애플리케이션)
  ├── 사이드카: X-Ray 데몬 (분산 추적)
  ├── 사이드카: Fluent Bit (로그 수집)
  └── 사이드카: Envoy (서비스 메시, App Mesh)

4. EKS (Elastic Kubernetes Service)

핵심 개념

EKS는 AWS가 관리하는 Kubernetes다. 컨트롤 플레인(API 서버, etcd)은 AWS가 관리하고, 워커 노드만 사용자가 관리한다.

EKS 컨트롤 플레인 (AWS 관리)
  ↕ kubectl / API
워커 노드 그룹
  ├── 관리형 노드 그룹 (Managed Node Group) — EC2 자동 프로비저닝
  ├── 자체 관리 노드 (Self-managed)         — 직접 EC2 관리
  └── Fargate 프로파일                      — 서버리스 파드

ECS vs EKS 선택 기준

항목	ECS	EKS
학습 곡선	낮음 (AWS 전용)	높음 (Kubernetes 지식 필요)
이식성	AWS 종속	Kubernetes 표준 (멀티클라우드)
생태계	AWS 서비스 통합 우수	Helm, Istio 등 풍부한 CNCF 생태계
복잡도	단순	복잡 (고급 기능 많음)
멀티클라우드·온프레미스	어려움	용이 (EKS Anywhere)

SAP 핵심: Kubernetes 이미 사용 중 or 멀티클라우드 = EKS / AWS 신규 구축 = ECS

EKS 주요 구성

노드 유형

관리형 노드 그룹: AWS가 EC2 프로비저닝·패치·업그레이드 자동화
Fargate: 파드 단위 서버리스 실행, 노드 관리 불필요
Karpenter: 오픈소스 노드 오토스케일러, 빠른 스케일 아웃

스토리지

EBS: 파드 단일 연결 (ReadWriteOnce)
EFS: 여러 파드 동시 연결 (ReadWriteMany)
FSx for Lustre: HPC, ML 워크로드

네트워킹

VPC CNI 플러그인: 파드에 VPC IP 직접 할당
보안 그룹 for Pods: 파드별 보안 그룹 적용

EKS Anywhere

온프레미스, 엣지 환경에서 EKS 실행
동일한 Kubernetes API, 도구 사용

5. App Runner

핵심 개념

App Runner는 소스코드 또는 컨테이너 이미지만 제공하면 나머지는 AWS가 알아서 처리하는 완전 관리형 서비스다.

소스: GitHub 리포지토리 or ECR 이미지
  → App Runner
    ├── 빌드 (소스 코드의 경우)
    ├── 배포
    ├── 로드 밸런싱
    ├── Auto Scaling (0 → N → 0)
    └── TLS 인증서

App Runner vs 다른 서비스

항목	App Runner	ECS Fargate	Lambda
설정 복잡도	최소	중간	낮음
최대 실행 시간	무제한	무제한	15분
트래픽 0일 때	최소 인스턴스 유지	태스크 0 가능	완전 중단
사용 시나리오	웹 API, 마이크로서비스	범용 컨테이너	이벤트 기반

SAP 핵심: "가장 빠르게 컨테이너 배포, 인프라 관리 전혀 하지 않겠다" = App Runner

6. 마이크로서비스 배포 패턴

패턴 1: ECS + ALB 기반 마이크로서비스

클라이언트
  → ALB
    ├── /api/user*   → ECS 서비스 (User Service)
    ├── /api/order*  → ECS 서비스 (Order Service)
    └── /api/payment* → ECS 서비스 (Payment Service)

각 서비스: Fargate + awsvpc 모드 + 독립 보안 그룹

패턴 2: 서비스 메시 (AWS App Mesh)

각 ECS 태스크에 Envoy 사이드카 자동 주입
  → 서비스 간 통신 암호화 (mTLS)
  → 트래픽 가중치 기반 라우팅 (카나리 배포)
  → X-Ray 분산 추적 자동 통합

패턴 3: CI/CD 파이프라인

CodeCommit / GitHub
  → CodeBuild
    ├── docker build
    ├── docker push → ECR
    └── 이미지 취약점 스캔
  → CodeDeploy
    → ECS Blue/Green 배포
      → CloudWatch 지표 모니터링
        → 문제 시 자동 롤백

패턴 4: 배치 처리 (ECS Scheduled Tasks)

EventBridge 스케줄 (매일 새벽 2시)
  → ECS 태스크 실행 (Fargate)
    → 데이터 처리 완료 후 자동 종료
      → 비용: 실행 시간만큼만 과금

패턴 5: 하이브리드 (EC2 + Fargate)

ECS 클러스터
  ├── EC2 Capacity Provider — GPU 작업, 지속 실행 서비스
  └── Fargate Capacity Provider — 버스트 트래픽, 배치 작업
→ Capacity Provider 전략으로 자동 분배

7. 컨테이너 스토리지 및 시크릿 관리

데이터 영속성

ECS 볼륨 | 유형 | 특성 | |------|------| | EFS | Fargate 지원, 여러 태스크 공유, 영구 저장 | | EBS | EC2 모드만, 단일 태스크 연결 | | Bind Mount | 호스트 경로 마운트 (임시, 태스크 간 공유) |

시크릿 주입

태스크 정의 → 환경변수에 직접 하드코딩 (X)

올바른 방법:
AWS Secrets Manager or SSM Parameter Store에 저장
  → 태스크 정의에서 참조 (ARN)
    → ECS가 태스크 시작 시 자동으로 값 주입
      → 컨테이너 환경변수로 전달

8. 비용 최적화

Fargate Spot

Fargate Spot: 일반 Fargate 대비 최대 70% 저렴
  → AWS가 용량 필요 시 2분 전 알림 후 중단
  → 중단 허용 가능한 배치 작업, 개발 환경에 적합
  → 프로덕션: 일반 Fargate + Spot 혼합 사용

EC2 Spot + ECS

EC2 Spot 인스턴스로 ECS 클러스터 구성
  → 비용 최대 90% 절감
  → Spot 중단 시 ECS가 다른 인스턴스에 태스크 재배치
  → 중단에 강한 Spot 드레이닝(draining) 설정 필요

9. 핵심 암기 포인트

키워드	선택
인프라 관리 없는 컨테이너 실행	ECS Fargate
GPU, 특수 인스턴스 컨테이너	ECS EC2 모드
Kubernetes 기반, 멀티클라우드	EKS
온프레미스 Kubernetes	EKS Anywhere
소스코드 → 자동 배포, 최소 설정	App Runner
컨테이너 이미지 저장·스캔	ECR
태스크별 보안 그룹 적용	awsvpc 네트워크 모드
여러 태스크가 공유하는 영구 스토리지	EFS
컨테이너 시크릿 안전 주입	Secrets Manager / SSM → 태스크 정의 참조
ECS 무중단 배포	Blue/Green (CodeDeploy)
배치 작업 비용 최소화	Fargate Spot
ECS + 분산 추적	X-Ray 사이드카
사내 Kubernetes 도구 그대로 AWS에서	EKS

핵심 내용을 다시 정리하면

ECR: 이미지 저장·스캔·수명 주기 정책, VPC 내 접근은 VPC Endpoint
ECS: 태스크 정의 → 서비스 → 클러스터 구조, Fargate(관리 최소)와 EC2(유연성) 모드 구분
EKS: Kubernetes 표준, 멀티클라우드·온프레미스 이식성, ECS보다 복잡하지만 생태계 풍부
App Runner: 가장 단순한 컨테이너 배포, 소스/이미지만 제공하면 끝
배포 패턴: Blue/Green, 사이드카, Capacity Provider 혼합 전략

이어 읽기: 13. 7R 전략과 AWS 이전 서비스