1. Amazon S3 개요
S3란?
- S3 = Simple Storage Service의 약자
- AWS의 핵심 구성 요소 중 하나
- "무한 확장" 스토리지로 홍보됨
- 많은 웹사이트와 AWS 서비스의 백본으로 사용
왜 S3를 사용할까?
기존 스토리지의 문제점:
- 물리적 서버의 하드디스크는 용량 한계가 있음
- 서버 장애 시 데이터 손실 위험
- 용량 증설 시 다운타임 발생
- 글로벌 접근 시 지연시간 문제
S3가 제공하는 해결책:
| 특징 | 설명 |
|---|---|
| 무제한 용량 | 저장 용량 걱정 없이 필요한 만큼 사용 |
| 높은 내구성 | 99.999999999% (11 9's) - 데이터 손실 거의 불가능 |
| 고가용성 | 여러 시설에 자동 복제되어 장애에도 접근 가능 |
| 글로벌 접근 | 전 세계 어디서든 HTTP/HTTPS로 접근 |
| 종량제 과금 | 사용한 만큼만 비용 지불 (미리 용량 구매 불필요) |
S3의 핵심 개념
┌─────────────────────────────────────────────────┐
│ S3 서비스 │
│ ┌─────────────────────────────────────────┐ │
│ │ 버킷 (Bucket) │ │
│ │ - 파일을 담는 최상위 컨테이너 │ │
│ │ - 폴더의 폴더 개념 │ │
│ │ │ │
│ │ ┌──────┐ ┌──────┐ ┌──────┐ │ │
│ │ │객체1 │ │객체2 │ │객체3 │ │ │
│ │ │.jpg │ │.pdf │ │.mp4 │ │ │
│ │ └──────┘ └──────┘ └──────┘ │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘- 버킷(Bucket): 파일을 담는 컨테이너 (폴더의 폴더)
- 객체(Object): 실제 저장되는 파일 (이미지, 동영상, 문서 등)
- 키(Key): 객체의 고유 식별자 (파일 경로처럼 생각)
주요 사용 사례
| 분류 | 사용 사례 |
|---|---|
| 저장/백업 | 백업, 재해 복구, 아카이브 |
| 호스팅 | 애플리케이션 호스팅, 미디어 호스팅, 정적 웹사이트 |
| 데이터 분석 | 데이터 레이크, 빅데이터 분석 |
| 기타 | 하이브리드 클라우드 스토리지, 소프트웨어 배포 |
💡 실제 사례
- Nasdaq: 7년치 데이터를 S3 Glacier에 저장
- Sysco: 데이터 분석으로 비즈니스 인사이트 획득
2. S3 버킷 (Buckets)
버킷이란?
- 객체(파일)를 저장하는 컨테이너 (디렉토리 개념)
- 전역적으로 고유한 이름 필요 (모든 리전, 모든 계정 통틀어)
- 리전 레벨에서 정의됨
⚠️ S3는 글로벌 서비스처럼 보이지만, 버킷은 특정 리전에 생성됨
버킷 이름 규칙
| 규칙 | 설명 |
|---|---|
| 대문자 | ❌ 불가 |
| 언더스코어 (_) | ❌ 불가 |
| 길이 | 3~63자 |
| IP 형식 | ❌ 불가 |
| 시작 문자 | 소문자 또는 숫자 |
접두사 xn-- | ❌ 불가 |
접미사 -s3alias | ❌ 불가 |
3. S3 객체 (Objects)
객체 키 (Key)
s3://my-bucket/my_folder1/another_folder/my_file.txt
│ │ │
└── 버킷명 └── prefix ────┴── object name- 키 = 전체 경로 (FULL path)
- S3에는 실제 "디렉토리" 개념이 없음
- 슬래시(/)를 포함한 긴 키 이름일 뿐 (UI가 폴더처럼 보여줄 뿐)
객체 구성 요소
| 구성 요소 | 설명 |
|---|---|
| Value | 파일 본문 내용 |
| Max Size | 5TB (5000GB) |
| Metadata | 텍스트 키/값 쌍 (시스템 또는 사용자 메타데이터) |
| Tags | 유니코드 키/값 쌍 (최대 10개) - 보안/수명주기에 유용 |
| Version ID | 버전 관리 활성화 시 |
⚠️ 5GB 초과 업로드 시 반드시 Multi-part Upload 사용
4. S3 보안
접근 제어 방식
| 방식 | 유형 | 설명 |
|---|---|---|
| User-Based | IAM Policies | 특정 IAM 사용자에게 허용할 API 호출 정의 |
| Resource-Based | Bucket Policies | 버킷 전체 규칙, Cross-Account 허용 가능 |
| Object ACL | 객체 단위 세밀한 제어 (비활성화 가능) | |
| Bucket ACL | 버킷 단위 (잘 안 씀, 비활성화 가능) |
S3 객체 접근 조건
IAM 권한이 허용 OR 리소스 정책이 허용
AND
명시적 DENY 없음Bucket Policy 구조 (JSON)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/*"
}
]
}| 요소 | 설명 |
|---|---|
| Resource | 버킷과 객체 지정 |
| Effect | Allow / Deny |
| Action | 허용/거부할 API |
| Principal | 정책 적용 대상 (계정/사용자) |
Bucket Policy 사용 사례
- 버킷 퍼블릭 액세스 허용
- 업로드 시 암호화 강제
- Cross-Account 접근 허용
접근 시나리오별 설정
| 시나리오 | 설정 방법 |
|---|---|
| 퍼블릭 접근 | Bucket Policy (Public Access 허용) |
| IAM 사용자 접근 | IAM Policy |
| EC2 인스턴스 접근 | IAM Role (권장) |
| 다른 AWS 계정 접근 | Bucket Policy (Cross-Account) |
시나리오 1: 퍼블릭 접근 (누구나 접근 가능)
사용 사례: 정적 웹사이트, 공개 이미지/파일 배포
┌─────────────┐ ┌─────────────┐
│ 인터넷 │ ──────▶ │ S3 버킷 │
│ (누구나) │ │ (퍼블릭) │
└─────────────┘ └─────────────┘설정 방법:
- Block Public Access 설정 해제
- Bucket Policy에서
Principal: "*"설정
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}시나리오 2: IAM 사용자 접근 (특정 사용자만)
사용 사례: 개발자가 코드에서 S3 접근, 관리자가 콘솔에서 관리
┌─────────────┐ IAM Policy ┌─────────────┐
│ IAM User │ ────────────▶ │ S3 버킷 │
│ (개발자) │ │ │
└─────────────┘ └─────────────┘설정 방법: IAM 사용자에게 S3 권한 정책 연결
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}시나리오 3: EC2 인스턴스 접근 (서버에서 접근)
사용 사례: 웹 서버에서 이미지 업로드, 백엔드에서 파일 처리
┌─────────────┐ IAM Role ┌─────────────┐
│ EC2 │ ───────────▶ │ S3 버킷 │
│ 인스턴스 │ (자동 인증) │ │
└─────────────┘ └─────────────┘왜 IAM Role을 사용해야 할까?
| 방법 | 장점 | 단점 |
|---|---|---|
| Access Key 직접 사용 | 간단함 | 키 유출 위험, 키 관리 번거로움 |
| IAM Role (권장) | 자동 인증, 키 관리 불필요, 보안성 높음 | 없음 |
설정 방법:
- S3 접근 권한이 있는 IAM Role 생성
- EC2 인스턴스에 해당 Role 연결
- 코드에서 별도 인증 없이 S3 접근 가능
시나리오 4: 다른 AWS 계정 접근 (Cross-Account)
사용 사례: 파트너사와 데이터 공유, 멀티 계정 환경
┌─────────────┐ ┌─────────────┐
│ 계정 A │ │ 계정 B │
│ (파트너) │ ────────────▶ │ S3 버킷 │
└─────────────┘ Bucket Policy └─────────────┘설정 방법: Bucket Policy에서 다른 계정 ID 허용
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}Block Public Access 설정
- 회사 데이터 유출 방지 목적
- 버킷이 절대 퍼블릭이 되면 안 되는 경우 활성화 유지
- 계정 레벨에서도 설정 가능
5. 정적 웹사이트 호스팅
정적 웹사이트란?
정적 웹사이트는 서버에서 별도의 처리 없이 파일을 그대로 전달하는 웹사이트입니다.
| 구분 | 정적 웹사이트 | 동적 웹사이트 |
|---|---|---|
| 서버 처리 | 없음 (파일 그대로 전달) | 있음 (DB 조회, 로직 처리) |
| 예시 | HTML, CSS, JS, 이미지 | PHP, Node.js, Python 앱 |
| 사용 사례 | 블로그, 포트폴리오, 랜딩 페이지 | 쇼핑몰, SNS, 대시보드 |
| 호스팅 비용 | 매우 저렴 | 상대적으로 비쌈 |
S3 정적 웹사이트 호스팅의 장점
기존 방식: S3 호스팅:
┌─────────┐ ┌─────────┐
│ EC2 서버 │ ← 서버 관리 필요 │ S3 │ ← 서버리스!
│ + Nginx │ ← 웹서버 설정 필요 │ 버킷 │ ← 설정만 하면 끝
│ + 스토리지│ ← 용량 관리 필요 │ │ ← 자동 확장
└─────────┘ └─────────┘
월 $30~ 월 $1~| 장점 | 설명 |
|---|---|
| 서버리스 | EC2 없이 S3만으로 웹사이트 운영 |
| 저렴한 비용 | 사용한 저장/전송량만 과금 |
| 자동 확장 | 트래픽 급증에도 자동 대응 |
| 고가용성 | AWS 인프라로 99.99% 가용성 |
설정 방법 (단계별)
Step 1: S3 버킷 생성
- 버킷명을 도메인과 동일하게 설정 권장 (예:
www.example.com)
Step 2: 정적 웹사이트 호스팅 활성화
- 버킷 → 속성 → 정적 웹사이트 호스팅 → 활성화
- 인덱스 문서:
index.html - 오류 문서:
error.html(선택)
Step 3: 퍼블릭 접근 허용
- Block Public Access 해제
- Bucket Policy 추가:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket-name/*"
}
]
}Step 4: 파일 업로드
index.html, CSS, JS, 이미지 등 업로드
웹사이트 URL 형식
http://bucket-name.s3-website-aws-region.amazonaws.com
또는
http://bucket-name.s3-website.aws-region.amazonaws.com예시 (us-west-2 리전, demo-bucket):
http://demo-bucket.s3-website-us-west-2.amazonaws.com
http://demo-bucket.s3-website.us-west-2.amazonaws.comCloudFront와 함께 사용하기
실무에서는 S3 단독보다 **CloudFront(CDN)**와 함께 사용합니다.
┌──────────────┐
│ CloudFront │ ← HTTPS 지원
사용자 ───────────▶ │ (CDN) │ ← 글로벌 캐싱
│ │ ← 커스텀 도메인
└──────┬───────┘
│
▼
┌──────────────┐
│ S3 버킷 │
│ (원본 저장) │
└──────────────┘| CloudFront 사용 시 장점 |
|---|
| HTTPS 지원 (S3 단독은 HTTP만) |
| 커스텀 도메인 연결 용이 |
| 전 세계 엣지 로케이션에서 캐싱 → 빠른 응답 |
| DDoS 방어 (AWS Shield 통합) |
자주 발생하는 에러와 해결법
| 에러 | 원인 | 해결 방법 |
|---|---|---|
| 403 Forbidden | 퍼블릭 접근 차단됨 | Bucket Policy 확인, Block Public Access 해제 |
| 404 Not Found | 파일 없음 또는 경로 오류 | index.html 존재 확인, 파일 경로 확인 |
| Access Denied | 권한 부족 | Bucket Policy의 Resource ARN 확인 |
⚠️ 403 Forbidden 에러 발생 시 → Bucket Policy에서 퍼블릭 읽기 허용 확인!
6. 버전 관리 (Versioning)
개요
- 버킷 레벨에서 활성화
- 같은 키로 덮어쓰기 시 버전 증가: 1, 2, 3...
장점
- 의도치 않은 삭제 방지 (버전 복원 가능)
- 이전 버전으로 쉽게 롤백
주의사항
- 버전 관리 활성화 전 파일의 버전 =
null - 버전 관리 일시 중지해도 이전 버전은 삭제되지 않음
7. 복제 (Replication)
유형
| 유형 | 설명 | 사용 사례 |
|---|---|---|
| CRR (Cross-Region) | 다른 리전으로 복제 | 규정 준수, 지연시간 단축, 계정 간 복제 |
| SRR (Same-Region) | 같은 리전 내 복제 | 로그 집계, 프로덕션↔테스트 실시간 복제 |
필수 조건
- 원본/대상 버킷 모두 버전 관리 활성화
- S3에 적절한 IAM 권한 부여
- 복제는 비동기로 수행
주의사항
| 항목 | 설명 |
|---|---|
| 기존 객체 | 복제 활성화 후 새 객체만 복제됨 |
| 기존 객체 복제 | S3 Batch Replication 사용 |
| DELETE 작업 | Delete Marker 복제는 선택사항 |
| Version ID 삭제 | 복제 안 됨 (악의적 삭제 방지) |
| 체이닝 | ❌ 불가 (버킷1→버킷2→버킷3 시 버킷1→버킷3 복제 안 됨) |
8. S3 스토리지 클래스
스토리지 클래스란?
S3는 데이터의 접근 빈도와 검색 속도 요구사항에 따라 다양한 스토리지 클래스를 제공합니다. 적절한 클래스를 선택하면 비용을 크게 절감할 수 있습니다.
비용 높음 비용 낮음
│ │
▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Standard │ → │ IA │ → │ Glacier │ → │ Deep │
│ │ │ │ │ │ │ Archive │
│ 자주 │ │ 가끔 │ │ 거의 │ │ 거의 │
│ 접근 │ │ 접근 │ │ 안접근 │ │ 안접근 │
│ │ │ │ │ (90일보관)│ │(180일보관)│
└──────────┘ └──────────┘ └──────────┘ └──────────┘
빠름 느림쉽게 비유하면:
- Standard: 책상 위 (바로 손이 닿는 곳)
- Standard-IA: 서랍 안 (조금 걸리지만 빨리 꺼냄)
- Glacier: 창고 (찾으러 가야 함)
- Deep Archive: 외부 창고 (하루 걸림)
내구성 vs 가용성
| 구분 | 설명 | 쉬운 설명 |
|---|---|---|
| 내구성 (Durability) | 99.999999999% (11 9's) | 데이터가 손실되지 않을 확률 |
| 가용성 (Availability) | 스토리지 클래스마다 다름 | 데이터에 접근할 수 있을 확률 |
💡 내구성 예시: 1천만 개 객체 저장 시 평균 1만 년에 1개 손실
💡 가용성 예시: 99.99% = 1년에 약 52분 정도 접근 불가할 수 있음
스토리지 클래스 종류
8.1 S3 Standard (범용)
한 줄 요약: 자주 사용하는 데이터를 위한 기본 클래스
| 항목 | 값 |
|---|---|
| 가용성 | 99.99% |
| 용도 | 자주 접근하는 데이터 |
| 특징 | 저지연, 높은 처리량, 2개 시설 동시 장애 견딤 |
| 사용 사례 | 빅데이터 분석, 모바일/게임 앱, 콘텐츠 배포 |
언제 사용?
- 매일 또는 매주 접근하는 데이터
- 빠른 응답이 필요한 웹 콘텐츠
- 활성 사용 중인 애플리케이션 데이터
8.2 S3 Standard-IA (Infrequent Access)
한 줄 요약: 가끔 접근하지만 필요할 때는 빨리 꺼내야 하는 데이터
| 항목 | 값 |
|---|---|
| 가용성 | 99.9% |
| 용도 | 자주 접근 안 하지만 빠른 접근 필요 시 |
| 비용 | Standard보다 저장 비용 저렴, 검색 비용 있음 |
| 사용 사례 | 재해 복구, 백업 |
언제 사용?
- 월 1회 정도 접근하는 데이터
- 백업 데이터 (복구 시 빠른 접근 필요)
- 오래된 로그 파일
⚠️ 주의: 최소 30일 저장 요금이 부과됩니다
8.3 S3 One Zone-IA
한 줄 요약: Standard-IA와 같지만 단일 AZ에만 저장 (더 저렴, 더 위험)
| 항목 | 값 |
|---|---|
| 가용성 | 99.5% |
| 특징 | 단일 AZ (AZ 파괴 시 데이터 손실) |
| 사용 사례 | 보조 백업, 재생성 가능한 데이터 |
언제 사용?
- 다른 곳에 원본이 있는 보조 백업
- 손실되어도 다시 생성 가능한 데이터 (썸네일, 변환된 파일 등)
- 비용 절감이 최우선이고 데이터 손실 위험 감수 가능할 때
Standard-IA: One Zone-IA:
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│ AZ1 │ │ AZ2 │ │ AZ3 │ │ AZ1 │ ← 이 AZ가 장애나면 데이터 손실!
│ ● │ │ ● │ │ ● │ │ ● │
└─────┘ └─────┘ └─────┘ └─────┘
3개 AZ에 복제 1개 AZ만 사용8.4 S3 Glacier 클래스
한 줄 요약: 아카이브(장기 보관)용 초저가 스토리지
| 클래스 | 검색 시간 | 최소 저장 기간 | 용도 |
|---|---|---|---|
| Glacier Instant Retrieval | 밀리초 | 90일 | 분기 1회 접근 데이터 |
| Glacier Flexible Retrieval | 1분 ~ 12시간 | 90일 | 아카이브 |
| Glacier Deep Archive | 12시간 ~ 48시간 | 180일 | 장기 보관 |
Glacier 3종 비교:
검색 속도 비용 사용 사례
│ │ │
Glacier Instant ─────┼─ 밀리초 │ $0.004/GB │ 의료 영상, 미디어 자산
│ │ │
Glacier Flexible ─────┼─ 분~시간 │ $0.0036/GB │ 백업, 재해 복구
│ │ │
Glacier Deep ─────┼─ 12~48시간 │ $0.00099/GB │ 규정 준수 아카이브
▼ ▼ ▼Glacier Flexible Retrieval 검색 옵션:
| 옵션 | 시간 | 비용 | 사용 사례 |
|---|---|---|---|
| Expedited | 1~5분 | 비쌈 | 긴급 복구 |
| Standard | 3~5시간 | 보통 | 일반 복구 |
| Bulk | 5~12시간 | 무료 | 대량 데이터, 급하지 않을 때 |
Glacier Deep Archive 검색 옵션:
| 옵션 | 시간 | 사용 사례 |
|---|---|---|
| Standard | 12시간 | 일반 복구 |
| Bulk | 48시간 | 대량 데이터 |
언제 Glacier를 사용?
- 법적 보관 의무가 있는 데이터 (7년 보관 등)
- 거의 접근하지 않는 오래된 데이터
- 규정 준수를 위한 아카이브
8.5 S3 Intelligent-Tiering
한 줄 요약: 접근 패턴을 모를 때 AWS가 자동으로 최적의 클래스로 이동
| 항목 | 설명 |
|---|---|
| 특징 | 사용 패턴에 따라 자동으로 티어 이동 |
| 비용 | 월간 모니터링 + 자동 티어링 비용 |
| 검색 비용 | 없음 |
티어 구성:
| 티어 | 조건 | 자동/선택 |
|---|---|---|
| Frequent Access | 기본 티어 | 자동 |
| Infrequent Access | 30일 미접근 | 자동 |
| Archive Instant Access | 90일 미접근 | 자동 |
| Archive Access | 90~700일+ 설정 | 선택 |
| Deep Archive Access | 180~700일+ 설정 | 선택 |
Intelligent-Tiering 작동 방식:
파일 업로드 ──▶ Frequent Access (기본)
│
30일 미접근
▼
Infrequent Access
│
90일 미접근
▼
Archive Instant Access
│
▼ (선택 활성화 시)
Archive Access / Deep Archive Access언제 Intelligent-Tiering을 사용?
- 데이터 접근 패턴이 예측 불가능할 때
- 직접 관리하기 귀찮을 때 (AWS가 알아서 최적화)
- 검색 비용 없이 자동 비용 최적화를 원할 때
9. 스토리지 클래스 비교표
| 클래스 | 가용성 | AZ 수 | 최소 저장 기간 | 검색 비용 |
|---|---|---|---|---|
| Standard | 99.99% | ≥3 | 없음 | 없음 |
| Intelligent-Tiering | 99.9% | ≥3 | 없음 | 없음 |
| Standard-IA | 99.9% | ≥3 | 30일 | GB당 |
| One Zone-IA | 99.5% | 1 | 30일 | GB당 |
| Glacier Instant | 99.9% | ≥3 | 90일 | GB당 |
| Glacier Flexible | 99.99% | ≥3 | 90일 | GB당 |
| Glacier Deep Archive | 99.99% | ≥3 | 180일 | GB당 |
10. 스토리지 클래스 가격 비교 (us-east-1 기준)
| 클래스 | 저장 비용 (GB/월) | 특징 |
|---|---|---|
| Standard | $0.023 | 가장 높음 |
| Intelligent-Tiering | $0.0025~$0.023 | 자동 최적화 |
| Standard-IA | $0.0125 | Standard의 약 절반 |
| One Zone-IA | $0.01 | 단일 AZ |
| Glacier Instant | $0.004 | 빠른 검색 |
| Glacier Flexible | $0.0036 | 유연한 검색 옵션 |
| Glacier Deep Archive | $0.00099 | 가장 저렴 |
스토리지 클래스 선택 가이드
자주 접근? ─────────────────────────────────────┐
│ │
├─ Yes → S3 Standard │
│ │
└─ No ─┬─ 빠른 접근 필요? ─┬─ Yes ──────────┤
│ │ │
│ └─ No → Glacier │
│ │
└─ 접근 패턴 예측 불가? → Intelligent-Tiering핵심 포인트 요약
- 버킷명은 전역 고유 - 모든 리전, 모든 계정 통틀어 유일해야 함
- 5GB 초과 → Multi-part Upload 필수
- EC2에서 S3 접근 → IAM Role 사용 (Access Key 대신)
- 버전 관리 - 삭제 방지, 롤백에 필수
- 복제는 버전 관리 필수 - CRR/SRR 모두
- 비용 최적화 - Lifecycle 정책으로 스토리지 클래스 자동 전환