AWS) Amazon EFS, EBS와 EFS 차이점

SMALL

안녕하세요, 코린이의 코딩 학습기 채니 입니다.
"유데미" AWS 강의를 참고하여 포스팅한 개인 공부 내용입니다.

→ 관리형 NFS (네트워크 파일 시스템)

→ 많은 EC2 인스턴스에 마운트 가능, AZ가 다른 EC2 인스턴스에서도 가능

→ 가용성이 높고, 확장성 뛰어남 (비용도 gp2 EBS 볼륨의 3배..)

✅ NFS 프로토콜이란?
→ 네트워크에 파일을 저장하는 매커니즘

✅ KMS(Key Management Service)란?

→ 암호키를 쉽게 생성하고 제어해주는 관리형 서비스

사용 사례

성능 및 스토리지 클래스

EFS Scale
- 수천 개의 동시 NFS 클라이언트와 10GB 이상 처리량
- 페타바이트 규모의 네트워크 파일 시스템으로 자동 확장 가능

General Purpose (범용)
- 웹 서버, CMS 등 지연 시간에 민감한 경우 사용
Max I/O
- 처리량 최대화할 때 사용
- 지연 시간이 더 길지만, 처리량이 크고 병렬성이 높음
- 빅데이터 애플리케이션, 미디어 처리 필요한 경우 유용
처리량 모드
- 버스팅
- 프로비저닝 → 스토리지 크기에 상관 없이 처리량 설정 가능 (처리량을 알고 있을 때 유용, 미리 비용 지불)
- 엘라스틱 → 워크로드에 따라 처리량 자동 확장 가능 (워크로드 예측할 수 없을 때 유용)

스토리지 계층 (며칠 후 파일을 다른 계층으로 옮길 수 있음)
- 스탠다드 → 자주 액세스하는 파일을 위한 계층
- EFS-IA
  → 자주 액세스 하지 않는 계층
  → 파일 검색 시 검색 비용이 발생 (파일을 EFS-IA에 저장하면 비용 낮아짐)
  → 생명 주기 정책 사용해야 함

⭐️ 이해가 쉽도록 예제

EFS 스탠다드 계층에 파일들이 A, B, C 파일이 들어있다고 가정해보자!

해당 파일 중 C 파일이 60일 동안 액세스하지 않았을 때, 함께 설정한 생명 주기 정책에 따라서 해당 파일은 자주 액세스 하지 않는 계층인 EFS-IA로 이동하여 비용을 절감할 수 있음!

가용성과 내구성
- Regional (스탠다드)
  → 다중 AZ로 설정 가능
  → 가용 영역이 다운되더라도 EFS 파일 시스템 영향 주지 않음 (프로덕션 환경에서 유용)
- One Zone-IA
  → 개발 환경에서 유용
  → 하나의 AZ에만 있고, 백업은 기본적으로 설정되어 있음
  → EFS-IA와 호환되지 않음

만약에

가용 영역 단위에 묶임 (가용 영역에 있는 수백 개의 인스턴스와 연결 가능)
- 하나의 EFS 파일 시스템의 마운트 대상 → 여러 가용 영역에 있는 인스턴스들
  따라서 여러 인스턴스가 하나의 파일 시스템 공유 가능 (WordPress 유용)
POSIX 시스템 사용하므로, 리눅스 인스턴스와만 연결
EBS보다 비용이 높지만, EFS-IA 기능 이용 시 비용 절감 가능

LIST

관련글