AWS Certified Solutions Architect - Associate (SAA-C03) #11 Domain 3-3 고성능 아키텍처: 스토리지 선택
#10 캐싱에 이어, 이번에는 데이터를 어떤 스토리지에 둘 것인가를 다룹니다. AWS 스토리지 선택은 먼저 블록,파일,객체 세 유형을 가르고, 그 안에서 성능,공유,비용 요건에 맞는 서비스를 고르는 순서입니다.
세 가지 스토리지 유형 #
| 유형 | 서비스 | 접근 방식 | 비유 |
|---|---|---|---|
| 블록(Block) | EBS | 인스턴스에 디스크로 연결 | 컴퓨터에 꽂은 하드디스크 |
| 파일(File) | EFS, FSx | 네트워크 파일 시스템(공유) | 공용 네트워크 드라이브 |
| 객체(Object) | S3 | API/HTTP로 객체 단위 | 무한한 파일 보관함 |
첫 갈림길은 **“하나의 인스턴스용 디스크(EBS)인가, 여러 인스턴스가 공유하는 파일 시스템(EFS/FSx)인가, 객체 저장(S3)인가”**입니다.
EBS: 블록 스토리지 #
EBS는 EC2 인스턴스에 연결하는 블록 볼륨입니다. 기본적으로 하나의 AZ에 속하고 하나의 인스턴스에 연결됩니다(여러 AZ가 공유하는 스토리지가 아닙니다). 볼륨 타입은 워크로드에 따라 고릅니다.
| 타입 | 분류 | 적합 |
|---|---|---|
| gp3 / gp2 | 범용 SSD | 대부분의 워크로드, 부팅 볼륨 |
| io2 / io1 | 프로비저닝 IOPS SSD | 고 IOPS,고성능 DB |
| st1 | 처리량 최적화 HDD | 빅데이터, 로그 처리(순차 접근) |
| sc1 | 콜드 HDD | 자주 안 쓰는 대용량(최저가) |
“고 IOPS가 필요한 데이터베이스"는 io2, “큰 순차 처리량(로그,빅데이터)“은 st1, 일반적이면 gp3입니다.
EFS: 공유 파일 시스템(Linux) #
EFS는 여러 EC2 인스턴스가 여러 AZ에서 동시에 마운트하는 관리형 NFS입니다. 용량이 자동으로 늘고 줄며, Linux 워크로드의 공유 파일 시스템에 적합합니다. “여러 인스턴스가 같은 파일을 공유해야 한다"는 요구사항의 기본 답입니다.
- 스토리지 클래스. Standard, IA(저접근), One Zone(단일 AZ,저비용)
- 자주 접근하지 않는 파일을 IA로 자동 이동해 비용을 낮출 수 있습니다.
FSx: 특수 목적 파일 시스템 #
FSx는 특정 워크로드에 맞춘 관리형 파일 시스템입니다. 시험에는 주로 두 가지가 나옵니다.
| FSx 종류 | 프로토콜/용도 |
|---|---|
| FSx for Windows File Server | SMB, Windows 환경의 공유 파일(AD 연동) |
| FSx for Lustre | HPC,ML 등 고처리량,고성능 컴퓨팅 |
“Windows의 SMB 파일 공유"는 FSx for Windows, “HPC,머신러닝의 초고처리량 파일 시스템"은 FSx for Lustre입니다. (이 외에 NetApp ONTAP, OpenZFS도 있습니다.)
S3 스토리지 클래스 #
S3는 객체 스토리지이며, 접근 빈도와 복구 시간에 따라 클래스를 고릅니다. 클래스 선택이 비용 문항의 핵심입니다.
| 클래스 | 접근 빈도 | 특징 |
|---|---|---|
| Standard | 잦음 | 기본. 즉시 접근 |
| Intelligent-Tiering | 모름/변동 | 접근 패턴에 따라 자동 계층 이동 |
| Standard-IA | 드묾 | 저장 저렴, 검색 수수료. 다중 AZ |
| One Zone-IA | 드묾 | 더 저렴, 단일 AZ(내구성 낮음) |
| Glacier Instant Retrieval | 아카이브 | 즉시 접근 가능한 아카이브 |
| Glacier Flexible Retrieval | 아카이브 | 분~시간 단위 복구 |
| Glacier Deep Archive | 장기 보관 | 최저가, 복구 ~12시간 |
- 접근 패턴을 모르겠다 → Intelligent-Tiering(자동 최적화)
- 가끔 쓰지만 즉시 접근 필요 → Standard-IA(또는 Glacier Instant Retrieval)
- 거의 안 쓰는 장기 보관, 복구 느려도 됨 → Glacier Deep Archive(최저가)
- One Zone-IA는 단일 AZ라 그 AZ 장애 시 데이터를 잃을 수 있어, 재생성 가능한 데이터에만 적합합니다.
수명 주기 정책(Lifecycle) #
수명 주기 규칙으로 객체를 시간이 지남에 따라 자동으로 더 싼 클래스로 이동하거나 만료시킵니다. 예: “30일 후 Standard-IA로, 90일 후 Glacier로, 365일 후 삭제.” #8 백업의 버전 관리와 결합해 오래된 버전을 저비용으로 보관합니다.
시험 출제 패턴 #
- “여러 EC2가 공유하는 파일 시스템(Linux).” → EFS
- “Windows SMB 공유.” → FSx for Windows File Server
- “HPC/ML 고처리량 파일 시스템.” → FSx for Lustre
- “단일 인스턴스 고 IOPS 블록.” → EBS io2
- “접근 패턴을 모름, 자동 비용 최적화.” → S3 Intelligent-Tiering
- “최저 비용 장기 보관, 복구 12시간 OK.” → Glacier Deep Archive
- “오래된 객체를 자동으로 저비용 이동.” → S3 수명 주기 정책
자주 만나는 함정 #
1) EBS를 여러 인스턴스,여러 AZ가 공유한다고 생각 #
EBS는 기본적으로 단일 AZ,단일 인스턴스용입니다. 공유 파일 시스템은 EFS입니다.
2) One Zone-IA의 내구성을 간과 #
One Zone-IA는 단일 AZ에만 저장되어 AZ 장애 시 손실 위험이 있습니다. 중요한 원본 데이터에는 부적합합니다.
3) Glacier 클래스의 복구 시간 차이를 무시 #
Glacier Instant은 즉시, Deep Archive는 ~12시간입니다. “즉시 접근"이 단서면 Deep Archive는 오답입니다.
4) Windows 공유에 EFS를 권한다 #
EFS는 Linux NFS입니다. Windows SMB 공유는 FSx for Windows입니다.
정리 #
이번 글에서 잡은 것:
- 세 유형: 블록(EBS) , 파일(EFS,FSx) , 객체(S3). 공유 여부가 첫 갈림길
- EBS. 단일 AZ,단일 인스턴스. io2(고 IOPS) , st1(처리량) , gp3(범용)
- EFS(Linux 공유 NFS) vs FSx(Windows SMB / Lustre HPC)
- S3 클래스. Standard , Intelligent-Tiering(패턴 모름) , IA , Glacier(아카이브, Deep는 최저가,느림)
- 수명 주기 정책으로 자동 비용 최적화
다음: Domain 3-4 DB 선택 #
스토리지를 잡았으니, 고성능 도메인의 마지막으로 데이터베이스 선택을 다룹니다.
#12 Domain 3-4 DB 선택에서는 RDS의 Multi-AZ(고가용성)와 읽기 복제본(읽기 확장)의 차이, 클라우드 네이티브 Aurora, NoSQL DynamoDB, 그리고 분석용 Redshift까지 워크로드에 맞는 데이터베이스 선택을 정리하겠습니다.