목록으로 가기

EC2, ECS, EKS 차이점과 Auto Scaling, Fargate 구성 방법

EC2 인스턴스 타입 선택부터 Auto Scaling Group, ECS vs EKS 비교, Fargate 서버리스 컨테이너까지 정리했습니다.

EC2, ECS, EKS 차이점과 Auto Scaling, Fargate 구성 방법 ko posts aws EC2 인스턴스 타입 선택부터 Auto Scaling Group, ECS vs EKS 비교, Fargate 서버리스 컨테이너까지 정리했습니다.

개요

AWS에서 애플리케이션을 실행하는 방법은 여러 가지입니다. 서버를 직접 관리하는 EC2부터, 컨테이너 오케스트레이션인 ECS/EKS, 서버리스인 Fargate/Lambda까지.

이 글은 EC2, ECS, EKS를 비교하고 각각의 핵심을 정리합니다.

1. EC2 기본

정리 보기

EC2 (Elastic Compute Cloud) = AWS의 가상 서버

Linux/Windows 서버를 원하는 스펙으로 만들어서 쓰는 것입니다.

인스턴스 타입 읽는 법

m5.xlarge
│ │  └── 크기 (nano < micro < small < medium < large < xlarge < 2xlarge ...)
│ └──── 세대 (5세대)
└────── 패밀리 (범용)
패밀리 용도 예시
t3/t4g 버스트 (가변 CPU, 저비용) 개발서버, 소규모 앱
m5/m6i 범용 (CPU/메모리 균형) 웹서버, API 서버
c5/c6i 컴퓨팅 최적화 (CPU 집중) 배치 처리, 빌드 서버
r5/r6i 메모리 최적화 DB, 캐시
g4/p4 GPU ML 학습

구매 옵션

옵션 할인 약정
On-Demand 없음 없음 (시간당 과금)
Reserved 최대 72% 1~3년 약정
Spot 최대 90% 언제든 회수될 수 있음
Savings Plans 최대 72% 사용량 약정 (유연)

AMI (Amazon Machine Image)

EC2를 만들 때 사용하는 템플릿입니다. OS + 미리 설치된 소프트웨어.

# EC2 생성
aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \
  --instance-type t3.medium \
  --key-name my-key \
  --security-group-ids sg-xxx \
  --subnet-id subnet-xxx

2. Auto Scaling Group (ASG)

정리 보기

ASG = “EC2를 트래픽에 따라 자동으로 늘리고 줄이기”

트래픽 증가 → CPU 80% 넘음 → ASG가 EC2 추가
트래픽 감소 → CPU 30% 이하 → ASG가 EC2 제거

구성 요소

요소 역할
Launch Template EC2 생성 스펙 정의 (AMI, 타입, SG, 키)
ASG 인스턴스 수 관리 (min/max/desired)
Scaling Policy 언제 늘리고 줄일지 규칙
Target Group ALB와 연결하여 트래픽 분산

Launch Template 예시

aws ec2 create-launch-template \
  --launch-template-name app-template \
  --launch-template-data '{
    "ImageId": "ami-xxx",
    "InstanceType": "t3.medium",
    "SecurityGroupIds": ["sg-xxx"],
    "KeyName": "my-key"
  }'

ASG 설정

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name app-asg \
  --launch-template LaunchTemplateName=app-template \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 3 \
  --vpc-zone-identifier "subnet-a,subnet-c" \
  --target-group-arns "arn:aws:elasticloadbalancing:..."

Scaling Policy 종류

공식 문서는 동적 스케일링 정책을 Target tracking, Step scaling, Simple scaling 세 가지로 구분하고, 여기에 예측 스케일링(Predictive scaling)과 예정된 작업(Scheduled scaling)을 별도로 둡니다.

종류 동작
Target Tracking 지정한 목표값(예: CPU 평균 70%)을 유지하도록 자동 조정
Step Scaling 임계값 초과 폭에 따라 단계별로 다른 수만큼 조정
Simple Scaling 알람 하나에 조정 동작 하나 (다음 조정까지 대기 시간 적용)
Predictive Scaling 과거 패턴으로 미래 수요를 예측해 미리 조정
Scheduled 지정한 시각에 min/max/desired 변경

헬스체크

ASG는 비정상 인스턴스를 자동 교체합니다. EC2 상태 확인은 기본 헬스체크 유형이고 끌 수 없습니다. 나머지는 추가 유형으로 켜서 씁니다.

  • EC2 상태 확인: 인스턴스가 실행 중인지, 하드웨어/소프트웨어 문제가 없는지 (기본, 항상 활성)
  • Elastic Load Balancing 헬스체크: 타겟 그룹이 unhealthy로 보고하면 교체 (추가 유형)
  • EBS 헬스체크, VPC Lattice 헬스체크, 사용자 지정 헬스체크: 필요할 때 추가로 활성화
# ASG 상태 확인
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names app-asg

3. ECS (Elastic Container Service)

정리 보기

ECS = AWS 자체 컨테이너 오케스트레이션

Docker 컨테이너를 AWS에서 실행하고 관리하는 서비스입니다.

ECS 구조

ECS Cluster
├── Service (Deployment처럼 Task 수 유지)
│   └── Task (Pod처럼 컨테이너 실행 단위)
│       └── Container
└── Task Definition (Pod 스펙처럼 컨테이너 정의)

K8s와 비교

ECS Kubernetes 역할
Cluster Cluster 전체 환경
Service Deployment 원하는 수 유지
Task Pod 실행 단위
Task Definition Pod Spec + Deployment Spec 컨테이너 정의
ALB + Target Group Service + Ingress 트래픽 분산

실행 모드

모드 설명
EC2 직접 관리하는 EC2 위에서 실행
Fargate 서버 관리 없이 실행 (서버리스 컨테이너)

Fargate를 쓰면 EC2를 관리할 필요 없이 컨테이너만 정의하면 AWS가 알아서 실행합니다.

Task Definition 예시 (JSON)

{
  "family": "my-app",
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "111111111111.dkr.ecr.ap-northeast-2.amazonaws.com/myapp:latest",
      "portMappings": [{ "containerPort": 8080 }],
      "memory": 512,
      "cpu": 256,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "ap-northeast-2",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ],
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512"
}

Fargate에서는 공식 문서 기준으로 두 가지 제약이 따라옵니다. networkModeawsvpc여야 하고, ECR에서 이미지를 가져오거나 awslogs 드라이버로 로그를 보내려면 태스크 실행 역할(executionRoleArn)이 필요합니다. cpu/memory도 임의 조합이 아니라 정의된 유효한 조합 중에서 골라야 합니다.

4. EKS (Elastic Kubernetes Service)

정리 보기

EKS = AWS 관리형 Kubernetes

Control Plane(API Server, etcd 등)은 AWS가 관리하고, Node(워커)만 직접 또는 Fargate로 운영합니다.

EKS 구조

AWS가 관리 (Control Plane):
  - API Server
  - etcd
  - Scheduler
  - Controller Manager

직접 관리 (Data Plane):
  - EC2 Node Group (또는 Fargate)
  - Pod, Deployment, Service 등

Node 옵션

옵션 설명
Managed Node Group AWS가 EC2 프로비저닝/업데이트 관리
Self-managed Node EC2를 직접 관리 (유연하지만 복잡)
Fargate 서버 없이 Pod 실행 (Pod 단위 과금)

EKS 생성 (eksctl)

eksctl create cluster \
  --name my-cluster \
  --region ap-northeast-2 \
  --nodegroup-name workers \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 2 \
  --nodes-max 5

kubectl 연결

aws eks update-kubeconfig --name my-cluster --region ap-northeast-2
kubectl get nodes

EKS 비용 구조

항목 비용
Control Plane (표준 버전 지원) 클러스터당 $0.10/시간
Control Plane (확장 버전 지원) 클러스터당 $0.60/시간
Node (EC2) EC2 요금 그대로
Fargate 사용한 vCPU + 메모리 기준

표준 지원 기간이 끝난 Kubernetes 버전을 계속 쓰면 확장 지원 요금으로 넘어갑니다. 위 단가는 공식 요금 페이지 기준이고, 요금은 변경될 수 있으니 실제 견적은 요금 페이지에서 확인하는 게 맞습니다.

5. ECS vs EKS 선택 기준

정리 보기
항목 ECS EKS
학습 곡선 낮음 (AWS 네이티브) 높음 (K8s 지식 필요)
이식성 AWS 종속 멀티 클라우드 가능
생태계 AWS 서비스 연동 쉬움 Helm, Istio, ArgoCD 등 K8s 생태계
운영 복잡도 단순 복잡 (RBAC, NetworkPolicy 등)
비용 Fargate 쓰면 비슷 Control Plane 추가 비용

ECS는 AWS 네이티브 서비스로 AWS 서비스와의 연동이 단순하고 K8s 지식 없이 시작할 수 있습니다. EKS는 K8s API를 그대로 사용하므로 Helm, Istio, ArgoCD 등 K8s 생태계를 활용할 수 있고 다른 환경으로의 이식이 가능합니다.