AWS 스토리지 S3, EBS, EFS 쉽게 구분하기

저장소 선택은 "어떻게 읽고 쓰는가"에서 시작한다

웹 서비스를 만들면 반드시 데이터를 저장해야 한다. 사용자가 올린 이미지, 서버 로그, 데이터베이스 파일, 백업 파일, 여러 서버가 함께 읽는 설정 파일까지 모두 저장소가 필요하다.

이때 가장 흔한 실수는 "저장소는 다 비슷하다"고 생각하는 것이다. 하지만 AWS에서는 저장 방식에 따라 서비스가 나뉜다. 대표적으로 S3는 객체 스토리지, EBS는 블록 스토리지, EFS는 파일 스토리지다.¹

쉽게 비유하면 이렇다.

핵심 질문은 "무엇을 저장하느냐"보다 "애플리케이션이 데이터를 어떤 방식으로 읽고 쓰느냐"다. 파일 하나를 객체처럼 올리고 내려받으면 S3가 어울린다. 서버 안의 디스크처럼 빠르게 읽고 써야 하면 EBS가 어울린다. 여러 서버가 같은 폴더를 동시에 봐야 하면 EFS가 어울린다.

AI 생성 이미지

S3는 파일 서버가 아니라 객체 스토리지다

S3를 처음 보면 폴더와 파일이 있는 파일 서버처럼 보인다. 콘솔에서도 폴더처럼 경로가 보인다. 하지만 S3는 일반적인 파일 시스템이 아니다. S3는 데이터를 객체 단위로 저장하는 객체 스토리지다.

S3의 기본 단위는 세 가지다.

• 버킷: 객체를 담는 가장 큰 보관함이다.

• 객체: 실제 데이터와 메타데이터를 합친 저장 단위다. 이미지 파일, 로그 파일, 압축 파일 등이 객체가 된다.

• 키: 객체의 이름이다. images/cat.png처럼 보이면 폴더 안의 파일 같지만, 실제로는 하나의 긴 이름에 가깝다. 여기서 /는 폴더 구조라기보다 이름을 보기 좋게 나누는 구분자로 이해하면 쉽다.

예를 들어 사용자가 프로필 이미지를 올린다고 하자. 애플리케이션은 그 이미지를 EC2 디스크에 저장할 수도 있다. 하지만 서버가 교체되거나 여러 대로 늘어나면 문제가 생긴다. A 서버에 저장된 이미지를 B 서버는 바로 볼 수 없기 때문이다.

이런 파일은 S3에 저장하는 편이 자연스럽다. 애플리케이션은 S3 API를 호출해 이미지를 업로드하고, 필요할 때 객체 URL이나 API를 통해 다시 읽는다. 서버가 한 대든 열 대든 같은 버킷을 바라보면 된다.

다만 S3를 서버 디스크처럼 생각하면 안 된다. S3 객체는 보통 객체 단위로 올리고 내려받는 방식에 가깝다. 큰 파일을 나누어 업로드하거나 일부 범위만 읽는 기능은 있지만, 데이터베이스 파일처럼 작은 조각을 계속 제자리에서 고쳐 쓰는 용도에는 맞지 않는다. 그 경우에는 EBS가 더 적합하다.

S3가 잘 맞는 예시는 다음과 같다.

• 사용자가 올린 이미지, 동영상, 문서

• 웹사이트의 정적 파일

• 애플리케이션 로그 보관

• 백업 파일 저장

• 분석용 원본 데이터 보관

반대로 운영체제 디스크, 데이터베이스 데이터 파일, 자주 수정되는 로컬 파일 구조에는 S3보다 EBS나 EFS를 먼저 검토하는 것이 좋다.

EBS는 EC2에 붙는 디스크처럼 동작한다

앞에서 EC2 인스턴스를 만들 때 루트 볼륨을 함께 만들었다. 그 루트 볼륨이 바로 EBS다. EBS는 EC2에 연결해 사용하는 블록 스토리지다. 블록 스토리지는 디스크를 작은 블록 단위로 나누어 읽고 쓰는 방식이다.

EC2 입장에서 EBS는 서버에 장착된 디스크처럼 보인다. 운영체제를 설치할 수도 있고, 파일 시스템을 만들 수도 있고, 데이터베이스가 데이터를 저장하는 공간으로도 쓸 수 있다.

EBS의 특징은 다음과 같다.

• EC2에 연결해 디스크처럼 사용한다.

• 일반적으로 같은 가용 영역의 EC2에 붙인다.

• EC2가 중지되어도 EBS 볼륨은 남길 수 있다.

• 성능과 용량을 볼륨 단위로 선택한다.

• 스냅샷으로 백업할 수 있다.

예를 들어 MySQL을 EC2에 직접 설치해 운영한다고 하자. 데이터베이스는 작은 읽기와 쓰기를 자주 반복한다. 이런 작업은 객체 하나를 통째로 올리고 받는 S3보다, 디스크처럼 동작하는 EBS가 맞다.

한 가지 더 기억할 점은 EBS가 보통 "한 서버에 붙는 디스크"라는 점이다. 일부 고성능 볼륨 유형에는 여러 인스턴스에 연결하는 기능도 있지만, 초보 단계에서는 예외로 생각해도 된다. 여러 서버가 같은 파일 폴더를 동시에 공유해야 한다면 먼저 EFS를 떠올리는 편이 이해하기 쉽다.

EBS를 사용할 때는 비용도 함께 생각해야 한다. EC2를 삭제해도 EBS 볼륨이 남아 있으면 계속 과금될 수 있다. 실습 후에는 EC2뿐 아니라 연결된 볼륨도 확인해야 한다. 앞에서 "인스턴스 종료 후 EBS 볼륨 확인"을 강조한 이유가 여기에 있다.

스냅샷은 EBS 백업의 기본 습관이다

EBS 볼륨에 중요한 데이터가 있다면 스냅샷을 만들어야 한다. 스냅샷은 특정 시점의 EBS 볼륨 상태를 저장한 백업이다.² 운영 중 실수로 파일을 삭제하거나, 애플리케이션 배포가 실패했을 때 되돌아갈 수 있는 안전망이 된다.

흐름은 단순하다.

1. EC2 콘솔에서 EBS 볼륨을 선택한다.

2. Create snapshot을 선택한다.

3. 설명을 적고 스냅샷을 만든다.

4. 나중에 스냅샷에서 새 EBS 볼륨을 생성한다.

5. 새 볼륨을 EC2에 연결해 데이터를 복구한다.

스냅샷은 매번 전체 디스크를 새로 복사하는 개념이 아니라, 변경분을 중심으로 저장되는 방식으로 이해하면 된다. 그래서 정기적으로 백업하기에 적합하다. 하지만 스냅샷도 저장 용량에 따라 비용이 발생한다. "백업은 만들었지만 오래된 백업을 정리하지 않는" 상황도 비용 낭비가 된다.

운영에서는 보통 이런 규칙을 둔다.

• 배포 전 주요 서버의 스냅샷을 만든다.

• 데이터베이스 볼륨은 정기 스냅샷을 만든다.

• 오래된 스냅샷은 보관 기간을 정해 삭제한다.

• 복구 절차를 한 번은 실제로 테스트한다.

데이터베이스처럼 계속 쓰기가 발생하는 서비스라면 스냅샷을 만들기 전에 애플리케이션이나 데이터베이스의 백업 방식도 함께 고려해야 한다. 디스크 상태만 저장했다고 해서 항상 애플리케이션 관점에서 완벽한 복구가 보장되는 것은 아니기 때문이다. 백업은 "있다"보다 "복구할 수 있다"가 중요하다.

EFS는 여러 서버가 함께 쓰는 공유 파일 시스템이다

EFS는 Elastic File System의 약자로, 여러 EC2 인스턴스가 동시에 마운트해서 사용할 수 있는 관리형 파일 시스템이다.³ 쉽게 말해 AWS에서 제공하는 네트워크 공유 폴더다.

EBS는 기본적으로 한 EC2에 붙여 서버 디스크처럼 쓰는 방식이다. 반면 EFS는 여러 서버가 같은 경로를 함께 볼 수 있다. 예를 들어 웹 서버가 세 대 있고, 사용자가 올린 파일을 세 서버가 모두 읽어야 한다면 EFS가 선택지가 될 수 있다.

EFS가 어울리는 상황은 다음과 같다.

• 여러 EC2가 같은 업로드 폴더를 공유해야 할 때

• 콘텐츠 관리 시스템이 공통 파일 디렉터리를 필요로 할 때

• 개발자별 홈 디렉터리나 공용 작업 폴더가 필요할 때

• 컨테이너 여러 개가 같은 파일 시스템을 마운트해야 할 때

EFS는 리눅스의 NFS(Network File System) 방식으로 마운트한다. NFS는 네트워크를 통해 폴더를 연결해 쓰는 파일 공유 프로토콜이다. 그래서 보안 그룹에서 NFS 포트인 2049번 통신을 허용해야 할 수 있다.

다만 EFS를 모든 공유 문제의 정답으로 생각하면 안 된다. 네트워크 파일 시스템이므로 로컬 디스크인 EBS와 성능 특성이 다르다. 파일을 함께 보는 구조에는 편리하지만, 데이터베이스처럼 낮은 지연 시간이 중요하고 쓰기가 매우 잦은 작업에는 EFS보다 EBS나 관리형 데이터베이스를 검토하는 편이 좋다.

S3 비용은 보관 방식으로 줄인다

S3는 저장할 수 있는 규모가 매우 크고 사용하기 쉽지만, 아무렇게나 쌓아 두면 비용이 커진다. 특히 로그, 백업, 오래된 업로드 파일은 시간이 지날수록 잘 열어 보지 않는데도 계속 비용을 만든다.

S3는 이런 상황을 위해 여러 스토리지 클래스를 제공한다. 스토리지 클래스는 데이터의 접근 빈도와 복구 속도에 따라 저장 비용을 다르게 책정하는 보관 등급이다.⁴

대표적인 선택지는 다음과 같다.

여기서 IA는 Infrequent Access, 즉 "자주 접근하지 않음"을 뜻한다. Glacier 계열은 더 저렴한 대신 데이터를 꺼내는 데 시간이 걸릴 수 있다. 단, Glacier 계열 안에서도 즉시 접근에 가까운 클래스와 몇 시간 이상 걸릴 수 있는 아카이브 클래스가 나뉜다. 따라서 "무조건 싼 클래스"가 좋은 것이 아니다. 자주 조회하는 데이터를 아카이브용 클래스에 넣으면 조회 비용이나 복구 시간이 문제가 될 수 있다.

이때 함께 쓰는 기능이 수명 주기 정책이다. 예를 들어 다음처럼 규칙을 만들 수 있다.

• 업로드 후 30일이 지난 로그는 Standard-IA로 이동

• 90일이 지난 로그는 Glacier 계열로 이동

• 1년이 지난 임시 파일은 삭제

또 하나 중요한 기능은 버전 관리다. S3 버전 관리를 켜면 같은 키의 객체를 덮어써도 이전 버전이 남는다. 실수로 파일을 삭제하거나 잘못된 파일을 업로드했을 때 복구 가능성이 생긴다.⁵

하지만 버전 관리는 비용을 늘릴 수 있다. 눈에 보이는 최신 파일은 하나여도, 뒤에 이전 버전들이 계속 남아 있을 수 있기 때문이다. 그래서 버전 관리를 켰다면 오래된 버전을 정리하는 수명 주기 정책도 함께 설계해야 한다.

S3 공개와 비공개는 의도적으로 나누어야 한다

S3에서 가장 조심해야 할 부분은 공개 설정이다. 버킷에 개인정보, 백업 파일, 내부 로그가 들어 있는데 실수로 공개되면 큰 사고가 된다.

기본 원칙은 간단하다.

• 비공개 데이터는 퍼블릭 액세스를 차단한다.

• 공개해야 하는 데이터만 별도 경로 또는 별도 버킷으로 분리한다.

• 권한은 버킷 정책과 IAM 정책으로 명확히 관리한다.

• "일단 공개하고 나중에 막기"는 피한다.

S3 퍼블릭 액세스 차단(Block Public Access)은 실수로 버킷이나 객체가 공개되는 것을 막는 안전장치다.⁶ 초보자는 기본적으로 이 설정을 켜 두는 것이 좋다. 정적 웹사이트 파일처럼 공개가 필요한 경우에도, 정말 모든 객체를 공개해야 하는지 먼저 확인해야 한다.

공개가 필요할 때는 버킷 정책을 사용해 범위를 제한한다. 버킷 정책은 "누가, 어떤 객체에, 어떤 작업을 할 수 있는가"를 정하는 규칙이다. 예를 들어 public/ 아래의 이미지 파일만 읽을 수 있게 하고, private/ 아래의 원본 파일은 막을 수 있다.

실제 서비스에서는 S3를 직접 전 세계에 공개하기보다 CloudFront 같은 CDN을 앞에 두는 구성이 자주 쓰인다. 이 내용은 뒤에서 도메인과 CDN을 다룰 때 다시 연결한다. 지금은 한 가지만 기억하면 된다. S3 버킷은 기본 비공개로 두고, 공개는 필요한 범위만 의도적으로 연다.

선택 기준을 한 문장으로 정리하기

S3, EBS, EFS는 모두 저장소지만 같은 문제를 풀지 않는다. 선택 기준은 다음처럼 정리할 수 있다.

• S3: 파일을 객체 단위로 저장하고 API로 읽고 쓴다. 이미지, 백업, 로그, 정적 파일에 적합하다.

• EBS: EC2에 붙는 디스크처럼 쓴다. 운영체제, 데이터베이스, 낮은 지연 시간이 필요한 서버 데이터에 적합하다.

• EFS: 여러 서버가 같은 폴더를 동시에 마운트한다. 공유 파일 시스템이 필요한 웹 서버나 컨테이너 환경에 적합하다.

저장소를 잘 고르면 성능 문제를 줄이고, 서버 확장도 쉬워지고, 비용도 예측하기 좋아진다. 반대로 저장소를 잘못 고르면 서버를 늘릴 때 파일이 흩어지고, 백업이 복잡해지고, 필요 없는 데이터 보관 비용이 계속 쌓인다.

AWS에서 좋은 설계는 멋진 서비스를 많이 쓰는 것이 아니다. 데이터가 어떻게 사용되는지 보고, 그 방식에 맞는 가장 단순한 저장소를 고르는 것이다.

참고

¹AWS 클라우드 스토리지

²Amazon EBS 스냅샷

³Amazon Elastic File System이란 무엇입니까?

⁴Amazon S3 스토리지 클래스

⁵S3 버킷에서 버전 관리 사용

⁶Amazon S3 퍼블릭 액세스 차단