오늘은 AWS 스토리지 서비스들을 정리해 보겠다.
AWS 스토리지 서비스를 크게 5개 유형으로 나눌 수 있는데
- 오브젝트 스토리지: S3
- 블록 스토리지: EBS, Instance Store
- 파일 스토리지: EFS, FSx
- 아카이브 스토리지: Glacier
- 하이브리드: Storage Gateway
이제 이 서비스들에 대해 공부해 보겠다.
1. 오브젝트 스토리지(Object Storage)
AWS에서 제공하는 완전관리형 오브젝트 스토리지 서비스
인터넷을 통해 어디서나 접근 가능
무제한 저장, 높은 내구성, 다양한 활용성
S3는 AZ 고장과 무관 리전 전체 관리
구성요소
Bucket: 객체를 저장하는 단위, 리전 단위로 생성
Object: 저장되는 파일, 메타데이터 + 본문으로 구성
Key: 객체의 이름(파일 경로처럼 동작)
Value: 실제 파일 내용
Version ID: 버전 관리를 활성화했을 경우 부여
특징
1. 무제한 저장과 확장성
- 객체 하나당 최대 5TB 저장 가능
- 수십억 객 객체 저장 가능
2. 스토리지 클래스 다양성
용도와 엑세스 빈도에 따라 여러 클래스 제공함
클래스 | 설명 | 특징 |
S3 Standard | 기본 클래스 | 자주 접근, 높은 가용성 |
S3 IA (Infrequent Access) | 저빈도 접근용 | 저장 비용↓, 접근 비용↑ |
S3 One Zone-IA | 단일 AZ에만 저장 | 비용↓, 내구성 다소↓ |
S3 Glacier | 아카이빙용 | 복구 수 분~시간 소요 |
S3 Glacier Deep Archive | 장기 보관용 | 복구 수 시간 이상, 매우 저렴 |
S3 Intelligent-Tiering | 접근 패턴 불규칙, 예측불가 | AWS 패턴분석, 자동 티어 이동 |
1. S3 Standard
- 용도: 자주 읽고 쓰는 데이터를 위한 기본 클래스
- 특징:
- 높은 가용성 (99.99%), 내구성 11 9’s
- 지연 없음, 별도 비용 없음
- 사용 예시: 운영 로그, 웹 콘텐츠, 실시간 이미지 저장
- 시험 키워드: 자주 접근, 높은 가용성, 빠른 응답, 기본
2. S3 Intelligent-Tiering
- 용도: 접근 패턴이 불규칙하거나 예측 불가한 경우
- 특징:
- AWS가 30일 단위로 접근 패턴 분석
- 자동으로 4개 티어 이동: Frequent / Infrequent / Archive / Deep Archive
- 최소 저장 기간 없음, 일부 티어에 전환 모니터링 비용 부과
- 사용 예시: 어떤 객체가 자주 접근될지 모르는 데이터셋
- 시험 키워드: 불규칙, 자동 전환, 운영 오버헤드↓, 계층 전환
3. S3 Standard-IA (Infrequent Access)
- 용도: 가끔 접근하지만 즉시 접근이 필요한 데이터
- 특징:
- 30일 미만 삭제 시 조기 삭제 요금 발생
- 요청당 읽기 비용 있음
- 사용 예시: 백업 데이터, 월간 보고서
- 시험 키워드: 저장 비용↓, 접근 비용↑, 30일, 즉시 복원
4. S3 One Zone-IA
- 용도: 복원이 가능하고 비용을 더 절감하고 싶은 경우
- 특징:
- 단일 AZ에만 저장 → AZ 장애 시 손실 가능성 존재
- Standard-IA보다 20~30% 더 저렴
- 사용 예시: 썸네일, 캐시 파일 등 재생성 가능한 데이터
- 시험 키워드: 단일 AZ, 복원 가능, 저비용, 30일
5. S3 Glacier
- 용도: 빠른 복원이 필요 없는 아카이브 목적
- 특징:
- 복구 요청 후 수분~수시간
- 3가지 복원 모드: Expedited / Standard / Bulk
- 90일 미만 삭제 시 요금 부과
- 사용 예시: 월별 백업, 오래된 시스템 로그
- 시험 키워드: 복원 지연, 90일, 아카이빙, Restore
6. S3 Glacier Deep Archive
- 용도: 거의 접근하지 않는, 법적 보관 목적 데이터
- 특징:
- S3 중 가장 저렴한 비용
- 복원에 12~48시간 소요
- 180일 미만 삭제 시 요금 부과
- 사용 예시: 회계자료, 계약서, 테이프에서 마이그레이션한 파일
- 시험 키워드: 장기 보관, 180일, 복구 수십시간, 테이프 대체
요약
클래스 | 설명 | 특징 |
S3 Standard | 기본 클래스 | 자주 접근, 높은 가용성 |
S3 IA (Infrequent Access) | 저빈도 접근용 | 저장 비용↓, 접근 비용↑ |
S3 One Zone-IA | 단일 AZ에만 저장 | 비용↓, 내구성 다소↓ |
S3 Glacier | 아카이빙용 | 복구 수 분~시간 소요 |
S3 Glacier Deep Archive | 장기 보관용 | 복구 수 시간 이상, 매우 저렴 |
S3 Intelligent-Tiering | 접근 패턴 불규칙, 예측불가 | AWS 패턴분석, 자동 티어 이동 |
3. 버전 관리
- 우발적 삭제 및 덮어쓰기 방지
- 삭제 마커로 삭제 시에도 복원 가능
4. 수명주기 관리
- 객체를 자동으로 IA, Glacier로 전환하거나 삭제 가능
-> 비용 절감 매우 유용
5. 암호화 지원
- SSE-S3: AWS 관리 키로 서버측 암호화
- SSE-KMS: KMS 키를 이용한 암호화(감사 추적 가능해짐)
- SSE-C: 고객 제공 키로 암호화
6. 정적 웹 호스팅 기능
- index.html, error.html 설정 가능
- 퍼블릭 엑세스 권한 필요
7. S3 Select
- 전체 파일 다운로드 없이 CSV/JSON에서 필요한 필드만 조회
- 데이터 처리 비용과 시간 절감
8. 멀티파트 업로드
- 100MB 이상의 대용량 파일 업로드 시 필수
- 병렬로 업로드하고 실패한 파트만 재시도 할 수 있음
9. 이벤트 알림
- 객체 업로드/삭제 시 SNS, SQS, Lambda로 이벤트 발생 가능
10. 액세스 제어
- Bucket Policy(리소스 기반 정책)
- IAM Policy(주체 기반 정책)
- ACL(Access Control List, 구식 방식)
사용예시
사례 | 설명 |
백업 저장소 | 정기적으로 S3에 로그 및 이미지 백업 |
정적 웹 호스팅 | React/Vue SPA 정적 파일 업로드 후 공개 호스팅 |
머신러닝 학습 | S3에 학습용 데이터 저장 후 SageMaker 연동 |
멀티 리전 복제 | 여러 리전에 객체 자동 복제하여 DR 구성 |
핵심 키워드
키워드 | 설명 |
"정적 웹 사이트", "HTML", "웹 호스팅" | S3 정적 웹 호스팅 |
"저렴하게 저장", "무제한", "백업", "로그 저장" | S3 Standard / S3 IA |
"데이터를 일정 기간 후 자동 이동" | S3 수명주기 정책 (Lifecycle) |
"버전 관리", "우발적 삭제 방지" | S3 버전 관리(Versioning) |
"S3에서 특정 필드만 읽기", "CSV 일부 읽기" | S3 Select |
"S3에 저장하지만 암호화 필요" | SSE-S3, SSE-KMS |
"멀티파트 업로드", "5GB 이상", "대용량 업로드" | Multipart Upload |
2. 블록스토리지(Block Storage)
디스크처럼 동작하는 저장 장치
운영체제, 데이터베이스 저장소 등 EC2와 밀접하게 연관됨
각 블록에 데이터가 저장되고, OS가 직접 파일 시스템으로 관리
EBS와 Instance Store가 있음
EC2 할 때 구성요소에 포함되었던 녀석
Amazon EBS (Elastic Block Store)
EBS는 EC2 인스턴스에 네트워크 기반으로 연결되는 영구 저장 디스크
일반적인 컴퓨터의 SSD나 HDD처럼 동작하며, EC2와 분리해도 데이터가 유지됨
그냥 외장 SSD 같은 개념
EBS 핵심 특징 요약
항목 | 내용 |
연결 | EC2에 네트워크 기반으로 연결됨 |
지속성 | EC2 종료 후에도 데이터 유지 |
크기 조정 | 실시간 확장 가능 |
백업 | 스냅샷(S3에 저장) 기능 제공 |
암호화 | SSE-KMS 등으로 지원 |
사용 OS | 리눅스, 윈도우 등 모든 OS에서 사용 |
EBS 볼륨 유형 비교
유형 | 설명 | 예 |
gp3 (기본) | 범용 SSD, 저렴한 비용에 안정적 성능 | 대부분의 일반 워크로드 |
io1/io2 | 고성능 IOPS 보장 SSD | DB, OLTP, IOPS 민감한 애플리케이션 |
st1 | Throughput HDD, 순차 읽기 최적화 | 대용량 로그, 빅데이터 분석 |
sc1 | Cold HDD, 드물게 접근 | 아카이브, 백업 |
스냅샷 기능
- EBS 볼륨을 스냅샷으로 백업 가능 (S3에 저장됨)
- 증분 방식이므로 변경된 부분만 저장 → 비용 효율
- 스냅샷으로 AMI 생성 가능 (EC2 재생성 시 유용)
EBS 암호화
- SSE-KMS 방식이 일반적
- KMS 키로 암호화된 상태로 저장, 전송 중에도 보호됨
- 복호화/재암호화 필요 없음 (투명 암호화)
EBS 비용 구조
항목 | 설명 |
저장 공간 | GB 단위로 과금 |
프로비저닝된 IOPS (io1/io2) | IOPS 수에 따라 별도 과금 |
스냅샷 | S3에 저장되며 별도 과금 발생 |
연결된 EC2 요금과 별도 |
-> EBS는 저장량, 성능, 백업 등에 따라 요금이 계속 발생함, 하지만 내구성, 기능, 백업 측면에서 매우 강력
Instance Store
EC2 인스턴스에 물리적으로 내장된 디스크
즉, EC2 인스턴스와 수명을 같이 하는 저장소이다.
로컬 SSD처럼 동작하며, 속도는 빠르지만 휘발성
영구적으로 사용할 건 넣으면 안됨
Instance Store 특징 정리
항목 | 내용 |
위치 | EC2 인스턴스 호스트 서버의 물리 디스크 |
속도 | 매우 빠름 (로컬 디스크 수준) |
지속성 | 없음, 인스턴스 중지/종료 시 삭제됨 |
백업 | 불가 (스냅샷 없음) |
사용 조건 | 일부 인스턴스 타입에서만 사용 가능 (예: i3, d2) |
사용 사례
- 대용량 임시 데이터 처리 (로그 압축, 비디오 렌더링)
- 고속 캐시 저장소
- 어플리케이션 실행 중에만 필요한 임시 파일 저장
비용 구조
- 별도 요금 없음
- EC2 인스턴스 요금에 포함
- 디스크 추가 용량에 따라 요금 변화 없음
→ 빠르지만 위험하고, 싸지만 휘발성. 비용은 EBS보다 유리하지만 위험도 높음.
EBS vs Instance Store 비교표
항목 | Amazon EBS | Instance Store |
위치 | 네트워크 연결된 외부 디스크 | 물리적 로컬 디스크 |
지속성 | O (인스턴스 종료에도 유지) | X (종료 시 삭제) |
스냅샷 | 지원 (S3에 백업) | 지원하지 않음 |
암호화 | 가능 (KMS) | 불가능 |
속도 | 중간~높음 | 매우 빠름 |
비용 | 저장량 기준 별도 과금 | EC2 요금에 포함 |
사용 목적 | OS, DB 등 주요 데이터 저장 | 임시 캐시, 일시적 처리 전용 |
시험 대비 핵심 포인트
상황 | 적합한 스토리지 | 판단 이유 |
EC2에서 OS, DB 저장 | EBS | 지속성 필요, 백업 가능 |
로그 압축, 일시적 작업 | Instance Store | 고속 + 휘발성 허용 |
고성능 DB → 수만 IOPS | EBS (io1/io2) | IOPS 보장 |
비용 아끼고 휘발성 허용 가능 | Instance Store | EC2 요금에 포함, 빠름 |
스냅샷 백업 필요 | EBS | Snapshot 기능 지원 |
오브젝트 스토리지 (Amazon S3) 관련 문제 분석
Q1.
지문 (요약 번역)
회사에서는 S3에 데이터가 전달되면 SNS로 알림을 보내고 Lambda로 처리하도록 구성했는데, 네트워크 오류로 Lambda가 실행되지 못하는 경우가 발생함. 이 문제를 방지하고 모든 데이터를 처리하도록 보장해야 함.
보기 (선택지 요약 및 번역)
A. 여러 AZ에 Lambda 배포
B. SNS를 SQS에 구독시키기
C. Lambda에 CPU와 메모리 증가
D. Lambda 처리량 증가
E. Lambda가 SQS에서 직접 읽도록 수정
정답: B, E
해설:
- 핵심 키워드: SNS, Lambda, 네트워크 실패, 재시도, 데이터 손실 방지
- Lambda는 SNS 이벤트를 받을 때 네트워크 장애가 생기면 재시도 보장 안 됨 → 중간 버퍼인 SQS를 두고 Lambda가 pull 방식으로 읽도록 구성해야 함
Q2.
지문 요약
900TB 규모의 텍스트 문서를 EC2에서 서비스하려고 한다. 확장성과 비용이 중요하다.
보기
A. EBS
B. EFS
C. OpenSearch
D. S3
정답: D
해설:
- 대용량 비정형 데이터 저장에 적합하고 비용 효율적임
- S3는 무제한 오브젝트 저장 가능하며 EC2에서 접근 가능
- 키워드: 900TB, 웹 앱, 확장성, 비용 효율성 → S3
Q3.
한 이미지 호스팅 회사가 Amazon S3 Standard 버킷에 대용량 자산을 업로드합니다. 병렬로 multipart upload를 사용하고, 동일한 객체가 업로드되면 덮어씁니다. 업로드 후 처음 30일은 자주 액세스하고, 이후에는 접근 빈도가 낮지만 불규칙합니다. 고가용성과 복원력을 유지하면서 저장 비용을 최적화해야 합니다.
정답을 고르시오 (2개).
선택지:
- A. 30일 후 S3 Intelligent-Tiering으로 이동
- B. 수명 주기 정책으로 불완전한 multipart upload 정리
- C. 만료된 삭제 마커 정리
- D. 30일 후 S3 Standard-IA로 이동
- E. 30일 후 S3 One Zone-IA로 이동
정답: A, B
해설:
- S3 Intelligent-Tiering은 불규칙한 접근 패턴에 최적화된 스토리지로 자동으로 계층을 전환해주므로 매우 적합
- 불완전한 multipart upload는 요금이 계속 발생하므로 수명 주기 정책으로 정리 필요
- IA 계열은 예측 가능한 비정기 접근일 때 유리하므로 본 케이스에는 덜 적합함
핵심 키워드:
- multipart upload
- S3 Intelligent-Tiering
- Lifecycle Policy
- 비용 최적화
- 불규칙한 액세스 패턴
Q4.
개발팀이 HTML, CSS, 자바스크립트, 이미지로 구성된 정적 웹사이트를 내부 팀들과 공유하고자 합니다.
가장 비용 효율적인 호스팅 방법은 무엇인가요?
선택지:
- A. AWS Fargate로 컨테이너 호스팅
- B. Amazon S3 버킷에서 웹사이트 호스팅
- C. EC2 인스턴스에서 웹 서버로 호스팅
- D. ALB와 Express.js 기반 Lambda 연결
정답: B
해설:
- 정적 웹사이트는 EC2나 Fargate보다 S3 정적 웹사이트 호스팅이 가장 저렴하고 관리 오버헤드가 없음
- ALB + Lambda는 동적 사이트에 어울리는 구조
핵심 키워드:
- 정적 웹사이트
- HTML, CSS
- 비용 효율
- S3 웹 호스팅
Q5.
회사가 S3 버킷에 저장되는 모든 새로운 객체를 암호화해야 하며, 운영 오버헤드를 줄이고 매년 자동으로 키를 교체해야 합니다.
적절한 구성은 무엇인가요?
선택지:
- A. AWS 관리형 키 사용
- B. 고객 관리형 CMK를 사용하고 기본 암호화 설정
- C. KMS 키 수동 회전
- D. 데이터 업로드 전 수동 암호화(CSE 방식)
정답: B
해설:
- SSE-KMS + 고객 관리형 CMK를 설정하고 자동 키 회전을 활성화하면 연간 자동 암호화 키 교체 가능
- 수동 회전(C)은 운영 오버헤드 증가
- CSE(D)는 객체별로 처리해야 하므로 일관성 부족
핵심 키워드:
- S3 버킷 암호화
- SSE-KMS
- CMK 자동 회전
- 기본 암호화 정책
Q6.
지문 (요약):
정적 콘텐츠만 필요한 웹 애플리케이션. 유지보수 최소화, 확장성 중요
질문: 어떤 조합이 가장 적합한가?
정답: D. S3 + CloudFront 조합
해설:
- 정적 웹사이트를 위한 대표 아키텍처는 S3 + CloudFront
- Lambda나 EC2 사용은 오버엔지니어링
핵심 키워드:
- 정적 콘텐츠
- 서버리스
- S3
- CloudFront
- 비용 효율, 확장성
Q7.
지문 (요약):
S3에 저장된 데이터를 KMS로 암호화하면서, 자동 키 순환 및 운영 오버헤드를 줄이고 싶음
질문: 어떤 방식이 가장 적합한가?
정답: B. CMK를 생성하고 S3 기본 암호화로 설정
해설:
- S3 + KMS + 기본 암호화 설정 = 매년 자동 키 회전 지원
- 수동 키 교체나 사전 암호화는 관리 부담이 큼
핵심 키워드:
- SSE-KMS
- 기본 암호화 정책
- 고객 관리형 키
- 키 순환 자동화
블록 스토리지 (EBS, Instance Store) 관련 문제 분석
Q1.
지문
EC2에 붙은 EBS 볼륨의 데이터를 테스트 환경으로 복제하고 싶다. 원본에 영향을 주면 안 되며, 빠른 I/O 성능 필요.
정답: D
해설:
- EBS Fast Snapshot Restore 사용 → 복제 후 지연 최소화
- Instance Store는 비휘발성 아님(데이터 손실 우려)
Q2.
지문
EC2에서 지연이 민감한 인메모리 DB를 운영 중이며, 네트워크 비용을 절감하고 성능을 최대로 하고 싶다.
정답: A
해설:
- EBS 볼륨 + 클러스터 배치 그룹 조합 → AZ 내 고속 통신 + 네트워크 비용 절감
- 핵심 키워드: 고성능, 저지연, EC2, 네트워크 대역폭
Q3.
지문
제약회사가 S3에 데이터를 보관하고, 자주 사용하는 일부는 빠르게 접근하길 원함.
정답: C
해설:
- Storage Gateway - Volume Gateway (캐시 모드) 사용
- 자주 쓰는 데이터는 로컬 캐시, 전체 데이터는 S3에 저장
Q4.
지문
온프레미스에 있는 대규모 데이터를 AWS로 옮기고자 하며, 일부는 빠른 접근이 필요함.
정답: C
해설:
- 캐시된 볼륨 방식의 Storage Gateway – Volume Gateway
- 백엔드는 Amazon S3이지만, 앞단은 iSCSI 방식
Q5.
지문
여러 EC2 인스턴스가 같은 파일을 공유해야 함
보기 요약
- D: FSx (Windows 기반)
- E: EBS (gp2) → 공유용으로 마운트
정답: A, D
해설:
- EBS는 한 인스턴스 전용 (Multi-Attach 조건 제외)
- 파일 공유에는 FSx 또는 EFS 적합
'공부일지' 카테고리의 다른 글
첫 면접 복기 (0) | 2025.07.14 |
---|---|
CNN 이해하기 (0) | 2025.05.08 |
용어 정리 (0) | 2025.05.02 |
CDN(Content Delivery Network): 정적파일 캐싱 (0) | 2025.04.28 |