AWS에서 컨테이너를 여러 서버에 배치한 뒤 업로드 파일이 어느 서버에서는 보이고 다른 서버에서는 보이지 않는다면 저장소의 공유 방식부터 확인해야 합니다. 한 서버가 사용하는 디스크가 필요하면 EBS를, 여러 실행 환경이 같은 파일 경로를 읽고 써야 하면 EFS를 후보로 검토할 수 있습니다. 두 서비스는 용량 단가만으로 비교하기보다 애플리케이션이 블록 장치와 네트워크 파일 시스템 중 무엇을 요구하는지 먼저 구분해야 합니다.
1. EBS는 블록 저장소, EFS는 공유 파일 저장소입니다
Amazon EBS 공식 문서에서 EBS는 EC2에 연결하는 블록 장치로 설명합니다. 볼륨과 인스턴스는 같은 가용 영역(AZ)에 있어야 하며, 운영체제에서 파일 시스템을 구성해 디스크처럼 사용합니다. 한 인스턴스의 데이터 디렉터리나 데이터베이스 저장 장치처럼 해당 환경에서 직접 디스크를 관리하는 용도에 맞춰 검토할 수 있습니다.
Amazon EFS 공식 문서의 EFS는 NFS 기반 파일 저장소입니다. 여러 클라이언트가 네트워크를 통해 같은 파일을 이용할 수 있지만, 동시에 같은 파일을 덮어쓸 때의 충돌 처리와 애플리케이션 잠금 설계까지 자동으로 대신하지는 않습니다. 공유 디렉터리가 생기는 것과 애플리케이션의 동시 작업이 안전해지는 것은 별도의 확인 항목입니다.
| 항목 | EBS | EFS |
|---|---|---|
| 접근 형태 | EC2에 연결하는 블록 장치 | NFS로 접근하는 파일 시스템 |
| 공유 요구 | 보통 한 인스턴스의 디스크로 검토 | 여러 클라이언트가 같은 파일 경로 이용 |
| 배치 범위 | 볼륨과 인스턴스가 같은 AZ | Regional 또는 One Zone 선택 |
| 운영 점검 | 파일 시스템·용량·IOPS·복구 | 마운트·네트워크·파일 권한·복구 |
2. EBS Multi-Attach를 일반 공유 폴더로 보면 안 됩니다
EBS가 언제나 한 대에만 연결된다고 단정하면 Multi-Attach 예외를 놓칩니다. 지원되는 io1·io2 볼륨은 같은 AZ의 여러 인스턴스에 연결할 수 있지만 조건이 있습니다. AWS는 일반적인 EXT4·XFS가 여러 서버의 동시 접근을 위해 설계된 파일 시스템이 아니라고 설명합니다. 공유 쓰기를 조정하는 파일 시스템과 애플리케이션 구성이 필요합니다.
예를 들어 웹 서버 두 대의 업로드 디렉터리를 공유하려고 같은 디스크를 양쪽에서 일반 파일 시스템으로 마운트하는 방식은 EFS의 대체 구성이 아닙니다. 반대로 한 서버에서만 사용하는 데이터 디스크라면 공유 기능 때문에 EFS를 도입할 필요가 있는지 다시 검토할 수 있습니다. 저장소를 결정하기 전에 “여러 서버가 같은 파일을 실제로 함께 수정하는가?”를 질문하세요.
3. 비용은 저장량·성능·접근량을 분리해 비교하세요
EBS 요금 안내에서는 gp3의 할당 용량과 기본 제공 성능을 넘는 IOPS·처리량을 구분합니다. EFS 요금 안내에서는 저장 클래스, 처리량 모드, 읽기·쓰기·계층 이동, 백업과 전송을 살펴봐야 합니다. EFS의 모든 읽기·쓰기에 한 가지 단가가 적용되는 것으로 단순화하지 말고 선택한 모드의 과금 구조를 확인하세요.
다음은 견적을 준비하기 위한 가상 입력 예입니다. 현재 파일은 300GB인데 EBS에는 성장 여유를 포함해 500GB를 할당했다고 가정합니다. EBS 견적에는 할당한 500GB와 필요한 성능을, EFS 견적에는 저장 클래스별 사용량과 한 달의 접근·처리량을 넣습니다. 300과 500만 비교해 절감률을 계산할 수는 없습니다. 파일 요청이 많거나 다른 AZ의 마운트 대상으로 접근하면 추가 항목이 결론을 바꿀 수 있습니다.
- 같은 리전·같은 가용성 목표·같은 백업 보존 기간으로 견적 조건 맞추기
- EBS: 할당 용량, 볼륨 유형, 추가 IOPS·처리량, 스냅샷 항목 확인
- EFS: Regional/One Zone, 저장 클래스, 처리량 모드, 접근·계층 이동 항목 확인
- 클라이언트와 마운트 대상의 AZ, 복제·백업·복원에 따른 비용 확인
요금표의 리전과 작성 시점을 함께 기록해야 합니다. 이 글은 2026년 10월 3일 확인한 공식 과금 항목을 기준으로 하며 특정 원화 금액이나 절감률을 보장하지 않습니다.
4. 컨테이너 업로드 파일은 요구사항에 따라 선택이 달라집니다
가상의 콘텐츠 서비스가 두 AZ에 웹 서버를 운영하고, 기존 코드가 /uploads/report.pdf 같은 파일 경로를 열어 읽고 쓰는 상황을 생각해 보겠습니다. 코드가 공유 파일 시스템을 전제로 한다면 Regional EFS를 검증할 이유가 있습니다. 클라이언트별 경로와 사용자 ID를 나누고, 동일 파일의 중복 생성·수정이 생겼을 때 동작을 시험해야 합니다.
파일을 객체 키와 다운로드 URL로 다룰 수 있다면 S3 같은 객체 저장소도 비교 대상입니다. EFS는 일반 공개 다운로드 URL을 발급하는 객체 서비스와 역할이 다릅니다. 데이터베이스 파일은 해당 엔진과 배포 방식이 지원하는 저장소, 지연 시간과 장애 복구 요구사항을 먼저 따르세요. 파일 공유가 가능하다는 이유만으로 데이터베이스 디렉터리를 옮기지는 않습니다.
실행 환경의 책임 범위는 ECS Fargate와 EC2 선택 기준을, 객체 저장소로 전환하는 선택은 S3와 Cloudflare R2 비교를 함께 보면 정리하기 쉽습니다.
5. 이전 전에 마운트·권한·복구를 검증하세요
EFS DNS 마운트 안내에서는 파일 시스템 DNS 이름을 사용하는 경우 클라이언트와 같은 AZ의 마운트 대상이 필요하다고 설명합니다. 보안 그룹의 NFS 접근과 VPC DNS 조건을 확인하고, 실제 배치 위치에서 마운트가 되는지 점검하세요. EFS 액세스 포인트는 애플리케이션별 루트 경로와 POSIX 사용자·그룹 ID를 적용하는 데 사용할 수 있습니다. 네트워크 연결과 파일 쓰기 권한은 각각 확인해야 합니다.
- 시험 디렉터리에서 실제 컨테이너 사용자로 파일 생성·읽기·이름 변경·삭제 확인
- 작은 파일 다수와 큰 파일 전송을 나눠 응답 시간·처리량·오류율 기록
- 여러 프로세스의 동시 쓰기와 재배포 후 파일 유지 여부 확인
- 쓰기 중지 또는 일관성 확보 절차를 정한 뒤 복사·크기·개수·검증값 비교
- 백업에서 별도 경로로 복원하고 실제 애플리케이션이 읽는지 확인
복제나 다중 AZ 구성은 실수로 삭제한 파일을 원하는 시점으로 되돌리는 백업 절차와 구별해야 합니다. 전환 직후 기존 저장소를 지우지 말고, 검증과 되돌리기 조건을 마련한 뒤 운영 정책에 따라 정리하세요. 위 예시는 설계 검토용이며 실제 AWS 계정에서 수행한 성능 시험 결과가 아닙니다.
6. 자주 묻는 질문
EFS를 쓰면 EBS를 전부 없앨 수 있나요?
아닙니다. 운영체제 디스크나 개별 인스턴스의 블록 저장소 요구와 공유 파일 요구를 나눠 판단해야 합니다. 두 서비스를 함께 사용하는 구성도 가능합니다.
EFS는 모두 다중 AZ에 저장되나요?
Regional과 One Zone의 범위가 다릅니다. 여러 클라이언트에서 접근할 수 있다는 사실만으로 One Zone의 데이터가 여러 AZ에 복제된다고 해석하면 안 됩니다.
공유 파일이 필요하면 EFS가 항상 더 저렴한가요?
접근 패턴·처리량·리전·백업·네트워크·운영 부담에 따라 달라집니다. 같은 기능과 복구 목표를 만족하는 전체 비용으로 비교해야 합니다.
확인 기준: 2026-10-03. 제품 제약과 과금 조건은 위 공식 문서를 확인하세요. 선택 예시는 일반적인 요구사항을 설명하기 위한 가정입니다.
'소프트웨어개발' 카테고리의 다른 글
| Amazon SES와 SendGrid 비교: 인증·주문 메일 발송 비용과 운영 기준 (0) | 2026.10.04 |
|---|---|
| Nginx 499 Client Closed Request 해결: 요청 취소·시간 제한·백엔드 지연 점검 (0) | 2026.10.01 |
| Docker exec format error 해결: amd64·arm64·멀티플랫폼 이미지 점검 (0) | 2026.10.01 |
