🐳 AWS Container Services#

개념#

• 애플리케이션을 Container로 패키징하여 어떤 OS, 어떤 환경에서도 동일하게 실행
• “Works on my machine” 문제 해결: 개발/테스트/운영 환경 불일치 제거
• Use Cases: 마이크로서비스(Microservices), 온프레미스 앱의 AWS Lift-and-Shift

Docker Image 저장소#

Docker vs. Virtual Machine#

1
Virtual Machine:
2
  [Hardware] → [Hypervisor] → [Guest OS 1] → [App A]
3
                           → [Guest OS 2] → [App B]
4

5
Docker:
6
  [Hardware] → [Host OS] → [Docker Engine] → [Container A: App A]
7
                                           → [Container B: App B]

• Docker: Host OS 커널 공유 → 가볍고 빠름
• VM: 각각 완전한 OS 포함 → 무겁지만 강한 격리

EC2 Launch Type#

• ECS Cluster 위에 직접 EC2 Instance를 프로비저닝/관리
• 각 EC2 Instance에 ECS Agent 설치 필수 → ECS Cluster에 등록
• AWS는 Container의 시작/중지만 담당

1
[ECS Cluster]
2
  ├── EC2 Instance 1 (ECS Agent 실행)
3
  │     ├── Container A
4
  │     └── Container B
5
  └── EC2 Instance 2 (ECS Agent 실행)
6
        └── Container C

Fargate Launch Type#

• EC2 Instance 없이 완전 Serverless로 컨테이너 실행
• Task Definition만 생성하면 AWS가 알아서 컨테이너 실행
• 스케일링: Task 수만 늘리면 됨 — EC2 Instance 관리 불필요

1
[ECS Cluster]
2
  └── Fargate Task A  ← AWS가 인프라 자동 관리
3
  └── Fargate Task B
4
  └── Fargate Task C

EC2 Launch Type vs. Fargate 비교#

ECS IAM Roles#

두 가지 Role을 명확히 구분 — 시험 빈출

1
EC2 Instance
2
  └── ECS Agent (EC2 Instance Profile 사용)
3
        └── ECS Task A (Task Role A: S3 Read 권한)
4
        └── ECS Task B (Task Role B: DynamoDB Write 권한)

TIP

Task Role은 Task Definition에서 정의. EC2 Instance Profile과 독립적으로 동작.

ECS Load Balancer 통합#

ECS - Data Volumes (EFS 연동)#

• ECS Task에 EFS 파일 시스템 마운트 가능
• EC2 및 Fargate Launch Type 모두 지원
• 어떤 AZ에서 실행되든 동일한 EFS 데이터 공유

1
Fargate + EFS = 완전 Serverless 영구 스토리지

IMPORTANT

Amazon S3는 ECS Task에 파일 시스템으로 마운트 불가 (S3는 Object Storage).

ECS Service Auto Scaling#

ECS Service(Task 레벨) Auto Scaling과 EC2 Instance Auto Scaling은 별개임.

ECS Service Auto Scaling 정책:

스케일링 지표:

• ECS Service Average CPU Utilization
• ECS Service Average Memory Utilization
• ALB Request Count Per Target

EC2 Launch Type — Auto Scaling EC2 Instances#

ECS Service가 스케일 아웃되면 EC2 인스턴스도 함께 늘어야 함.

TIP

Capacity Provider가 권장됨: Task 수요에 따라 EC2를 자동 프로비저닝.

ECS 이벤트 기반 아키텍처#

Pattern 1: S3 → EventBridge → ECS Task (On-demand)

1
[사용자] → S3 Upload
2
              │
3
              ▼ EventBridge Rule
4
         [ECS Task 실행] → S3에서 파일 가져오기 → DynamoDB 저장
5
         (ECS Task Role: S3 + DynamoDB 권한)

Pattern 2: EventBridge Schedule → ECS Task (Batch)

1
[EventBridge: 매 1시간] → ECS Task 실행 → S3 Batch Processing

개요#

• 완전 관리형 Kubernetes Cluster 서비스
• Kubernetes: 컨테이너 자동 배포, 스케일링, 관리를 위한 오픈소스 시스템
• ECS와 유사한 목적이지만 다른 API (Kubernetes API)
• Cloud-agnostic → 다른 클라우드/온프레미스의 Kubernetes와 호환

TIP

• 선택 기준:
  • 이미 Kubernetes를 사용 중이거나 멀티 클라우드 전략 → EKS.
  • AWS에서 새로 시작 → ECS가 더 단순.

EKS Node Types#

Managed/Self-Managed: On-Demand 또는 Spot Instance 모두 지원

EKS Data Volumes#

• EKS Cluster에 StorageClass Manifest 지정 필요
• CSI (Container Storage Interface) 드라이버 사용

A2C 프로세스#

1
1. Discover & Analyze
2
   앱 인벤토리 생성 + 런타임 의존성 분석
3

4
2. Extract & Containerize
5
   앱 + 의존성 추출 → Docker Image 생성
6

7
3. Create Deployment Artifacts
8
   ECS Task Definition / EKS Pod Definition 생성
9
   CloudFormation Template (인프라: 컴퓨팅, 네트워크) 생성
10
   CI/CD Pipeline 생성
11

12
4. Deploy to AWS
13
   Docker Image → ECR 등록
14
   → ECS / EKS / App Runner 배포