ECS·Fargate·컨테이너 등은 모두 "애플리케이션을 어떻게 안정적으로 실행할 것인가"를 다루는 기술이지만, 각각이 담당하는 계층과 해결하려는 문제가 다릅니다. 본 문서는 각 기술이 무엇이고, 어떤 상황에 쓰이며, 어떤 장단점과 사용 시 유의점이 있는지를 정리한 배경 지식 자료입니다.

1. 컨테이너 (Container)

격리·이식성을 제공하는 포장 기술

어떤 기술인가

운영체제 커널의 네임스페이스(namespace), cgroups, 유니온 파일시스템을 활용해 프로세스를 격리해 실행하는 기술. 가상머신과 달리 OS 전체를 부팅하지 않고, 호스트 커널을 공유하면서 사용자 공간(user-space)만 격리합니다. 대표 구현체로 Docker, containerd, CRI-O, Podman 등이 있습니다.

어떨 때 쓰이는가

• 개발/스테이징/프로덕션 환경 간 "내 컴퓨터에서는 됐는데" 문제 제거
• 마이크로서비스 단위 배포·확장
• CI/CD 파이프라인의 빌드·테스트 환경 표준화
• 단기간 실행되는 배치/Job, 함수형 워크로드 패키징

2. Docker

컨테이너 이미지의 사실상 표준 도구

어떤 기술인가

컨테이너 이미지 빌드·배포·실행을 표준화한 도구 + 생태계. Dockerfile이라는 선언적 빌드 스크립트, 이미지 레지스트리, CLI/데몬 아키텍처로 구성됩니다. 현재 컨테이너 이미지의 사실상 표준은 OCI(Open Container Initiative) 규격이며, Docker는 그 대표 구현체입니다.

어떨 때 쓰이는가

• 로컬 개발 환경 구축 (DB, Redis, 메시지 큐 한 번에)
• CI 환경에서 빌드·테스트 격리
• 프로덕션 배포 단위 패키징

3. ECS (Elastic Container Service)

AWS 네이티브 컨테이너 오케스트레이터

어떤 기술인가

AWS가 제공하는 컨테이너 오케스트레이션 서비스. 다수의 컨테이너를 클러스터 단위로 관리하며, 배포·스케일링·헬스체크·롤링 업데이트를 선언적으로 처리합니다. Kubernetes(EKS)와 같은 위치의 AWS 네이티브 솔루션입니다.

핵심 개념

Task Definition	컨테이너 이미지·자원·환경변수·IAM Role 등을 담은 JSON 명세
Task	Task Definition을 바탕으로 실제 띄워진 컨테이너 묶음
Service	desired count, 배포 전략, 로드 밸런서 연결을 관리
Cluster	위 자원들을 그룹화하는 논리적 경계

어떨 때 쓰이는가

• AWS 단일 클라우드에서 Kubernetes의 운영 복잡도를 피하고 싶을 때
• ALB/NLB·IAM·CloudWatch·ECR과 깊게 통합된 운영을 선호할 때
• 팀 규모가 작아 별도 K8s 운영 인력을 두기 어려울 때

4. Fargate

서버리스 컨테이너 실행 모드

어떤 기술인가

ECS(또는 EKS) 위에서 동작하는 서버리스 컨테이너 실행 모드. EC2 인스턴스를 직접 프로비저닝·패치하지 않고도 컨테이너를 실행할 수 있도록, AWS가 격리된 microVM(Firecracker 기반)을 태스크 단위로 즉시 할당해줍니다.

EC2 모드와의 차이

항목	ECS on EC2	ECS on Fargate
호스트 OS 관리	팀 책임	AWS 책임
패치·업데이트	팀이 수행	자동
과금 단위	인스턴스 시간	태스크 vCPU·메모리 시간
컨테이너 밀도	운영자가 결정	AWS가 격리 보장

어떨 때 쓰이는가

• 트래픽 변동이 큰 서비스 (자동 스케일 시 노드 확장 부담 제거)
• 노드 OS 패치·보안 관리 인력을 따로 둘 수 없는 팀
• 배치/Job 같은 단발성 워크로드
• 컨테이너 밀도보다 격리·관리 편의성이 중요한 케이스

5. ECR (Elastic Container Registry)

AWS 관리형 컨테이너 이미지 레지스트리

AWS가 제공하는 컨테이너 이미지 레지스트리. Docker Hub의 AWS 버전이며, IAM과 통합되어 권한·암호화·취약점 스캐닝을 기본 제공합니다.

6. ALB / NLB (로드 밸런서)

L7·L4 트래픽 분산

AWS의 관리형 로드 밸런서.

• ALB(Application Load Balancer): L7(HTTP/HTTPS), 경로·호스트 기반 라우팅, gRPC, WebSocket 지원
• NLB(Network Load Balancer): L4(TCP/UDP), 초저지연·정적 IP·고정 포트 필요 시 사용

7. CloudWatch Logs / Metrics

AWS 통합 모니터링 서비스

AWS의 통합 모니터링 서비스. 컨테이너 stdout/stderr가 자동으로 로그 그룹에 적재되며, 메트릭 기반 알람·대시보드를 제공합니다.

8. IAM (Identity and Access Management)

권한 관리 시스템

AWS의 권한 관리 시스템. 사용자·역할(Role)·정책(Policy)으로 리소스 접근을 통제합니다. 컨테이너 환경에서는 Task Role을 통해 컨테이너 내부 SDK가 임시 자격증명을 자동 획득합니다.

🛠 실습 — Express 앱을 ECS Fargate에 띄우기

로컬 Docker로 검증 → ECR push → ECS Fargate 서비스 배포 → ALB로 트래픽 받기까지 한 번에 따라가는 시나리오입니다.

사전 준비

• AWS 계정 + IAM 사용자 (ECR·ECS·IAM·CloudWatch 권한)
• AWS CLI v2 (aws configure 완료)
• Docker Desktop 또는 Colima
• Node.js 20 (실습은 Node 기준)
• (선택) AWS Copilot CLI — Fargate 배포를 한 줄로 단축

STEP 1 — 작은 Express 앱과 Dockerfile

mkdir hello-fargate && cd hello-fargate
npm init -y
npm i express

cat > server.js <<'EOF'
const express = require('express');
const app = express();
app.get('/health', (_, res) => res.json({ ok: true }));
app.get('/', (_, res) => res.json({ msg: 'hello fargate', host: require('os').hostname() }));
app.listen(3000, () => console.log('listening 3000'));
EOF

# Dockerfile (멀티스테이지 + 비루트)
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev

FROM node:20-alpine
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY server.js ./
USER node
EXPOSE 3000
CMD ["node", "server.js"]

# 로컬 검증
docker build -t hello-fargate:1.0.0 .
docker run --rm -p 3000:3000 hello-fargate:1.0.0
curl http://localhost:3000/health

STEP 2 — ECR 레포 생성 + push

REGION=ap-northeast-2
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

# 1) 레포 생성 (immutable 태그 + 자동 스캔)
aws ecr create-repository \
  --repository-name hello-fargate \
  --image-tag-mutability IMMUTABLE \
  --image-scanning-configuration scanOnPush=true \
  --region $REGION

# 2) 로그인
aws ecr get-login-password --region $REGION \
  | docker login --username AWS --password-stdin \
      $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com

# 3) 태깅 + push
docker tag hello-fargate:1.0.0 \
  $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/hello-fargate:1.0.0
docker push \
  $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/hello-fargate:1.0.0

STEP 3 — Task Definition 등록

// task-def.json — Fargate awsvpc 모드
{
  "family": "hello-fargate",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole",
  "containerDefinitions": [{
    "name": "app",
    "image": "<ACCOUNT_ID>.dkr.ecr.ap-northeast-2.amazonaws.com/hello-fargate:1.0.0",
    "essential": true,
    "portMappings": [{ "containerPort": 3000, "protocol": "tcp" }],
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "/ecs/hello-fargate",
        "awslogs-region": "ap-northeast-2",
        "awslogs-stream-prefix": "app",
        "awslogs-create-group": "true"
      }
    }
  }]
}

aws ecs register-task-definition --cli-input-json file://task-def.json

Execution Role은 컨테이너 이미지 pull과 로그 전송용, Task Role은 컨테이너 안 애플리케이션이 다른 AWS 리소스를 호출할 때 쓰는 권한 — 둘은 별개입니다.

STEP 4 — 클러스터 + Service 생성, ALB 연결

# 1) 클러스터
aws ecs create-cluster --cluster-name hello-cluster

# 2) ALB / Target Group / Listener는 콘솔 또는 IaC로 미리 준비
#    Target Type = IP (awsvpc 호환), Health check path = /health

# 3) 서비스 생성 (desiredCount 2)
aws ecs create-service \
  --cluster hello-cluster \
  --service-name hello-svc \
  --task-definition hello-fargate \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-xxx,subnet-yyy],securityGroups=[sg-zzz],assignPublicIp=ENABLED}" \
  --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:...,containerName=app,containerPort=3000" \
  --deployment-configuration "minimumHealthyPercent=100,maximumPercent=200"

ALB의 DNS로 호출해 응답이 다른 호스트명을 번갈아 반환하는지 확인하면 다중 태스크 분산이 동작하는 것입니다.

STEP 5 — 로그·롤링 업데이트·롤백

• CloudWatch Logs → /ecs/hello-fargate 그룹에서 컨테이너 stdout 확인
• 새 이미지(1.0.1) push 후 Task Definition revision을 올리고 aws ecs update-service --task-definition hello-fargate:2 → 무중단 롤링 배포
• 장애 시 aws ecs update-service --task-definition hello-fargate:1로 즉시 롤백
• Container Insights를 켜면 태스크 단위 CPU·메모리 추적 가능

STEP 6 — 한 줄 단축: AWS Copilot

copilot init    # 앱 이름·서비스 타입(Load Balanced Web Service) 선택
copilot deploy  # ECR push + ECS Fargate + ALB까지 자동
copilot svc logs --follow

위 STEP 1~5의 흐름을 그대로 자동화해 빠른 프로토타이핑이 가능합니다. 운영 세부 조정이 필요하면 다시 IaC(Terraform/CDK)로 옮기는 방식도 흔합니다.

의사결정 가이드 — 어떤 조합을 언제 쓸까

상황	권장 조합	이유
작은 팀, AWS 단일 클라우드, 빠른 시작	ECS + Fargate	운영 부담 최소, 학습 곡선 낮음
멀티 클라우드/하이브리드, 복잡한 배포 패턴	EKS + Fargate or 노드 그룹	Kubernetes 생태계 활용
비용 최우선, 트래픽 평탄, 운영 인력 충분	ECS + EC2 (Spot 혼합)	단가·밀도 우위
짧은 단발성 작업	Fargate Tasks / AWS Batch	노드 유휴 시간 제거
초저지연 TCP 서비스	NLB + ECS/EKS	L4 처리, 정적 IP

🎯 핵심 요약

• 컨테이너 — 격리·이식성을 제공하는 포장 기술
• Docker — 그 포장을 만드는 가장 보편적인 도구
• ECS — 포장된 컨테이너를 떼로 굴리는 AWS 오케스트레이터
• Fargate — 그 오케스트레이터의 서버리스 실행 모드
• ECR · ALB/NLB · CloudWatch · IAM — 위 시스템을 저장·노출·관찰·보호하는 주변 서비스

각 기술은 단독이 아니라 계층적으로 결합될 때 가치가 생긴다.
도입 시 가장 먼저 점검할 것은 "이 기술이 우리 팀의 운영 역량과 비용 구조에 맞는가" 한 가지다.