AWS - S3

클라우드

by myeongjaechoi 2025. 10. 21. 16:21

1. Amazon S3란?

**S3(Simple Storage Service)**는 AWS의 대표적인 **파일 저장소(스토리지 서비스)**예요.
“무한히 확장 가능한 스토리지”로, 전 세계 수많은 웹사이트와 기업들이 이미지, 동영상, 로그, 백업 데이터를 저장할 때 사용합니다.
쉽게 말해 인터넷 상의 클라우드 하드디스크라고 생각하면 됩니다.

2. S3의 주요 사용 사례

백업 및 복구: 데이터를 안전하게 저장하고, 리전 장애 시 다른 리전으로 복제해 복구 가능
아카이브(보관용): 오래된 데이터를 저비용으로 저장해두는 용도 (예: Glacier 사용)
하이브리드 스토리지: 온프레미스(내 서버)에 있는 저장 공간을 클라우드로 확장
미디어 호스팅: 앱, 웹의 이미지나 동영상 파일 저장
데이터 레이크 및 분석용: 대규모 데이터 저장 후 분석
정적 웹사이트 호스팅: HTML, CSS, JS 파일로 구성된 웹사이트를 직접 서비스할 수도 있음

3. S3의 구조: “버킷과 객체”

버킷(Bucket): 데이터를 담는 최상위 디렉터리 개념
- 하나의 AWS 계정 안에 여러 버킷을 만들 수 있음
- 단, **버킷 이름은 전 세계에서 유일(unique)**해야 함 (예: mycompany-files는 전 세계 AWS 중 단 하나만 존재 가능)
- **버킷은 특정 리전(Region)**에 속함 (예: ap-northeast-2 = 서울 리전)
객체(Object): 버킷 안에 저장되는 실제 파일
- 객체는 **키(Key)**로 식별됨 (키 = 파일의 전체 경로)
  - 예: my_folder1/another_folder/my_file.txt
- Amazon S3는 실제로는 폴더 개념이 없고, 키 이름의 슬래시(/)로 경로처럼 표현하는 것뿐임
- 객체 크기 제한: 최대 5TB
  - 단, 5GB를 넘는 파일은 멀티파트 업로드(여러 조각으로 나눠 업로드) 필요

4. 객체의 부가정보

메타데이터: 파일의 추가 정보(키-값 쌍)
- 예: 파일의 MIME 타입, 업로드 날짜, 사용자 정의 태그 등
태그(Tag): 최대 10개까지 설정 가능, 보안 정책이나 수명 주기 관리에 활용
버전 관리(Versioning): 같은 이름의 파일이 여러 버전으로 저장되도록 설정 가능

5. 정리

개념	설명
S3	AWS의 파일 저장소 서비스
버킷(Bucket)	파일을 담는 최상위 폴더, 전 세계에서 유일한 이름
객체(Object)	버킷 안의 실제 파일
키(Key)	파일의 전체 경로 (폴더처럼 표현됨)
리전(Region)	버킷이 속한 실제 물리적 위치
멀티파트 업로드	5GB 이상의 큰 파일을 여러 조각으로 나눠 업로드

1. S3 버킷 생성하기

(1) 리전 선택

S3는 전역 서비스처럼 보이지만 버킷은 특정 리전에 속함.
예: “유럽(스톡홀름) eu-north-1”을 선택하면 해당 리전에 버킷이 만들어짐.
하지만 모든 리전의 버킷을 콘솔에서 볼 수 있음.
시험에서는 “디렉토리 버킷”이 아닌 범용(General purpose) 버킷만 다룸.

(2) 버킷 이름 지정

버킷 이름은 전 세계에서 고유해야 함.
- 예: test → 이미 존재하면 오류 발생
- 예: stefan-demo-s3-v5 → 고유한 이름으로 통과
따라서 개인 이름 + 프로젝트명 조합으로 지정하는 게 좋음.
(예: choi-tripagent-files)

(3) 접근 제어 및 보안 설정

객체 소유권(ACL): 기본적으로 비활성화(권장).
공개 액세스 차단: 기본으로 모든 공개 액세스 차단 유지 (보안상 권장).
→ 나중에 공개할 객체만 따로 설정할 수 있음.
버전 관리(Versioning): 처음엔 비활성화해도 됨. 추후 활성화 가능.
암호화(Encryption):
- “SSE-S3” (Amazon S3 관리 키로 서버 측 암호화) 선택.
- 모든 객체가 자동으로 암호화됨.

(4) 버킷 생성

설정을 모두 기본으로 두고 버킷 생성(Create bucket) 클릭.
생성 완료 후 S3 콘솔에서 전체 버킷 목록을 볼 수 있음.
(전 리전의 버킷도 모두 표시됨.)

2. 객체(파일) 업로드하기

(1) 업로드

버킷 클릭 → “업로드” → “파일 추가(Add files)”
예시: coffee.jpg 파일 선택
경로: s3://stefan-demo-s3/coffee.jpg
업로드 완료 후 객체 리스트에서 확인 가능.

(2) 객체 정보 보기

업로드된 객체 클릭 시 메타데이터, 크기, 유형, URL 등 정보 확인 가능.
예:
- 유형: JPEG 이미지
- 크기: 100KB
- 객체 URL: https://bucket-name.s3.region.amazonaws.com/coffee.jpg

3. 객체 접근 (URL 차이 이해)

구분설명

공용 URL (Public URL)	모든 사용자가 접근 가능하도록 공개된 주소. 현재는 “공개 차단” 설정 때문에 “Access Denied” 발생.
미리 서명된 URL (Pre-signed URL)	사용자의 임시 자격 증명이 포함된 URL. 로그인하지 않아도 일정 시간 동안 접근 가능.
비공개 객체	버킷 소유자만 접근 가능. 기본 설정임.

즉,

“공용 URL”은 공개 설정을 하지 않으면 접근 불가.
“미리 서명된 URL”은 자격 증명이 포함되어 있어 소유자는 접근 가능.

4. 폴더 만들기 및 관리

(1) 폴더 생성

버킷 내부 → “폴더 생성(Create folder)”
예: images 폴더 생성 → images/ 경로 추가됨.
S3는 폴더 개념이 실제로 없고, **객체 키(prefix)**로 경로를 표현함.

(2) 폴더 안에 파일 업로드

images/ 내부에 beach.jpg 업로드
결과 경로: s3://stefan-demo-s3/images/beach.jpg

(3) 폴더 삭제

폴더 삭제 시 내부 객체도 함께 삭제됨.
삭제 전 “permanently delete” 입력으로 확인 절차 진행.

5. 요약

단계	작업	설명
1	버킷 생성	고유한 이름 + 리전 선택
2	보안 설정	ACL 비활성화, 공개 차단 유지, 암호화 활성화
3	객체 업로드	파일 선택 후 업로드
4	URL 확인	공용 URL vs 미리 서명된 URL 차이 이해
5	폴더 생성	접두사(prefix)로 구조화 가능
6	삭제	영구 삭제 시 직접 입력 필요

1. S3 보안의 기본 개념

(1) 사용자 기반 보안

IAM 정책: 특정 사용자가 어떤 API 호출을 허용받는지 정의
- 예: GetObject, PutObject 등
- IAM 권한이 허용되어야 S3 객체에 접근 가능

(2) 리소스 기반 보안

S3 버킷 정책(Bucket Policy): 버킷 단위로 적용되는 정책
- 특정 사용자, 계정, 또는 공개 접근 허용 가능
- 교차 계정(Cross-account) 접근에도 사용

(3) ACL(Access Control List)

객체 단위 또는 버킷 단위 권한 부여
세밀하게 제어 가능하지만 현재는 비활성화 권장
버킷 정책 사용이 일반적

(4) 객체 암호화

서버 측 암호화(Server-side encryption) 사용 가능
- SSE-S3: Amazon S3 관리 키 사용
- SSE-KMS: 사용자 지정 키 관리 가능
데이터를 안전하게 저장하고 전송 시 보호

2. S3 버킷 정책(Bucket Policy) 이해

JSON 형식으로 작성
주요 구성:
1. Resource: 정책이 적용되는 버킷/객체 지정
  - 예: arn:aws:s3:::examplebucket/* → 모든 객체 적용
2. Effect: 허용(Allow) 또는 거부(Deny)
3. Action: 허용/거부할 API 호출
  - 예: s3:GetObject
4. Principal: 정책이 적용될 계정 또는 사용자
  - 예: "*" → 모든 사용자 (공개 접근)
예시:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::examplebucket/*" } ] }

위 정책은 버킷 내 모든 객체를 공개 읽기 가능하게 설정

3. 접근 시나리오

공개 웹 접근
- 버킷 정책을 통해 공개 허용 → 웹사이트 방문자가 접근 가능
IAM 사용자 접근
- IAM 정책 + 버킷 정책 조합으로 권한 부여
- 사용자 인증 필요
EC2 인스턴스 접근
- IAM 역할(Role) 부여 → 해당 EC2에서 S3 접근 가능
교차 계정 접근
- 다른 AWS 계정 사용자에게 권한 부여
- 추가 버킷 정책 필요

4. 블록 공개 액세스(Block Public Access)

S3에서 제공하는 추가 보안 계층
버킷 정책이나 ACL에서 공개를 허용하더라도 활성화된 경우 공개되지 않음
기업 데이터 유출 방지용
계정 수준에서도 활성화 가능

✅ 요약

IAM 정책 → 사용자 권한 제어
버킷 정책 → 버킷 단위 접근 제어, 공개 허용 가능
ACL → 객체 단위 세밀한 권한, 보통 비활성화
암호화 → 객체 보호
블록 공개 액세스 → 잘못된 설정으로 인한 데이터 유출 방지

1. S3 버킷 공용 접근 설정 단계

버킷의 공용 접근 차단 해제
- S3 버킷의 권한 탭 → 공용 접근(Block Public Access) 설정에서 차단을 해제
- 경고: 실제 회사 데이터나 민감 데이터에는 절대 적용 금지
버킷 정책(Bucket Policy) 생성
- 정책 생성기(Policy Generator) 사용
- 설정:
  - Type: S3 Bucket Policy
  - Principal: * (모든 사용자 허용)
  - Actions: GetObject (객체 읽기 허용)
  - Amazon Resource Name(ARN): 버킷 ARN + /*
    예: arn:aws:s3:::stefan-demo-s3/*
    - 슬래시 /와 별표 * 추가 → 버킷 내 모든 객체에 적용
버킷 정책 복사 및 적용
- 생성된 정책을 복사 후 버킷 정책 탭에 붙여넣기
- 공백 제거 및 저장
적용 확인
- 객체 클릭 → 객체 URL 복사
- 브라우저에서 열어 확인 → 이제 공개 URL로 접근 가능

2. 결과

버킷 내 모든 객체가 공개 읽기 가능 상태가 됨
정책을 통해 누구나 접근 가능
민감한 데이터는 절대 이렇게 설정하면 안 됨

1. S3 버킷 준비

S3 콘솔에서 버킷 생성
- 버킷 이름은 고유해야 함
- 리전 선택 (웹 사이트 URL은 리전에 따라 달라짐)
HTML, CSS, 이미지 등 웹 사이트 파일 업로드
- 예: index.html, style.css, logo.png

2. 버킷 공개 읽기 설정

권한 → Block Public Access
- 모든 차단 설정 해제 (웹 사이트 공개용)
- 주의: 민감 데이터에는 절대 적용 금지
버킷 정책(Bucket Policy) 생성
- 정책 예시:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "PublicReadGetObject", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::버킷이름/*" } ] }

ARN에 슬래시 /와 별표 * 반드시 추가 → 버킷 내 모든 객체에 적용

3. 정적 웹 사이트 호스팅 활성화

Properties → Static website hosting
- Enable 선택
- Index document: index.html
- 필요 시 Error document: error.html
S3가 제공하는 웹 사이트 엔드포인트 URL 확인
- 예: http://버킷이름.s3-website.eu-north-1.amazonaws.com
- 리전에 따라 URL 형식이 달라질 수 있음

1. 파일 업로드

index.html : 웹 사이트 기본 페이지
coffee.jpg, beach.jpg : 웹 페이지에서 보여줄 이미지

2. 정적 웹 사이트 호스팅 활성화

S3 콘솔에서 Properties → Static website hosting → Edit 클릭
Enable 선택
Index document: index.html 지정
저장 후 웹 사이트 엔드포인트 URL 확인

3. 공개 접근 확인

버킷 정책이 공개 읽기(GetObject 허용) 되어 있어야 웹 사이트 URL에서 파일 확인 가능
브라우저에서 웹 사이트 URL 접속 시:
- index.html 내용 표시 (I love coffee Hello world!)
- 이미지 파일 공개 확인 (coffee.jpg, beach.jpg)

4. 핵심 포인트

버킷 정책: 공개 읽기 허용
파일 구조: index.html은 루트, 이미지 파일은 루트 또는 폴더 내 가능
웹 사이트 엔드포인트 URL: 리전별로 다름, URL 접속 시 S3가 정적 웹 사이트로 서비스

1. 버전 관리란?

파일 변경 이력 관리 기능
동일한 키(Key)를 가진 객체를 여러 버전으로 저장
덮어쓰기나 삭제 시 이전 버전을 보존
의도치 않은 삭제나 덮어쓰기로부터 데이터를 보호

2. 버전 관리 활성화

S3 콘솔에서 버킷 선택 → Properties → Bucket Versioning → Edit
Enable 선택 후 저장

주의: 버전 관리는 버킷 수준에서 설정하며, 기존 객체에는 버전이 적용되지 않습니다.
버전 관리를 비활성화해도 기존 버전은 삭제되지 않습니다.

3. 버전 관리 동작

새로운 객체 업로드: 버전 1 생성
동일 키 업로드(덮어쓰기): 버전 2, 3 … 생성
객체 삭제: 삭제 마커(Delete Marker) 생성 → 이전 버전은 그대로 유지
이전 버전 복구: 원하는 버전으로 롤백 가능

4. 주의 사항

버전 관리 활성화 전 파일은 null 버전을 가짐
버전 관리 활성화 후 업로드된 파일만 새로운 버전으로 기록
버전 관리 기능은 안전하지만, 사용하지 않는 오래된 버전은 스토리지 비용 증가 요인

1. 버전 관리 활성화

Properties → Bucket Versioning → Edit → Enable
이후 파일을 업로드하거나 덮어쓰면 새로운 버전 ID가 생성됨

2. 객체 덮어쓰기와 버전 생성

기존 index.html을 수정하고 다시 업로드
새로운 버전 ID가 생성되어 이전 버전과 구분됨
웹 페이지에서 새로고침 시 최신 내용 반영

3. 이전 버전 확인

Show versions 토글 ON → 각 객체의 버전 ID 확인 가능
버전 관리 이전 파일(coffee.jpg, beach.jpg)은 버전 ID가 null
버전 관리 이후 업로드한 파일은 고유 버전 ID를 가짐

4. 이전 버전으로 롤백

특정 버전 ID 선택
permanently delete 입력 후 삭제 → 해당 버전만 제거
웹 페이지 새로고침 → 이전 상태로 복구됨

5. 삭제 마커(Delete Marker)

객체 삭제 시 실제 데이터는 삭제되지 않고 삭제 마커 생성
이전 버전은 여전히 존재
삭제 마커 제거(permanently delete) 시 이전 버전 복원 가능
웹 페이지 새로고침 시 삭제된 객체는 404 표시

1. S3 복제(Replication) 개요

S3 객체를 한 버킷에서 다른 버킷으로 자동으로 복사하는 기능
두 가지 유형:
1. CRR (Cross-Region Replication)
  - 서로 다른 AWS 리전 간 복제
  - 컴플라이언스, 재해 복구, 지연 시간 최소화 목적
2. SRR (Same-Region Replication)
  - 동일 리전 내 버킷 간 복제
  - 로그 통합, 개발/운영 환경 동기화 목적

2. 복제 전 요구 사항

버전 관리 활성화: 소스와 대상 버킷 모두 활성화 필요
권한 설정: S3에서 올바른 IAM 권한(읽기/쓰기) 필요
리전 조건:
- CRR → 리전이 서로 달라야 함
- SRR → 동일 리전이어야 함
계정: 동일 계정 또는 다른 계정 간도 가능
비동기 처리: 복제는 백그라운드에서 비동기적으로 수행

3. 유스케이스

CRR
- 규제 준수(Compliance)
- 재해 복구(Disaster Recovery)
- 지연 시간 최적화
- 계정 간 데이터 공유
SRR
- 다수 버킷 로그 통합
- 운영/개발 환경 동기화

1. 새 객체만 복제

S3 복제는 복제를 활성화한 시점 이후 업로드되는 객체만 자동으로 복제됨
기존 객체를 복제하려면 S3 배치 복제(Batch Replication) 기능 사용 필요

2. 삭제 마커 복제

S3 버전 관리가 활성화된 경우 객체 삭제 시 **삭제 마커(Delete Marker)**가 생성됨
삭제 마커를 복제 대상으로 포함하면 소스 버킷에서 대상 버킷으로 삭제 상태 동기화 가능
단, 버전 ID를 직접 삭제하는 경우 복제되지 않음
- 이유: 악의적 의도로 다른 버킷의 객체를 영구 삭제하는 것을 방지

3. 체이닝 복제 불가

예: 버킷1 → 버킷2 → 버킷3
버킷1에서 버킷2로 복제되어도, 버킷3으로 자동으로 복제되지 않음
각 버킷은 독립적으로 복제 규칙을 설정해야 함

1. S3 복제 버킷 생성 및 버전 관리 실습

오리진 버킷과 복제 대상 버킷 모두 버전 관리(Versioning) 활성화 필수
버전 관리가 없으면 복제 기능을 사용할 수 없음

2. 복제 규칙 생성

Management → Replication → Create rule
규칙 이름 지정(DemoReplicationRule 등)
활성화(Enabled) 체크
범위: 버킷 내 모든 객체 또는 특정 접두사/태그
대상 버킷 선택: 같은 계정 또는 다른 계정 가능
IAM 역할 생성 필요(자동 생성 옵션 사용 가능)

3. 복제 동작

새 객체 업로드: 규칙 적용 후 새 파일만 복제
기존 객체 복제 필요 시 → S3 배치 복제(Batch Replication) 사용
삭제 마커 옵션: 기본은 미복제, 활성화하면 삭제 마커도 복제 가능

4. 삭제 및 버전 관리

오리진 버킷에서 파일 삭제 → 삭제 마커 생성
삭제 마커가 복제되면 복제 버킷에서도 삭제 상태 동기화
특정 버전 영구 삭제 → 복제 버킷에는 반영되지 않음
- 복제는 객체 자체가 아닌 삭제 마커 상태만 동기화

5. 주의 사항

CRR(교차 리전 복제) / SRR(같은 리전 복제) 구분
체이닝 복제 불가 (1→2, 2→3 자동 전달되지 않음)
버전 ID까지 복제되므로, 이전 버전 복구 가능

1. S3 스토리지 클래스 내구성과 가용성

내구성(Durability): 모든 스토리지 클래스 동일, 11 9’s (99.999999999%)
가용성(Availability): 스토리지 클래스별 차이 존재
- 예: S3 Standard 99.99%, S3 Standard-IA 99.9%, S3 One Zone-IA 99.5%

2. 주요 스토리지 클래스

클래스	특징	사용 사례
S3 Standard	자주 액세스, 낮은 지연, 높은 처리량, 2개 AZ 장애 견딤	모바일/게임 앱, 빅데이터, 콘텐츠 배포
S3 Standard-IA	자주 사용하지 않지만 필요 시 빠른 액세스, 검색 비용 발생	재해복구, 백업
S3 One Zone-IA	단일 AZ에 저장, AZ 파괴 시 데이터 손실 가능	온프레미스 2차 백업, 재생성 가능한 데이터
Glacier Instant Retrieval	콜드 스토리지, 밀리초 단위 검색, 최소 90일	분기별 백업, 빠른 접근 필요 아카이브
Glacier Flexible Retrieval	Expedited 1~5분, Standard 3~5시간, Bulk 5~12시간, 최소 90일	저비용 아카이브
Glacier Deep Archive	가장 저렴, Standard 12시간, Bulk 48시간, 최소 180일	장기 보관, 법규 준수 아카이브
S3 Intelligent-Tiering	액세스 패턴 기반 자동 티어링, 소액 모니터링/티어링 비용, 검색 비용 없음	액세스 패턴 변화가 있는 데이터, 비용 최적화

3. 특징 요약

내구성: 모든 클래스 동일
가용성: AZ 수에 따라 다름
비용: 액세스 빈도 낮을수록 저렴, Glacier 시리즈가 가장 낮음
검색 시간: Standard-IA < Glacier Instant < Glacier Flexible < Glacier Deep Archive
자동 관리: Intelligent-Tiering은 사용 패턴에 따라 자동 이동

1. 스토리지 클래스 버킷 생성 실습

버킷 이름: s3-storage-classes-demos-2022
리전: 자유롭게 선택 가능
버킷 생성 후, 파일 업로드 준비

2. 객체 업로드 및 스토리지 클래스 선택

coffee.jpg 업로드
업로드 시 Storage class 메뉴 확인
- S3 Standard: 기본값, 자주 사용하는 데이터
- Intelligent-Tiering: 접근 패턴 알 수 없을 때 자동 관리
- Standard-IA: 접근 빈도 낮음, 지연 시간 짧음
- One Zone-IA: 단일 AZ, 재생성 가능, 낮은 가용성
- Glacier 시리즈: 콜드 스토리지, Instant Retrieval / Flexible Retrieval / Deep Archive
- Reduced Redundancy: 사용하지 않음
예시: Standard-IA 선택 후 업로드 → 객체 속성에서 클래스 확인

3. 객체 스토리지 클래스 변경

Properties → Storage class 변경 가능
예시 변경: One Zone-IA → Glacier Instant Retrieval → Intelligent-Tiering
변경 저장 후 객체에 적용됨

4. 자동 스토리지 클래스 변경 (Lifecycle Rule)

Management → Lifecycle rules → Create lifecycle rule
- 이름: DemoRule
- 모든 객체 적용
- 현재 버전 객체 선택
클래스 변경 스케줄 설정:
1. 30일 후 → Standard-IA
2. 60일 후 → Intelligent-Tiering
3. 180일 후 → Glacier Flexible Retrieval
설정 후 자동으로 객체 스토리지 클래스 이동

'클라우드' 카테고리의 다른 글

AWS - 고급 Amazon S3 (0)	2025.10.24
AWS - 세 개의 아키텍처 예시 및 Beanstalk (0)	2025.10.21
AWS - DNS, Route 53 (0)	2025.10.19
AWS - RDS, Aurora, ElastiCache (0)	2025.10.18
AWS - Load Balancer (0)	2025.10.17

MJK

고정 헤더 영역

메뉴 레이어

메뉴 리스트

검색 레이어

검색 영역

상세 컨텐츠

본문 제목

본문