AWS DVA 항해기 - EC2 인스턴스 스토리지 - EFS

에옹이다아옹·2025년 11월 10일

DVA aws

AWS-DVA

목록 보기

13/21

EFS

같은 리전 내 여러 AZ에 배치된 EC2/ECS/EKS/Lambda가 NFS(2049)로 동시에 마운트하는 공유 파일시스템 / 다른 리전에서 직접 마운트는 불가

EC2는 서로 다른 AZ에 흩어져 있어도 된다

EFS는 “같은 리전” 안이라면 그 여러 AZ의 EC2들이 하나의 EFS를 함께(동시에) 마운트해 쓸 수 있다

=> 즉, 리전(Region) = 서울/도쿄 같은 “큰 구역”, AZ = 그 안의 서로 떨어진 데이터센터 묶음
EFS는 “서울 리전”에 만들면 서울 리전의 AZ들(예: ap-northeast-2a, 2b, 2c) 어디에 있는 EC2든 같은 EFS 폴더를 공유할 수 있음

특징
- 가용성이 높다
- 확장성이 뛰어나다(자동으로 확장됨)
- 비싸다(EBS의 gp2 볼륨의 약 3배)
- 사용량에 따라 비용을 지불(프로비저닝 할 필요가 없음)

다른 AZ에 위치한 인스턴스들을 EFS를 통해 동일한 네트워크 파일 시스템에 동시에 연결 가능

Use Case

콘텐츠 관리
웹 서빙
데이터 공유
Wordpress

EFS에 대한 액세스를 제어하려면 보안 그룹을 설정해야 함

💡 EFS는 윈도우가 아닌 Linux 기반 AMI와만 호환된다 ‼️

보안

EFS는 저장되는 파일·메타데이터를 ‘미사용 상태(at rest)’에서 KMS 키로 자동 암호화할 수 있다
=> 즉, 디스크에 얹힐 때는 암호문, EC2/ECS/EKS/Lambda가 읽을 땐 평문으로 보인다(자동 복호화)

EFS 퍼포먼스

EFS는 수천 개의 NFS 클라이언트가 동시에 붙을 수 있고, 처리량도 10 GiB/s를 넘길 수 있으며, 저장 용량은 자동으로 페타바이트(PB) 규모까지 확장

EFS 성능은 크게 두 축으로 스케일 됨

Performance mode (파일시스템 생성 시 결정)
- General Purpose: 대부분 워크로드, 낮은 지연(ex: 웹 서버, CMS)
- Max I/O: 아주 많은 파일/클라이언트가 동시에 접근하는 대규모 분산 워크로드에서 총 처리량 극대화(지연 다소↑ 가능) (ex: 빅데이터, 미디어 처리)
- 암기: “동시성·파일 수가 엄청 많다” → Max I/O.
Throughput mode (운영 중 변경 가능)
- Bursting(기본(1TB)): 저장 용량에 비례해 기본 처리량 + 버스트 크레딧 제공.
  - 데이터가 작은데 지속 고처리량이 필요하면 크레딧이 바닥날 수 있음
- Provisioned Throughput: 저장 용량과 무관하게 처리량을 고정 예약
  - “작은 용량 + 지속 고성능”에 적합.
- Elastic Throughput: 워크로드 변동을 자동 추적해 처리량을 탄력 적용(운영 단순화, 사용량 기반 과금) => 워크로드를 예측하기 어려울 때 유용

결정법

1) 평균적/보통 패턴 → Bursting(저렴·간편)

2) 작은 데이터 + 상시 고부하 → Provisioned

3) 예측 불가한 변동 → Elastic

IOPS는 처리량에 종속

EFS는 블록 스토리지(EBS)처럼 “고정 IOPS”를 잡는 모델이 아님

작은 IO가 많으면 IOPS 수요가 커지고, 큰 IO는 처리량(Throughput) 한도에 더 민감

필요 시 Provisioned/Elastic로 처리량을 확보하고, 클라이언트 측 NFS 파라미터(rsize/wsize), 병렬성, 워커 수로 실효 IOPS를 끌어올림

EFS 스토리지 클래스

? Storage tiers

=> 파일 접근 빈도에 따라 다른 등급(클래스)로 자동 이동시키는 기능을 말하고, 며칠(정책) 후 IA/Archive로 내리거나, 접근 시 다시 Standard로 올리는 것까지 설정

가용성(위치) 축 — “어디에 저장하느냐”

Standard (Regional):
- 자주 액세스하는 파일을 위한 계층
- 다중 AZ 설정이 있는 경우 내구성·가용성 측면에서 볼 때 사용하는 것이 좋음
One Zone:
- 단일 AZ에 저장 → 더 저렴/낮은 지연 가능하지만 AZ 장애 리스크↑ (백업 필수 권장: 백업은 기본적으로 활성화하도록 설정되어 있음)
- 액세스 빈도가 낮은 스토리지 계층과 호환됨

접근 빈도(Access) 축 — “얼마나 자주 읽히느냐”

Frequent Access: 자주 접근하는 데이터에 맞춘 등급(기본)
IA (Infrequent Access):
드물게 접근하는 파일용
요청/조회 비용(파일 검색) 비용이 발생하지만 저장하면 비용이 감소함
최소 보관 기간 요금(예: ~30일)이 적용될 수 있음
Archive:
거의 액세스하지 않는 데이터용(1년에 몇 번 정도) 50% 정도 저렴

전반적으로 올바른 EFS 스토리지 클래스를 사용하면 최대 90%의 비용 절감 가능

EFS 실습

VPC는 default로 진행하되 Customize로 옵션을 살펴보겠다

Regional을 선택하면 다중 AZ가 지원된다

하지만 One Zone을 선택하면 AZ를 하나 특정해야 함

백업은 활성화된 채로 유지하는 것이 좋음

IA나 아카이브로 전환했다가 다시 스탠다드로 전환 가능

ex) 30일동안 파일에 액세스 하지 않으면 IA로 이동 / 90일동안 액세스하지 않으면 아카이브로 이동

Enhanced => elastic과 Provisioned을 그룹화하는 카테고리에 불과함

Elastic: 트래픽에 맞춰 자동으로 처리량을 확장/과금(스파이크/예측 어려운 워크로드에 적합)
Provisioned: 용량과 무관하게 처리량을 고정 예약(지속 고처리량, 예측 가능한 워크로드)
Bursting: 파일시스템 크기와 버스트 크레딧에 비례해 처리량 제공(기본값, 단 단발성 피크 중심)

EFS의 “버스트 크레딧(Burst Credits)”이란?

Bursting 처리량 모드에서만 쓰이는 토큰 같은 개념이야.

파일시스템마다 용량(저장한 데이터 양)에 비례한 기본 처리량(베이스라인)이 있음

네 I/O가 이 베이스라인보다 낮게 쓰일 때는 크레딧이 쌓이고,
베이스라인보다 높게 쓰고 싶을 때는 크레딧을 소모해서 일시적으로 더 빠르게 달릴 수 있어.

흐름 요약

한가할 때(트래픽↓) → 베이스라인 이하 사용 → 크레딧 적립

바쁠 때(트래픽↑) → 베이스라인 초과 사용 → 크레딧 사용해 고처리량 버스트

크레딧 소진 → 다시 베이스라인 속도로 제한(성능이 확 느려진 느낌)

포인트: 저장 용량이 작을수록 베이스라인이 낮아 크레딧을 빨리 다 써버릴 수 있음

반대로 용량이 클수록(몇 TiB 이상) 베이스라인 자체가 높아 버스트 없이도 꽤 오래 빠르게 버틸 수 있음

us-ease-? 존에 대한 EFS 네트워크 설정

EFS를 위한 SG(Security Group) 만들어주기

그 다음 단계들은 선택 사항이라서 건너뛰고 Create File system 클릭

잘 생성된 것 확인 가능

EC2 인스턴스에 EFS를 연결해볼건데 Instance 생성시

우측 하단 부 "Edit" 버튼 클릭

네트워크 설정에서 Subnet을 설정해줘야 EFS 연동 가능

Instance A로 이름을 지어서 us-east-1a를 선택했다

Add shared file system 클릭

Automatically mount shared file system by attaching required user data script

=> EC2를 띄울 때 “유저 데이터(User data) 스크립트”를 자동으로 붙여서 EFS를 부팅 시점에 알아서 마운트해 주는 옵션

유저 데이터 스크립트가 EC2 첫 부팅 때 자동 실행되어 아래 작업 실시

필요 패키지 설치

amazon-efs-utils(또는 NFS 클라이언트) 설치
마운트 지점 준비

예: mkdir -p /mnt/efs
마운트 수행(보통 TLS 포함)

예: mount -t efs -o tls fs-XXXX:/ /mnt/efs

Access Point를 쓰면 fs-XXXX:AP-YYYY:/ 형태로 마운트

/etc/fstab 등록(부팅 시 자동 마운트)
재부팅해도 자동으로 붙도록 엔트리를 추가

예: fs-XXXX:/ /mnt/efs efs _netdev,tls 0 0