개요
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-xxx2. 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-asg3. 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에서는 공식 문서 기준으로 두 가지 제약이 따라옵니다. networkMode는 awsvpc여야 하고, 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 5kubectl 연결
aws eks update-kubeconfig --name my-cluster --region ap-northeast-2
kubectl get nodesEKS 비용 구조
| 항목 | 비용 |
|---|---|
| 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 생태계를 활용할 수 있고 다른 환경으로의 이식이 가능합니다.