Amazon EFS vs Amazon S3 언제 무엇을 써야 할까?

Amazon EFS vs Amazon S3: 언제 무엇을 써야 할까?

AWS에서 스토리지를 고를 때 가장 자주 마주치는 고민 중 하나가 EFS(Elastic File System) 와 S3(Simple Storage Service) 중 무엇을 써야 하냐는 겁니다.
둘 다 “저장소”이긴 한데, 근본적으로 다른 종류의 스토리지라서 목적에 따라 선택이 완전히 갈립니다.

이 글에서는 개념 → 기술 차이 → 성능/비용 → 대표 사용 사례 → 선택 가이드 순서로 정리합니다.

---

1. 한 줄 정의

• Amazon EFS: 여러 서버가 동시에 붙어 쓰는 공유 파일 시스템(NFS 기반, POSIX 호환)
• Amazon S3: HTTP/SDK로 접근하는 객체(Object) 스토리지

공유 디스크냐(파일 시스템), 대용량 오브젝트 저장소냐가 핵심 차이입니다. :contentReference[oaicite:0]{index=0}

---

2. 저장 방식의 차이

EFS: “파일 시스템”

• POSIX 호환 디렉터리/파일 구조
• EC2/ECS/EKS/Lambda 등이 NFS로 마운트해서 로컬 디스크처럼 사용
• 다수의 클라이언트가 같은 디렉터리/파일을 동시에 읽고 쓰는 공유 스토리지 :contentReference[oaicite:1]{index=1}

앱 입장에선:

# EC2에서 EFS 마운트 예시
sudo mount -t nfs4 <efs-endpoint>:/ /mnt/efs

이후 /mnt/efs/app.log 같은 방식으로 일반 파일 I/O를 합니다.

---

S3: “오브젝트 스토리지”

• “폴더”가 아니라 버킷 + 오브젝트(key) 구조
• REST API/SDK로 접근
• 저장 단위는 파일이 아니라 오브젝트
• 스토리지 클래스(Standard, IA, Glacier 등) 로 비용/성능을 선택 가능 (Amazon Web Services, Inc.)

앱 입장에선:

s3Client.putObject(
    PutObjectRequest.builder()
        .bucket("my-bucket")
        .key("images/a.png")
        .build(),
    RequestBody.fromFile(Paths.get("a.png"))
);

---

3. 접근/네트워크 모델

항목	EFS	S3
접근 방식	NFS 마운트 (파일 I/O)	HTTP API (객체 요청)
사용 느낌	“공유 디스크”	“클라우드 저장소/웹 스토리지”
동시 접근	여러 서버가 같은 파일 읽기/쓰기	여러 클라이언트가 동일 오브젝트 read/write (overwrite는 전체 교체)
지연/성격	파일시스템형 저지연 I/O 지향	요청 기반 지연, 대규모 병렬 처리 지향

---

4. 성능 특성

EFS 성능 포인트

• 성능 모드: General Purpose / Max I/O
• 처리량 모드: Bursting / Provisioned / Elastic Throughput
• 워크로드와 파일 시스템 설정에 따라 지연, IOPS, Throughput이 스케일링 (AWS Docs)
• NFS 특성상 메타데이터·작은 파일·공유 워크로드에 강함

S3 성능 포인트

• 사실상 “무제한”에 가까운 확장성
• 대용량/대량 병렬 요청에 최적화
• 멀티파트 업로드, prefix 분산 등으로 고성능 구성 가능
• 다양한 스토리지 클래스로 비용/성능을 자유롭게 조절 (Amazon Web Services, Inc.)

체감으로 정리하면:

• “서버가 디스크처럼 계속 읽고 쓰는 워크로드”는 EFS
• “오브젝트를 저장해두고 필요할 때 가져오는 워크로드”는 S3

---

5. 비용 구조

단가는 리전/클래스별로 변하니 비용이 발생하는 방식만 보세요.

EFS 비용

• 저장 용량(GB-month) 기준 과금
• Elastic/Provisioned Throughput, IA/Archive 접근/티어링 비용 등이 추가될 수 있음 (Amazon Web Services, Inc.)
• 접근/처리량이 높은 워크로드면 비용이 커질 수 있음

S3 비용

• 저장 용량 + 요청 수(GET/PUT 등) + 데이터 전송
• 대신 스토리지 클래스로 장기보관 비용을 크게 낮출 수 있음 (Amazon Web Services, Inc.)
• 대규모 저장/백업/로그는 S3가 거의 항상 유리

---

6. 대표 사용 사례

EFS가 딱 맞는 경우

• 여러 인스턴스가 동시에 접근하는 공유 디렉터리
• 컨테이너/서버팜에서 공통 파일 읽기/쓰기
• ML/배치 작업에서 “POSIX 파일 시스템”이 꼭 필요한 경우
• 웹서버 다중화에서 공용 업로드 디렉터리 (jranke 님의 블로그)

S3가 딱 맞는 경우

• 이미지/동영상/문서 등 대규모 정적 파일 저장
• 백업/아카이브/로그 적재
• 데이터 레이크/분석/ETL 원본 저장소
• CDN(CloudFront) 앞단 저장소 (아주 쉽게 정리한 블로그)

---

7. 선택 가이드 (실전 체크리스트)

아래 질문에 답하면 거의 결정됩니다.

1. 애플리케이션이 파일 시스템이 필요해?

   • open()/read()/write() 같은 로컬 파일 I/O가 전제라면 → EFS

2. 데이터가 몇 TB~PB까지 커질 수 있어?

   • 대규모 확장/저장 효율이 핵심이면 → S3

3. 여러 서버가 같은 파일을 동시에 쓰고 읽어야 해?

   • 공유 디렉터리/파일 단위 협업이면 → EFS

4. 장기보관/저장 비용 최소화가 중요해?

   • 스토리지 클래스/라이프사이클로 최적화하고 싶으면 → S3

---

8. 아키텍처 예시

예시 A: 멀티 EC2 웹서버 업로드 공유

• 업로드 디렉터리 /uploads 를 모두가 공유해야 함 → EFS

EC2 A ─┐
EC2 B ─┼─ (mount) ─ EFS ─ /uploads
EC2 C ─┘

예시 B: 서비스 이미지/백업/로그 저장

• 대용량, 히스토리 보관, 저비용 장기 저장 → S3

App → S3 bucket → (lifecycle) IA/Glacier

---

9. 결론

• EFS는 “공유 파일 시스템”
• S3는 “대규모 객체 저장소”

둘은 경쟁 관계라기보다 서로 다른 레이어에 있는 서비스입니다. 실제로는 한 서비스에서 EFS + S3를 같이 쓰는 패턴이 가장 흔합니다.

---

10. 실전 사례: 레거시 시스템과 MSA 환경에서 EFS + S3 하이브리드 전략

배경: 왜 EFS와 S3를 함께 사용하게 되었나?

많은 기업이 레거시 시스템을 운영하면서 동시에 클라우드로 전환하는 과정에서 비슷한 고민을 합니다. 다음은 전자문서, 전자세금계산서, 팩스 서비스를 MSA로 전환하는 과정에서 설계한 실제 아키텍처입니다.

아키텍처 개요

Classic ASP (레거시)
  ├─→ EFS (파일 직접 저장)
  └─→ MSA API 호출 (DB 처리, 메타데이터)
         ↓
    MSA Services (Java)
      - 전자문서
      - 전자세금계산서
      - 팩스
      - 카카오톡
      - 문자
         ↓
    file-manager (Go)
         ↓
      Amazon S3

설계 결정의 핵심 이유

1. 레거시 호환성 - 관심사의 분리

문제: Classic ASP에는 S3 SDK가 없고, 기존 코드가 NAS(파일 시스템) 방식으로 작성되어 있음

해결: 파일 처리와 비즈니스 로직을 분리

' 1. 파일은 EFS에 직접 저장 (기존 로직 유지)
Set upload = Server.CreateObject("Component.Upload")
filePath = Server.MapPath("/uploads/file.pdf")
upload.Save(filePath)  ' EFS 마운트 포인트

' 2. MSA API 호출 (DB 처리: 문서 정보, 상태, 메타데이터 등)
Set xmlHttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlHttp.open "POST", "http://msa-service/api/documents", False
xmlHttp.send jsonData

핵심:

• 파일 I/O: EFS (Classic ASP 코드 변경 최소화)
• 비즈니스 로직: MSA (DB insert/update, 상태 관리, 알림 등)
• 스토리지 최적화: file-manager가 백그라운드에서 EFS → S3 이동

2. MSA 전환 전략 (Strangler Fig Pattern)

문제: 모든 서비스를 한 번에 바꿀 수 없고, 점진적 마이그레이션 필요

해결:

• 레거시: EFS에 업로드 (기존 방식)
• MSA: DB 처리 + S3 마이그레이션 담당
• 위험 최소화하며 단계적 전환

3. 중앙 집중식 파일 관리 (API Gateway 패턴)

여러 MSA 서비스가 file-manager(Go)를 통해 S3 작업을 수행:

// edoc MSA (Java) 서비스 예시
@Override
public S3ObjectVo fileToS3(String bucket, Path sourcePath, Path destPath) {
    Map<String, String> requestBody = new HashMap<>();
    requestBody.put("bucket", bucket);
    requestBody.put("sourcePath", sourcePath.toString().replaceAll("[/\\\\]", "/"));
    requestBody.put("destPath", destPath.toString().replaceAll("[/\\\\]", "/"));

    URI uri = new DefaultUriBuilderFactory().builder()
        .path("/api/s3")
        .build();

    ApiResponse<S3ObjectVo> response = fileManagerApiRequester.post(
        uri.toString(),
        requestBody,
        S3ObjectVo.class
    );

    if (!response.getCode().equals("OK")) {
        throw new BusinessException(response);
    }

    return response.getData();
}

이 설계의 장점:

1. 횡단 관심사 중앙화
   • 바이러스 스캔, 암호화, 썸네일 생성 등을 file-manager에서 한 번만 구현
   • 모든 서비스(카카오톡, 문자, 전자문서, 팩스)에 자동 적용
2. 정책 일관성
   • 모든 서비스가 동일한 파일 관리 규칙 준수
   • 개인정보보호법, GDPR 등 규정 준수를 한 곳에서 관리
3. 기술 스택 독립성
   • Classic ASP, Java, 향후 Python/Node.js 등 언어 무관
   • REST API로 통신하므로 서비스 간 결합도 낮음
4. 운영 효율
   • S3 정책 변경 시 file-manager만 수정
   • 스토리지 마이그레이션 시 각 서비스 코드 수정 불필요

4. 비용 최적화

전략:

• 즉시 접근 필요: EFS (빠른 I/O)
• 장기 보관: S3 Standard → Intelligent-Tiering → Glacier

비용 절감 포인트:

• 전자문서/세금계산서는 법정 보관 의무 기간이 있음
• S3 Lifecycle 정책으로 자동 티어링
• 온프렘 스토리지 대비 TCO 절감

운영 고려사항

1. 비동기 처리 (권장)

// 동기: 사용자가 S3 이동 완료까지 대기
S3ObjectVo result = fileToS3(bucket, sourcePath, destPath);

// 비동기: 즉시 응답, 백그라운드 처리
@Async
public CompletableFuture<S3ObjectVo> fileToS3Async(...) {
    // 메시지 큐 또는 비동기 작업
}

2. EFS 정리 전략

@Scheduled(cron = "0 0 2 * * ?") // 매일 새벽 2시
public void cleanupEfsFiles() {
    // S3 이동 완료된 파일은 EFS에서 삭제
    // 예: 7일 이상 된 파일 중 S3 백업 완료 확인 후 삭제
}

3. 장애 복구

// file-manager 장애 시 재시도
@Retryable(maxAttempts = 3, backoff = @Backoff(delay = 5000))
@CircuitBreaker(name = "file-manager", fallbackMethod = "fallbackFileToS3")
public S3ObjectVo fileToS3(...) {
    // ...
}

// fallback: 일시적으로 EFS에만 저장, 나중에 배치로 S3 이동
public S3ObjectVo fallbackFileToS3(...) {
    // 큐에 적재 후 복구 시 재처리
}

4. 모니터링 체크리스트

• EFS 디스크 사용량: CloudWatch 알림 설정
• S3 이동 실패 건: Dead Letter Queue 모니터링
• 이동 소요 시간: 평균/P99 메트릭 추적
• file-manager 가용성: Circuit Breaker 상태 모니터링

확장 로드맵

향후 file-manager에 추가할 기능:

// 대용량 파일 비동기 업로드
POST /api/s3/async
GET  /api/s3/status/{jobId}

// 멀티파트 업로드
POST /api/s3/multipart/init
POST /api/s3/multipart/upload
POST /api/s3/multipart/complete

// 메타데이터 조회
GET  /api/files/{key}/metadata

// 이벤트 발행 (다른 서비스 구독)
fileUploaded -> EventBus
fileDeleted -> EventBus

핵심 교훈

1. 레거시와 클라우드의 공존: EFS를 브릿지로 활용
2. 점진적 마이그레이션: 리스크 없이 단계적 전환
3. 중앙화된 파일 관리: 일관성과 유지보수성 확보
4. 적재적소 활용: EFS(즉시 I/O) + S3(장기 저장)

이 패턴은 “Strangler Fig + API Gateway + Hybrid Storage” 전략의 좋은 예시입니다.

---

참고 자료

• Amazon EFS 성능/모드/처리량 공식 문서 (AWS Docs)
• Amazon EFS 가격 구조 (Amazon Web Services, Inc.)
• Amazon S3 스토리지 클래스 공식 문서 (Amazon Web Services, Inc.)
• S3 개념/특징 정리 글 (아주 쉽게 정리한 블로그)