S3 버킷 핵심 정리 — 객체 스토리지 입문 1편

이 글은 Amazon S3 심화 정리 시리즈의 첫 번째 편입니다. AWS를 처음 시작하는 분들이 거의 가장 먼저 만나는 서비스 중 하나가 S3 버킷이에요. 이름은 단순한데 — Simple Storage Service — 막상 들어가 보면 S3 버킷·객체·키·접두사·스토리지 클래스·버전 관리 같은 단어가 줄지어 나와서 "이거 정말 단순한가?" 싶어집니다.

이 시리즈는 그 부담을 덜어 주는 게 목표예요. 한 번에 다 외우려 하지 말고 흐름과 비유만 머리에 들어와도 충분합니다. 7편이 끝날 즈음엔 S3 버킷 보안·복제·라이프사이클·고급 기능까지 한 그림으로 잡힐 거예요. 이번 1편은 S3 버킷 자체의 뼈대 — 만드는 법, 이름 규칙, 객체와 키, 스토리지 클래스, 가격 — 을 한 번에 쭉 따라가요.

공식 사양이 궁금하면 S3 사용자 가이드를 같이 펼쳐 두세요. 시리즈는 그 가이드를 한국어 학습 노트로 풀어쓴다고 보면 됩니다.

왜 S3 버킷이 처음엔 어렵게 느껴질까요

이유는 두 가지예요.

첫째, "객체 스토리지"가 뭔지 직관이 안 옵니다. 우리가 평소 쓰는 윈도 탐색기·맥 파인더는 폴더 안에 폴더가 있고 그 안에 파일이 있는 계층 구조예요. 그런데 S3는 폴더처럼 보이지만 사실은 평면 구조입니다. "왜 굳이?" 라는 의문이 생기죠.

둘째, 스토리지 클래스가 7개로 너무 많아 보입니다. Standard·Standard-IA·One Zone-IA·Intelligent-Tiering·Glacier Instant·Glacier Flexible·Glacier Deep Archive — 외국 SF 영화 우주선 이름 같은 게 줄지어 나오는데, 이게 다 비슷비슷해 보여서 어떤 걸 골라야 할지 막막합니다.

해결법은 한 가지예요. S3 버킷을 "회사 거대 사물함의 내 칸" 이라고 비유로 잡고, 스토리지 클래스를 "보관 창고 등급" 으로 풀면 갑자기 그림이 명확해집니다. 자주 꺼낼 자료는 책상 옆 사물함, 가끔 보는 자료는 창고, 거의 안 볼 자료는 외부 보관소 — 이런 식으로요. 이 글은 그 비유를 따라 처음부터 풀어 갑니다.

S3 버킷이 도대체 어떤 서비스인가요

S3 — Simple Storage Service — 는 AWS에서 가장 일찍 공개된 서비스 중 하나입니다. 정의를 한 줄로 풀면 "객체 기반 스토리지(Object-based Storage) 서비스" 예요. 파일·이미지·비디오·문서·DB 백업 같은 거의 모든 종류의 파일을 S3 버킷 안에 넣고 보관할 수 있습니다.

회사 비유로 풀면 — S3 버킷은 회사 차원에서 운영하는 거대한 디지털 사물함의 내 칸이에요. 직원 누구나 (권한 있으면) 자기 칸에 자료를 넣고, 필요할 때 꺼내 봅니다. 다만 "사물함"이라는 단어로는 부족할 만큼 크기가 어마어마해요. 한 S3 버킷에 저장 가능한 데이터 양에 제한이 없습니다.

핵심 특징을 한 번에 정리하면 다음과 같아요.

• 무한 확장성 — 저장 데이터 양에 제한 없음
• 11 nines 내구성 — 99.999999999% 데이터 손실 방지. 1만 개 객체 저장 시 천만 년에 1개 손실 가능성 정도
• 99.99% 가용성 — 연간 약 52분의 다운타임만 허용
• 글로벌 가용성 — 대부분의 AWS 리전에서 사용 가능
• 공유 책임 모델 — AWS는 플랫폼·인프라 관리, 고객은 데이터 자체와 접근 설정 책임

여기서 시험 함정이 하나 있어요. "11 nines 내구성"과 "99.99% 가용성"이 비슷해 보이는데 완전히 다른 개념입니다.

• 내구성(Durability) — 데이터 자체가 손실되지 않고 유지되는 능력. 한 번 저장하면 거의 영구적으로 살아 있어요.
• 가용성(Availability) — 그 데이터에 언제든 접근 가능한가. 연 1년 365일 중 약 52분 정도는 접근 못 할 수 있다는 뜻.

데이터는 살아있지만 잠깐 못 꺼내는 시점이 있을 수 있다 — 이게 가용성이고, 데이터가 영구히 사라지는 사고 가능성 — 이게 내구성입니다.

S3 버킷을 쓰면 안 되는 경우

S3 버킷이 만능처럼 보여서 거의 모든 데이터를 거기에 넣고 싶어지는데, 쓰면 안 되는 자리가 분명히 있어요. 정리하면 이렇습니다.

• 애플리케이션 실행 — 코드를 돌리는 용도가 아닙니다. EC2·ECS·Lambda 자리예요.
• 운영체제·소프트웨어 설치 — OS 디스크가 아닙니다. EBS·EC2 자리.
• 블록 레벨 스토리지가 필요할 때 — DB 데이터 파일 같은 건 EBS·EFS.
• 고성능 컴퓨팅 스토리지 — FSx for Lustre 자리.
• 관계형/트랜잭션 DB — RDS·DynamoDB 자리.

요약하면 S3 버킷은 "한 번 쓰고 가끔 또는 자주 읽는 파일" 의 자리입니다. 한 줄씩 빠르게 갱신해야 하는 데이터(트랜잭션)는 DB가 적합해요.

내구성과 가용성 — S3 버킷이 어떻게 11 nines를 보장할까요

11 nines라는 숫자는 그냥 마케팅이 아니에요. S3 버킷은 모든 데이터를 최소 3개의 가용 영역(AZ) 에 걸쳐 자동으로 복제합니다. 한 데이터센터에 화재가 나도 다른 두 데이터센터에 사본이 있어서 데이터가 살아 있어요.

여기에 더해 다음과 같은 방어 장치가 깔려 있습니다.

• 시설 격리 — 데이터센터 간 물리적 분리
• 하드웨어 장애 대비 — 디스크·서버 장애를 가정한 설계
• 데이터 부패 방지 — TCP 체크섬으로 비트 단위 변형 감지
• 소프트웨어 버그 대비 — 신중한 배포 관행, 사양 패턴, 모델 체커
• 운영자 오류 대비 — 자동화 + 최소 권한 원칙

여기서 시험 함정이 하나 있어요. 이렇게 견고한 S3여도 다운된 적이 있긴 합니다. 그리고 S3가 다운되면 — EC2의 AMI, EBS 스냅샷처럼 S3를 백엔드로 쓰는 다른 AWS 서비스도 같이 영향을 받아요. S3는 사실상 AWS 인프라의 뼈대 같은 역할이라, S3 장애 = AWS 절반 이상이 흔들린다고 봐도 과언이 아닙니다.

> 한 줄 정리 — 내구성은 "데이터가 살아있는가", 가용성은 "지금 꺼낼 수 있는가". 둘 다 11 nines·99.99% 수준으로 매우 높지만 같은 개념이 아니다.

S3 버킷 — 회사 사물함에 내 칸 만들기

S3에서 데이터를 저장하는 단위가 S3 버킷(Bucket) 입니다. 회사 비유로 — 거대한 사물함 시스템 안에 내 이름을 박은 칸을 하나 분양받는 거예요. 그 칸 안에는 파일을 무제한으로 넣을 수 있어요.

S3 버킷 이름이 왜 전 세계 고유여야 하나

여기서 시험 함정이 하나 있어요. S3 버킷 이름은 전 세계적으로 고유해야 합니다. 모든 AWS 계정에 걸쳐서요. 내 계정 안에서만 고유한 게 아니라 지구 전체에서 단 하나뿐이어야 해요.

왜 이런 규칙이냐면 — S3 버킷에 접근하는 URL이 https://my-bucket.s3.amazonaws.com/... 형식이라, 전 세계 누구나 접근할 수 있는 도메인 같은 거예요. 도메인은 하나만 존재할 수 있죠.

이름 규칙을 정리하면:

• 3~63자 길이
• 소문자, 숫자, 하이픈(-)만 허용
• 대문자·공백 사용 불가
• 점(.)은 사용 가능하지만 SSL 인증서·Path-style 접근 시 문제가 될 수 있어 권장 X
• 전 세계적으로 고유

그래서 회사·프로젝트 이름을 그대로 쓰면 거의 항상 충돌해요. 보통 회사명 + 환경 + 용도 + 임의 식별자 (예: acme-prod-logs-2026-a1b2c3) 조합으로 만듭니다.

S3 버킷 생성 시 선택 사항

새 S3 버킷을 만들 때 결정해야 하는 항목들이에요.

• 리전(Region) — 데이터가 저장될 지역. 사용자와 가까운 리전을 골라야 지연이 짧음
• 버전 관리(Versioning) — 같은 객체의 여러 버전을 보관할지
• 암호화(Encryption) — 기본값 SSE-S3 또는 SSE-KMS
• Block Public Access — 공개 접근 차단 (보안 사고 방지의 첫 번째 방어선)
• Object Lock — 객체를 일정 기간 또는 영구히 삭제·변경 못 하게 잠금. 버킷 생성 시점에만 활성화 가능

마지막 Object Lock이 시험 함정이에요. 버킷을 만든 뒤에는 Object Lock을 켤 수 없습니다. WORM(Write Once Read Many) 모델이 필요한 워크로드라면 버킷 생성 단계에서 미리 켜야 해요.

CLI로 S3 버킷 만들기

# 버킷 생성 (us-east-1은 기본 리전이라 LocationConstraint 불필요)
aws s3api create-bucket \
  --bucket my-unique-bucket-name \
  --region us-east-1

# 버킷 목록 조회
aws s3 ls

# 다른 리전에 버킷 생성 (LocationConstraint 필수)
aws s3api create-bucket \
  --bucket my-bucket-name \
  --region ap-northeast-2 \
  --create-bucket-configuration LocationConstraint=ap-northeast-2

# 버킷 버전 관리 활성화
aws s3api put-bucket-versioning \
  --bucket my-bucket-name \
  --versioning-configuration Status=Enabled

# 버킷 삭제 (객체가 비어있어야 함)
aws s3api delete-bucket --bucket my-bucket-name --region us-east-1

여기서 가장 자주 만나는 함정 — us-east-1만 LocationConstraint 옵션을 안 받습니다. us-east-1은 historical reasons로 기본 리전이라 그래요. 다른 리전은 모두 명시해야 합니다.

객체 — S3 버킷 안에 들어가는 자료

S3 버킷 안에 들어가는 단위 하나하나가 객체(Object) 예요. 파일·이미지·비디오·문서·아카이브 다 됩니다.

객체 한 개의 최대 크기는 5TB. 5TB 넘으면 한 객체로 못 담아요. 다만 한 S3 버킷 안에 객체를 몇 개나 넣을 수 있느냐 — 무제한입니다. 정말 말 그대로 끝이 없어요.

객체는 단순히 "파일 + 내용"이 아니라 다음 6가지로 구성됩니다.

구성 요소	설명
키(Key)	객체의 고유 식별자, 파일 이름 역할
값(Value)	실제 데이터 내용
버전 ID(Version ID)	버전 관리 활성화 시 부여되는 고유 ID
메타데이터(Metadata)	생성일·크기·MIME 타입 등 부가 정보
태그(Tags)	키-값 쌍으로 분류·정책 적용에 사용
ACL	개별 객체 수준의 접근 제어

읽기 일관성 — 옛날엔 헷갈렸던 영역

오래 전에는 S3가 eventual consistency(최종 일관성)였어요. 객체를 업데이트하고 즉시 다시 읽으면 옛날 버전이 나오기도 했죠. 그래서 시험에 "S3 일관성"이 함정으로 자주 나왔습니다.

그런데 2020년 12월 이후 S3는 강한 일관성(Strong Consistency) 으로 바뀌었어요. 이제는 다음 두 경우 모두 즉시 최신 데이터가 보장됩니다.

• 신규 객체 쓰기 후 읽기 — 항상 최신 버전 반환
• 기존 객체 업데이트/삭제 후 읽기 — 최신 업데이트된 버전 반환

여기서 시험 함정이 하나 있어요. 옛날 자료에는 "S3는 eventual consistency"라고 쓰여 있는 게 아직 많은데, 현재 S3는 strong consistency입니다. 시험에서 옛날 표현이 보기로 나오면 함정이에요.

객체 키와 접두사 — 폴더처럼 보이지만 사실은 평면

이 부분이 처음 보는 분에게 가장 헷갈리는 영역입니다. 차근차근 풀어 갈게요.

키(Key) — 객체의 고유 이름

버킷 안 객체의 고유한 이름이 키(Key) 입니다. 예를 들어:

photos/2024/january/photo.jpg

윈도/맥에서 보면 — photos 폴더 안에 2024 폴더, 그 안에 january 폴더, 그 안에 photo.jpg 파일 — 이렇게 4단계 계층 같죠.

여기서 시험 함정이 하나 있어요. S3는 사실 폴더 구조가 없습니다. 위 예시의 키 전체가 photos/2024/january/photo.jpg 라는 한 덩어리 문자열이에요. 슬래시(/)는 그냥 키 안의 일반 문자고, 폴더 구분자가 아닙니다. 모든 객체는 버킷 안에 평면적으로 줄지어 저장돼 있어요.

접두사(Prefix) — 가상 폴더라는 시각적 도구

그럼 왜 콘솔에서는 폴더처럼 보일까요? S3가 접두사(Prefix) 라는 개념을 시각적으로 폴더처럼 렌더해 주기 때문이에요. 키의 앞부분(접두사)이 같은 객체끼리 묶어서 폴더 형태로 보여 주는 거죠.

회사 비유로 — 사물함 안의 자료를 모두 한 칸에 쌓아 놓는데, 자료 이름 앞에 사업부/연도/월/ 같은 접두어를 붙여 놓으니까 마치 폴더처럼 보이는 식입니다. 실제로는 폴더가 없고 자료만 잔뜩 있는 거예요.

이 평면 구조 덕에 S3는 무한 확장이 가능합니다. 폴더 트리 깊이 제한 같은 게 없거든요.

# 특정 접두사 아래 객체 목록 조회
aws s3 ls s3://my-bucket-name/photos/2024/

# 접두사 기반 복사
aws s3 cp s3://my-bucket-name/photos/ s3://destination-bucket/backup/ --recursive

> 한 줄 정리 — S3는 평면 구조, 슬래시는 그냥 키의 일반 문자. 폴더처럼 보이는 건 접두사를 시각적으로 폴더로 표현한 것뿐.

버전 관리 — 실수로 덮어써도 살아남기

버전 관리(Versioning) 는 같은 객체의 여러 버전을 버킷 안에 동시에 보관하는 기능이에요. 회사 비유로 — 사물함에 자료를 새로 넣을 때 옛날 버전을 버리지 않고 "v1, v2, v3 …" 식으로 라벨을 붙여 함께 보관하는 식입니다.

가장 큰 효용은 실수 방지예요. 누군가 실수로 파일을 덮어쓰거나 삭제해도 이전 버전이 살아 있어 복구할 수 있습니다. 깃 같은 버전 관리 시스템과 비슷한 개념이에요.

버전 관리는 세 가지 상태가 있습니다.

상태	설명
비활성(Unversioned)	기본값, 버전 관리 없음
활성(Enabled)	모든 객체에 고유 버전 ID 부여
중단(Suspended)	새 버전 생성 중단, 기존 버전은 유지

여기서 중요한 사실 — 버전 관리는 한 번 켜면 비활성으로 되돌릴 수 없어요. "중단(Suspended)"으로만 갈 수 있습니다. 그리고 기존 버전들은 그대로 유지돼요. 이걸 모르고 켰다가 나중에 비용 폭탄을 맞는 경우가 있습니다.

삭제 동작 — 삭제 마커의 정체

여기서 시험에 자주 나오는 개념이 삭제 마커(Delete Marker) 입니다. 버전 관리가 켜진 S3 버킷에서 객체를 삭제하면 — 실제로 데이터가 사라지지 않습니다. 대신 "이 객체는 삭제됐다"는 표식(삭제 마커)이 새 버전으로 추가돼요.

그래서 삭제했다가 "어 잘못 지웠다" 싶으면 — 삭제 마커를 제거하면 객체가 다시 살아납니다. 진짜로 영구 삭제하려면 특정 버전 ID를 명시해서 삭제해야 해요.

# 버전 관리 활성화
aws s3api put-bucket-versioning \
  --bucket my-bucket-name \
  --versioning-configuration Status=Enabled

# 모든 버전 목록 조회
aws s3api list-object-versions \
  --bucket my-bucket-name

# 특정 버전 다운로드
aws s3api get-object \
  --bucket my-bucket-name \
  --key file.txt \
  --version-id VERSION_ID \
  ./downloaded-file.txt

# 특정 버전 영구 삭제
aws s3api delete-object \
  --bucket my-bucket-name \
  --key file.txt \
  --version-id VERSION_ID

# 삭제 마커 제거 (객체 복구)
aws s3api delete-object \
  --bucket my-bucket-name \
  --key file.txt \
  --version-id DELETE_MARKER_VERSION_ID

비용 함정

여기서 시험 함정이 하나 있어요. 모든 버전이 저장 비용을 발생시킵니다. 100MB 파일을 100번 업데이트하면 100MB × 100 = 10GB의 저장 공간을 쓰는 거예요. 그래서 버전 관리만 켜고 방치하면 비용이 무섭게 불어납니다.

해결책은 라이프사이클 정책이에요. "이전 버전은 30일 뒤에 Glacier로 옮기고, 1년 뒤에는 삭제" 같은 규칙을 걸어 두면 자동으로 비용이 통제됩니다. 라이프사이클은 이 시리즈 5편에서 자세히 풀어 갈게요.

스토리지 클래스 — 7개의 보관 창고 등급

이제 가장 많이 헷갈리는 영역인 스토리지 클래스입니다. 한 S3 버킷 안에서도 객체별로 다른 클래스를 쓸 수 있어요. 7개나 돼서 처음 보면 "이게 다 뭐야?" 싶은데, 회사 비유로 풀면 갑자기 깔끔해져요. 실제 가격표는 S3 스토리지 클래스 페이지에서 그대로 확인할 수 있습니다.

회사 자료실에는 보통 등급이 있습니다.

• 책상 옆 자주 보는 폴더 — 즉시 꺼냄, 보관비 비쌈 (책상 공간이 비싸니까)
• 사무실 캐비닛 — 가끔 꺼냄, 약간 저렴
• 사무실 한쪽 창고 — 한 달에 한두 번, 더 저렴
• 외부 보관 창고 — 분기에 한 번, 훨씬 저렴
• 장기 아카이브 창고 — 1년에 한두 번, 가장 저렴 (꺼내려면 며칠 걸림)
• 법적 의무 보관소 — 7~10년 보관, 거의 안 봄, 압도적으로 저렴 (꺼내려면 1~2일)

S3 스토리지 클래스가 정확히 이 등급 체계와 맞아떨어집니다.

클래스	가용성	최소 저장 기간	검색 비용	사용 사례 (책상 → 외부 창고)
S3 Standard	99.99%	없음	없음	책상 옆 — 자주 접근하는 데이터
S3 Standard-IA	99.9%	30일	있음	사무실 캐비닛 — 가끔 접근, 빠른 검색 필요
S3 One Zone-IA	99.5%	30일	있음	한 사무실에만 — 재생성 가능한 데이터
S3 Intelligent-Tiering	99.9%	없음	없음	자동 등급 조정 — 패턴 불규칙
S3 Glacier Instant Retrieval	99.9%	90일	있음	외부 창고 (즉시 꺼냄) — 분기별 접근
S3 Glacier Flexible Retrieval	99.99%	90일	있음	외부 창고 (몇 시간) — 아카이브
S3 Glacier Deep Archive	99.99%	180일	있음	장기 아카이브 — 7~10년 보존

내구성은 모든 클래스가 11 nines로 같습니다. One Zone-IA만 단일 AZ라 AZ 장애 시 데이터 손실 가능성이 있다는 점만 다른데, 그래도 11 nines 내구성은 보장돼요.

이제 각 클래스를 한 줄씩 풀어 갑니다.

S3 Standard — 책상 옆 자료

가장 일반적으로 쓰는 클래스. 밀리초 단위 지연으로 즉시 데이터를 가져올 수 있고, 다중 AZ에 자동 복제. 자주 접근하는 모든 데이터의 기본 자리입니다. 월 GB당 약 $0.023 (us-east-1 기준).

S3 Standard-IA (Infrequent Access) — 사무실 캐비닛

자주 접근하지 않지만 빠른 검색이 필요한 데이터. Standard보다 저장 비용이 절반 가까이 저렴한데, 대신 검색할 때마다 비용이 발생합니다. 월 GB당 약 $0.0125.

여기서 시험 함정이 하나 있어요. 30일 미만 저장하고 삭제해도 30일치 요금을 청구합니다. 자주 지웠다 다시 올렸다 하는 데이터에는 부적합해요.

S3 One Zone-IA — 한 사무실에만 보관

Standard-IA와 거의 같은데, 단일 AZ에만 저장합니다. 그래서 약 20% 더 저렴해요(월 GB당 약 $0.01). 다만 그 AZ에 사고가 나면 데이터를 잃을 수 있어요.

언제 쓰느냐 — 재생성 가능한 데이터, 예를 들어 다른 곳에서 다시 만들 수 있는 썸네일이나 캐시, 그리고 온프레미스 백업의 사본 같은 자리. 진짜 중요한 원본은 여기 두면 안 됩니다.

S3 Intelligent-Tiering — 자동 등급 조정

이게 가장 똑똑한 클래스예요. 접근 패턴에 따라 AWS가 알아서 최적 계층으로 객체를 옮겨 줍니다. 자주 쓰면 Frequent Access 계층, 한 달 안 쓰면 Infrequent로, 90일 안 쓰면 Archive Instant로 자동 이동.

대신 객체당 월 $0.0025의 모니터링·자동화 비용이 발생해요. 그래서 작은 객체가 엄청 많은 경우엔 오히려 손해일 수 있습니다.

4가지 접근 계층이 있고 두 개는 선택 활성화입니다:

• Frequent Access — 자주 접근
• Infrequent Access — 30일 이상 미접근
• Archive Instant Access — 90일 이상 미접근
• Archive Access — 90~730일 (선택 활성화)
• Deep Archive Access — 180~730일 (선택 활성화)

언제 쓰느냐 — 접근 패턴이 예측 안 될 때. 어느 데이터가 자주 쓰일지 미리 모를 때 Intelligent-Tiering에 던져 두면 알아서 등급이 조정됩니다.

S3 Glacier Instant Retrieval — 외부 창고, 즉시 꺼냄

분기 한 번 정도 접근하는 아카이브 데이터의 자리. Glacier 시리즈 중 가장 빠른 검색 — 밀리초 단위로 꺼낼 수 있어요. 월 GB당 약 $0.004, 90일 최소 저장.

이게 헷갈리는 부분 — "Glacier"라는 이름이 붙어 있는데 실제로는 즉시 꺼낼 수 있어요. Glacier 시리즈가 "차가운 보관"이라는 컨셉이긴 한데, Instant Retrieval만은 즉시 검색이 가능합니다.

S3 Glacier Flexible Retrieval — 외부 창고, 몇 시간 후

장기 아카이브·재해 복구. 검색 옵션이 셋으로 갈려요.

• 긴급(Expedited) — 1~5분, 가장 비쌈
• 표준(Standard) — 3~5시간
• 대량(Bulk) — 5~12시간, 가장 저렴

월 GB당 약 $0.0036.

S3 Glacier Deep Archive — 7~10년 장기 보관

가장 저렴한 S3 클래스. 7~10년 단위 보존이 목적인 자료(법적 의무 기록 등) 자리. 검색 시간이 표준 12시간, 대량 48시간이라 즉시 꺼내 쓰는 용도가 아니에요.

월 GB당 약 $0.00099 — Standard의 약 1/23 수준입니다. 정말 안 꺼낼 자료라면 비용이 압도적으로 절약됩니다. 다만 180일 최소 저장 기간이라 그 안에 지우면 손해예요.

클래스 선택 가이드 — 한 줄로 정리

• 자주 접근 → Standard
• 가끔 접근, 빠른 검색 → Standard-IA
• 재생성 가능, 비용 절감 우선 → One Zone-IA
• 접근 패턴 모름 → Intelligent-Tiering
• 분기에 한 번, 즉시 검색 → Glacier Instant
• 연 1~2회, 몇 시간 OK → Glacier Flexible
• 7년+ 장기, 거의 안 봄 → Glacier Deep Archive

# 특정 스토리지 클래스로 업로드
aws s3 cp file.txt s3://my-bucket/ \
  --storage-class STANDARD_IA

# 스토리지 클래스 변경 (자기 자신을 복사)
aws s3 cp s3://my-bucket/file.txt s3://my-bucket/file.txt \
  --storage-class GLACIER

# 대량 클래스 변경
aws s3 cp s3://my-bucket/ s3://my-bucket/ \
  --recursive \
  --storage-class INTELLIGENT_TIERING

객체 태그 — 자료에 라벨 붙이기

객체에 키-값 쌍으로 추가 정보를 붙일 수 있는 기능이 태그(Object Tags) 입니다. 회사 비유로 — 자료 봉투에 색깔 라벨을 붙여 두는 식이에요.

규칙은 단순해요.

• 객체당 최대 10개 태그
• 키는 최대 128자, 고유해야 함
• 값은 최대 256자
• 대소문자 구별 — Department ≠ department

태그가 시험에 자주 나오는 이유는 — 태그를 기반으로 다양한 정책을 적용할 수 있기 때문이에요. 다음 같은 자리에 쓰입니다.

• 부서별 비용 할당 — Department=Finance, Department=Marketing
• 접근 권한 제어 — Confidential=True 태그가 붙은 객체는 특정 그룹만 접근
• 수명 주기 정책 적용 — Archive=Yes 태그가 붙은 객체는 30일 뒤 Glacier로
• 환경 구분 — Environment=Production, Environment=Dev

# 객체 태그 추가
aws s3api put-object-tagging \
  --bucket my-bucket \
  --key file.txt \
  --tagging '{"TagSet": [{"Key": "Department", "Value": "Finance"}, {"Key": "Confidential", "Value": "True"}]}'

# 객체 태그 조회
aws s3api get-object-tagging \
  --bucket my-bucket \
  --key file.txt

# 업로드 시 태그 함께 지정
aws s3api put-object \
  --bucket my-bucket \
  --key file.txt \
  --body file.txt \
  --tagging "Department=Finance&Environment=Prod"

S3 버킷에 접근하는 방법들

S3 버킷에 데이터를 넣고 빼는 통로가 여러 개입니다. 각자의 자리가 있어요.

방법	용도
AWS 관리 콘솔	UI를 통한 직관적 관리, 소량·일회성
AWS CLI	터미널, 스크립트 자동화
AWS SDK	프로그래밍 (Java·Python·JavaScript 등)
REST API	HTTP/HTTPS 직접 호출
VPC 엔드포인트	내부 네트워크 private 접근
S3 액세스 포인트	대규모 데이터셋 접근 관리
객체 URL	직접 URL로 접근 (공개 객체)

업로드 크기 제한 — 이건 외워둡니다

방법	최대 파일 크기
AWS 콘솔	160GB
AWS CLI / SDK / API	5TB (멀티파트 업로드 권장: 100MB 이상)

여기서 시험 함정이 하나 있어요. 콘솔로는 160GB까지만, CLI/SDK로는 5TB까지. 그리고 5GB를 넘는 단일 객체는 멀티파트 업로드가 필수입니다. 5GB 넘으면 단일 PUT 요청으로 못 보내요.

멀티파트 업로드 — 큰 짐을 여러 개로 쪼개기

회사 비유로 — 트럭으로 한 번에 옮기기 어려운 큰 짐을 여러 작은 박스로 쪼개서 동시에 여러 트럭으로 보내는 식입니다. 도착해서 다시 합치면 원본 그대로예요.

장점이 두 가지 있어요.

• 병렬 업로드로 속도 향상 — 여러 파트를 동시에 전송
• 재시작 용이 — 네트워크가 끊겨도 실패한 파트만 다시 보내면 됨

100MB 이상 권장, 5GB 이상 필수입니다. 자세한 작동 원리와 함정은 3편(성능 최적화)에서 풀어 갈게요.

# 간단한 대용량 파일 업로드 — CLI가 자동으로 멀티파트 처리
aws s3 cp large-file.zip s3://my-bucket/

# 멀티파트 업로드를 직접 제어 (수동)
aws s3api create-multipart-upload \
  --bucket my-bucket \
  --key large-file.zip

# 각 파트 업로드
aws s3api upload-part \
  --bucket my-bucket \
  --key large-file.zip \
  --part-number 1 \
  --body part1 \
  --upload-id UPLOAD_ID

# 멀티파트 업로드 완료
aws s3api complete-multipart-upload \
  --bucket my-bucket \
  --key large-file.zip \
  --upload-id UPLOAD_ID \
  --multipart-upload '{"Parts": [{"ETag": "etag1", "PartNumber": 1}]}'

S3 버킷 가격 — 4가지 결정 요소

가격을 결정하는 핵심 요소가 4개입니다.

1. 저장 데이터 양 — GB당 과금
2. 스토리지 클래스 — Standard부터 Deep Archive까지 23배 차이
3. 저장 리전 — 리전마다 다름. us-east-1이 보통 가장 저렴
4. 추가 비용 — 데이터 전송, API 요청, Glacier 검색 등

추가 비용 항목 — 잊기 쉬운 함정들

저장 비용만 생각하면 의외의 청구서를 받게 됩니다. 다음 항목들이 같이 들어와요.

• 데이터 전송 비용 — S3 밖으로 데이터를 인터넷으로 빼낼 때 GB당 과금. 들어오는 건 보통 무료
• API 요청 비용 — PUT·GET·LIST 등 API 호출도 요금 발생. 작은 객체가 매우 많으면 의외로 큼
• 검색 비용 — Glacier 클래스에서 데이터를 꺼내는 비용
• 최소 저장 기간 — IA·Glacier는 30·90·180일 안에 삭제해도 그 기간만큼 청구

여기서 시험 함정이 하나 있어요. "Glacier로 옮기면 무조건 저렴" 이라는 보기는 함정입니다. 자주 꺼내야 한다면 검색 비용이 저장 비용을 초과할 수 있어요. Glacier는 정말 안 꺼낼 자료에만 적합합니다.

비용 최적화 4가지 패턴

• 자주 접근 안 하는 데이터 → Standard-IA 또는 Glacier
• 접근 패턴 불규칙 → Intelligent-Tiering
• 오래된 데이터 자동 정리 → 수명 주기 정책
• 사용 패턴 분석·최적화 기회 발견 → S3 Storage Lens

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

여기까지가 S3 1편의 핵심입니다. 시험 직전 또는 실무에서 헷갈릴 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.

• S3 = 객체 스토리지, 평면 구조. 슬래시는 그냥 키의 일반 문자
• 내구성 11 nines (데이터 손실 X) ≠ 가용성 99.99% (접근 가능 시간)
• 단일 객체 최대 5TB, 한 버킷 안 객체 수 무제한
• 버킷 이름은 전 세계 고유 (3~63자, 소문자·숫자·하이픈)
• 버킷 생성 시점에만 켤 수 있는 옵션 = Object Lock
• us-east-1만 LocationConstraint 옵션 안 받음
• 2020년 이후 strong consistency — eventual consistency 아님
• 폴더처럼 보이는 건 접두사를 시각화한 것뿐, 실제 폴더 X
• 버전 관리 한 번 켜면 비활성화 X, Suspended로만
• 삭제 마커 = 데이터는 살아있고 "삭제됐다"는 표식
• 모든 버전이 저장 비용 발생 → 라이프사이클 정책으로 통제
• 스토리지 클래스 7개, 모두 11 nines (One Zone-IA만 단일 AZ)
• One Zone-IA 약 20% 저렴, AZ 장애 시 데이터 손실 가능
• Standard-IA 30일 최소, Glacier Instant·Flexible 90일, Deep Archive 180일 최소 저장
• Glacier Instant Retrieval은 밀리초 검색 (이름과 다름)
• Glacier Flexible 검색 — Expedited(1~5분) / Standard(3~5h) / Bulk(5~12h)
• Deep Archive 검색 — 표준 12h / 대량 48h, 7~10년 보관용
• 콘솔 업로드 160GB, CLI/SDK 5TB, 5GB+는 멀티파트 필수
• 객체 태그 — 객체당 최대 10개, 키 128자·값 256자
• 가격 4요소 — 저장량·클래스·리전·추가 비용(전송·API·검색·최소 저장)

다음 글(2편)에서는 S3 버킷 보안 — IAM·버킷 정책·ACL·CORS·암호화·Block Public Access·MFA Delete·Object Lock·Presigned URL을 회사 출입카드와 금고 비유로 풀어 갑니다. 보안은 시험과 실무 모두에서 가장 출제 빈도가 높은 영역이라 단단히 잡고 가야 해요.

시리즈 다른 편

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

• 1편 — 기초 (현재 글)
• 2편 — 보안
• 3편 — 성능 최적화
• 4편 — 복제
• 5편 — 라이프사이클
• 6편 — 고급 기능
• 7편 — AWS 통합 (완)