🖥️ AWS EC2 (Elastic Compute Cloud)#

☁️ EC2가 제공하는 것#

⚙️ EC2 설정 옵션#

1
EC2 인스턴스 구성 요소
2
├── OS: Linux / Windows / macOS
3
├── CPU: vCPU 수, 프로세서 아키텍처 (x86, ARM/Graviton)
4
├── RAM: 메모리 크기
5
├── Storage
6
│   ├── Network-attached: EBS (Elastic Block Store), EFS (Elastic File System)
7
│   └── Hardware: EC2 Instance Store (임시, 고속)
8
├── Network: 네트워크 카드 속도, 공인 IP 설정
9
├── Security Group: 방화벽 규칙
10
└── User Data: 최초 실행 시 부트스트랩 스크립트

🚀 EC2 User Data (부트스트랩)#

• 인스턴스 최초 시작 시 딱 한 번만 실행
• root 권한으로 실행됨
• 자동화할 수 있는 작업 예시:

1
#!/bin/bash
2
# EC2 User Data 예시
3
yum update -y
4
yum install -y httpd
5
systemctl start httpd
6
systemctl enable httpd
7
echo "<h1>Hello from EC2 $(hostname -f)</h1>" > /var/www/html/index.html

💡 활용 팁: 소프트웨어 설치, 설정 파일 다운로드, 환경변수 설정 등 초기화 작업을 자동화할 때 사용. 복잡한 설정이 필요하면 CloudFormation 또는 Ansible 연계 권장.

🏷️ 명명 규칙#

1
m  7  g  .  2xlarge
2
│  │  │       └── 크기 (nano / micro / small / medium / large / xlarge / 2xlarge ...)
3
│  │  └────────── 추가 속성 (g=Graviton, a=AMD, i=Intel, n=고속 네트워크)
4
│  └───────────── 세대 (숫자가 높을수록 최신)
5
└──────────────── 인스턴스 패밀리 (m=범용, c=컴퓨팅, r=메모리, i=스토리지 등)

📊 인스턴스 패밀리별 용도#

⚡ Graviton (ARM 기반) 인스턴스 — 2025 핵심 트렌드#

AWS Graviton 프로세서 기반 EC2 인스턴스는 x86 기반 인스턴스 대비 최대 40% 향상된 가격 대비 성능을 제공합니다.

WARNING

ARM 아키텍처이므로 애플리케이션이 x86 바이너리에 의존하는 경우 멀티 아키텍처 빌드 테스트 필요. Docker 이미지도 arm64 지원 여부 확인 필수.

🔀 버스터블 인스턴스 (T 시리즈)#

• 기준 CPU 성능 + 필요 시 일시적으로 버스트 가능
• CPU 크레딧 방식: 평소에 크레딧 적립 → 부하 시 소진
• 개발/테스트, 트래픽 변동이 큰 소규모 앱에 적합

1
t3.micro:  기준 20% CPU, 필요 시 최대 100%까지 버스트
2
t3.large:  기준 30% CPU, 필요 시 최대 100%까지 버스트

WARNING

프로덕션 고부하 환경에서 크레딧 고갈 시 심각한 성능 저하 발생. unlimited 모드 설정 시 추가 비용 발생.

🔥 개념#

• EC2 인스턴스 앞단의 가상 방화벽
• Allow 규칙만 존재 (Deny 규칙 없음 — NACL과 차이)
• IP 또는 다른 Security Group을 참조해 규칙 설정 가능

1
인터넷
2
  │
3
  ▼
4
[Security Group]  ← 여기서 허용된 트래픽만 통과
5
  │
6
  ▼
7
[EC2 Instance]   ← 차단된 트래픽은 인스턴스가 아예 볼 수 없음

📋 Inbound / Outbound 기본값#

📌 주요 포트 번호#

✅ Security Group 활용 팁#

1. Security Group 간 참조 (IP 대신)

1
[App Server SG]  →  Inbound: MySQL(3306) from [DB Server SG]

→ IP 변경 시에도 자동 적용, IP 관리 불필요

2. 트러블슈팅 가이드

💡 Best Practice

SSH용 Security Group을 별도로 분리하여 관리. 0.0.0.0/0 (전체 허용)은 절대 프로덕션에 사용 금지.

플랫폼별 지원 현황#

SSH 접속 예시#

1
# 키 파일 권한 설정 (최초 1회)
2
chmod 400 my-key.pem
3

4
# 접속
5
ssh -i my-key.pem ec2-user@<공인IP>
6
# Amazon Linux: ec2-user
7
# Ubuntu: ubuntu
8
# CentOS: centos

🌟 EC2 Instance Connect vs SSM Session Manager#

AWS Systems Manager Session Manager

• SSH 포트를 열거나 Bastion 호스트를 사용하지 않고 EC2 인스턴스, 온프레미스 서버, VM 등을 엑세스 할 수 있는 안전하고(secure), 감사가 가능하며(audited), 브라우저 기반(browser-based) 쉘
• Benefits
  • 보안 (Security) : SSH 포트나 RDP (3389) 포트를 열지 않아도 되어서 높은 보안 수준 유지 가능
  • 접근 제어 (Access Control) : IAM 정책을 사용하여 사용자의 접근 제어 가능
  • 감사 추적 가능성 (Auditability) : 모든 세션 명령어는 로깅 → CloudWatch Logs가 Amazon S3 등에서 로그 중앙 관리 지원
  • SSH Key 관리 ❌ : SSH 키 관리, 저장 및 로테이션이 불필요
  • 크로스 플랫폼 (Cross-Platform) : Windows와 Linux 인스턴스 둘다 지원 가능
• How to setup?
  • SSM Agent 설치
  • IAM Role Configuration : AmazonSSMManagedInstanceCore 정책 설정을 통해서 System Manager service와 통신 가능하도록 허용
  • Network Connectivity : 인스턴스는 HTTPS (443) 아웃바운드 정책 허용

💡 2025 Best Practice

포트 22를 아예 열지 않고 SSM Session Manager로 접속하는 것이 보안상 가장 권장되는 방식입니다.

🏨 호텔 비유로 이해하기#

💰 비용 비교 및 사용 시나리오#

1
비용 (높음 → 낮음)
2
On-Demand > Dedicated Host > Reserved > Savings Plans > Spot
3

4
유연성 (높음 → 낮음)
5
On-Demand > Spot > Savings Plans > Reserved > Dedicated Host

On-Demand#

• Linux/Windows: 초 단위 과금 (최초 1분 이후)
• 기타 OS: 시간 단위 과금
• 예측 불가한 단기 워크로드, 신규 앱 테스트에 적합

Reserved Instances (RI)#

• 최대 72% 할인 (3년 전액 선불 시 최대)
• 고정 조건: 인스턴스 타입, 리전, OS, 테넌시

• Convertible RI: 인스턴스 타입 변경 가능, 최대 66% 할인
• Reserved Instance Marketplace에서 남은 기간 판매 가능

Savings Plans#

• 시간당 사용 금액 약정 ($X/시간 형태)
• RI보다 유연: 인스턴스 크기, OS, 테넌시 변경 가능
• 약정 초과분은 On-Demand 요금 적용
• 취소 불가 (1년 또는 3년 약정)

대부분의 팀에게는 Compute Savings Plans가 절감액과 유연성의 가장 좋은 균형을 제공합니다. AWS는 새로운 약정에 대해 Savings Plans를 권장합니다.

Spot Instances#

• 최대 90% 할인 — AWS에서 가장 저렴
• 현재 Spot 가격이 설정한 최대 가격 초과 시 2분 경고 후 인스턴스 종료
• 중단에 견딜 수 있는 워크로드에만 적합:

1
✅ 적합: 배치 처리, 데이터 분석, 이미지 처리, ML 학습, CI/CD
2
❌ 부적합: 운영 DB, 결제 시스템, 실시간 서비스

Dedicated Hosts vs Dedicated Instances#

💡 Dedicated Host 사용 시나리오: Oracle, Microsoft SQL Server 등 소켓/코어 기반 라이선스가 있는 소프트웨어를 클라우드로 이전(Lift & Shift)할 때.

🎯 Spot Instance 작동 방식#

1
사용자가 max price 설정
2
        │
3
        ▼
4
현재 Spot 가격 < max price → 인스턴스 실행 유지
5
        │
6
현재 Spot 가격 > max price → 2분 경고
7
        │
8
        ├── Stop: Spot 가격이 낮아지면 자동 재시작 (Persistent)
9
        └── Terminate: 완전 종료 (One-time)

📋 Spot Request 유형#

올바른 종료 순서:

1
1️⃣ Spot Request 취소 (Cancel) — 먼저!
2
2️⃣ 연결된 인스턴스 종료 (Terminate)
3

4
⚠️ 인스턴스만 종료하면 Persistent 요청이 새 인스턴스를 다시 시작시킴

🚢 Spot Fleet — 더 스마트한 Spot 활용#

Spot Fleet = Spot 인스턴스 집합 + (선택) On-Demand 인스턴스

1
Spot Fleet
2
├── Launch Pool A: c5.xlarge, Linux, us-east-1a
3
├── Launch Pool B: c5.2xlarge, Linux, us-east-1b
4
└── Launch Pool C: c5a.xlarge, Linux, us-east-1c
5

6
→ 목표 용량에 맞춰 가장 유리한 풀에서 자동으로 인스턴스 요청

Spot Fleet 할당 전략:

🌐 공인 IP (Public IP) vs 사설 IP (Private IP)#

1
[사설 네트워크 A]          [사설 네트워크 B]
2
  192.168.1.10               192.168.1.10   ← 사설 IP 중복 가능
3
       │                          │
4
   [NAT/IGW]                  [NAT/IGW]
5
       │                          │
6
       └──────── 인터넷 ──────────┘
7
           (공인 IP는 유일)

TIP

EC2 인스턴스는 기본적으로 사설 IP는 고정이지만, 공인 IP는 인스턴스를 중지(Stop) 후 재시작(Start)하면 변경됩니다.

🔒 IPv4 vs IPv6#

📌 Elastic IP (탄력적 IP)#

• EC2 인스턴스를 중지(Stop) 후 시작(Start)하면 공인 IP가 바뀌는 문제를 해결하는 고정 공인 IPv4 주소
• 삭제하지 않는 한 계속 소유 가능
• 한 번에 하나의 인스턴스에만 연결 가능
• 인스턴스 또는 네트워크 인터페이스 장애 시, 다른 인스턴스로 빠르게 재매핑(Remap)하여 장애를 마스킹(Masking)하는 용도로 활용 가능
• 계정당 기본 5개 제한 (AWS에 증가 요청 가능)
• 연결되지 않은 Elastic IP에는 요금 부과 (낭비 방지용)

⚠️ Elastic IP 사용을 피해야 하는 이유#

Elastic IP를 사용하는 아키텍처는 종종 설계가 잘못된 신호입니다 (often reflect poor architectural decisions).

대신 권장하는 방법:

📊 배치 전략 비교#

🚀 Cluster Placement Group (클러스터 배치 그룹)#

1
┌─────────── Availability Zone ───────────┐
2
│  ┌─────────── 단일 랙 ─────────────┐   │
3
│  │  [EC2] [EC2] [EC2] [EC2] [EC2]  │   │
4
│  └─────────────────────────────────┘   │
5
└─────────────────────────────────────────┘

• 장점: Enhanced Networking (향상된 네트워킹) 활성화 시 인스턴스 간 10Gbps 대역폭
• 단점: AZ 전체 장애 시 모든 인스턴스가 동시에 중단됨
• Use Case: 빠르게 완료해야 하는 빅데이터 작업 (Big Data job), 초저지연·고처리량이 필요한 애플리케이션

🛡️ Spread Placement Group (분산 배치 그룹)#

1
┌── AZ 1 ──┐   ┌── AZ 2 ──┐   ┌── AZ 3 ──┐
2
│ [랙1]    │   │ [랙2]    │   │ [랙3]    │
3
│  [EC2]   │   │  [EC2]   │   │  [EC2]   │
4
└──────────┘   └──────────┘   └──────────┘

• 장점: 각 인스턴스가 서로 다른 물리 하드웨어(랙)에 배치 → 동시 장애 위험 최소화, 여러 AZ에 걸쳐 배치 가능
• 단점: AZ당 최대 7개 인스턴스 제한 (소규모 배포에만 적합)
• Use Case: 각 인스턴스가 서로 독립적으로 장애 격리(Isolated from failure)되어야 하는 고가용성 미션 크리티컬 애플리케이션

🗂️ Partition Placement Group (파티션 배치 그룹)#

1
┌──────────────── AZ 1 ──────────────────┐
2
│  ┌─파티션1─┐  ┌─파티션2─┐  ┌─파티션3─┐ │
3
│  │ [EC2]  │  │ [EC2]  │  │ [EC2]  │ │
4
│  │ [EC2]  │  │ [EC2]  │  │ [EC2]  │ │
5
│  │ [EC2]  │  │ [EC2]  │  │ [EC2]  │ │
6
│  └────────┘  └────────┘  └────────┘ │
7
│   (서로 다른 랙, 파티션 간 랙 공유 없음)     │
8
└────────────────────────────────────────┘

• AZ당 최대 7개 파티션, 동일 리전 내 여러 AZ에 걸쳐 배치 가능
• 그룹당 수백 개의 EC2 인스턴스 지원
• 파티션 간 랙을 절대 공유하지 않음 → 한 파티션 장애가 다른 파티션에 영향 없음
• 인스턴스 메타데이터(Instance Metadata)로 자신이 속한 파티션 정보 접근 가능 → 애플리케이션이 토폴로지 인식(Topology-aware) 배포 가능
• Use Case: HDFS, HBase, Cassandra, Kafka 등 대규모 분산 데이터 시스템

🔌 ENI란?#

• ENI (Elastic Network Interface, 탄력적 네트워크 인터페이스): VPC (Virtual Private Cloud, 가상 사설 클라우드) 내에서 가상 네트워크 카드를 나타내는 논리적 컴포넌트
• EBS 볼륨을 필요에 따라 EC2에 붙이듯, 네트워킹 계층도 인스턴스와 독립적으로 분리하여 별도로 관리 가능
• 특정 AZ (Availability Zone, 가용 영역)에 종속됨 — AZ 간 이동 불가

💡 AWS 공식 블로그 핵심 인사이트: ENI 도입 이전에는 EC2 인스턴스가 특정 서브넷(Subnet)에 속하는 개념이었으나, ENI 도입 이후 서브넷 귀속 단위는 인스턴스가 아닌 ENI 로 바뀌었습니다. 따라서 하나의 인스턴스에 서로 다른 서브넷의 ENI 두 개를 붙여 듀얼 홈(Dual-homed) 환경을 구성할 수 있습니다.

📋 ENI 속성 (Attributes)#

🔄 ENI의 독립적 생명주기 (Independent Lifetime)#

EBS 볼륨처럼 ENI도 특정 EC2 인스턴스와 독립적인 생명주기를 가집니다.

1
ENI 생성 (미리 만들어 놓기 가능)
2
    │
3
    ├── 인스턴스 시작 시 연결 (Launch-time attach)
4
    ├── 실행 중인 인스턴스에 즉시 연결 (Hot attach, 핫 어태치)
5
    └── 인스턴스 종료 후에도 ENI는 유지 (Delete on Termination = false 시)

🏗️ ENI 주요 활용 패턴#

1. 관리 네트워크 분리 (Management Network / Backnet)

1
EC2 인스턴스
2
├── ENI 1 (공용 서브넷) ─→ 인터넷 게이트웨이 → 외부 트래픽 처리 (포트 80/443)
3
└── ENI 2 (사설 서브넷) ─→ VPN 게이트웨이 → SSH 접속·로그·관리 트래픽 (포트 22)

각 ENI에 다른 보안 그룹을 적용해 트래픽을 세밀하게 제어 가능.

2. 멀티 인터페이스 애플리케이션 (Multi-Interface Applications)

로드 밸런서(Load Balancer), 프록시 서버(Proxy Server), NAT 서버 구성 시 두 서브넷 사이에서 트래픽을 전달. 이 경우 소스/목적지 확인(Source/Destination Check)을 비활성화해야 함.

3. MAC 주소 기반 라이선스 (MAC-Based Licensing)

특정 MAC 주소에 묶인 상용 소프트웨어 라이선스를 사용할 때, 인스턴스가 교체·타입 변경이 필요한 경우에도 동일한 ENI(MAC 주소 유지)를 새 인스턴스에 재연결하여 라이선스 재발급 없이 계속 사용 가능.

4. 저비용 고가용성 (Low-Budget High Availability)

1
1️⃣ ENI를 인스턴스 A에 연결
2
2️⃣ 인스턴스 A 장애 발생
3
3️⃣ 새 인스턴스 B 시작
4
4️⃣ ENI를 인스턴스 B에 재연결 → 수 초 내 트래픽 복구

IP 주소와 보안 그룹 설정이 ENI에 종속되어 있으므로, 인스턴스가 바뀌어도 네트워크 구성이 그대로 유지됨.

🔁 장애 복구 시나리오 (Failover)#

1
[ENI: 10.0.1.50]──→ [인스턴스 A: 정상]
2
                             │ 장애!
3
                             ▼
4
[ENI: 10.0.1.50]──→ [인스턴스 B: 교체됨]
5
  (동일 IP 유지)      (수 초 내 트래픽 전환)

TIP

ENI는 특정 AZ에 종속(Bound to a specific AZ)됩니다. AZ 간 이동은 불가하므로, 멀티 AZ 고가용성이 필요한 경우 ELB(Elastic Load Balancer)를 사용해야 합니다.

💤 인스턴스 상태 전환 비교#

🔧 Hibernate 작동 원리#

1
Hibernate 실행
2
    │
3
    ▼
4
RAM 전체 내용을 루트 EBS 볼륨 파일에 덤프(Dump)
5
    │
6
    ▼
7
인스턴스 중지 (OS가 완전히 종료되지 않음)
8
    │
9
    ▼
10
재시작 시 → EBS에서 RAM 상태 복원 → 중단 지점부터 즉시 재개

IMPORTANT

OS 재부팅(OS booting)이 없으므로 시작 시간이 매우 빠름. 애플리케이션이 캐시 워밍(Cache Warming)을 다시 할 필요 없음.

✅ 지원 조건 (Requirements)#

💡 Hibernate 주요 Use Case#

WARNING

⚠️ 루트 볼륨 암호화가 필수인 이유: RAM 내용(민감한 데이터 포함 가능)이 EBS 디스크에 평문으로 쓰이는 것을 방지하기 위함.

💡 인스턴스 선택#

1. 워크로드 특성 먼저 파악

1
CPU 집약적  → Compute Optimized (c 계열)
2
메모리 집약적 → Memory Optimized (r, x 계열)
3
스토리지 I/O  → Storage Optimized (i, d 계열)
4
균형 잡힌 일반 → General Purpose (m, t 계열)
5
AI/ML 학습   → GPU (p, g 계열) 또는 Trn1
6
AI/ML 추론   → Inf2 (가장 저렴한 추론 전용)

2. Graviton(ARM) 우선 검토

Graviton(arm64)은 x86 대비 최대 40% 향상된 가격 대비 성능을 제공합니다. 멀티 아키텍처 빌드를 테스트하고 롤아웃 전에 p95/p99 성능을 측정하세요.

💰 비용 최적화 전략#

1. Right-Sizing (적정 규모 조정)

2~4주 동안 활용도 데이터를 수집하고, AWS Compute Optimizer 또는 Cost Explorer를 통해 과소 활용 인스턴스를 파악한 뒤 적절한 크기로 조정하세요.

1
# AWS Compute Optimizer로 우선 분석
2
# → CloudWatch 지표 기반 권장 인스턴스 타입 제안

2. 구매 옵션 혼합 (Blended Pricing)

1
안정적 기본 부하  → Reserved Instances 또는 Savings Plans (72% 절감)
2
변동적 추가 부하  → Spot Instances (최대 90% 절감)
3
예측 불가 피크   → On-Demand (백업)

기준 부하에는 Savings Plans/Reserved Instance로 커버하고, 기준 초과의 변동 부하에는 Spot Instance를 사용하세요. Spot 용량 부족 시에는 중요 워크로드를 위해 On-Demand로 자동 폴백하도록 구성하세요.

3. 스케줄링으로 유휴 비용 절감

1
개발/테스트 환경: 업무 시간(09:00-19:00)에만 실행
2
→ 태그 기반 자동 시작/종료 → 최대 65% 비용 절감
3

4
권장 태그 체계:
5
  Environment = dev | staging | prod
6
  Schedule    = OfficeHours | AlwaysOn
7
  Owner       = team-name
8
  CostCenter  = CC-1234

4. EBS 볼륨 비용 최적화

CloudWatch 또는 Compute Optimizer를 통해 일관되게 낮은 IOPS 또는 처리량을 보이는 볼륨을 식별하고, 더 저렴한 gp3 또는 st1 볼륨 타입으로 다운그레이드를 검토하세요.

TIP

gp2 → gp3 전환 시 동일 성능에 약 20% 비용 절감 가능.

🔐 EC2 보안 Best Practice#

1. 인스턴스 접근

• 포트 22(SSH)를 0.0.0.0/0으로 여는 것 절대 금지
• 가능하면 SSM Session Manager 사용 (포트 22 불필요)
• 불가피한 경우 회사 IP 또는 VPN IP만 허용

2. IAM Role 사용

1
# ❌ 절대 금지: Access Key를 EC2에 직접 저장
2
export AWS_ACCESS_KEY_ID="AKIA..."
3
export AWS_SECRET_ACCESS_KEY="..."
4

5
# ✅ 권장: EC2 IAM Role 사용 (자동으로 임시 자격증명 관리)
6
# 인스턴스에 Role만 붙이면 코드에서 자격증명 불필요
7
import boto3
8
s3 = boto3.client('s3')  # Role이 자동으로 처리

3. Auto Scaling 활용

1
Auto Scaling Group
2
├── Minimum: 2 (최소 가용성 보장)
3
├── Desired: 4 (평소 운영 수량)
4
└── Maximum: 10 (트래픽 급증 대비)
5

6
→ CloudWatch 지표(CPU 70% 초과 시) 기반 자동 Scale Out
7
→ CloudWatch 지표(CPU 30% 미만 시) 기반 자동 Scale In

🚨 자주 하는 실수 (Anti-Patterns)#