S3 핵심 정리 — 버킷·버전 관리·암호화 한 번에

이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 네 번째 편입니다. S3는 강의 중반쯤 나오는데, 처음 들으면 "그냥 파일 저장소 아니에요?" 하는 인상을 받기 쉬워요. 그런데 막상 시험 문제를 풀어 보면 — 출제 빈도가 가장 높은 단원 중 하나입니다. EC2랑 거의 비슷하거나 더 많이 나와요.

이유가 있습니다. AWS의 거의 모든 서비스가 어딘가에서 한 번씩 S3를 거쳐 가요. 백업 저장도 S3, 정적 웹사이트 호스팅도 S3, 데이터 레이크도 S3, 이벤트 트리거의 출발점도 S3, 하이브리드 스토리지 게이트웨이의 백엔드도 S3 — 시험 시나리오의 절반 가까이가 어떤 식으로든 S3를 끼고 갑니다. 그래서 S3를 단단히 잡고 가면 다른 단원의 시나리오 문제가 한결 가벼워져요.

이 글에서는 S3 본체부터 시작해서 — 버전 관리·복제·스토리지 클래스 7종·수명 주기·암호화 5종·MFA Delete·Object Lock·Pre-signed URL·정적 웹사이트 호스팅·이벤트 알림까지 한 번에 풀고, 그 주변 스토리지 풀세트(Storage Gateway·FSx·Snow Family·DataSync·Transfer Family)도 묶어서 정리합니다. 분량이 좀 됩니다. 한 번에 다 외우려 하지 말고, "왜 이렇게 설계됐는가" 만 머리에 들어와도 충분해요.

S3가 도대체 뭘 하는 서비스인가요

S3는 풀어 쓰면 Simple Storage Service — 그러니까 "파일을 저장하는 단순한 창고"입니다. 회사로 치면 거대한 사물함 빌딩 같은 거예요. 사물함마다 이름표가 붙어 있고(키), 그 안에 내용물이 들어 있고(값), 옆에는 메모지(메타데이터)와 색깔 라벨(태그)이 붙어 있어요. 이 사물함이 사실상 무제한으로 늘어납니다.

활용 사례가 굉장히 광범위합니다 — 백업·재해 복구, 아카이빙, 하이브리드 클라우드 스토리지, 미디어 호스팅, 데이터 레이크, 빅데이터 분석, 소프트웨어 배포, 정적 웹사이트 호스팅. 한 마디로 "어딘가에 파일을 두고 싶다" 싶은 모든 시나리오가 S3로 풀립니다.

버킷 — 사물함 한 동의 이름

S3에서 가장 큰 단위가 버킷(Bucket) 입니다. 사물함 빌딩 한 동이라고 보시면 돼요. 여기 시험에 자주 나오는 함정이 하나 있습니다.

버킷 이름은 전 세계 모든 AWS 계정·모든 리전에서 고유(Globally Unique) 해야 합니다. 누군가 이미 my-bucket을 만들었으면, 다른 사람·다른 회사·다른 리전이라도 그 이름은 못 써요. 마치 도메인 이름처럼요.

그런데 또 헷갈리는 게 — 콘솔에서는 글로벌하게 보이지만, 실제 버킷은 특정 리전에 생성됩니다. 이게 무슨 말이냐면 — 이름은 전 세계에서 유일하지만, 실제 파일이 물리적으로 저장되는 곳은 서울이면 서울, 도쿄면 도쿄 한 군데라는 뜻이에요. 시험에 "버킷이 글로벌인가 리전인가" 묻는 보기가 나오면 답은 "이름은 글로벌, 데이터는 리전" 입니다.

명명 규칙도 자주 출제돼요.

• 소문자/숫자로 시작
• 대문자·언더스코어 불가
• 3~63자
• IP 주소 형식 불가 (192.168.5.4 같은 거 안 됨)

기본 설정이 또 시험 단골입니다. 새 버킷을 만들면 — 퍼블릭 액세스 차단 ON, 버전 관리 비활성화, SSE-S3 암호화 활성화 가 디폴트예요. 즉 기본은 비공개·버전 관리 꺼짐·기본 암호화 켜짐.

객체 — 사물함 안의 한 개 한 개

버킷 안에 들어가는 게 객체(Object) 입니다. 객체 하나는 다음 다섯 가지로 구성돼요.

• 키(Key) — 객체의 전체 경로 (예: folder1/folder2/file.txt)
• 값(Body) — 실제 파일 내용
• 메타데이터 — 키-값 쌍의 부가 정보
• 태그 — 최대 10개까지
• 버전 ID — 버전 관리 켜져 있을 때

여기서 처음 헷갈리는 부분 — S3에는 실제 디렉터리 구조가 없어요. 슬래시(/)가 들어가도 실제로는 폴더가 아니라, 그냥 키 이름의 일부일 뿐입니다. 콘솔에서는 폴더처럼 보이지만 내부적으로는 평평한(Flat) 키 공간이에요. 그래서 시험에 "S3 폴더 구조에 의존해서…" 같은 보기가 나오면 함정인 경우가 많습니다.

객체 하나의 최대 크기는 5TB이고, 5GB를 넘으면 무조건 멀티파트 업로드 를 써야 합니다. 이게 시험 단골이에요. "10GB 파일을 어떻게 올리나?" 같은 시나리오의 정답은 항상 멀티파트 업로드.

S3 버전 관리(Versioning) — 실수로 덮어써도 살릴 수 있게

버전 관리는 버킷 레벨에서 켜는 기능입니다. 회사 비유로 — 사물함 안의 서류를 새 버전으로 갈아 끼울 때마다 옛날 버전을 한 칸 뒤로 쌓아 두는 거예요. 그래서 실수로 덮어써도 이전 버전을 다시 꺼낼 수 있습니다.

여기서 시험 함정이 두 개 있어요.

첫째, 버전 관리를 켜기 전에 이미 있던 파일의 버전 ID는 null 입니다. "이때부터 버전 관리 시작"이라는 표시예요. 시험에 "이 파일의 버전 ID가 null인 이유는?" 같은 보기가 나오면 답은 "버전 관리 활성화 이전에 업로드된 파일이라서" 입니다.

둘째, 한 번 활성화한 버전 관리는 완전히 비활성화할 수 없어요. 일시 중단(Suspend)만 가능하고, Suspend해도 기존 버전들은 그대로 살아 있습니다. 시험에 "버전 관리를 끄면 이전 버전이 다 사라지나요?" 같은 보기가 나오면 답은 "아니다, 그대로 유지된다".

삭제 동작이 또 단골 함정입니다.

S3 복제 — 다른 리전·다른 계정으로 자동 복사

복제는 두 종류로 나뉩니다.

구분	CRR (Cross-Region Replication)	SRR (Same-Region Replication)
의미	리전 간 복제	동일 리전 복제
사용 사례	규정 준수, 지연 시간 최소화, 계정 간 복제	로그 집계, 프로덕션/테스트 환경 동기화

회사 비유로 풀면 — CRR은 서울 본사 사물함의 내용을 도쿄 지사 사물함에 자동으로 복사해 두는 거고, SRR은 같은 빌딩 안의 다른 동에 복사해 두는 거예요.

전제 조건이 명확합니다.

• 소스·대상 버킷 모두 버전 관리 활성화 필요 (이게 안 켜져 있으면 복제 자체가 안 됨)
• 비동기식(Asynchronous) 으로 백그라운드에서 처리
• S3 서비스가 양쪽 버킷에 접근할 IAM 역할 필요
• 다른 AWS 계정 간 복제도 지원
• 복제된 객체는 원본과 동일한 버전 ID를 유지

여기서 시험에 자주 나오는 함정이 네 개 있어요.

1. 복제 활성화 이전에 있던 객체는 자동으로 복제되지 않습니다. 활성화 시점부터 새로 들어오는 객체만 복제돼요. 기존 객체를 복제하려면 S3 Batch Replication 을 별도로 써야 합니다.
2. 삭제 마커는 기본적으로 복제 안 됨 — 선택적으로 활성화는 가능하지만 디폴트는 꺼져 있어요.
3. 특정 버전 ID 지정 영구 삭제는 절대 복제 안 됩니다. 백업 보호가 목적인 안전장치예요. 한쪽 계정이 해킹돼서 누가 의도적으로 영구 삭제를 해도, 그게 다른 쪽까지 전파되지 않게 막는 거죠.
4. 복제 연쇄(Chaining) 불가 — A→B→C 설정해도 A에 올린 객체는 B까지만 가고 C로는 안 갑니다.

S3 스토리지 클래스 7종 — 보관 창고 등급 고르기

S3는 한 가지 클래스만 있는 게 아니라 7종의 스토리지 클래스 중에서 골라 쓸 수 있어요. 회사 비유로 풀면 — 보관 창고 등급입니다. 매일 꺼내 보는 자료는 책상 옆 서랍, 가끔 보는 자료는 사무실 캐비닛, 1년에 한 번 볼까 말까 한 자료는 지하 창고, 7년 동안 안 꺼낼 법무 자료는 외부 보관소 — 이런 식으로 등급이 나뉘는 거예요. 클래스별 특성·가격은 AWS의 S3 스토리지 클래스 공식 페이지에 한 번 더 정리돼 있어서, 시험 전에 한 번 훑어보면 좋아요.

여기서 한 가지 짚고 가요. 내구성(Durability)은 모든 클래스에서 11개의 9 (99.999999999%) 로 동일합니다. 1,000만 개 객체를 저장하면 1만 년에 1개가 분실되는 수준. 등급별로 차이 나는 건 가용성(Availability)·최소 저장 기간·검색 시간 입니다.

클래스	가용성	최소 저장	검색 시간	AZ	특징
Standard	99.99%	없음	즉시	≥3	기본 클래스, 자주 접근
Standard-IA	99.9%	30일	즉시(밀리초)	≥3	가끔 접근, 즉시 복구 필요, DR/백업
One Zone-IA	99.5%	30일	즉시(밀리초)	1	단일 AZ, IA보다 20% 저렴, 재생성 가능 데이터
Glacier Instant Retrieval	99.9%	90일	즉시(밀리초)	≥3	분기 1회 액세스, 즉시 검색
Glacier Flexible Retrieval	99.99%	90일	1분~12시간	≥3	구 Glacier, 장기 아카이브
Glacier Deep Archive	99.99%	180일	12~48시간	≥3	가장 저렴, 7~10년 장기
Intelligent-Tiering	99.9%	없음	계층별	≥3	접근 패턴 모름, 자동 계층 이동, 검색 비용 X

여기서 시험 함정이 하나 — Reduced Redundancy Storage(RRS)는 사용 중단(Deprecated) 된 클래스입니다. 시험 보기에 등장하면 거의 100% 오답이에요.

Glacier Flexible Retrieval의 검색 시간 옵션도 외워둘 가치가 있습니다.

옵션	시간
Expedited	1~5분
Standard	3~5시간
Bulk	5~12시간 (무료)

Glacier Deep Archive는 — Standard 12시간, Bulk 48시간.

Intelligent-Tiering의 계층 이동 규칙도 한 번 짚고 갑니다. 자주 액세스(기본) → 30일 미사용 시 IA → 90일 미사용 시 아카이브 즉시 액세스로 자동 이동. 선택적으로 90일+ 아카이브 액세스, 180일+ 딥 아카이브 액세스도 설정 가능. 검색 비용이 없다는 게 결정적인 차이라서, "접근 패턴을 모를 때" 시나리오의 정답이 거의 항상 이쪽이에요.

> 키워드 매칭 한 줄 정리 — "접근 패턴 모름" → Intelligent-Tiering / "재생성 가능 + 비용 최소" → One Zone-IA / "12~48시간 검색 OK + 장기 보관" → Glacier Deep Archive.

S3 수명 주기 정책(Lifecycle) — 자동으로 등급 내려보내기

매번 손으로 "이건 30일 됐으니까 IA로 옮기자"고 할 수는 없잖아요. 수명 주기 정책(Lifecycle Rules) 으로 자동화합니다. 작업 유형은 두 가지.

• 전환 작업(Transition) — 다른 스토리지 클래스로 자동 이동 (예: 30일 후 Standard → Standard-IA → 180일 후 Glacier)
• 만료 작업(Expiration) — 객체 자동 삭제 (예: 365일 후 로그 삭제), 버전 관리 활성화 시 이전 버전(Non-current version) 삭제, 미완성 멀티파트 업로드(Incomplete Multipart Uploads) 자동 정리

마지막 항목이 의외로 중요해요. 멀티파트 업로드가 중간에 실패하면 그 조각들이 그대로 남아서 비용이 계속 청구돼요. 수명 주기에서 "7일 지난 미완성 업로드는 자동 삭제"를 걸어 두는 게 표준 모범 사례입니다.

규칙 적용 범위는 — 버킷 전체, 특정 접두사(Prefix), 특정 객체 태그(Tags) 기준. 이 셋을 조합해서 세분화된 정책을 짤 수 있어요.

시험에 자주 나오는 시나리오 패턴을 한 번 풀어 보겠습니다.

• 원본 이미지 — Standard에서 시작 → 60일 후 Glacier Flexible Retrieval로 전환 (한 번 처리하고 나면 거의 안 봄)
• 썸네일(재생성 가능) — One Zone-IA에서 시작 → 60일 후 만료(삭제) (없어지면 다시 만들면 됨)
• 삭제된 객체 30일 즉시 복구 + 그 이후 365일은 48시간 내 복구 — 버전 관리 활성화 + 비최신 버전 Standard-IA → 30일 후 Glacier Flexible

이런 식으로 데이터의 성격에 맞춰 등급을 단계적으로 내려보내는 게 수명 주기 정책의 핵심입니다.

여기서 짝지어 외울 게 하나 — S3 Analytics입니다. 언제 Standard에서 Standard-IA로 전환하는 게 최적인지 분석해 주는 도구예요. 함정 하나 — Standard → Standard-IA 전환만 추천하고, One Zone-IA나 Glacier 전환은 추천하지 않습니다. 24~48시간 후에 첫 결과가 나오고, 매일 업데이트되는 CSV 보고서를 생성해요.

S3 성능 최적화 — Prefix·Multipart·Transfer Acceleration

S3는 자체적으로 굉장히 빠른데, 더 빠르게 쓰려면 몇 가지 기법이 있어요.

기본 성능은 접두사(Prefix)당 다음과 같습니다.

• PUT/COPY/POST/DELETE: 초당 3,500개
• GET/HEAD: 초당 5,500개

핵심은 — 여러 접두사로 객체를 분산하면 성능이 배수로 늘어납니다. 4개의 Prefix를 쓰면 GET이 22,000/초까지 가요. 즉 폴더 구조를 짤 때 한 폴더에 다 몰아넣지 말고, 적당히 분산하는 게 좋습니다.

업로드 최적화는 두 가지.

기능	설명	기준
멀티파트 업로드	큰 파일을 조각으로 나눠 병렬 업로드 후 합침	100MB 이상 권장, 5GB 초과 필수
S3 Transfer Acceleration	엣지 로케이션 → AWS 프라이빗 글로벌 네트워크 경유	대륙 간 전송 시 효과적

비유로 풀면 — 멀티파트는 "큰 짐을 여러 명이 나눠서 동시에 옮기기"고, Transfer Acceleration은 "근처 엣지 사무실에 일단 맡기면 AWS 내부 고속도로 타고 본부까지 빠르게 옮겨줌"이에요.

다운로드 최적화는 두 가지.

기능	설명
Byte-Range Fetches	특정 바이트 범위만 요청, GET 병렬화 가능. 파일 헤더 50바이트만 읽고 싶을 때 유용
S3 Select	SQL을 사용해 객체 내에서 필요한 데이터만 추출

S3 Select는 "10GB CSV 파일에서 특정 컬럼만 뽑아내고 싶다" 같은 시나리오에 답이에요. 파일 전체를 다운로드하지 않고 서버 쪽에서 필터링한 결과만 받습니다.

이벤트 알림과 EventBridge — S3가 트리거가 되는 순간

S3 버킷에 객체가 새로 생기거나 삭제되거나 복원되거나 복제되는 이벤트가 일어나면 — 이걸 다른 서비스에 알림으로 보낼 수 있어요. 회사 비유로 — 사물함에 새 서류가 들어오자마자 자동으로 메일 알림이 가는 거예요.

직접 알림을 보낼 수 있는 대상은 3가지입니다.

1. Amazon SQS 큐
2. Amazon SNS 주제
3. AWS Lambda 함수

접두사·접미사로 필터링도 가능해요. 예를 들어 "이미지 폴더에 .jpeg 확장자가 들어올 때만" 같은 식.

더 고급으로 가면 Amazon EventBridge 통합이 있어요. S3 이벤트를 EventBridge로 보내면 — 18개+ AWS 서비스로 라우팅 가능 (Step Functions, Kinesis 등), 메타데이터·크기 같은 고급 필터링, 동시에 다중 목적지로 전송, 이벤트 아카이브·재생 까지 됩니다. "복잡한 이벤트 라우팅이 필요" 시나리오의 답은 EventBridge.

Pre-signed URL — 비공개 객체 잠깐 빌려주기

기본적으로 S3 버킷은 비공개입니다. 그런데 잠깐 외부 사람에게 "이 파일 다운로드만 해라" 하고 싶을 때가 있죠. 이걸 Pre-signed URL 로 풀어요.

회사 비유로 — 평소엔 잠긴 사물함을 한 시간만 열 수 있는 일회성 열쇠를 만들어 주는 겁니다. URL을 받은 사람은 그 시간 동안만 그 객체에 접근할 수 있어요.

여기 시험 함정이 두 개.

첫째, URL을 사용하는 사람은 URL 생성자의 권한을 그대로 상속받습니다. 즉 GetObject 권한을 가진 사람이 만든 URL이면 GET 가능, PutObject 권한이 있으면 업로드도 가능해요.

둘째, 만료 시간이 콘솔과 CLI/SDK에서 다릅니다.

생성 도구	최대 만료 시간
S3 콘솔	12시간
AWS CLI / SDK	168시간 (7일)

시험에 "Pre-signed URL의 최대 만료 시간"을 묻는 보기가 나오면 — 콘솔이면 12시간, CLI/SDK면 168시간(7일). 헷갈리지 마세요.

AWS 계정이 없는 외부 사용자에게도 임시 접근 허용이 가능해서, 유료 콘텐츠 다운로드 링크나 브라우저에서 S3로 직접 업로드 받을 때 자주 씁니다.

S3 보안 — 5가지 암호화 + MFA Delete + Object Lock

S3 보안은 시험 함정의 본진이에요. 천천히 가겠습니다. AWS가 공식적으로 정리해 둔 S3 보안 모범 사례 문서가 있는데, 시험 보고 나서도 실무에서 한 번 더 쓰게 되니 북마크해 두면 좋아요.

5가지 암호화 방식

방식	키 관리	특징	도구
SSE-S3	AWS	기본 암호화, AES-256, 헤더 x-amz-server-side-encryption: AES256	콘솔/CLI/SDK
SSE-KMS	AWS (KMS)	CloudTrail로 키 사용 감사 가능, KMS API Throttling 주의, S3 Bucket Key로 비용 절감	콘솔/CLI/SDK
SSE-C	고객	AWS는 키 저장 X (사용 후 즉시 폐기), HTTPS 필수, 콘솔 설정 불가	CLI/API만
DSSE-KMS	AWS (KMS)	KMS 기반 이중 암호화 (2023.6 출시)	콘솔/CLI/SDK
클라이언트 측 암호화	고객	전송 전 클라이언트에서 암호화. AWS는 키·암호화 여부 모름	클라이언트 코드

여기서 시험 함정 정리.

• SSE-C — 콘솔에서 설정 불가, CLI/API만, HTTPS 필수. 키워드 "AWS는 키를 저장하지 않는다 + 콘솔에서 안 됨"이면 SSE-C.
• SSE-KMS — KMS API 호출이 많아지면 Throttling 발생 가능. Service Quotas에서 할당량 증가 요청, 또는 S3 Bucket Keys로 KMS 호출 횟수를 줄여 비용·throttling 모두 절감.
• HTTPS 강제 — 버킷 정책에 aws:SecureTransport: false 조건으로 모든 요청 Deny.
• 버킷 정책은 기본 암호화 설정보다 먼저 평가됩니다. 시험에 "버킷 정책에서 X 암호화 요구하는데 기본 암호화는 Y로 설정. 결과는?" 같은 보기가 나오면 — 답은 버킷 정책이 이긴다.

MFA Delete — 가장 까다로운 자물쇠

MFA Delete는 시험 단골인데, 조건이 정말 까다로워요. 회사 비유로 — 사물함을 영구 삭제하려면 단순 카드만으로는 안 되고, 회장(루트) 본인이 직접 와서 손바닥 인증까지 추가로 해야 한다는 식.

조건을 모두 외워둬야 합니다.

• 버전 관리 활성화 필수
• 루트(Root) 계정만 활성화·비활성화 가능 — IAM 관리자 권한자도 불가 (이게 핵심 함정)
• 콘솔에서 설정 불가, CLI/API만
• MFA 필요한 작업 — 특정 버전 영구 삭제, 버전 관리 Suspend
• MFA 불필요한 작업 — 버전 관리 활성화, 일반 삭제(삭제 마커 생성)

시험에 "MFA Delete를 활성화하려는데 IAM 관리자가 콘솔에서 설정하려고 한다. 안 되는 이유는?" 같은 보기가 나오면 답은 "루트 계정만 가능하고, 콘솔이 아닌 CLI/API로만 설정 가능" 입니다.

Object Lock — 일정 기간 무조건 보호

규정 준수(Compliance) 시나리오에 자주 나오는 게 Object Lock이에요.

• Compliance Mode — 루트 포함 누구도 보존 기간 동안 삭제·수정 불가. 가장 엄격.
• Governance Mode — 일반 사용자는 못 지우지만, 특별 IAM 권한자(s3:BypassGovernanceRetention)는 수정·삭제 가능. 좀 유연한 모드.
• Legal Hold — 보존 기간과 무관하게 무기한 보호. s3:PutObjectLegalHold 권한자만 적용·해제 가능. 소송 같은 상황에 사용.

키워드 매칭 — "누구도 못 건드림" → Compliance / "특정 권한자는 가능" → Governance / "기간 무관 무기한" → Legal Hold.

여기 짝지어 알아둘 게 Glacier Vault Lock — 잠금 정책 설정 후 누구도 변경·삭제 불가. WORM(Write Once Read Many) 모델 그 자체. 규정 준수 시나리오에서 활용해요.

Block Public Access — 4중 안전망

퍼블릭 액세스 차단(Block Public Access) 은 4가지 설정으로 구성됩니다. 핵심은 — 버킷 정책에서 퍼블릭 허용을 명시해도, 이 차단 설정이 켜져 있으면 차단됩니다. 일종의 마스터 스위치예요. 계정 또는 버킷 수준에서 설정 가능하고, 시험에서 "버킷 정책으로 퍼블릭 허용했는데 왜 안 열리는가" 같은 시나리오의 정답이 거의 이쪽입니다.

정적 웹사이트 호스팅 + IAM 권한 평가

S3로 정적 사이트(HTML·CSS·JS) 호스팅하는 흐름은 단순해요.

1. 버킷 속성에서 정적 웹사이트 호스팅 활성화
2. 인덱스 문서 지정 (예: index.html)
3. 퍼블릭 액세스 차단 해제
4. 버킷 정책으로 s3:GetObject를 Principal: * 에게 허용

여기서 단골 트러블슈팅 — 403 Forbidden 에러는 거의 항상 버킷 정책 문제입니다. 퍼블릭 읽기 권한이 빠져 있거나 Block Public Access가 안 풀린 경우.

IAM 권한 평가 로직도 한 번 짚고 갑니다.

> IAM 정책의 Allow 또는 리소스 정책(버킷 정책)의 Allow + 어디에서도 명시적 Deny 없으면 → 허용

명시적 Deny는 1편에서 다룬 것처럼 항상 이깁니다. 그리고 EC2 → S3 접근 시나리오의 정답은 항상 IAM 역할(Role)을 EC2에 부여예요. 액세스 키 하드코딩은 무조건 오답.

S3 Batch Operations + Object Lambda + Access Points

여기서부터는 좀 더 고급 기능들이에요. 시험 시나리오에 키워드로 나오면 바로 매칭할 수 있게 정리합니다.

S3 Batch Operations

수백만 개 객체에 한 번에 작업을 걸고 싶을 때 — 메타데이터 수정, 버킷 간 복사, 기존 객체 암호화, ACL/태그 수정, Glacier 대규모 복원, Lambda 호출(사용자 정의 작업).

핵심 워크플로우는 3단계.

1. S3 Inventory — 전체 객체 목록 생성
2. Amazon Athena — SQL로 원하는 객체 필터링 (예: 암호화 안 된 객체만)
3. S3 Batch Operations — 필터링된 목록으로 일괄 작업 실행

자동 재시도, 진행 상황 추적, 완료 보고서 생성까지 다 해줘요.

S3 Object Lambda

원본 데이터를 복제하지 않고 단일 버킷으로 여러 뷰를 제공하는 패턴이에요. 흐름이 좀 길어요.

> 원본 S3 → S3 Access Point → Lambda(실시간 가공) → S3 Object Lambda Access Point → 애플리케이션

사용 사례 — PII 마스킹, XML→JSON 변환, 데이터 강화(Enrichment), 이미지 리사이즈. "원본은 그대로 두고 클라이언트마다 다른 형태로 보여주고 싶다"가 정답 키워드.

S3 Access Points + VPC

단일 버킷에 여러 진입점을 만들어 각각 독립적인 보안 정책을 부여하는 기능. VPC 내 리소스만 접근 허용하려면 — AP 네트워크 오리진을 VPC로 설정 + VPC 엔드포인트 생성. 권한 평가는 3중 정책 — VPC 엔드포인트 정책 + Access Point 정책 + 버킷 정책 — 모두 통과해야 접근 가능.

S3 Storage Lens — 조직 전체 분석

조직(Organization) 전체에 걸친 S3 사용량을 분석·최적화해주는 도구예요. 무료와 고급 티어가 다릅니다.

구분	무료 (Free)	고급 (Advanced, 유료)
지표 수	28개 기본	추가 (활동, 고급 비용 최적화)
데이터 보존	14일	15개월
집계 수준	버킷 수준까지	접두사(Prefix) 수준
CloudWatch 연동	불가	가능

기본 대시보드는 삭제 불가, 비활성화만 가능. 데이터 내보내기는 CSV 또는 Parquet 형식으로 S3 버킷에 저장.

Requester Pays + CORS + Access Logs — 자잘한 함정들

세 개를 묶어서 짧게 정리합니다.

Requester Pays — 데이터 전송 비용을 다운로드 요청자가 부담하는 모드. 버킷 소유자는 저장 비용만, 요청자는 전송 + 요청 비용. 요청자는 반드시 인증된 AWS 계정이어야 합니다(익명 불가). 대용량 데이터를 외부 사용자/계정과 공유할 때.

CORS — 함정 하나 — 리소스를 제공하는 타겟 버킷에 CORS 설정 합니다. 요청하는 쪽 버킷이 아니에요. 시험에 "CORS 설정을 어디에?" 같은 보기가 나오면 답은 타겟 버킷.

S3 Access Logs — 함정 두 개 — 대상 버킷은 원본과 동일 리전이어야 하고, 원본·대상이 같은 버킷이면 무한 로깅 루프가 발생합니다. 반드시 다른 버킷으로 보내야 해요.

Storage Gateway — 온프레미스에서 AWS 스토리지 쓰기

여기서부터는 S3 본체 밖의 스토리지 서비스들이에요. Storage Gateway는 온프레미스 서버에서 AWS 스토리지를 마치 로컬처럼 쓰게 해주는 하이브리드 게이트웨이입니다. 4가지 타입이 있어요.

타입	프로토콜	백엔드	특징
S3 File Gateway	NFS, SMB	Amazon S3	S3를 네트워크 드라이브처럼, 로컬 캐시, AD 통합 (SMB)
Volume Gateway - Cached	iSCSI	S3 (EBS 스냅샷 백업)	전체 데이터는 S3, 자주 쓰는 것만 로컬 캐시
Volume Gateway - Stored	iSCSI	S3 (EBS 스냅샷 백업)	전체 데이터는 온프레미스, S3에 비동기 백업
Tape Gateway	iSCSI-VTL	S3 → Glacier	물리 테이프 백업 대체, 기존 백업 SW 변경 없음

배포는 VMware ESXi, Microsoft Hyper-V, Linux KVM(온프레미스) 또는 Amazon EC2(클라우드).

키워드 매칭으로 외우는 게 가장 빨라요.

• "NFS/SMB + S3" → S3 File Gateway
• "iSCSI-VTL + 물리 테이프 대체 + Glacier" → Tape Gateway
• "블록 스토리지 + 전체 S3 + 자주 쓰는 것만 로컬 캐시" → Volume Gateway Cached
• "블록 스토리지 + 전체 로컬 + S3는 백업만" → Volume Gateway Stored

FSx — 관리형 파일 시스템 4종

EC2와 함께 쓰는 관리형 파일 시스템이에요. 4종이 있는데, 각각 용도가 명확히 갈립니다.

종류	프로토콜	호환 OS	주요 특징	사용 사례
Windows File Server	SMB, NTFS	Windows (+ Linux 가능)	AD 통합, Multi-AZ, S3 백업	Windows 앱, 공유 드라이브
Lustre	Lustre (POSIX)	Linux	HPC/ML 초고성능, S3 연동	HPC, ML, 비디오 처리
NetApp ONTAP	NFS, SMB, iSCSI	Linux, Windows, macOS, VMware	중복 제거 O, Auto 스케일링, Multi-AZ	온프레미스 ONTAP 마이그레이션
OpenZFS	NFS (다중 버전)	Linux, Windows, macOS	최대 100만 IOPS, 0.5ms 미만 지연, 중복 제거 X	ZFS 워크로드

FSx for Lustre의 배포 옵션 두 가지를 외워둬야 해요.

• Scratch — 임시 저장, 데이터 복제 없음, 비용 최적화, Persistent의 6배 성능
• Persistent — 장기 저장, 동일 AZ 내 복제, 서버 장애 시 투명 Failover

시험 함정 두 개:

• FSx for Windows는 Linux EC2에도 마운트 가능 (이게 의외)
• NetApp ONTAP는 중복 제거 O / OpenZFS는 X (둘이 비슷해 보이지만 이 차이 있음)

키워드 매칭 — "HPC/ML + S3 연동 + 고성능" → Lustre / "Windows + AD + SMB" → Windows File Server / "NetApp + 다중 OS + 중복 제거" → NetApp ONTAP / "ZFS + NFS" → OpenZFS.

Snow Family — 물리적 데이터 마이그레이션

네트워크가 너무 느려서 데이터 옮기기에 시간이 너무 오래 걸린다 — 이럴 때 AWS가 실제 디바이스를 트럭으로 보내주는 게 Snow Family 입니다.

서비스	스토리지	컴퓨팅	사용 사례
Snowcone	~8TB HDD / 14TB SSD	소형 (DataSync 에이전트 내장)	소규모, 오지 데이터 수집
Snowball Edge Storage Optimized	최대 210TB	EC2, Lambda	페타바이트급 마이그레이션
Snowball Edge Compute Optimized	28TB	EC2, Lambda 고성능	엣지 컴퓨팅, ML, 미디어 트랜스코딩
Snowmobile	최대 100PB	없음 (트럭형)	엑사바이트급 데이터센터 마이그레이션

여기서 시험 단골이 — 네트워크 전송에 1주일(7일) 이상 걸리면 Snow Family 권장입니다. "1Gbps 회선으로 100TB 옮기면 며칠?" 같은 계산 문제가 나오면, 일주일 넘으면 답은 Snowball.

작업 유형 세 가지 — Import to S3(온프레미스→AWS), Export from S3(AWS→온프레미스), Local Compute and Storage Only(엣지 컴퓨팅).

함정 두 개:

• Snowball → Glacier 직접 전송 불가 — Snowball → S3 Standard → 수명 주기 정책 → Glacier 경로로 가야 합니다.
• Snowcone에 DataSync 에이전트가 내장돼 있어요 — 대역폭이 부족할 때 Snowcone으로 데이터 동기화하는 시나리오의 답.

DataSync vs Transfer Family vs Storage Gateway

데이터 전송 서비스들도 정리해 둡니다.

서비스	프로토콜/방식	백엔드	에이전트	특징
AWS DataSync	NFS, SMB, HDFS	S3, EFS, FSx	온프레→AWS 시 필요, AWS 서비스 간 불필요	스케줄 기반 동기화, 메타데이터·권한 보존
AWS Transfer Family	FTP, FTPS, SFTP	S3, EFS	불필요	레거시 FTP 통합, AD/LDAP/Cognito 인증
Snow Family	물리 전송	S3	불필요	대역폭 부족 시, 오프라인
Storage Gateway	NFS/SMB/iSCSI	S3, S3 Glacier, EBS	VM으로 배포	하이브리드 클라우드

DataSync에서 외워둘 포인트:

• 스케줄 기반 동기화 — 실시간/Continuous 아님
• 메타데이터 + 파일 권한(NFS POSIX, SMB) 보존
• 대역폭 제한 설정 가능
• DataSync + Snowcone — 대역폭 부족 시 Snowcone(에이전트 내장)으로 데이터 동기화

키워드 매칭 — "FTP/SFTP로 S3/EFS 접근" → Transfer Family / "스케줄 기반 동기화 + 메타데이터 보존" → DataSync / "물리 전송 + 대역폭 부족" → Snow Family.

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 S3·스토리지 영역의 핵심입니다. 분량이 정말 많은데, 시험 직전에 다시 펼쳐 볼 압축 노트를 마지막에 박아 둘게요. 이 부분만 시험 전날 한 번 더 읽으면 거의 다 떠오릅니다.

S3 기본

• 버킷 이름 = 전 세계 고유, 실제 데이터는 특정 리전
• 명명 규칙 — 소문자/숫자 시작, 대문자·언더스코어 X, 3~63자, IP 형식 X
• 기본 — 퍼블릭 차단 ON, 버전 관리 OFF, SSE-S3 ON
• 객체 최대 5TB, 5GB 초과 → 멀티파트 업로드 필수, 100MB 이상 권장
• 키에 슬래시 들어가도 실제 폴더 구조는 없음

버전 관리

• 활성화 이전 파일 ID = null
• Suspend해도 기존 버전 유지, 완전 비활성화 불가
• 버전 ID 미지정 삭제 = 삭제 마커 추가(복구 가능)
• 버전 ID 지정 삭제 = 영구 삭제(복구 불가)

복제(CRR/SRR)

• 양쪽 버전 관리 활성화 필수, 비동기, IAM 역할 필요
• 기존 객체 → S3 Batch Replication
• 삭제 마커는 기본 복제 X (선택적 활성화)
• 버전 ID 지정 영구 삭제는 절대 복제 X
• 연쇄(A→B→C) 불가

스토리지 클래스

• 내구성은 모두 11 9s 동일, 차이는 가용성·최소 저장·검색 시간
• "접근 패턴 모름" → Intelligent-Tiering (검색 비용 X)
• "재생성 가능 + 비용 최소" → One Zone-IA
• "12~48시간 OK + 장기" → Glacier Deep Archive
• RRS는 Deprecated — 보기에 나오면 오답
• S3 Analytics → Standard → Standard-IA만 추천

수명 주기

• Transition(클래스 이동) + Expiration(삭제)
• 미완성 멀티파트 업로드 자동 정리 룰 필수
• Prefix·Tag 기준 적용 가능

암호화 + 보안

• SSE-C — 콘솔 X, CLI/API만, HTTPS 필수
• SSE-KMS — Throttling 주의, S3 Bucket Keys로 비용·호출 절감
• HTTPS 강제 — 버킷 정책에 aws:SecureTransport: false Deny
• 버킷 정책이 기본 암호화보다 먼저 평가
• MFA Delete — 버전 관리 + 루트 계정만 + CLI/API만
• Object Lock — Compliance(누구도 X) / Governance(특정 권한자) / Legal Hold(무기한)
• Block Public Access — 버킷 정책의 퍼블릭 허용을 무효화하는 마스터 스위치

Pre-signed URL

• 콘솔 = 최대 12시간 / CLI/SDK = 최대 168시간(7일)
• 사용자가 생성자의 권한 상속 (GET·PUT 모두 가능)

이벤트 알림

• 직접 대상 3가지 — SQS / SNS / Lambda
• 대상 서비스의 리소스 기반 정책에서 S3 허용 필요
• 고급 라우팅·필터링 → EventBridge

정적 웹 호스팅

• 403 → 버킷 정책 확인 (퍼블릭 읽기 누락)
• EC2 → S3 접근은 IAM 역할 (액세스 키 하드코딩 X)

S3 고급

• S3 Batch Operations — Inventory → Athena → Batch Operations 워크플로우
• S3 Object Lambda — 원본 복제 없이 실시간 가공된 뷰 제공
• S3 Access Points — 단일 버킷 + 여러 보안 정책, VPC 전용 접근 가능
• Storage Lens — 무료 14일 / 고급 15개월 + Prefix 수준 + CloudWatch
• CORS — 타겟 버킷에 설정 (요청 버킷 X)
• Access Logs — 동일 리전, 같은 버킷이면 무한 루프

Storage Gateway 4종

• NFS/SMB + S3 → File Gateway
• iSCSI-VTL + 테이프 + Glacier → Tape Gateway
• 자주 쓰는 것만 캐시 → Volume Cached
• 전체 로컬 + S3 백업만 → Volume Stored

FSx 4종

• HPC/ML + S3 → Lustre (Scratch=임시 6배 성능 / Persistent=장기)
• Windows + AD + SMB → Windows File Server (Linux 마운트도 가능)
• NetApp + 다중 OS → NetApp ONTAP (중복 제거 O)
• ZFS + NFS → OpenZFS (중복 제거 X)

Snow Family

• 1주일 이상 전송 시 권장
• Snowball → Glacier 직접 X, S3 경유 후 수명 주기로 이동
• Snowcone — DataSync 에이전트 내장

데이터 전송

• DataSync — 스케줄 기반, 메타데이터·권한 보존, 온프레→AWS 에이전트 필요
• Transfer Family — FTP/FTPS/SFTP, S3·EFS, AD/LDAP/Cognito 인증

여기까지가 SAA-C03 시험의 S3·스토리지 영역의 전부입니다. 분량은 많지만 키워드 매칭으로 표를 외워두면 시나리오 문제 절반은 거의 자동으로 풀려요. 한두 번 정독으로 끝내지 말고, 표를 직접 손으로 다시 그려보면서 머리에 새겨두는 걸 권합니다. 특히 스토리지 클래스 7종, FSx 4종, Storage Gateway 4종은 키워드 → 정답 매핑이 자동으로 떠올라야 해요.

다음 글(5편)에서는 RDS·Aurora·ElastiCache·DynamoDB 같은 데이터베이스 영역을 정리합니다. SAA에서 출제 빈도가 높고, 특히 Multi-AZ vs Read Replica의 차이, Aurora의 글로벌 데이터베이스, DynamoDB의 강한 일관성·궁극적 일관성 같은 부분이 단골 함정이에요.

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.

• 1편 — IAM
• 2편 — EC2 / Storage
• 3편 — ELB · ASG
• 4편 — S3 (스토리지) (현재 글)
• 5편 — Databases
• 6편 — Networking
• 7편 — Messaging
• 8편 — Containers · Serverless
• 9편 — Monitoring
• 10편 — Analytics · ML
• 11편 — Security
• 12편 — DR · Migration
• 13편 — Architectures
• 14편 — Exam Prep (완)