[AWS] 4회차: Storage 핵심 정리 - Storage 서비스 이해

이번 회차에서 다룬 내용

2026년 1월 15일 목요일, AWS Certified Cloud Practitioner(CLF-C02) 스터디 4회차를 진행했다. 이날 주제는 Storage 핵심이었다.

발표자 배정표 기준으로 4회차 범위는 다음과 같았다.

• A(현석): S3 (객체 스토리지)
• B(현석): EBS (블록 스토리지)
• C(지호): Instance Store
• D(지호): EFS (파일 스토리지)

이번 회차는 단순히 저장소 이름 4개를 외우는 시간이 아니었다. 오히려 “AWS에서 데이터를 저장하는 방식이 왜 이렇게 여러 종류로 나뉘는가”를 이해하는 회차에 가까웠다.

컴퓨팅 회차에서 EC2, Lambda, Lightsail을 비교하며 느꼈던 것과 비슷하게, 스토리지도 마찬가지였다. 어떤 저장소가 더 좋다고 단정할 수 없고, 데이터를 어떤 방식으로 저장하고 접근할 것인가에 따라 정답이 달라진다.

이번 글은 4회차 내용을 복습하면서, 시험에서 가장 많이 헷갈리는 포인트들을 한 번에 정리하려는 목적에서 쓴다.

왜 스토리지 파트가 헷갈리는가

처음 AWS를 공부할 때는 스토리지라는 말이 너무 넓다.

• 파일을 저장하는 건가
• 디스크처럼 쓰는 건가
• 여러 서버가 같이 쓰는 건가
• 오래 보관하는 용도인가
• 빠른 성능이 중요한가

문제는 이 질문들이 한 서비스 안에서 다 해결되지 않는다는 점이다.

AWS는 저장 방식에 따라 스토리지를 다르게 제공한다.

• 객체 단위로 저장하는 서비스
• 서버 디스크처럼 붙이는 서비스
• EC2 물리 호스트에 종속된 임시 저장소
• 여러 인스턴스가 같이 쓰는 네트워크 파일 시스템

즉, 이번 회차의 핵심은 “저장소 이름 암기”가 아니라 저장 단위와 연결 방식의 차이를 이해하는 것이었다.

4회차 전체를 한 문장으로 요약하면

이번 회차를 아주 짧게 줄이면 이렇게 말할 수 있다.

• S3: 객체를 저장한다
• EBS: EC2에 붙는 디스크다
• Instance Store: 빠르지만 휘발성인 로컬 디스크다
• EFS: 여러 EC2가 함께 쓰는 파일 시스템이다

시험에서는 이 차이만 명확히 구분해도 절반 이상은 풀린다. 하지만 실제 문제에서는 “정적 웹사이트”, “데이터베이스 디스크”, “임시 캐시”, “다중 서버 공유 파일”처럼 사용 사례가 섞여 나오기 때문에 조금 더 깊게 이해해두는 편이 좋다.

먼저 큰 그림: 객체 / 블록 / 파일 스토리지

AWS 스토리지를 이해할 때 가장 중요한 출발점은 저장 방식의 종류다.

객체 스토리지(Object Storage)

데이터를 파일처럼 보이지만, 내부적으로는 객체 단위로 저장한다.

대표 서비스:

• Amazon S3

블록 스토리지(Block Storage)

운영체제가 디스크처럼 인식할 수 있는 저장소다.

대표 서비스:

• Amazon EBS
• Instance Store

파일 스토리지(File Storage)

여러 시스템이 파일 시스템 형태로 접근할 수 있는 저장소다.

대표 서비스:

• Amazon EFS

이 구분이 먼저 잡혀야 각 서비스의 역할이 선명해진다.

S3란 무엇인가

Amazon S3(Simple Storage Service)는 AWS의 대표적인 객체 스토리지 서비스다.

Cloud Practitioner에서 S3는 매우 자주 나온다. 이유는 단순하다. AWS를 상징하는 서비스 중 하나이기도 하고, 사용 범위가 넓기 때문이다.

S3를 쉽게 이해하면

S3는 파일을 폴더 구조에 넣는 것처럼 보이지만, 실제로는 객체를 버킷(bucket) 안에 저장하는 구조다.

즉:

• 내가 서버 디스크에 직접 저장하는 느낌이 아니라
• AWS가 관리하는 객체 저장소에 데이터를 넣는 것

에 가깝다.

S3의 핵심 특징

• 객체 스토리지
• 매우 높은 내구성
• 높은 확장성
• 웹을 통해 접근 가능
• 정적 콘텐츠, 백업, 로그, 이미지 저장 등에 폭넓게 사용

시험에서는 보통:

• 정적 파일 저장
• 백업
• 대용량 객체 저장
• 정적 웹사이트 호스팅

과 연결해 S3를 떠올리면 된다.

S3가 적합한 대표 사례

1. 정적 웹사이트 호스팅

4회차 자료에도 이 부분이 들어 있었다. HTML, CSS, JS 같은 정적 파일을 호스팅하는 데 S3를 쓸 수 있다.

즉:

• 서버 코드를 실행하는 것이 아니라
• 미리 만들어진 정적 파일을 전달하는 경우

에는 S3가 아주 잘 맞는다.

2. 이미지, 영상, 문서 저장

애플리케이션에서 업로드되는 파일을 장기 보관하거나 배포할 때 적합하다.

3. 백업 및 아카이브

S3는 높은 내구성과 다양한 스토리지 클래스를 바탕으로 백업에도 자주 사용된다.

4. 로그 저장

대량 로그를 쌓아두는 저장소로도 자주 쓰인다.

즉, S3는 “서버 디스크”가 아니라 대량의 파일성 데이터를 안전하게 보관하고 전달하는 저장소로 이해하는 편이 맞다.

S3에서 자주 나오는 키워드

버킷(Bucket)

S3에서 객체를 담는 논리적 컨테이너다. 폴더처럼 느껴질 수 있지만, 실제 개념은 버킷 안에 객체가 저장되는 구조다.

객체(Object)

S3에 저장되는 개별 데이터 단위다.

버전 관리(Versioning)

파일이 수정되거나 삭제되어도 이전 버전을 남겨둘 수 있게 하는 기능이다.

시험 관점에서는 실수 복구나 데이터 보호와 연결해서 보면 된다.

암호화(Encryption)

자료에도 s3_encrypt.png가 있었던 것처럼, S3는 데이터 암호화와 함께 자주 출제된다.

암호화는 크게:

• 저장 중 암호화(At Rest)
• 전송 중 암호화(In Transit)

를 떠올리면 된다.

접근 제어

S3는 기본적으로 private로 두는 것이 원칙에 가깝다. 접근 제어는 IAM, Bucket Policy, ACL 같은 요소와 연결되지만, Cloud Practitioner 수준에서는:

• 기본은 비공개
• 정책을 통해 접근 제어 가능

정도로 이해하면 충분하다.

S3의 강점: 내구성과 확장성

자료에서 보였던 핵심 포인트 중 하나는 S3의 높은 내구성이었다.

Cloud Practitioner에서는 S3를 이야기할 때 자주 다음 표현이 나온다.

• 매우 높은 durability
• 사실상 무제한에 가까운 확장성

여기서 중요한 건:

• Durability(내구성) 은 데이터가 안 없어지는 성질에 가깝고
• Availability(가용성) 은 필요할 때 접근 가능한 성질에 가깝다

라는 점이다.

이 둘은 비슷해 보여도 다른 개념이다. 시험에서 가끔 섞여 나온다.

EBS란 무엇인가

Amazon EBS(Elastic Block Store)는 EC2 인스턴스에 연결해서 사용하는 블록 스토리지다.

쉽게 말하면:

• S3가 파일 보관소에 가깝다면
• EBS는 EC2 서버에 붙이는 하드디스크에 가깝다

라고 볼 수 있다.

핵심 특징

• 블록 스토리지
• EC2에 연결해서 사용
• 운영체제가 디스크처럼 인식
• 영구 저장 가능

즉, OS가 설치되거나 애플리케이션 데이터가 디스크처럼 저장되어야 하는 경우 EBS가 자연스럽다.

왜 EBS가 필요한가

EC2는 컴퓨팅 자원이다. 그런데 컴퓨팅만으로는 충분하지 않다. 운영체제, 애플리케이션 파일, 데이터베이스 데이터 같은 것을 저장할 디스크가 필요하다.

이 역할을 EBS가 한다.

대표적인 예:

• EC2 부트 볼륨
• 애플리케이션 디스크
• 데이터베이스 저장소

즉, EC2를 실제 서버처럼 쓰려면 EBS를 같이 떠올려야 한다.

EBS의 핵심 포인트

1. 블록 스토리지

블록 단위로 읽고 쓰는 구조라서 운영체제 입장에서는 일반 디스크처럼 다룰 수 있다.

2. EC2와 밀접하게 연결됨

EBS는 보통 특정 EC2 인스턴스와 함께 생각한다.

즉, S3처럼 독립적인 대용량 객체 저장소라기보다, 인스턴스에 붙는 디스크라는 감각이 더 중요하다.

3. 휘발성이 아니라 영구 저장

Instance Store와 달리, EBS는 데이터가 더 영속적인 저장소다.

시험에서 이 차이는 매우 중요하다.

4. 스냅샷

자료 추출에서도 확인됐듯, EBS는 스냅샷을 통해 백업과 복원을 할 수 있다. 이 부분은 다른 AZ로 옮기거나 복구하는 맥락과 연결된다.

Cloud Practitioner 수준에서는:

• EBS는 AZ 단위로 생각하고
• 스냅샷은 백업/복구 및 재생성에 활용

정도로 정리하면 된다.

EBS와 S3를 헷갈리지 않는 방법

이 둘은 시험에서 매우 자주 비교된다.

S3

• 객체 스토리지
• 파일/이미지/백업/정적 웹사이트
• 웹 기반 접근
• 무제한 확장에 가까움

EBS

• 블록 스토리지
• EC2 디스크
• OS나 DB 저장소 같은 디스크성 워크로드
• 인스턴스와 밀접한 관계

이렇게 생각하면 된다.

쉽게 비유하면:

• S3는 창고
• EBS는 서버에 직접 꽂는 디스크

다.

Instance Store란 무엇인가

Instance Store는 EC2 인스턴스가 실행되는 물리 호스트에 직접 연결된 로컬 스토리지다.

4회차 자료에서도 이 부분이 굉장히 강조되어 있었다. 특히 핵심 키워드는 두 가지였다.

• 빠르다
• 휘발성이다

왜 빠를까

네트워크를 거쳐 접근하는 구조가 아니라, EC2가 실행 중인 물리 호스트와 직접 연결된 로컬 디스크에 가깝기 때문이다.

그래서 매우 높은 I/O 성능이 필요한 상황에 유리할 수 있다.

왜 휘발성일까

Instance Store는 인스턴스가 실행되는 호스트에 종속적이기 때문이다.

즉:

• 인스턴스를 중지하거나 종료하면
• 데이터가 사라질 수 있다

이 점이 EBS와의 가장 큰 차이점이다.

Instance Store가 적합한 경우

자료에서도 다음처럼 정리돼 있었다.

• 캐시
• 버퍼
• 스크래치 데이터
• 임시 연산 공간

즉, 없어져도 다시 만들 수 있는 데이터에 적합하다.

반대로 다음에는 부적합하다.

• 중요한 영구 데이터
• 데이터베이스 본 저장소
• 오래 보존해야 하는 파일

시험에서는 “매우 빠른 임시 스토리지”가 필요하면 Instance Store를 떠올리면 된다.

EFS란 무엇인가

Amazon EFS(Elastic File System)는 여러 EC2 인스턴스가 함께 사용할 수 있는 관리형 파일 스토리지다.

쉽게 말하면:

• EBS가 한 서버에 붙는 디스크라면
• EFS는 여러 서버가 공유하는 네트워크 드라이브에 가깝다

라고 이해할 수 있다.

핵심 특징

• 파일 스토리지
• 여러 인스턴스가 동시에 접근 가능
• 관리형 서비스
• 자동 확장
• Linux 기반 NFS

자료에서도 이 부분이 강조되었다. 특히 Multi-AZ 환경에서 여러 EC2가 하나의 EFS를 공유한다는 구조가 핵심이었다.

EFS가 적합한 경우

1. 여러 EC2가 같은 파일을 공유해야 하는 경우

예:

• 웹 서버 팜이 같은 정적 파일을 읽어야 할 때
• 여러 애플리케이션 서버가 공통 파일에 접근할 때

2. 파일 시스템 형태가 필요한 경우

즉, 단순 객체 저장이 아니라 파일 경로 기반 접근이 필요한 경우

3. 가용성과 공유성이 중요한 경우

Multi-AZ 구조를 통해 한 AZ 문제가 있어도 다른 AZ에서 접근을 이어갈 수 있다는 점이 장점이다.

EFS의 핵심 포인트

1. 여러 인스턴스가 동시에 사용 가능

이건 EBS와의 가장 큰 차이 중 하나다.

2. 파일 스토리지

파일 시스템 형태로 접근한다.

3. Linux 기반

자료에서도 Linux 기반 NFS 공유 스토리지라는 점이 언급됐다. Windows 계열 파일 스토리지는 별도 서비스(FSx) 맥락으로 가는 편이다.

4. 고가용성

각 AZ에 mount target을 두고, 여러 EC2가 접근하는 구조다. 그래서 공유 스토리지이면서도 가용성을 고려할 수 있다.

Instance Store vs EFS가 왜 같이 묶였는가

4회차 자료에서 지호 님 발표는 Instance Store와 EFS를 한 묶음으로 설명하고 있었다. 시험에서 이 둘을 비교할 때 핵심이 꽤 분명하기 때문이다.

Instance Store

• 빠름
• 휘발성
• 인스턴스 전용
• 공유 불가

EFS

• 영구적
• 여러 인스턴스 공유 가능
• 네트워크 파일 시스템
• Multi-AZ 활용 가능

즉, 이 비교의 핵심은:

• 데이터 수명
• 공유 가능 여부

였다.

자료의 치트시트도 사실상 이 포인트를 중심으로 정리되어 있었다.

네 가지 스토리지를 한 번에 비교해보기

S3

• 저장 방식: 객체
• 대표 용도: 정적 파일, 백업, 업로드 파일, 로그
• 특징: 매우 높은 내구성, 확장성, 정적 웹 호스팅 가능

EBS

• 저장 방식: 블록
• 대표 용도: EC2 디스크, OS, DB 저장소
• 특징: 영구적, 인스턴스 디스크처럼 사용

Instance Store

• 저장 방식: 로컬 블록
• 대표 용도: 캐시, 임시 데이터, 초고속 작업
• 특징: 매우 빠르지만 휘발성

EFS

• 저장 방식: 파일
• 대표 용도: 여러 EC2 간 공유 파일 시스템
• 특징: 공유 가능, 자동 확장, Linux 기반

이 네 가지를 섞어 보면:

• 파일 업로드 보관 → S3
• DB 디스크 → EBS
• 임시 캐시 → Instance Store
• 여러 웹 서버의 공통 파일 → EFS

처럼 연결하면 훨씬 쉽다.

시험에서 자주 나오는 비교 패턴

정적 웹사이트를 어디에 둘까

정적 HTML, CSS, JS를 제공하려면 보통 S3를 떠올린다.

EC2에 붙일 영구 디스크가 필요하다

이때는 EBS다.

데이터가 매우 빠르게 읽혀야 하지만, 사라져도 된다

이 경우는 Instance Store 다.

여러 EC2가 같은 파일에 동시에 접근해야 한다

이 경우는 EFS 다.

시험은 결국 이런 사용 사례를 서비스와 연결하게 한다.

이번 회차에서 남겨둘 포인트

이번 회차를 하면서 가장 크게 느낀 건, 스토리지 서비스는 기능 이름보다 데이터의 성격을 먼저 생각해야 한다는 점이었다.

예를 들어:

• 오래 보존해야 하는가
• 여러 서버가 같이 써야 하는가
• 디스크처럼 붙어야 하는가
• 파일이 아니라 객체로 저장해도 되는가
• 지워져도 되는 임시 데이터인가

이 질문에 답하면 어떤 서비스를 써야 하는지가 거의 정해진다.

반대로 서비스 이름부터 외우면 금방 헷갈린다. 특히 EBS와 EFS, EBS와 Instance Store, S3와 EBS는 시험에서 계속 비교되는 조합이라 목적 중심으로 이해하는 편이 훨씬 낫다.

시험 전에 다시 볼 포인트

짧게 압축하면:

• S3는 객체 스토리지다.
• EBS는 EC2에 연결하는 블록 스토리지다.
• Instance Store는 빠르지만 휘발성인 로컬 스토리지다.
• EFS는 여러 EC2가 함께 쓰는 파일 스토리지다.
• S3는 정적 웹사이트, 백업, 파일 저장에 강하다.
• EBS는 서버 디스크나 DB 저장소에 적합하다.
• EFS는 공유 파일 시스템에 적합하다.
• Instance Store는 캐시나 임시 데이터에 적합하다.

4회차는 이후 데이터베이스, 백업, 보안, 비용 파트로 넘어가기 전 꼭 잡고 가야 하는 회차였다. 저장소의 성격을 이해해야 나중에 RDS, Aurora, 백업, 암호화 문제도 더 자연스럽게 이해할 수 있기 때문이다.

자료 다운로드

reference 폴더 기준으로 4회차와 직접 연결되는 자료 파일은 아래 5개였다. 복습용으로 바로 내려받을 수 있게 정적 경로로 옮겨두었다.

• 20260115.pptx 4회차 메인 발표 자료. S3와 EBS 파트가 포함된 슬라이드 파일.

• 260115_Instance store_EFS.html Instance Store와 EFS 비교 발표 자료.

다음 글에서는 1월 20일 5회차 주제였던 Database 핵심, 즉 RDS, Aurora, DynamoDB, ElastiCache, Redshift를 정리할 예정이다.