AWS 기본 개념 통합
TL;DR
- AWS 기본 개념 통합의 핵심 개념과 사용 범위를 한눈에 정리
- 등장 배경과 필요한 이유를 짚고 실무 적용 포인트를 연결
- 주요 특징과 체크리스트를 빠르게 확인
1. 개념
┌─────────────────────────────────────────────────────────┐ │ AWS 컴퓨팅 진화 │ │ │ │ 2006: EC2 출시 │ │ └── "가상 서버를 빌려 쓰자" │ │ └── 물리 서버 구매 → 클라우드 서버 대여 │ │ │ │ 2013: Docker 등장 (AWS 아님) │ │ └── "컨테이너로 앱을 패키징하자" │ │ └── 가볍고 이식성 좋은 컨테이너 기술 │ │ │ │ 2014: ECS 출시 │ │ └── "Docker 컨테이너를 AWS에서 쉽게 관리하자" │ │ └── AWS 자체 컨테이너 오케스트레이션 │ │ │ │ 2017: Fargate 출시 │ │ └── "서버 관리도 하기 싫다" │ │ └── 서버리스 컨테이너 실행 환경 │ │ │ │ 2018: EKS 출시 │ │ └── "Kubernetes를 AWS에서 쓰고 싶다" │ │ └── 관리형 Kubernetes 서비스 │ │ │ └─────────────────────────────────────────────────────────┘
2. 배경
AWS 기본 개념 통합이(가) 등장한 배경과 기존 한계를 정리한다.
3. 이유
이 주제를 이해하고 적용해야 하는 이유를 정리한다.
4. 특징
- 등장 배경
- 약자
- 개념
- EC2의 특징
- ECS 구성 요소
5. 상세 내용
작성일: 2026-01-23 카테고리: Cloud / AWS 포함 내용: EC2, ECS, EKS, Fargate, ALB/NLB, Gateway, VPC
1. AWS 컴퓨팅 서비스 역사
등장 배경
┌─────────────────────────────────────────────────────────┐
│ AWS 컴퓨팅 진화 │
│ │
│ 2006: EC2 출시 │
│ └── "가상 서버를 빌려 쓰자" │
│ └── 물리 서버 구매 → 클라우드 서버 대여 │
│ │
│ 2013: Docker 등장 (AWS 아님) │
│ └── "컨테이너로 앱을 패키징하자" │
│ └── 가볍고 이식성 좋은 컨테이너 기술 │
│ │
│ 2014: ECS 출시 │
│ └── "Docker 컨테이너를 AWS에서 쉽게 관리하자" │
│ └── AWS 자체 컨테이너 오케스트레이션 │
│ │
│ 2017: Fargate 출시 │
│ └── "서버 관리도 하기 싫다" │
│ └── 서버리스 컨테이너 실행 환경 │
│ │
│ 2018: EKS 출시 │
│ └── "Kubernetes를 AWS에서 쓰고 싶다" │
│ └── 관리형 Kubernetes 서비스 │
│ │
└─────────────────────────────────────────────────────────┘
2. EC2 (Elastic Compute Cloud)
약자
EC2 = Elastic Compute Cloud = 탄력적 컴퓨팅 클라우드
개념
EC2 = AWS에서 제공하는 가상 서버 (VM)
비유: "컴퓨터를 빌려 쓰는 것"
┌─────────────────────────────────────────────────────────┐
│ │
│ 물리 서버 시절: │
│ ├── 서버 구매 (수백만원) │
│ ├── IDC에 입고 │
│ ├── 네트워크 설정 │
│ └── 몇 주 소요 │
│ │
│ EC2: │
│ ├── 클릭 몇 번으로 서버 생성 │
│ ├── 분 단위로 과금 │
│ ├── 필요하면 늘리고, 불필요하면 삭제 │
│ └── 몇 분 소요 │
│ │
└─────────────────────────────────────────────────────────┘
EC2의 특징
✅ 장점:
├── 완전한 서버 제어권 (OS, 네트워크 등)
├── 다양한 인스턴스 타입 (CPU/메모리/GPU)
├── 스팟 인스턴스로 비용 절감
└── AMI로 서버 이미지 복제
❌ 단점:
├── 서버 관리 필요 (OS 업데이트, 패치 등)
├── 용량 계획 필요
└── 유휴 자원 발생 가능
3. ECS (Elastic Container Service)
약자
ECS = Elastic Container Service = 탄력적 컨테이너 서비스
개념
ECS = AWS 자체 컨테이너 오케스트레이션 서비스
┌─────────────────────────────────────────────────────────┐
│ │
│ 컨테이너 오케스트레이션이란? │
│ │
│ 컨테이너 1개 관리 = 쉬움 │
│ 컨테이너 100개 관리 = 어려움 │
│ │
│ ├── 어떤 서버에 배치? │
│ ├── 컨테이너 죽으면? │
│ ├── 트래픽 증가하면? │
│ ├── 업데이트는 어떻게? │
│ └── 이걸 자동으로 해주는 게 "오케스트레이션" │
│ │
└─────────────────────────────────────────────────────────┘
ECS = AWS가 만든 오케스트레이션
Kubernetes = 구글이 만든 오케스트레이션 (오픈소스)
ECS 구성 요소
┌─────────────────────────────────────────────────────────┐
│ │
│ ECS 구조: │
│ │
│ ┌─────────────┐ │
│ │ Cluster │ ← 컨테이너들을 실행할 논리적 그룹 │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Service │ ← Task를 몇 개 유지할지 정의 │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Task │ ← 실제 실행되는 컨테이너(들) │
│ └─────────────┘ │
│ │
│ Task Definition = Task의 설계도 │
│ (어떤 이미지, CPU/메모리, 환경변수 등) │
│ │
└─────────────────────────────────────────────────────────┘
4. EKS (Elastic Kubernetes Service)
약자
EKS = Elastic Kubernetes Service = 탄력적 쿠버네티스 서비스
개념
EKS = AWS에서 관리해주는 Kubernetes
┌─────────────────────────────────────────────────────────┐
│ │
│ Kubernetes 직접 운영: │
│ ├── Control Plane 설치 (etcd, api-server 등) │
│ ├── Worker Node 관리 │
│ ├── 업그레이드 직접 수행 │
│ ├── HA 구성 직접 설계 │
│ └── 매우 복잡하고 전문성 필요 │
│ │
│ EKS: │
│ ├── Control Plane = AWS가 관리 (HA 기본 제공) │
│ ├── Worker Node = 사용자가 관리 (또는 Fargate) │
│ ├── 업그레이드 = AWS 콘솔에서 클릭 │
│ └── 표준 Kubernetes API 사용 │
│ │
└─────────────────────────────────────────────────────────┘
ECS vs EKS
| 항목 | ECS | EKS |
|---|---|---|
| 오케스트레이터 | AWS 자체 | Kubernetes |
| 학습 곡선 | 낮음 | 높음 |
| 이식성 | AWS 종속 | 멀티 클라우드 가능 |
| 생태계 | AWS 도구 | K8s 생태계 전체 |
| 비용 | 무료 (인프라 비용만) | Control Plane $0.10/시간 |
| 선택 기준 | AWS만 쓸 예정, 단순함 | 멀티클라우드, K8s 필요 |
5. Fargate
개념
Fargate = 서버리스 컨테이너 실행 환경
"서버 없이 컨테이너만 실행"
┌─────────────────────────────────────────────────────────┐
│ │
│ EC2 기반 ECS/EKS: │
│ ├── EC2 인스턴스 프로비저닝 필요 │
│ ├── 인스턴스 용량 관리 필요 │
│ ├── OS 패치 필요 │
│ └── 유휴 자원 발생 가능 │
│ │
│ Fargate: │
│ ├── 컨테이너만 정의하면 끝 │
│ ├── 서버 관리 불필요 │
│ ├── 사용한 만큼만 과금 │
│ └── AWS가 인프라 관리 │
│ │
└─────────────────────────────────────────────────────────┘
Fargate는 ECS/EKS의 “실행 모드”
┌─────────────────────────────────────────────────────────┐
│ │
│ ECS / EKS (오케스트레이션) │
│ │ │
│ ┌──────┴──────┐ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ │
│ │ EC2 │ │ Fargate │ │
│ │ 모드 │ │ 모드 │ │
│ └─────────┘ └─────────┘ │
│ (서버 관리) (서버리스) │
│ │
│ Fargate는 ECS와 EKS 둘 다에서 사용 가능! │
│ │
└─────────────────────────────────────────────────────────┘
6. EC2 vs ECS vs EKS vs Fargate 비교
추상화 레벨
┌─────────────────────────────────────────────────────────┐
│ │
│ 추상화 레벨 (아래로 갈수록 더 많은 것을 관리해줌) │
│ │
│ 낮음 ◄─────────────────────────────────────────► 높음 │
│ │
│ EC2 ECS/EKS Fargate │
│ │ │ │ │
│ │ │ │ │
│ OS부터 컨테이너 관리 컨테이너만 │
│ 모두 관리 (서버는 직접) 정의하면 끝 │
│ │
└─────────────────────────────────────────────────────────┘
비교표
| 항목 | EC2 | ECS + EC2 | EKS + EC2 | Fargate |
|---|---|---|---|---|
| 서버 관리 | 직접 | 직접 | 직접 | AWS |
| 컨테이너 관리 | 직접 | ECS | K8s | ECS/EKS |
| 확장성 | 수동/ASG | 자동 | 자동 | 자동 |
| 비용 모델 | 인스턴스 | 인스턴스 | 인스턴스 + 관리비 | vCPU/메모리 |
| 이식성 | 낮음 | 낮음 | 높음 | 중간 |
| 복잡도 | 중간 | 중간 | 높음 | 낮음 |
선택 가이드
┌─────────────────────────────────────────────────────────┐
│ │
│ Q: 무엇을 선택해야 할까? │
│ │
│ "VM으로 충분하고, 완전한 제어가 필요" │
│ → EC2 │
│ │
│ "컨테이너 쓰고 싶고, AWS만 쓸 예정, 단순하게" │
│ → ECS + Fargate │
│ │
│ "컨테이너 쓰고, 비용 최적화 중요" │
│ → ECS + EC2 (스팟 인스턴스 활용) │
│ │
│ "Kubernetes 필요, 멀티클라우드 고려" │
│ → EKS + EC2 또는 Fargate │
│ │
│ "서버 관리 싫고, 소규모/스타트업" │
│ → Fargate (ECS 또는 EKS) │
│ │
└─────────────────────────────────────────────────────────┘
7. Load Balancer (ALB/NLB)
약자
ALB = Application Load Balancer = L7 로드밸런서
NLB = Network Load Balancer = L4 로드밸런서
개념
Load Balancer = 트래픽을 여러 서버에 분산시키는 장치
┌─────────────────────────────────────────────────────────┐
│ │
│ Client │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ Load Balancer │ │
│ └────────┬────────┘ │
│ │ │
│ ┌─────┼─────┐ │
│ ▼ ▼ ▼ │
│ ┌─────┬─────┬─────┐ │
│ │ S1 │ S2 │ S3 │ ← 백엔드 서버들 │
│ └─────┴─────┴─────┘ │
│ │
└─────────────────────────────────────────────────────────┘
ALB vs NLB
| 항목 | ALB (L7) | NLB (L4) |
|---|---|---|
| 계층 | Application (HTTP/HTTPS) | Transport (TCP/UDP) |
| 라우팅 | URL, 헤더, 쿠키 기반 | IP, 포트 기반 |
| 성능 | 중간 | 초고성능 |
| 가격 | 상대적으로 높음 | 상대적으로 낮음 |
| 용도 | 웹 애플리케이션 | 게임, IoT, 고성능 |
ALB 라우팅 예시
ALB는 HTTP 레벨에서 라우팅 가능
/api/* → API 서버들
/admin/* → 관리자 서버들
/static/* → CDN
8. Gateway
API Gateway
┌─────────────────────────────────────────────────────────┐
│ │
│ API Gateway = API의 "정문" │
│ │
│ 역할: │
│ ├── 인증/인가 │
│ ├── Rate Limiting │
│ ├── 요청/응답 변환 │
│ ├── 로깅/모니터링 │
│ └── 라우팅 │
│ │
│ Client → API Gateway → 내부 서비스들 │
│ │
└─────────────────────────────────────────────────────────┘
Kubernetes Ingress vs Istio Gateway
┌─────────────────────────────────────────────────────────┐
│ │
│ K8s Ingress: │
│ ├── L7 로드밸런서 │
│ ├── 외부 → 클러스터 내부 트래픽 관리 │
│ └── 단순한 HTTP 라우팅 │
│ │
│ Istio Gateway: │
│ ├── Ingress의 확장판 │
│ ├── 더 세밀한 트래픽 제어 │
│ ├── mTLS, 트래픽 미러링 등 │
│ └── VirtualService와 함께 사용 │
│ │
└─────────────────────────────────────────────────────────┘
관련 키워드
EC2, ECS, EKS, Fargate, ALB, NLB, API Gateway, Load Balancer, Kubernetes, 컨테이너, 오케스트레이션, 서버리스