Gateway Load Balancer는 3rd party 네트워크 가상 어플라이언스의 배포, 확장, 관리를 위한 AWS 관리형 서비스입니다.

Layer 3 (Network Layer) - IP Protocol에서 작동하며, 모든 네트워크 트래픽을 투명하게 처리합니다.

2. 주요 사용 사례

보안 어플라이언스

• 방화벽 (Firewalls)
• 침입 탐지 시스템 (IDS)
• 침입 방지 시스템 (IPS)
• 딥 패킷 인스펙션 (DPI)
• 페이로드 조작 (Payload Manipulation)

3. 핵심 기능

Transparent Network Gateway

• 모든 트래픽의 단일 진입/출구점 역할
• VPC 라우팅 테이블을 자동으로 업데이트
• 애플리케이션에 투명하게 작동

Load Balancer

• 가상 어플라이언스 Target Group으로 트래픽 분산
• 여러 보안 어플라이언스 간 부하 분산
• Health Check를 통한 어플라이언스 상태 관리

기술적 세부사항

• 프로토콜: GENEVE protocol
• 포트: 6081
• 계층: Layer 3 (가장 낮은 수준의 로드 밸런서)

4. 작동 원리

기존 방식 (GLB 없이)

사용자 → ALB → 애플리케이션

문제점: 보안 검사 없이 직접 애플리케이션 접근

GLB 적용 후

사용자 → GWLB → 보안 어플라이언스 → GWLB → 애플리케이션
     ↑                    ↓
   라우팅 테이블        트래픽 분석/필터링
   자동 업데이트        (정상: 통과, 위험: 드롭)

5. 상세 동작 과정

1단계: 라우팅 설정

• GWLB 생성 시 VPC 라우팅 테이블이 자동으로 업데이트
• 모든 트래픽이 GWLB를 먼저 거치도록 설정

2단계: 트래픽 분산

• 사용자 트래픽이 GWLB에 도달
• GWLB가 보안 어플라이언스 Target Group으로 트래픽 분산

3단계: 보안 검사

• 각 보안 어플라이언스가 트래픽 분석
• 정상 트래픽: GWLB로 다시 전송
• 위험 트래픽: 드롭하여 차단

4단계: 애플리케이션 전달

• 검증된 트래픽만 GWLB를 통해 최종 애플리케이션으로 전달

6. 실제 구현 시나리오

방화벽 구성 예시

Internet Gateway
       ↓
   Gateway Load Balancer
       ↓
Firewall Appliances (EC2)
- Palo Alto Networks
- Fortinet FortiGate  
- Check Point CloudGuard
       ↓
   Gateway Load Balancer
       ↓
Application Load Balancer
       ↓
   Web Servers (EC2)

침입 탐지 시스템 구성

VPC Traffic
       ↓
   Gateway Load Balancer
       ↓
IDS/IPS Appliances
- Suricata
- Snort
- Commercial IDS Solutions
       ↓
Log Analysis & Alert

7. GLB vs 다른 Load Balancer

8. 구현 시 고려사항

성능

• 모든 트래픽이 보안 어플라이언스를 거치므로 지연 시간 증가
• 어플라이언스 성능이 전체 시스템 성능 결정

비용

• 보안 어플라이언스 EC2 인스턴스 비용
• GWLB 자체 사용 비용
• 데이터 처리 비용

가용성

• 보안 어플라이언스의 고가용성 설계 필수
• Multi-AZ 배포 권장

💡 핵심 포인트

• GLB는 보안 특화 Load Balancer: 일반적인 애플리케이션 로드 밸런싱이 아닌 보안 검사 목적
• 투명한 네트워크 게이트웨이: 애플리케이션 코드 변경 없이 모든 트래픽 검사 가능
• 3rd Party 어플라이언스 지원: AWS 네이티브 보안 서비스가 아닌 상용 보안 솔루션 통합
• Layer 3 동작: 가장 낮은 수준에서 모든 IP 트래픽 처리
• GENEVE 프로토콜: 표준 네트워크 가상화 프로토콜 사용 (Port 6081)

작성일: 2026-01-29

Load Balancer는 여러 서버로 트래픽을 분산시키는 중간 계층입니다. 사용자는 단일 DNS 엔드포인트를 통해 접근하며, 백엔드에 몇 대의 서버가 있는지 알 필요가 없습니다.

2. Load Balancer의 핵심 장점

트래픽 분산 및 고가용성

• 부하 분산: 여러 인스턴스에 트래픽을 균등하게 분배
• 장애 대응: 한 인스턴스가 다운되면 정상 인스턴스로만 트래픽 전달
• Health Check: 대상 인스턴스의 상태를 지속적으로 모니터링

보안 강화

중요한 보안 설정:

EC2 Security Group 인바운드 규칙:
- Source: Load Balancer Security Group ID
- 오직 Load Balancer에서 오는 트래픽만 허용

이 설정으로 EC2 인스턴스는 Load Balancer를 통해서만 접근 가능하게 됩니다.

3. AWS Load Balancer 3가지 타입

Application Load Balancer (ALB)

Layer 7 (Application Layer)

• 프로토콜: HTTP, HTTPS, WebSocket
• 특화 기능: 고급 라우팅, 콘텐츠 기반 라우팅
• 사용 사례: 웹 애플리케이션, 마이크로서비스

고급 라우팅 기능:

Host-based: api.example.com → API Target Group
Path-based: /images/* → Image Server Target Group  
Query-based: ?version=v2 → V2 Target Group
Header-based: User-Agent → Mobile Target Group

Network Load Balancer (NLB)

Layer 4 (Transport Layer)

• 프로토콜: TCP, UDP, TLS (TCP 기반)
• 성능: 초고성능, 초저지연 (Ultra-low latency)
• 처리량: 초당 수백만 개의 요청 처리

핵심 특징:

✅ AZ당 하나의 고정 IP (Static IP)
✅ Elastic IP 할당 가능
✅ 특정 IP 화이트리스팅에 최적
✅ 극한 성능이 필요한 애플리케이션용
❌ AWS Free Tier 미포함

Target Groups:

1. EC2 인스턴스
2. Private IP 주소 (온프레미스 서버 연결 가능)
3. Application Load Balancer (NLB + ALB 조합)

Health Check 프로토콜: TCP, HTTP, HTTPS

Gateway Load Balancer (GLB)

Layer 3 (Network Layer)

• 특화 분야: 보안, 네트워크 분석
• 주요 용도:
  • 침입 탐지/방지 시스템 (IDS/IPS)
  • 방화벽 어플라이언스
  • 딥 패킷 인스펙션 (DPI)

4. Listener Rules와 라우팅

ALB Listener Rules

기본 규칙: 모든 요청을 기본 Target Group으로 전달

조건부 라우팅 예시:

{
  "Rules": [
    {
      "Condition": "Host Header = api.example.com",
      "Action": "Forward to API Target Group"
    },
    {
      "Condition": "Path Pattern = /admin/*",
      "Action": "Forward to Admin Target Group"
    }
  ]
}

5. NLB + ALB 조합 아키텍처

사용 시나리오: 고정 IP + HTTP 라우팅 기능을 동시에 필요로 할 때

Internet → NLB (Static IP) → ALB (HTTP Routing) → Target Groups

장점:

• NLB: 고정 IP, 초고성능
• ALB: 세밀한 HTTP 라우팅, 콘텐츠 기반 분산

6. 선택 가이드

7. Health Check 모범 사례

기본 설정:

Path: /health (단순 / 보다 권장)
Port: 80 또는 애플리케이션 포트
Protocol: HTTP/HTTPS

실무 팁: /health 엔드포인트에서 DB 연결 상태, 외부 API 연결 등을 포함한 종합적인 상태 체크를 구현하는 것이 좋습니다.

💡 핵심 포인트

• ALB: HTTP/HTTPS 웹 애플리케이션의 표준 선택
• NLB: 고성능 + 고정 IP가 필요한 경우 (Free Tier 미포함)
• GLB: 보안 솔루션 통합 시에만 사용
• 보안: Security Group 간 참조로 EC2를 Load Balancer 뒤에 완전히 숨김
• Health Check: 단순한 응답보다는 애플리케이션 로직까지 검증하는 별도 엔드포인트 구성 권장

작성일: 2026-01-28

ALB는 Layer 7 (HTTP) 레벨에서 작동하는 로드 밸런서입니다.

핵심 기능:

• 여러 머신의 HTTP 애플리케이션에 대한 로드 밸런싱 (Target Groups)
• 동일 머신의 여러 애플리케이션에 대한 로드 밸런싱 (예: 컨테이너)
• HTTP/2 및 WebSocket 지원
• 리다이렉트 지원 (예: HTTP → HTTPS)

2. ALB 라우팅 기능

ALB는 라우팅 테이블을 통해 다양한 Target Group으로 트래픽을 분산합니다.

라우팅 방식

URL 경로 기반 라우팅:

• example.com/users → User 서비스
• example.com/posts → Post 서비스

호스트명 기반 라우팅:

• one.example.com → 첫 번째 서비스
• other.example.com → 두 번째 서비스

쿼리 스트링/헤더 기반 라우팅:

• example.com/user?id=123&order=false
• HTTP 헤더 값에 따른 라우팅

마이크로서비스 최적화

• 마이크로서비스 & 컨테이너 기반 애플리케이션에 최적 (Docker, Amazon ECS)
• 포트 매핑 기능: ECS의 동적 포트로 리다이렉트
• 비교: Classic Load Balancer는 애플리케이션마다 별도 필요

3. Target Groups (대상 그룹)

ALB가 트래픽을 전달할 수 있는 4가지 Target Group 유형:

EC2 인스턴스:

• Auto Scaling Group으로 관리 가능
• HTTP 프로토콜 사용

ECS 태스크:

• ECS 자체에서 관리
• HTTP 프로토콜 사용

Lambda 함수:

• HTTP 요청이 JSON 이벤트로 변환됨

IP 주소:

• 반드시 사설 IP여야 함
• 온프레미스 서버 연결 시 사용

Target Group 특징

• ALB는 여러 Target Group으로 라우팅 가능
• Health Check는 Target Group 레벨에서 수행

4. 실제 라우팅 예시

마이크로서비스 라우팅

ALB → /user 경로 → User 서비스 Target Group (EC2)
    → /search 경로 → Search 서비스 Target Group (EC2)

플랫폼별 라우팅

ALB → ?Platform=Mobile → 모바일 Target Group (AWS EC2)
    → ?Platform=Desktop → 데스크톱 Target Group (온프레미스)

5. ALB 주요 특징

고정 호스트명

• 형식: XXX.region.elb.amazonaws.com
• 애플리케이션에서 사용할 고정된 DNS 엔드포인트 제공

클라이언트 IP 처리

ALB는 연결 종료(Connection Termination)를 수행합니다.

문제: 애플리케이션 서버는 클라이언트의 실제 IP를 직접 볼 수 없음

• 서버가 보는 IP: 로드 밸런서의 사설 IP

해결: HTTP 헤더를 통한 클라이언트 정보 전달

• X-Forwarded-For: 클라이언트의 실제 IP
• X-Forwarded-Port: 클라이언트가 사용한 포트
• X-Forwarded-Proto: 사용된 프로토콜 (HTTP/HTTPS)

트래픽 흐름

클라이언트 (12.34.56.78) 
    ↓ 
ALB (연결 종료) 
    ↓ 
EC2 인스턴스 (ALB 사설 IP로 수신)
    ↓
X-Forwarded-For 헤더로 실제 클라이언트 IP 확인

💡 핵심 포인트

• ALB는 Layer 7에서 작동하여 HTTP 기반의 지능적 라우팅 제공
• 마이크로서비스 아키텍처에 최적화된 설계
• 다양한 라우팅 규칙으로 복잡한 애플리케이션 구조 지원
• Target Group 레벨에서 Health Check 및 관리 수행
• 클라이언트 정보는 HTTP 헤더를 통해 애플리케이션에 전달

작성일: 2026-01-26
*주제: AWS ALB *

로드 밸런서는 트래픽을 여러 대의 다운스트림 서버(EC2 인스턴스)로 전달하는 서버입니다.

핵심 개념: 사용자는 로드 밸런서의 단일 접점(DNS)을 통해 애플리케이션에 접근하며, 내부에 몇 대의 서버가 있는지 알 필요가 없습니다.

2. 로드 밸런서를 사용하는 이유

• 부하 분산: 여러 다운스트림 인스턴스에 부하를 분산
• 단일 접점 제공: 애플리케이션에 대한 단일 DNS 접점 노출
• 장애 처리: 다운스트림 인스턴스의 장애를 원활하게 처리
• Health Check: 인스턴스에 대한 정기적인 상태 확인 수행
• SSL Termination: 웹사이트에 대한 HTTPS SSL 종료 제공
• 쿠키 고정성: 쿠키를 통한 Stickiness 강제 적용
• 고가용성: 여러 가용 영역에 걸친 고가용성 제공
• 트래픽 분리: 공용 트래픽과 사설 트래픽 분리

3. Elastic Load Balancer를 사용하는 이유

ELB는 AWS 관리형 로드 밸런서입니다.

AWS 보장사항:

• AWS가 작동을 보장
• 업그레이드, 유지보수, 고가용성을 AWS가 담당
• 제한된 구성 옵션만 제공 (간편함)

비용 효율성: 다른 AWS 서비스와의 통합으로 설정 비용 절감

• EC2, Auto Scaling Groups, Amazon ECS
• AWS Certificate Manager (ACM), CloudWatch
• Route 53, AWS WAF, AWS Global Accelerator

4. Health Checks (상태 확인)

Health Check는 로드 밸런서에게 중요한 기능입니다.

목적: 로드 밸런서가 트래픽을 전달하는 인스턴스가 요청에 응답할 수 있는지 확인

작동 방식:

• 특정 포트와 경로에서 상태 확인 수행 (일반적으로 /health)
• 응답이 200 (OK)이 아니면 인스턴스를 Unhealthy로 판단
• Unhealthy 인스턴스에는 트래픽을 보내지 않음

5. AWS 로드 밸런서의 4가지 종류

AWS는 4가지 관리형 로드 밸런서를 제공합니다.

Classic Load Balancer (CLB) - v1 (구세대):

• HTTP, HTTPS, TCP, SSL (secure TCP) 지원

Application Load Balancer (ALB) - v2 (신세대):

• HTTP, HTTPS, WebSocket 지원
• Layer 7에서 작동

Network Load Balancer (NLB) - v2 (신세대):

• TCP, TLS (secure TCP), UDP 지원
• Layer 4에서 작동, 초고성능

Gateway Load Balancer (GWLB):

• Layer 3 (Network layer) - IP Protocol에서 작동
• 방화벽, IDS/IPS 등 네트워크 가상 어플라이언스용

권장사항: 더 많은 기능을 제공하는 신세대 로드 밸런서 사용 권장

배치 옵션: 모든 로드 밸런서는 Internal (private) 또는 External (public)로 설정 가능

6. 로드 밸런서 보안 그룹 설정

로드 밸런서 보안을 위한 보안 그룹 간 참조 방식이 핵심입니다.

ELB 보안 그룹:

• 포트: 80 (HTTP), 443 (HTTPS)
• 소스: 0.0.0.0/0 (어디서든 접근 허용)
• 사용자가 어디서든 로드 밸런서에 접근 가능

EC2 보안 그룹:

• 포트: 80 (HTTP)
• 소스: 로드 밸런서의 보안 그룹 ID (IP 범위가 아님)
• EC2 인스턴스를 로드 밸런서의 보안 그룹에 연결

보안 효과: EC2 인스턴스는 로드 밸런서를 통해서만 트래픽을 받을 수 있어 강화된 보안 메커니즘을 제공합니다.

💡 핵심 포인트

• ELB는 관리형 서비스라 AWS가 알아서 확장(Scaling)과 유지보수를 다 해줌
• Health Check 경로를 단순히 /로 두기보다, 애플리케이션의 로직이나 DB 연결 상태까지 체크하는 별도의 /health 경로를 만드는 게 실무에서 더 확실함
• NLB는 정적 IP(Static IP)를 가질 수 있다는 점이 ALB와의 큰 차이. 화이트리스트 관리가 필요한 환경이라면 NLB를 고려

확장성은 애플리케이션이나 시스템이 증가하는 부하(Load)에 맞춰 적응하고 처리할 수 있는 능력을 의미합니다.

수직적 확장 (Vertical Scaling)

• 정의: 인스턴스의 사양(Size)을 향상시키는 방식
• 별칭: Scale Up (확장) / Scale Down (축소)
• 예시: t2.micro → t2.large → m5.xlarge로 업그레이드

# AWS CLI로 인스턴스 타입 변경 예시
aws ec2 modify-instance-attribute \
    --instance-id i-1234567890abcdef0 \
    --instance-type m5.large

적용 사례:

• Amazon RDS (관계형 데이터베이스)
• Amazon ElastiCache (인메모리 캐시)
• 단일 노드 애플리케이션

한계점:

• 하드웨어의 물리적 제약 (현재 AWS 최대 사양: u-24tb1.112xlarge - 24TB RAM)
• 단일 장애점(Single Point of Failure) 위험

수평적 확장 (Horizontal Scaling = Elasticity)

• 정의: 인스턴스의 개수(Number)를 증가시키는 방식
• 별칭: Scale Out (확장) / Scale In (축소)
• 예시: EC2 인스턴스 1대 → 10대로 확장

# Auto Scaling Group 설정 예시
AutoScalingGroup:
  MinSize: 2
  MaxSize: 10
  DesiredCapacity: 3
  TargetGroupARNs:
    - !Ref ApplicationLoadBalancer

핵심 AWS 서비스:

• Auto Scaling Groups (ASG): 자동 인스턴스 관리
• Elastic Load Balancer (ELB): 트래픽 분산
• Amazon ECS/EKS: 컨테이너 오케스트레이션

2. 고가용성 (High Availability)

고가용성은 시스템 장애 발생 시에도 서비스 중단 없이 운영을 지속할 수 있는 능력입니다.

핵심 원칙: Multi-AZ 배치

• 최소 2개 이상의 가용 영역(Availability Zone)에 리소스 분산
• 목표: 데이터센터 전체 장애 상황에서도 서비스 생존

구현 방식

1. Passive HA (수동 고가용성)

# RDS Multi-AZ 설정
aws rds create-db-instance \
    --db-instance-identifier mydb \
    --multi-az \
    --availability-zone us-east-1a

• 평상시: Primary에서만 서비스, Standby는 대기
• 장애시: 자동 Failover (RDS Multi-AZ, EFS 등)

2. Active HA (능동 고가용성)

# 다중 AZ에 걸친 ASG 설정
AutoScalingGroup:
  VPCZoneIdentifier:
    - subnet-12345 # us-east-1a
    - subnet-67890 # us-east-1b
    - subnet-abcde # us-east-1c

• 모든 AZ의 인스턴스가 동시에 트래픽 처리
• Load Balancer가 트래픽 분산

  3. 비교 요약표

함정 주의: 단일 AZ에서 인스턴스를 아무리 많이 늘려도 고가용성은 확보되지 않습니다. 반드시 Multi-AZ가 핵심입니다.

EFS란?

Amazon EFS는 관리형 NFS(Network File System)로, 여러 EC2 인스턴스에서 동시에 마운트할 수 있는 공유 파일 시스템입니다.

핵심 특징

• Multi-AZ 지원: 여러 가용영역의 EC2에서 동시 접근
• 고가용성 및 확장성: 자동 확장, 페타바이트 규모까지
• Pay-per-use: 사용한 만큼만 과금
• 비용: EBS gp2 대비 약 3배 비싸지만 공유 기능 제공

실제 사용 예시

Multi-AZ EFS 구성:
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   us-east-1a │    │   us-east-1b │    │   us-east-1c │
│             │    │             │    │             │
│ ┌─────────┐ │    │ ┌─────────┐ │    │ ┌─────────┐ │
│ │  EC2-1  │ │    │ │  EC2-2  │ │    │ │  EC2-3  │ │
│ └─────────┘ │    │ └─────────┘ │    │ └─────────┘ │
└─────────────┘    └─────────────┘    └─────────────┘
       │                   │                   │
       └───────────────────┼───────────────────┘
                           │
                  ┌─────────────────┐
                  │   Amazon EFS    │
                  │ (공유 파일시스템)  │
                  └─────────────────┘

2. EFS 기술 사양

프로토콜 및 호환성

• 프로토콜: NFSv4.1
• 보안: Security Group으로 접근 제어
• OS 호환성: Linux 기반 AMI만 지원 (Windows 불가)
• 암호화: KMS를 통한 저장 데이터 암호화
• 파일시스템: POSIX 호환 (~Linux 표준)

확장성

• 동시 클라이언트: 수천 개의 NFS 클라이언트
• 처리량: 10GB/s 이상
• 용량: 페타바이트 규모까지 자동 확장
• 용량 계획: 불필요 (자동 확장)

3. 성능 모드 (Performance Mode)

EFS 생성 시 설정하며, 이후 변경 불가능합니다.

General Purpose (기본값)

특징:

• 지연시간에 민감한 워크로드에 최적화
• 낮은 지연시간 제공

사용 사례:

• 웹 서버
• CMS (Content Management System)
• 일반적인 파일 공유

Max I/O

특징:

• 높은 지연시간이지만 더 높은 처리량과 병렬성
• 대규모 병렬 처리에 적합

사용 사례:

• 빅데이터 분석
• 미디어 처리
• 고도로 병렬화된 워크로드

4. 처리량 모드 (Throughput Mode)

Bursting (기본값)

처리량 계산:
기본 처리량 = 저장 용량(TB) × 50 MiB/s
버스트 처리량 = 최대 100 MiB/s

예시:
1TB 저장 → 50 MiB/s 기본 + 100 MiB/s 버스트
2TB 저장 → 100 MiB/s 기본 + 100 MiB/s 버스트

Provisioned

• 특징: 저장 용량과 무관하게 처리량 설정
• 예시: 1TB 저장소에 1GiB/s 처리량 설정 가능
• 용도: 일정한 고성능이 필요한 경우

Elastic (권장)

• 자동 조정: 워크로드에 따라 처리량 자동 확장/축소
• 최대 성능: 읽기 3GiB/s, 쓰기 1GiB/s
• 용도: 예측 불가능한 워크로드

5. 스토리지 클래스

계층별 특징

라이프사이클 정책

자동 계층 이동 설정:
Standard → (N일 후) → IA → (N일 후) → Archive

예시 정책:
- 30일 후 IA로 이동
- 90일 후 Archive로 이동

6. 가용성 및 내구성

Standard (프로덕션 권장)

• Multi-AZ: 여러 가용영역에 복제
• 고가용성: 99.999999999% (11 9's) 내구성
• 용도: 프로덕션 환경

One Zone (개발/테스트 권장)

• Single AZ: 하나의 가용영역에만 저장
• 비용 절약: Standard 대비 90% 이상 절약
• 백업: 기본적으로 활성화
• 호환성: IA와 함께 사용 가능 (EFS One Zone-IA)

7. EFS vs EBS 상세 비교

EBS (Elastic Block Store)

연결 방식: 1:1 (인스턴스당 하나의 볼륨)
예외: Multi-Attach (io1/io2만 가능)

제약사항:
- AZ 레벨에서 잠김
- 다른 AZ로 이동 시 스냅샷 필요
- 백업 시 I/O 사용 (트래픽 많을 때 주의)

성능:
- gp2: 디스크 크기에 따라 IOPS 증가
- gp3/io1: IOPS 독립적으로 증가 가능

종료 시 동작:
- Root 볼륨: 기본적으로 함께 삭제
- 추가 볼륨: 보존 (설정 변경 가능)

EFS (Elastic File System)

연결 방식: 1:N (수백 개 인스턴스 동시 마운트)

장점:
- Multi-AZ 자동 지원
- 웹사이트 파일 공유 (WordPress 등)
- Linux 전용 (POSIX 호환)

비용:
- EBS보다 높은 가격
- Storage Tier로 비용 최적화 가능

8. 주요 사용 사례

Content Management

WordPress 멀티 인스턴스:
┌─────────┐    ┌─────────┐    ┌─────────┐
│WordPress│    │WordPress│    │WordPress│
│ Server 1│    │ Server 2│    │ Server 3│
└─────────┘    └─────────┘    └─────────┘
     │              │              │
     └──────────────┼──────────────┘
                    │
            ┌───────────────┐
            │ EFS (공유 파일) │
            │ - 이미지       │
            │ - 테마         │
            │ - 플러그인     │
            └───────────────┘

데이터 공유

• 로그 집계: 여러 서버의 로그를 중앙 집중화
• 백업 저장소: 공통 백업 위치
• 개발 환경: 팀 간 코드 및 데이터 공유

웹 서빙

• 정적 콘텐츠: 이미지, CSS, JavaScript 파일
• 미디어 파일: 동영상, 오디오 파일 스트리밍

9. 스토리지 선택 가이드

EFS vs EBS vs Instance Store

선택 기준

파일 공유 필요 → EFS
고성능 블록 스토리지 → EBS
임시 고성능 스토리지 → Instance Store

10. 실무 활용 전략

비용 최적화

1. 적절한 스토리지 클래스 선택
2. 라이프사이클 정책 설정
3. One Zone 사용 (개발/테스트 환경)
4. 사용량 모니터링 및 정기적인 정리

성능 최적화

1. 적절한 성능 모드 선택
2. Elastic 처리량 모드 사용
3. Security Group 최적화
4. 네트워크 지연시간 고려

보안 강화

1. KMS 암호화 활성화
2. Security Group 세밀한 설정
3. IAM 정책을 통한 접근 제어
4. VPC 엔드포인트 사용

이러한 EFS의 특징과 활용 방법을 이해하면 AWS에서 확장 가능하고 효율적인 공유 파일 시스템을 구축할 수 있습니다.

EBS란?

EBS는 EC2 인스턴스에 연결할 수 있는 네트워크 드라이브입니다.

핵심 특징:

• 인스턴스 종료 후에도 데이터 지속성 보장
• 하나의 EBS는 하나의 EC2에만 마운트 가능 (CCP 레벨 기준)
• 특정 가용영역(AZ)에 종속
• 비유: "네트워크 USB 스틱"

💡 Free Tier 혜택

월 30GB의 General Purpose SSD 또는 Magnetic 스토리지 무료 제공

2. EBS 핵심 특성

네트워크 드라이브의 특징

EC2 Instance ←── 네트워크 ──→ EBS Volume
     │                           │
   물리적 서버                네트워크 스토리지

장점:

• 빠른 분리/연결 가능
• 다른 인스턴스로 이동 가능

단점:

• 네트워크 지연시간 존재

가용영역 제약

❌ 불가능한 연결
us-east-1a의 EBS → us-east-1b의 EC2

✅ 해결 방법
EBS 스냅샷 생성 → 다른 AZ로 복사 → 새 볼륨 생성

용량 관리

• 프로비저닝 방식: 미리 용량(GB)과 IOPS 설정
• 과금: 실제 사용량이 아닌 프로비저닝된 용량 기준
• 확장: 운영 중에도 용량 증설 가능

3. Delete on Termination 속성

EC2 인스턴스 종료 시 EBS 볼륨의 동작을 제어하는 설정:

실무 팁: 중요한 데이터가 있는 Root 볼륨은 비활성화로 설정하여 실수로 인한 데이터 손실 방지

4. EBS 스냅샷 (Snapshots)

스냅샷이란?

특정 시점의 EBS 볼륨 백업본

EBS Volume → Snapshot → 다른 AZ/Region으로 복사 가능

모범 사례:

• 스냅샷 생성 시 볼륨 분리 권장 (필수는 아님)
• 정기적인 백업 스케줄 설정

5. 고급 스냅샷 기능

5.1 EBS Snapshot Archive

목적: 비용 절약 (75% 저렴)

일반 스냅샷 → Archive Tier 이동
복원 시간: 24~72시간

사용 사례: 장기 보관용 백업, 규정 준수용 데이터

5.2 Recycle Bin

목적: 실수로 삭제한 스냅샷 복구

설정 옵션:

• 보존 기간: 1일 ~ 1년
• 자동 복구 규칙 설정 가능

스냅샷 삭제 → Recycle Bin 이동 → 보존 기간 내 복구 가능

5.3 Fast Snapshot Restore (FSR)

목적: 스냅샷에서 복원한 볼륨의 초기 성능 저하 방지

FSR의 동작 원리

일반 복원 과정:
스냅샷 → 새 볼륨 생성 → 첫 액세스 시 지연 발생

FSR 적용 시:
스냅샷 → 블록 미리 로딩 → 즉시 최적 성능

핵심 개념:

• ❌ "빈 디스크를 채우는 작업"이 아님
• ✅ "스냅샷 블록을 EBS로 미리 로딩하는 작업"

특징:

• 비용이 높음
• 즉시 최적 성능 필요한 경우에만 사용
• 미션 크리티컬 애플리케이션에 적합

6. 실무 활용 가이드

EBS 설계 원칙

1. 데이터 중요도에 따른 Delete on Termination 설정
2. 정기적인 스냅샷 백업 전략 수립
3. 비용 최적화를 위한 Archive 활용
4. 성능이 중요한 워크로드에는 FSR 고려

비용 최적화 전략

단계별 스토리지 관리:
활성 데이터 → EBS Volume
백업 데이터 → Snapshot
장기 보관 → Archive Tier

EBS Volume Types & 고급 기능

1. EBS Volume Types 개요

EBS는 6가지 볼륨 타입을 제공하며, 각각 다른 성능과 비용 특성을 가집니다.

볼륨 타입 분류

SSD 기반 (부팅 가능):
├── gp2/gp3: 범용 SSD
└── io1/io2: 프로비저닝된 IOPS SSD

HDD 기반 (부팅 불가):
├── st1: 처리량 최적화 HDD
└── sc1: 콜드 HDD

핵심 특성 지표:

• Size: 볼륨 크기 (GiB/TiB)
• Throughput: 처리량 (MiB/s)
• IOPS: 초당 입출력 작업 수

2. General Purpose SSD (gp2/gp3)

특징 및 용도

• 비용 효율적 스토리지
• 낮은 지연시간
• 다양한 워크로드에 적합

사용 사례:

• 시스템 부트 볼륨
• 가상 데스크톱
• 개발/테스트 환경

gp3 vs gp2 비교

gp2 성능 계산

gp2 IOPS = 볼륨 크기(GB) × 3
최대 IOPS 도달 볼륨 크기 = 16,000 ÷ 3 = 5,334 GB

예시:
- 100 GB → 300 IOPS
- 1,000 GB → 3,000 IOPS  
- 5,334 GB → 16,000 IOPS (최대)

gp2 버스트 기능: 작은 볼륨도 일시적으로 3,000 IOPS까지 버스트 가능

3. Provisioned IOPS SSD (io1/io2)

특징

• 미션 크리티컬 애플리케이션용
• 지속적인 IOPS 성능 보장
• 16,000 IOPS 이상 필요한 경우

사용 사례:

• 데이터베이스 워크로드
• 스토리지 성능과 일관성에 민감한 애플리케이션

io1 vs io2 Block Express

🔍 Nitro 인스턴스 중요성

32,000 IOPS 이상 필요 시:
EC2 Nitro 인스턴스 + io1/io2 조합 필수

4. Hard Disk Drives (HDD)

공통 특징

• 부팅 볼륨 불가
• 125 GiB - 16 TiB 용량 범위
• 처리량 중심 설계

st1 (Throughput Optimized HDD)

특징:

• 최대 처리량: 500 MiB/s
• 최대 IOPS: 500

사용 사례:

• 빅데이터 분석
• 데이터 웨어하우스
• 로그 처리

sc1 (Cold HDD)

특징:

• 최대 처리량: 250 MiB/s
• 최대 IOPS: 250
• 최저 비용

사용 사례:

• 자주 액세스하지 않는 데이터
• 아카이브 스토리지
• 비용이 가장 중요한 시나리오

5. 볼륨 타입 선택 가이드

워크로드별 권장사항

데이터베이스 → gp3 또는 io1/io2
높은 처리량 → st1
최저 비용 → sc1
범용 용도 → gp3
부팅 볼륨 → gp3 또는 io1/io2 (SSD만 가능)

성능 요구사항별 선택

16,000 IOPS 이하 → gp3
16,000 IOPS 초과 → io1/io2
32,000 IOPS 초과 → Nitro + io1/io2
256,000 IOPS 필요 → io2 Block Express

6. EBS Multi-Attach

개요

하나의 EBS 볼륨을 여러 EC2 인스턴스에 동시 연결

지원 볼륨: io1/io2 패밀리만 가능

제약사항

• 동일 AZ 내에서만 가능
• 최대 16개 인스턴스 동시 연결
• 클러스터 인식 파일시스템 필요 (XFS, EXT4 불가)

사용 사례

클러스터링된 Linux 애플리케이션:
┌─────────┐    ┌─────────────┐    ┌─────────┐
│  EC2-1  │────│ EBS io2     │────│  EC2-2  │
└─────────┘    │Multi-Attach │    └─────────┘
               └─────────────┘
                      │
               ┌─────────┐
               │  EC2-3  │
               └─────────┘

적용 예시:

• Teradata 클러스터
• 고가용성 데이터베이스
• 분산 파일시스템

⚠️ 주의사항: 애플리케이션에서 동시 쓰기 작업을 직접 관리해야 함

7. EBS 암호화

암호화 적용 범위

EBS 볼륨 암호화 시 다음이 모두 암호화됩니다:

암호화 적용 범위:
├── 볼륨 내부 저장 데이터 (Data at Rest)
├── 인스턴스-볼륨 간 전송 데이터 (Data in Transit)  
├── 모든 스냅샷
└── 스냅샷에서 생성된 모든 볼륨

암호화 특징

• 투명한 처리: 사용자 개입 불필요
• 최소한의 지연시간 영향
• KMS 키 사용: AES-256 암호화
• 스냅샷 복사 시 암호화 옵션 제공

기존 볼륨 암호화 방법

1. 암호화되지 않은 볼륨의 스냅샷 생성
   ↓
2. 스냅샷 복사하면서 암호화 적용
   ↓  
3. 암호화된 스냅샷에서 새 볼륨 생성
   ↓
4. 새 볼륨을 인스턴스에 연결

8. 실무 활용 전략

성능 최적화

일반적인 워크로드 → gp3 (비용 효율적)
데이터베이스 → io2 (일관된 성능)
빅데이터 처리 → st1 (높은 처리량)
아카이브 → sc1 (최저 비용)

보안 강화

• 민감한 데이터: 반드시 암호화 적용
• 규정 준수: 암호화된 스냅샷으로 백업
• 키 관리: KMS를 통한 중앙집중식 키 관리

비용 최적화

• gp3 우선 고려: gp2 대비 20% 저렴하고 성능 독립 조정 가능
• 적절한 볼륨 크기: 과도한 프로비저닝 방지
• 사용하지 않는 볼륨: 정기적인 정리

이러한 EBS 볼륨 타입과 고급 기능들을 이해하고 적절히 활용하면 AWS에서 안정적이고 확장 가능한 스토리지 인프라를 구축할 수 있습니다.

AMI란?

AMI는 EC2 인스턴스의 커스터마이징된 템플릿입니다.

포함 요소:

• 운영체제 (OS)
• 소프트웨어 패키지
• 애플리케이션 설정
• 모니터링 도구
• 보안 설정

💡 AMI의 핵심 장점

일반 EC2 부팅:
인스턴스 시작 → OS 설치 → 소프트웨어 설치 → 설정 → 사용 가능
(시간: 10-30분)

AMI 사용:
인스턴스 시작 → 즉시 사용 가능
(시간: 1-3분)

빠른 부팅의 이유: 모든 소프트웨어와 설정이 미리 패키징되어 있음

2. AMI 유형별 특징

2.1 Public AMI

제공자: AWS 공식

특징:

• AWS에서 관리 및 업데이트
• 기본 OS 이미지 (Amazon Linux, Ubuntu, Windows 등)
• 무료 사용 가능
• 보안 패치 자동 적용

2.2 Custom AMI (사용자 정의)

제공자: 직접 생성 및 관리

장점:

• 회사 표준 환경 구성 가능
• 특정 애플리케이션 사전 설치
• 보안 정책 사전 적용

단점:

• 직접 관리 및 업데이트 필요
• 보안 패치 책임

2.3 AWS Marketplace AMI

제공자: 서드파티 벤더

특징:

• 상용 소프트웨어 사전 설치
• 유료 라이선스 포함 가능
• 벤더 지원 제공

3. AMI 생성 프로세스

단계별 AMI 생성 과정

1. EC2 인스턴스 시작
   ↓
2. 소프트웨어 설치 및 설정
   ↓
3. 인스턴스 중지 (데이터 무결성 보장)
   ↓
4. AMI 생성 (EBS 스냅샷 자동 생성)
   ↓
5. 새로운 인스턴스에서 AMI 사용

🔍 중요 포인트

• 인스턴스 중지 필수: 데이터 일관성 보장
• EBS 스냅샷 자동 생성: AMI 생성 시 연결된 모든 EBS 볼륨의 스냅샷 생성
• 리전별 제한: AMI는 특정 리전에 생성되며, 다른 리전 사용 시 복사 필요

4. AMI 활용 전략

지역별 배포 전략

AMI 생성 (us-east-1) → 복사 → us-west-2
                     → 복사 → eu-west-1
                     → 복사 → ap-northeast-2

버전 관리 전략

Production AMI v1.0 → 테스트 → 배포
                 ↓
Development AMI v1.1 → 테스트 → Production AMI v1.1

5. EC2 Instance Store

Instance Store vs EBS 비교

⚠️ Instance Store 주의사항

인스턴스 중지/종료 → 데이터 완전 삭제
하드웨어 장애 → 데이터 복구 불가능
인스턴스 재부팅 → 데이터 보존 (OK)

6. Instance Store 활용 사례

적합한 용도

• 버퍼/캐시 데이터: Redis, Memcached
• 임시 처리 데이터: 로그 분석, 이미지 처리
• 스크래치 공간: 대용량 데이터 임시 저장
• 고성능 데이터베이스: NoSQL 임시 저장소

실제 사용 예시

빅데이터 처리 파이프라인:
S3에서 데이터 다운로드 → Instance Store에서 고속 처리 → 결과를 S3에 업로드

7. 데이터 보호 전략

Instance Store 사용 시 필수 고려사항

백업 전략:

Instance Store → 정기적 백업 → S3/EBS
실시간 복제 → 다른 인스턴스 Instance Store

고가용성 설계:

Master Instance Store ← 실시간 동기화 → Slave Instance Store
        ↓                                    ↓
    EBS 백업                              EBS 백업

8. 실무 활용 가이드

AMI 관리 모범 사례

1. 정기적인 AMI 업데이트: 보안 패치 및 소프트웨어 업데이트
2. 태깅 전략: 버전, 환경, 팀별 태그 관리
3. 자동화: CI/CD 파이프라인에 AMI 생성 통합
4. 비용 관리: 오래된 AMI 및 스냅샷 정리

스토리지 선택 기준

데이터 중요도가 높음 → EBS Volume
고성능이 필요함 → Instance Store + 백업 전략
비용 최적화 → 용도별 혼합 사용

성능 최적화 팁

• Instance Store: 고성능 I/O 작업
• EBS: 영구 저장이 필요한 데이터
• S3: 장기 보관 및 백업

이러한 AMI와 Instance Store 개념을 이해하고 적절히 활용하면 AWS에서 효율적이고 안정적인 인프라를 구축할 수 있습니다.

EBS란?

EBS는 EC2 인스턴스에 연결할 수 있는 네트워크 드라이브입니다.

핵심 특징:

• 인스턴스 종료 후에도 데이터 지속성 보장
• 하나의 EBS는 하나의 EC2에만 마운트 가능 (CCP 레벨 기준)
• 특정 가용영역(AZ)에 종속
• 비유: "네트워크 USB 스틱"

💡 Free Tier 혜택

월 30GB의 General Purpose SSD 또는 Magnetic 스토리지 무료 제공

EBS 핵심 특성

네트워크 드라이브의 특징

EC2 Instance ←── 네트워크 ──→ EBS Volume
     │                           │
   물리적 서버                네트워크 스토리지

장점:

• 빠른 분리/연결 가능
• 다른 인스턴스로 이동 가능

단점:

• 네트워크 지연시간 존재

가용영역 제약

❌ 불가능한 연결
us-east-1a의 EBS → us-east-1b의 EC2

✅ 해결 방법
EBS 스냅샷 생성 → 다른 AZ로 복사 → 새 볼륨 생성

용량 관리

• 프로비저닝 방식: 미리 용량(GB)과 IOPS 설정
• 과금: 실제 사용량이 아닌 프로비저닝된 용량 기준
• 확장: 운영 중에도 용량 증설 가능

Delete on Termination 속성

EC2 인스턴스 종료 시 EBS 볼륨의 동작을 제어하는 설정:

팁: 중요한 데이터가 있는 Root 볼륨은 비활성화로 설정하여 실수로 인한 데이터 손실 방지

EBS 스냅샷 (Snapshots)

스냅샷이란?

특정 시점의 EBS 볼륨 백업본

EBS Volume → Snapshot → 다른 AZ/Region으로 복사 가능

모범 사례:

• 스냅샷 생성 시 볼륨 분리 권장 (필수는 아님)
• 정기적인 백업 스케줄 설정

고급 스냅샷 기능

EBS Snapshot Archive

목적: 비용 절약 (75% 저렴한 "아카이브 계층")

일반 스냅샷 → Archive Tier 이동
복원 시간: 24~72시간

사용 사례: 장기 보관용 백업, 규정 준수용 데이터

Recycle Bin

목적: 실수로 삭제한 스냅샷 복구

설정 옵션:

• 보존 기간: 1일 ~ 1년
• 자동 복구 규칙 설정 가능

스냅샷 삭제 → Recycle Bin 이동 → 보존 기간 내 복구 가능

Fast Snapshot Restore (FSR)

목적: 스냅샷에서 복원한 볼륨의 초기 성능 저하 방지

FSR의 동작 원리

일반 복원 과정:
스냅샷 → 새 볼륨 생성 → 첫 액세스 시 지연 발생

FSR 적용 시:
스냅샷 → 블록 미리 로딩 → 즉시 최적 성능

핵심 개념:

• ❌ "빈 디스크를 채우는 작업"이 아님
• ✅ "스냅샷 블록을 EBS로 미리 로딩하는 작업"

특징:

• 스냅샷에서 볼륨을 생성할 때 발생하는 첫 번째 접근 지연(Latency)을 완전히 제거
• 비용이 높음
• 즉시 최적 성능 필요한 경우에만 사용
• 미션 크리티컬 애플리케이션에 적합

💡 학습 포인트 (Self-Note)

• EBS는 "가용 영역(AZ)에 묶여 있다"는 사실을 절대 잊지 말자. 다른 AZ로 이사가려면 무조건 Snapshot -> Copy -> Restore 과정을 거쳐야 함

• 비용 최적화를 하려면 사용하지 않는 스냅샷은 Archive로 보내거나 삭제하되, 만약을 위해 Recycle Bin 설정을 해두는 것이 안전함

• Delete on Termination 설정 미스로 데이터 날려먹는 일이 없도록 주의!!

EBS 설계 원칙

1. 데이터 중요도에 따른 Delete on Termination 설정
2. 정기적인 스냅샷 백업 전략 수립
3. 비용 최적화를 위한 Archive 활용
4. 성능이 중요한 워크로드에는 FSR 고려

비용 최적화 전략

단계별 스토리지 관리:
활성 데이터 → EBS Volume
백업 데이터 → Snapshot
장기 보관 → Archive Tier

IPv4 vs IPv6

네트워크에는 크게 두 가지 IP 체계(IPv4, IPv6)가 있지만, 아직은 IPv4가 대세다.

• IPv4: 1.160.10.240 (현재 가장 널리 사용)
• IPv6: 3ffe:1900:4545:3:200:f8ff:fe21:67cf (IoT 시대를 위한 차세대 프로토콜)

IPv4는 [0-255].[0-255].[0-255].[0-255] 형식으로 약 37억 개의 주소를 제공합니다.

2. Private IP vs Public IP

핵심 차이점

실제 사용 예시

회사 사설 네트워크 구조:
┌─────────────────────────────────────┐
│ 사설 네트워크 (Private Network)        │
│ ┌─────┐ ┌─────┐ ┌─────┐            │
│ │ PC1 │ │ PC2 │ │ PC3 │            │
│ └─────┘ └─────┘ └─────┘            │
│           │                        │
│    ┌─────────────┐                 │
│    │Internet GW  │ ← Public IP     │
│    └─────────────┘                 │
└─────────────────────────────────────┘
           │
      ┌─────────┐
      │Internet │
      └─────────┘

3. Elastic IP (EIP) - 고정 IP 서비스

EIP란?

• EC2 인스턴스 재시작 시 Public IP가 변경되는 문제를 해결
• 삭제하지 않는 한 계속 소유하는 고정 Public IPv4 주소
• 한 번에 하나의 인스턴스에만 연결 가능
• 계정당 5개 제한 (증설 요청 가능)

⚠️ EIP 사용을 피해야 하는 이유

1. 단일 장애점 문제

❌ EIP 방식 (권장하지 않음)
User → 고정 IP(EIP) → EC2 1대
문제점: EC2 장애 = 서비스 중단

2. 확장성 제한

• Auto Scaling과 호환성 문제
• Multi-AZ 구성과 부적합
• 옛날 단일 서버 시대의 사고방식

✅ 권장 대안: DNS + Load Balancer

✅ 현대적 구조 (권장)
User → DNS → ALB → EC2 여러 대

장점:
- EC2 대수 제한 없음
- IP 변경되어도 DNS만 유지
- 자동 장애 복구
- Auto Scaling 지원

4. Placement Groups - EC2 배치 전략

인스턴스가 물리적인 하드웨어 상에 어떻게 배치될지 결정하는 전략이다.

EC2 인스턴스의 물리적 배치를 제어하는 3가지 전략:

4.1 Cluster (클러스터 배치)

특징: 모든 인스턴스를 동일 AZ의 근접한 위치에 배치

┌─────────────────────────────────┐
│        Single AZ                │
│  ┌─────┐ ┌─────┐ ┌─────┐       │
│  │ EC2 │ │ EC2 │ │ EC2 │       │
│  └─────┘ └─────┘ └─────┘       │
│     └──── 10Gbps 네트워크 ────┘  │
└─────────────────────────────────┘

• 장점: 초고속 네트워크 (10Gbps)
• 단점: AZ 장애 시 모든 인스턴스 동시 장애
• 용도: 빅데이터 처리, 초저지연 애플리케이션

4.2 Spread (분산 배치)

특징: 각 인스턴스를 서로 다른 물리적 하드웨어에 배치

AZ-1a        AZ-1b        AZ-1c
┌─────┐     ┌─────┐     ┌─────┐
│ EC2 │     │ EC2 │     │ EC2 │
└─────┘     └─────┘     └─────┘
다른 랙      다른 랙      다른 랙

• 장점: 최대 가용성, 동시 장애 위험 최소화
• 단점: AZ당 7개 인스턴스 제한
• 용도: 가용성을 극대화해야 하는 핵심 애플리케이션, 서로 독립된 장애 격리가 필요한 경우.

4.3 Partition (분할 배치)

특징: 여러 파티션으로 나누어 인스턴스 그룹 배치

AZ-1a                    AZ-1b
┌─────────────────┐     ┌─────────────────┐
│ Partition 1     │     │ Partition 4     │
│ ┌─────┐┌─────┐  │     │ ┌─────┐┌─────┐  │
│ │ EC2 ││ EC2 │  │     │ │ EC2 ││ EC2 │  │
│ └─────┘└─────┘  │     │ └─────┘└─────┘  │
├─────────────────┤     ├─────────────────┤
│ Partition 2     │     │ Partition 5     │
│ ┌─────┐┌─────┐  │     │ ┌─────┐┌─────┐  │
│ │ EC2 ││ EC2 │  │     │ │ EC2 ││ EC2 │  │
│ └─────┘└─────┘  │     │ └─────┘└─────┘  │
└─────────────────┘     └─────────────────┘

• 제한: AZ당 최대 7개 파티션
• 확장성: 그룹당 수백 개 인스턴스 지원
• 특징: 파티션 정보를 메타데이터로 제공
• 용도: HDFS, HBase, Cassandra, Kafka 등 파티션 인식 빅데이터 애플리케이션

학습 포인트 요약

네트워킹 설계 원칙

1. EIP 대신 DNS(Route 53) + ALB 사용
2. Multi-AZ 구성으로 가용성 확보
3. Auto Scaling으로 확장성 보장

Placement Group 선택 기준

• 고성능 컴퓨팅: Cluster
• 미션 크리티컬: Spread
• 빅데이터 분산처리: Partition

✍️ 정리 메모

EC2의 네트워크와 배치 전략은 단순히 “인스턴스를 띄우는 문제”가 아니라, 장애 범위·확장 방식·시스템 성격을 드러내는 설계 선택에 가깝다고 느꼈다.

기존 방식: aws configure를 실행해 Access Key와 Secret Key를 직접 입력한다. 하지만 이건 인스턴스 내부에 자격 증명이 파일로 남아서 보안상 위험하다.

Role 방식: EC2 인스턴스의 Security > Modify IAM Role 메뉴에서 적절한 정책이 담긴 역할을 부여한다.

Before: aws configure 필요

aws configure aws iam list-users

After: IAM Role 연결 후

EC2 Console → Security → Modify IAM Role

이렇게 하면 aws configure를 따로 안 해도 바로 aws iam list-users 같은 명령어가 작동한다. EC2가 부여된 역할을 통해 임시 자격 증명을 자동으로 가져오기 때문이다. 인스턴스 운영할 땐 무조건 IAM Role을 쓰는 게 원칙이다.

EC2 Purchasing Options (구매 옵션 요약)

비용을 아끼려면 상황에 맞는 구매 방식을 선택해야 한다.

On-Demand Instances: 짧은 작업, 가격 예측 가능, 초 단위 결제. 가장 비싸지만 약정 없이 언제든 쓰고 버릴 수 있다.

Reserved Instances (RI): 1년 또는 3년 약정. 긴 작업에 적합하다.

Convertible Reserved Instances: 나중에 인스턴스 타입을 바꿀 수 있는 유연함이 포함된 약정.

Savings Plans: 일정량의 사용량을 약정하고 할인받는 방식. RI보다 좀 더 유연하다.

Spot Instances: 가장 저렴하지만(최대 90% 할인) AWS가 리소스가 필요하면 인스턴스를 회수해갈 수 있다. (신뢰성은 낮음)

Dedicated Hosts: 물리적 서버 한 대를 통째로 예약. 규제나 라이선스 이슈가 있을 때 쓴다.

Dedicated Instances: 하드웨어를 다른 고객과 공유하지 않는다.

Capacity Reservations: 특정 AZ에 용량을 미리 확보해두는 방식. 인스턴스를 실행하지 않아도 비용이 나간다.

구매 옵션을 리조트에 비유하기 (Resort Analogy)

On-demand: 리조트에 가고 싶을 때 언제든 가서 정가를 내고 묵는 것.

Reserved: 미리 계획을 세우고 장기 투숙을 예약해서 큰 할인을 받는 것.

Savings plans: 특정 기간 동안 시간당 일정 금액을 내기로 하고, 방 타입(킹, 스위트 등)을 유연하게 선택하는 것.

Spot instances: 빈방에 대해 경매(Bid)를 붙이는 것. 가장 높은 금액을 쓴 사람이 방을 차지하지만, 호텔이 필요하면 언제든 쫓겨날 수 있다.

Dedicated Hosts: 리조트 건물 한 동을 통째로 빌리는 것.

Capacity Reservations: 방을 미리 예약해두는 것. 실제로 가서 자든 안 자든 풀 가격을 지불해야 한다.

Public IPv4 과금 이슈 2024년 2월 1일부터 모든 퍼블릭 IPv4 주소에 대해 요금이 부과되기 시작했다.

가격: 시간당 $0.005 (한 달에 약 $3.6 정도).

Free Tier: 신규 계정은 처음 12개월 동안 EC2용 퍼블릭 IP 750시간 무료 제공. 하지만 다른 서비스(RDS 등)는 무료 혜택이 없다.

이유: 전 세계적인 IPv4 고갈 문제로 IPv6 전환을 독려하기 위함이다. 하지만 여전히 많은 곳이 IPv4를 쓰고 있어서 비용이 발생하더라도 쓰는 경우가 많다.

Troubleshooting: 내 계정에서 어디에 돈이 나가는지 보려면 AWS Bill을 보거나, IPAM (IP Address Manager)의 Public IP Insights를 확인하면 된다.

EC2 Spot Instance 상세 비용 절감의 핵심이지만 작동 방식을 정확히 알아야 사고가 안 난다.

작동 원리: 내가 설정한 Max Price보다 현재 Spot Price가 낮으면 인스턴스가 실행된다. 가격이 역전되면 인스턴스가 중단되는데, 이때 2분의 유예 시간(Grace period)이 주어진다.

Spot Block: 1~6시간 동안 끊김 없이 쓰도록 예약하는 방식인데, 정말 희귀한 상황에서는 회수될 수도 있다.

적합한 작업: 배치 작업, 데이터 분석 등 실패해도 다시 실행하면 되는 업무. DB나 중요한 운영 서버에는 절대 쓰면 안 된다.

★ 중요: 스팟 인스턴스 종료 방법 그냥 인스턴스만 종료(Terminate)하면 AWS가 "어? 사용자가 인스턴스를 원한다고 했는데 왜 없지?" 하고 스팟 요청(Spot Request)을 기반으로 새 인스턴스를 다시 띄워버린다.

먼저 Spot Request를 Cancel(취소) 한다. (그래야 AWS가 새로 안 만든다)

그 후에 실행 중인 Spot Instance를 Terminate 한다.

Spot Fleets (스팟 플릿) 비용 절감과 가용성을 동시에 챙기는 똑똑한 방법이다.

개념: 스팟 인스턴스 묶음 + (선택사항) 온디맨드 인스턴스.

장점: 여러 인스턴스 유형(m5.large, c5.large 등)과 여러 가용 영역(AZ)을 런치 풀(Launch Pool)로 정의해두면, 플릿이 알아서 가장 저렴하거나 안정적인 풀에서 인스턴스를 가져온다.

할당 전략 (Allocation Strategies):

lowestPrice: 가장 싼 풀에서 가져옴 (비용 최적화).

diversified: 모든 풀에 골고루 분산 (가용성 향상).

capacityOptimized: 용량이 넉넉한 풀을 우선 선택 (회수될 확률이 적음, 권장 방식).

**Spot vs Spot Fleet 차이점

Spot Instance: 특정 인스턴스 타입 + AZ 지정 Spot Fleet: 여러 인스턴스 타입 + AZ 중 최적 선택

💡 학습 포인트 (Self-Note)

보안 Best Practice

• EC2에는 IAM Role 필수 사용
• Access Key 하드코딩 금지

Spot Instance 관리

• 중단 가능한 워크로드만 사용
• 중요한 DB나 서비스에는 비추천
• 종료 시 순서 준수 필수

단순 스팟 요청은 내가 특정 타입과 AZ를 찍어서 요청하는 느낌이라면, 스팟 플릿은 "이런 조건들을 만족하는 것 중에 제일 최적인 걸로 알아서 가져와"라고 뭉텅이로 요청하는 느낌이다.

IPv4 비용이 이제는 무시 못 할 수준이니 안 쓰는 탄력적 IP(EIP)는 바로 반납하고, 퍼블릭 IP가 굳이 필요 없는 인스턴스는 프라이빗 서브넷으로 옮기는 습관을 들여야겠다.

Allow rules only: 보안 그룹은 오직 허용(Allow) 규칙만 가질 수 있다. 특정 트래픽을 명시적으로 거부(Deny)하는 기능은 없다.

Referencing: 규칙을 설정할 때 특정 IP 범위뿐만 아니라 다른 보안 그룹(Security Group ID)을 참조할 수 있다.

Stateful: 보안 그룹은 상태를 기억한다. Inbound로 들어온 트래픽이 허용되었다면, 돌아나가는 Outbound 트래픽은 설정과 상관없이 자동으로 허용된다. ( 기본적으로 모든 inbound 트래픽 차단, outbound 트래픽 허용 )

Security Groups Deeper Dive 보안 그룹이 구체적으로 어떤 것들을 규제하는지 정리한다.

Traffic Control 메커니즘 Internet ←→ Security Group ←→ EC2 Instance

Control points: 포트(Ports) 접근 권한, 인증된 IP 범위(IPv4, IPv6), 인바운드 및 아웃바운드 네트워크 트래픽을 조절한다.

Outside the EC2: 보안 그룹은 EC2 인스턴스 외부에서 작동한다. 만약 트래픽이 보안 그룹에서 차단된다면, EC2 인스턴스 자체는 해당 트래픽이 왔다는 사실조차 알지 못한다.

Region/VPC Locked: 보안 그룹은 특정 리전과 VPC 조합에 종속된다. 다른 리전으로 복사해서 쓸 수는 없다.

트래픽 허용 기본값 (Default Behavior):

All inbound traffic is blocked by default: 외부에서 들어오는 모든 트래픽은 기본적으로 차단된다. (필요한 것만 열어줘야 함)

All outbound traffic is authorised by default: 인스턴스에서 외부로 나가는 트래픽은 기본적으로 모두 허용된다.

알아둬야 할 중요한 포인트 (Good to know) 실제 운영이나 트러블슈팅 시 유용한 팁들이다.

Attached to multiple instances: 하나의 보안 그룹을 여러 인스턴스에 적용할 수 있고, 반대로 하나의 인스턴스에 여러 보안 그룹을 붙일 수도 있다.

Separate SSH access: SSH 접속 전용 보안 그룹을 따로 관리하는 것이 보안상 좋다.

Troubleshooting: * Time out: 트래픽이 응답 대기 시간을 초과한다면 높은 확률로 보안 그룹 설정 문제다. (트래픽이 아예 도달하지 못함)

Connection refused: 연결이 거부되었다면 보안 그룹은 통과했지만, 소프트웨어가 실행 중이 아니거나 설정 오류인 경우다.

다른 보안 그룹 참조 (Referencing Other SGs) IP 주소 대신 보안 그룹 ID를 규칙에 넣는 방식이다.

예를 들어, 보안 그룹 A를 가진 인스턴스가 보안 그룹 B를 참조하는 규칙을 갖고 있다면, 보안 그룹 B를 사용하는 모든 인스턴스의 트래픽을 허용하게 된다.

서버가 늘어나거나 IP가 바뀌어도 보안 그룹 기반으로 통신을 허용하므로 관리가 매우 유연해진다.

• IP 주소 변경에 관계없이 통신 허용
• Auto Scaling 환경에서 유용
• 계층별 보안 구성 가능

Classic Ports to know 네트워크 통신에서 표준으로 쓰이는 포트 번호들이다. 텍스트로 정리해둔다.

Port 22: SSH (Secure Shell) - 리눅스 인스턴스 로그인용.

Port 21: FTP (File Transfer Protocol) - 파일 전송.

Port 22: SFTP (Secure File Transfer Protocol) - SSH 기반 보안 파일 전송.

Port 80: HTTP - 비보안 웹사이트 접속.

Port 443: HTTPS - 보안 웹사이트 접속.

Port 3389: RDP (Remote Desktop Protocol) - 윈도우 인스턴스 원격 로그인용.

SSH Summary (How to access) 리모트 머신을 커맨드 라인으로 제어하기 위해 SSH는 필수다.

Linux / Mac OS X: 터미널에서 ssh 명령어를 통해 바로 접속 가능하다.

Windows: 예전에는 Putty 등을 썼지만, 최신 윈도우는 터미널에서 바로 접속하거나 전용 툴을 사용한다.

가장 중요한 점은 Port 22가 인바운드 보안 그룹에서 열려 있어야 한다는 것이다.

💡 정리하며 (Self-Note) 웹 서비스를 한다면 80(HTTP)과 443(HTTPS)은 기본으로 열어야 한다.

관리용으로는 22(SSH)나 3389(RDP)가 필요한데, 보안을 위해 My IP 옵션으로 내 컴퓨터에서만 접속되도록 제한하는 게 국룰이다.

Best Practices

1. SSH 전용 Security Group 별도 관리
2. 최소 권한 원칙 적용
3. 포트별 세분화 규칙 설정
4. 정기적인 규칙 검토

All inbound traffic is blocked by default라는 점을 항상 명심하자. 설정 안 하면 아무것도 안 들어온다.

*

• Security Group 변경사항은 즉시 적용
• 차단된 트래픽은 EC2 인스턴스에 도달하지 않음
• 로그 분석 시 Security Group 레벨에서 먼저 확인

핵심 구성 요소:

EC2: 가상 머신 그 자체.

EBS: 가상 드라이브 (데이터 저장).

ELB: 여러 서버로 트래픽을 분산해주는 장치.

ASG: 상황에 따라 서버 대수를 자동으로 늘리고 줄여주는 그룹.

EC2 설정 및 구성 옵션 서버를 만들 때 결정해야 할 게 꽤 많다. 사양에 따라 비용이 달라지니 신중해야 함.

OS: Linux, Windows, Mac OS 중 선택 가능.

CPU / RAM: 작업 부하에 맞는 컴퓨팅 파워와 메모리 크기 결정.

Storage (중요):

EBS / EFS: 네트워크로 연결된 드라이브. 인스턴스를 삭제해도 데이터 보존 가능.

EC2 Instance Store: 서버 본체에 직접 달린 물리적 하드웨어. 속도는 빠르지만 인스턴스 중단 시 데이터가 날아가는 휘발성(Ephemeral)이라 임시 데이터용으로만 써야 함.

Security Group: 방화벽 규칙. 어떤 포트를 열고 닫을지 설정.

EC2 User Data (부트스트래핑):

인스턴스가 처음 시작될 때 딱 한 번 실행되는 스크립트.

업데이트 설치, 소프트웨어 다운로드 등을 자동화할 때 쓴다.

root 권한으로 실행되기 때문에 모든 명령에 sudo를 붙일 필요가 없음.

인스턴스 명명 규칙 (Naming Convention) 예를 들어 m5.2xlarge라는 이름이 있다면 각각의 의미가 있다.

m: 인스턴스 클래스 (타입)

5: 세대 (숫자가 높을수록 최신/고성능)

2xlarge: 해당 클래스 내에서의 크기 (CPU, RAM 양이 결정됨)

EC2 인스턴스 타입별 용도 (Instance Types) 상황에 맞는 타입을 골라야 비용 낭비를 안 한다.

■ General Purpose (범용) Compute, Memory, Networking의 균형이 잘 잡힌 타입이다.

Prefix: M, T

Use Cases: 웹 서버, 코드 저장소(Code repositories) 등 다양한 워크로드.

■ Compute Optimized (컴퓨팅 최적화) 고성능 프로세서가 필요한 계산 집약적 작업에 적합하다.

Prefix: C

Use Cases: Batch processing, 미디어 트랜스코딩, 고성능 웹 서버, HPC(고성능 컴퓨팅), 머신러닝, 게임 서버.

■ Memory Optimized (메모리 최적화) 메모리 내에서 대규모 데이터셋을 처리하는 작업에 최적화되어 있다.

Prefix: R, X1, Z1 (R은 RAM의 R로 외우면 편함)

Use Cases: 고성능 관계형/비관계형 DB, 분산 웹 스케일 캐시 스토어, 실시간 빅데이터 분석.

■ Storage Optimized (스토리지 최적화) 로컬 스토리지에 대규모 데이터셋을 고속으로 읽고 써야 할 때 사용한다.

Prefix: I, D, H1

Use Cases: OLTP 시스템, NoSQL DB, Redis 캐시, 데이터 웨어하우징 애플리케이션

💡 학습 포인트 요약 (Self-Note) 서버를 껐다 켰을 때 데이터가 날아가면 안 된다면 반드시 EBS를 써야 한다. Instance Store는 임시 작업용으로만 쓰자.

User Data는 처음 생성 시에만 동작한다는 걸 잊지 말자. 나중에 수정하고 싶으면 인스턴스를 새로 만드는 게 빠를 수도 있다.

JSON

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::my-bucket",
            "Condition": {"IpAddress": {"aws:SourceIp": "1.2.3.4/32"}}
        }
    ]
}

Sid (Statement ID): 문장의 식별자. 어떤 역할을 하는 문장인지 적어둔다.

Effect: 허용(Allow)할지 거부(Deny)할지 결정. (가장 중요)

Principal: 특정 정책을 적용할 계정이나 유저를 지정한다.

Action: 어떤 API 호출을 허용/거부할지 목록을 적는다. (ex: S3 읽기, EC2 중지 등)

Resource: 액션이 적용될 구체적인 리소스 목록이다.

Condition: 정책이 언제 적용될지 결정하는 조건이다. (ex: 특정 IP에서만 접속 가능)

기억할 점: Effect, Principal, Action, Resource는 필수 요소다.

2. 비밀번호 정책 및 MFA 계정 보안을 위해 반드시 설정해야 하는 부분들이다.

Password Policy: 비밀번호 복잡도나 만료 기간을 설정한다.

MFA (다중 인증): 비밀번호 + 물리적 보안 장치 조합이다. 비밀번호가 털려도 물리 장치가 없으면 접속을 못 하니 보안성이 확 올라간다.

가상 MFA: Google Authenticator 같은 앱 사용. 폰 하나에 귀속됨.

U2F (물리적 보안 키): YubiKey 같은 전용 장치.

Hardware Key Fob: 하드웨어 보안 토큰 (TOTP 방식).

GovCloud용: 미국 정부용 클라우드 전용 장치.

3. AWS 접근 방식 및 Access Key 유저가 AWS에 접근하는 방법은 크게 3가지가 있다.

Management Console: 웹 브라우저 접속 (ID/PW + MFA 방식).

AWS CLI: 터미널에서 명령어로 제어. Access Key가 필요하다.

AWS SDK: 코드 내에서 API를 호출할 때 사용. 역시 Access Key가 필요하다.

Access Key 관리 주의사항:

Access Key ID는 유저네임, Secret Access Key는 비밀번호와 같다.

절대 공유하면 안 되고, 특히 코드에 하드코딩해서 깃허브 같은 곳에 올리면 큰일 난다.

4. AWS CloudShell 활용 웹 콘솔에서 바로 터미널을 쓸 수 있는 기능이다.

무료로 사용 가능한 터미널 개념이다.

내 계정의 자격 증명이 이미 적용되어 있어 aws iam list-users 같은 명령어가 바로 작동한다.

파일 저장소가 있어서 재시작해도 파일이 남아있는 게 큰 장점이다.

5. IAM Role (역할) 사람이 아니라 AWS 서비스에게 권한을 줄 때 사용한다.

EC2나 Lambda 같은 서비스가 다른 AWS 리소스(S3 등)에 접근해야 할 때 Role을 만들어 부여한다.

실제 사람이 쓰는 게 아니므로 장기적인 비밀번호(Access Key)가 필요 없고, 임시 자격 증명을 사용해서 훨씬 안전하다.

대표적 예시: EC2 Instance Role, Lambda Function Role.

6. 보안 검토 도구 (Audit) 내가 설정을 잘했는지, 안 쓰는 권한은 없는지 확인할 때 유용하다.

IAM Credentials Report: 계정 내 모든 유저의 자격 증명 상태(MFA 설정 여부 등)를 보고서로 뽑아준다. 계정 수준의 점검에 좋다.

IAM Access Advisor: 유저가 부여받은 권한 중 실제로 언제 마지막으로 사용했는지 보여준다. 안 쓰는 권한을 찾아내서 삭제하는 '최소 권한 원칙'을 지키기에 딱이다.