AWS Certified CloudOps Engineer - Associate (SOA-C03) #9 Domain 3-3 배포: 컨테이너 운영(ECS,EKS,ECR)
#7,#8에서 인프라 배포와 인스턴스 운영을 정리했습니다. 이 글은 SOA-C03에서 새로 들어온 컨테이너 운영입니다. 구 SOA-C02에는 컨테이너 범위가 거의 없었지만, CloudOps Engineer로 개명되면서 ECS,EKS,ECR이 출제 범위에 들어왔습니다. 시험은 컨테이너를 “어떻게 짜는가"가 아니라 “어떻게 운영하는가”(배포,로깅,스케일링,이미지 관리)를 묻습니다.
ECS vs EKS: 무엇을 고르는가 #
| 항목 | ECS | EKS |
|---|---|---|
| 성격 | AWS 자체 컨테이너 오케스트레이터 | 관리형 Kubernetes |
| 학습 곡선 | 낮음. AWS에 깊이 통합 | 높음. K8s 생태계 |
| 언제 | AWS 안에서 단순하게 | K8s 표준,멀티 클라우드,기존 K8s 자산 |
핵심 구분은 단순합니다. K8s가 꼭 필요한 이유(표준 호환,기존 자산,멀티 클라우드)가 없으면 ECS, K8s 생태계를 써야 하면 EKS입니다. 운영 부담 최소화 조건에서는 대체로 ECS가, 특히 Fargate와 묶이면 더 그렇습니다.
시작 유형: Fargate vs EC2 #
ECS와 EKS 모두 컨테이너를 실제로 돌릴 컴퓨팅을 골라야 합니다.
| 유형 | 누가 서버를 관리 | 언제 |
|---|---|---|
| Fargate | AWS(서버리스). 인스턴스 관리 없음 | 운영 부담 최소화, 가변 부하 |
| EC2 | 사용자가 인스턴스 관리 | 세밀한 제어,특수 인스턴스,비용 최적화 |
“컨테이너를 돌리되 인스턴스 패치,스케일링을 신경 쓰고 싶지 않다"는 답이 Fargate입니다. 반대로 GPU나 특정 인스턴스 타입이 필요하거나, 사용률이 높아 EC2가 더 싸면 EC2 시작 유형입니다.
ECR: 이미지 레지스트리 #
ECR은 컨테이너 이미지를 저장하는 프라이빗 레지스트리입니다. 운영 포인트는 다음입니다.
- 이미지 스캔: 푸시 시 또는 상시로 취약점(CVE) 스캔. 보안 운영의 단골
- 라이프사이클 정책: 오래된 미사용 이미지를 자동 정리해 저장 비용 관리
- 권한: IAM과 리포지토리 정책으로 접근 통제. 교차 계정 공유 가능
- 복제: 교차 리전,계정 복제로 배포 지연 단축과 DR
“컨테이너 이미지의 취약점을 배포 전에 잡아라"는 답이 ECR 이미지 스캔입니다. “이미지가 계속 쌓여 비용이 는다"는 라이프사이클 정책입니다.
컨테이너 로깅과 모니터링 #
#2,#3의 CloudWatch가 컨테이너에도 그대로 이어집니다.
| 대상 | 운영 방법 |
|---|---|
| 로그 | ECS는 awslogs 로그 드라이버로 CloudWatch Logs에 전송. Firelens(FluentBit)로 다른 대상도 가능 |
| 지표 | Container Insights로 CPU,메모리,태스크 수 등 컨테이너 지표 수집 |
| 추적 | X-Ray로 분산 추적 |
Container Insights가 컨테이너 모니터링의 핵심 이름입니다. “ECS,EKS의 컨테이너 단위 성능을 한눈에 보라"는 답이 Container Insights입니다. 기본 EC2 지표만으로는 컨테이너 안이 안 보입니다.
배포와 스케일링 운영 #
- 롤링 업데이트: 태스크를 점진 교체. 기본 배포 방식
- 블루/그린(CodeDeploy 연동): 새 버전을 따로 띄우고 전환. 빠른 롤백
- Service Auto Scaling: 지표(CPU,요청 수)에 따라 태스크 수 자동 조절
- 태스크 정의(Task Definition): 컨테이너 이미지,CPU,메모리,환경변수,IAM 역할(태스크 역할)을 선언
운영 보안 포인트 하나는 태스크 역할(Task Role)입니다. 컨테이너가 AWS API를 호출할 때 쓰는 권한으로, EC2 인스턴스 역할이 아니라 태스크 단위로 최소 권한을 부여하는 것이 정석입니다.
시험 출제 패턴 #
- K8s가 꼭 필요하지 않고 운영 부담 최소화 → ECS + Fargate
- 인스턴스 관리 없이 컨테이너 실행 → Fargate
- 이미지 취약점을 배포 전 탐지 → ECR 이미지 스캔
- 미사용 이미지로 비용 증가 → ECR 라이프사이클 정책
- 컨테이너 단위 성능 모니터링 → Container Insights
- 컨테이너가 AWS API 호출 → 태스크 역할(최소 권한)
- 빠른 롤백이 필요한 배포 → 블루/그린(CodeDeploy)
자주 만나는 함정 #
1) EC2 지표로 컨테이너가 보인다고 생각 #
기본 EC2 지표는 인스턴스 전체만 봅니다. 컨테이너,태스크 단위는 Container Insights가 있어야 보입니다.
2) 컨테이너 권한을 인스턴스 역할로 준다 #
여러 태스크가 한 인스턴스를 공유하면 인스턴스 역할은 과한 권한이 됩니다. 태스크 역할로 태스크별 최소 권한을 줍니다.
3) 운영 부담 최소화인데 EC2 시작 유형을 고름 #
특별한 이유가 없으면 운영 부담 최소화의 답은 Fargate입니다.
4) 로그가 자동으로 CloudWatch에 간다고 가정 #
ECS는 로그 드라이버(awslogs)나 Firelens 설정이 있어야 CloudWatch Logs로 보냅니다.
정리 #
이번 글에서 잡은 것:
- ECS(AWS 네이티브,단순) vs EKS(관리형 K8s). 특별한 이유 없으면 ECS
- Fargate(서버리스,운영 부담 최소) vs EC2 시작 유형(세밀 제어,비용). 운영 부담 최소화는 Fargate
- ECR: 이미지 스캔(취약점),라이프사이클 정책(비용),교차 리전 복제
- Container Insights로 컨테이너 단위 지표,
awslogs,Firelens로 로그 - 태스크 역할로 컨테이너별 최소 권한. 인스턴스 역할로 주지 않기
다음: Domain 4-1 VPC 운영과 트러블슈팅 #
배포,자동화 도메인을 마쳤습니다. 다음은 네 번째 도메인인 네트워킹과 콘텐츠 전송입니다.
#10 Domain 4-1 네트워킹: VPC 운영과 연결 트러블슈팅에서는 라우팅 테이블과 게이트웨이, 보안 그룹과 NACL의 차이, VPC 피어링과 엔드포인트, 그리고 연결이 안 될 때 어디를 어떤 순서로 점검하는지 운영 관점에서 정리하겠습니다.