💾 AWS Storage#

📦 개념#

• “네트워크 USB 스틱 (Network USB Stick)” — 인스턴스와 네트워크로 통신
• 실행 중인 인스턴스에 연결 가능한 네트워크 드라이브 (Network Drive)
• 인스턴스 종료(Terminate) 후에도 데이터 영구 보존 가능
• 특정 AZ에 종속 — AZ 간 이동 불가 (스냅샷을 통해 이전)

1
[EC2 Instance]  ←── 네트워크 ───→  [EBS Volume]
2
  us-east-1a                         us-east-1a (동일 AZ 필수)

⚙️ 주요 특성#

🗑️ Delete on Termination 속성#

💡 실무 팁: 데이터 보호가 필요한 경우 루트 볼륨의 Delete on Termination을 비활성화하거나, 별도 데이터 볼륨을 추가로 구성하세요.

📊 전체 타입 비교#

🔵 General Purpose SSD (gp3 / gp2)#

gp3 — 현재 권장 범용 타입 ⭐

• 기본 IOPS 3,000, 처리량 125 MiB/s 제공
• IOPS(최대 16,000)와 처리량(최대 1,000 MiB/s)을 독립적으로 설정 가능
• 적합: 시스템 부트 볼륨, 가상 데스크톱, 개발/테스트 환경

gp2 — 구세대 (마이그레이션 권장)

• IOPS와 볼륨 크기가 연동 (3 IOPS/GiB), 크기 늘려야 IOPS 증가
• 5,334 GiB에서 최대 IOPS(16,000) 도달
• 소규모 볼륨은 3,000 IOPS까지 버스트 가능

💡 gp2 → gp3 전환: 동일 성능 기준 약 20% 비용 절감. 독립 IOPS 설정으로 유연성도 향상.

🟠 Provisioned IOPS SSD (io1 / io2 Block Express)#

• 지속적인 고IOPS가 필요한 미션 크리티컬 비즈니스 애플리케이션
• DB 워크로드처럼 스토리지 성능과 일관성에 민감한 애플리케이션에 최적
• 16,000 IOPS 초과가 필요한 경우 필수

🟤 Hard Disk Drives (st1 / sc1)#

• 부트 볼륨으로 사용 불가
• 크기 범위: 125GiB ~ 16TiB

📸 개념#

• 특정 시점의 EBS 볼륨 백업 (Point-in-time Backup)
• 스냅샷 시 볼륨을 꼭 분리(Detach)할 필요는 없으나 권장
• 스냅샷은 AZ 또는 리전 간 복사 가능 → AZ 간 볼륨 이전 수단

1
us-east-1a [EBS Volume] → 스냅샷 생성 → us-east-1b [새 EBS Volume] 복원
2
                             (S3에 저장됨)

✨ 스냅샷 주요 기능#

💡 실무 팁: 자주 접근하지 않는 스냅샷은 Archive Tier로 이동하고, 실수 삭제 방지를 위해 Recycle Bin 규칙을 설정하세요.

🔒 암호화된 EBS 볼륨의 특성#

• 볼륨 내 저장 데이터 (Data at rest) 암호화
• 인스턴스 ↔ 볼륨 간 전송 데이터 (Data in flight) 암호화
• 해당 볼륨으로 생성된 모든 스냅샷 암호화
• 암호화된 스냅샷으로 생성한 모든 볼륨 암호화
• 암호화/복호화는 AWS가 투명하게 처리 (사용자가 별도 조작 불필요)
• 지연 시간에 미치는 영향 최소화
• AWS KMS (AES-256) 키 활용

🔄 미암호화 볼륨 → 암호화 변환 절차#

1
1️⃣ 기존 미암호화 EBS 볼륨의 스냅샷 생성
2
        │
3
        ▼
4
2️⃣ 스냅샷 복사 시 암호화 옵션 활성화 (Encrypt the EBS snapshot using copy)
5
        │
6
        ▼
7
3️⃣ 암호화된 스냅샷으로 새 EBS 볼륨 생성 (볼륨도 자동으로 암호화됨)
8
        │
9
        ▼
10
4️⃣ 원본 인스턴스에 새 암호화 볼륨 연결

📌 시험 포인트: 미암호화 스냅샷을 복사(Copy)할 때 암호화를 활성화하면 암호화된 스냅샷으로 변환 가능. 암호화된 볼륨의 스냅샷은 항상 암호화됨.

⚡ 개념#

• EC2 인스턴스에 물리적으로 직결된 하드웨어 디스크
• 네트워크 경유 없이 직접 I/O → EBS보다 훨씬 높은 I/O 성능

⚠️ 핵심 제약: 임시 스토리지 (Ephemeral Storage)#

1
인스턴스 중지(Stop) 또는 종료(Terminate) → 데이터 완전 소멸 ❌
2
인스턴스 재부팅(Reboot) → 데이터 유지 ✅

적합한 Use Case:

• 버퍼 (Buffer)
• 캐시 (Cache)
• 임시 데이터 (Scratch data / Temporary content)
• 빠른 읽기/쓰기가 필요한 임시 연산

❌ 데이터베이스, 영구 보관 데이터에는 절대 사용 금지

🖼️ 개념#

• AMI (Amazon Machine Image, 아마존 머신 이미지): EC2 인스턴스의 커스터마이징 템플릿
• OS, 소프트웨어, 설정, 모니터링 에이전트 등을 미리 패키징
• 빠른 부팅/설정: 필요한 소프트웨어가 이미 포함되어 있어 User Data 스크립트 최소화
• 특정 리전에 귀속, 리전 간 복사 가능

📂 AMI 소스 유형#

🛠️ AMI 생성 프로세스#

1
1️⃣ EC2 인스턴스 시작 후 소프트웨어/설정 커스터마이징
2
        │
3
        ▼
4
2️⃣ 인스턴스 중지 (데이터 무결성 보장을 위해 Stop 권장)
5
        │
6
        ▼
7
3️⃣ AMI 빌드 (내부적으로 EBS 스냅샷도 함께 생성)
8
        │
9
        ▼
10
4️⃣ 다른 인스턴스를 해당 AMI로 신속하게 실행

💡 골든 AMI (Golden AMI) 패턴: 표준화된 기업 환경 이미지를 AMI로 만들어 두고, Auto Scaling Group에서 사용. 배포 속도와 일관성 향상.

📁 개념#

• 관리형 NFS (Network File System) — 여러 EC2에 동시에 마운트 가능
• 멀티 AZ에서 동시 접근 가능
• 용량 자동 확장 (페타바이트 규모까지), 사용량 기반 과금 (Pay-per-use)
• Linux 기반 AMI 전용 (Windows 미지원, POSIX 파일시스템)
• NFSv4.1 프로토콜 사용
• 보안 그룹(Security Group)으로 접근 제어
• KMS 기반 저장 데이터 암호화

1
           [EFS]
2
          /  |  \
3
    [EC2]  [EC2]  [EC2]
4
    AZ-1   AZ-2   AZ-3
5
    (동시 마운트 가능, 파일 공유)

주요 Use Case: 콘텐츠 관리(Content Management), 웹 서빙(Web Serving), 데이터 공유, WordPress

⚡ 성능 모드 (Performance Mode)#

EFS 생성 시 설정, 이후 변경 불가

🔄 처리량 모드 (Throughput Mode)#

🗂️ 스토리지 클래스 (Storage Classes)#

라이프사이클 정책(Lifecycle Policy)으로 N일 후 자동 계층 이동

💡 비용 절감: 라이프사이클 정책으로 90% 이상 비용 절감 가능

🌐 가용성 및 내구성 (Availability & Durability)#

EBS vs EFS vs Instance Store#

1
데이터 영속성
2
  영구 ──────────────────────────── 임시
3
  EFS          EBS          EC2 Instance Store
4

5
공유 범위
6
  멀티 인스턴스/멀티 AZ ──────── 단일 인스턴스
7
  EFS              EBS (기본)    Instance Store
8

9
성능
10
  중간           중간~높음       최고 (직결)
11
  EFS             EBS            Instance Store