Amazon S3

사용자 업로드를 웹 서버 디스크에만 두면 서버를 교체하거나 여러 대로 늘리는 순간 파일 위치가 꼬입니다. 백업과 공유를 따로 챙기지 않으면 한 서버 장애가 곧 파일 유실과 다운로드 장애로 이어집니다.

예전에는 NAS나 파일 서버를 직접 늘리며 용량과 백업을 관리해야 했습니다. 이런 방식은 확장과 내구성 확보가 번거로워서, 사실상 무한대로 확장되는 객체 저장소인 S3 같은 모델이 자리 잡았습니다.

S3는 버킷 안에 객체를 키-값 구조로 저장합니다. 파일을 PUT하면 버킷 이름과 키(경로처럼 보이는 문자열)가 조합된 주소가 생기고, GET 요청을 보내면 해당 키에 매핑된 객체 본문이 그대로 반환됩니다. 파일시스템처럼 디렉터리를 탐색하는 것이 아니라 키를 알거나 prefix로 나열하는 방식이라 수백만 개 객체도 일관된 성능으로 읽고 씁니다. 스토리지 클래스와 Lifecycle 정책을 설정하면 접근 빈도가 줄어든 객체는 자동으로 저렴한 계층으로 이동해 비용이 내려갑니다.

S3, EBS, EFS는 모두 데이터를 저장합니다. 차이는 접근 방식입니다. EBS는 한 인스턴스에 붙는 블록 디스크이고 EFS는 여러 인스턴스가 공유하는 파일시스템이며, S3는 파일을 객체 단위로 다루는 API 기반 저장소입니다. 파일시스템처럼 마운트할 필요 없이 HTTP로 읽고 쓸 데이터라면 S3가 맞습니다.

정적 웹 자산, 사용자 업로드, 백업과 복구, 아카이브, 로그 보관, 데이터 레이크처럼 파일을 대량으로 저장하고 여러 서비스에서 다시 읽어야 할 때 적합합니다. 파일시스템처럼 마운트해야 하거나 서버에 직접 붙는 디스크가 필요한 경우에는 맞지 않습니다.