S3란 — 서버 디스크와 무엇이 다른가
Amazon S3(Simple Storage Service)는 파일을 서버 디스크가 아니라 객체(Object) 단위로 저장하는 관리형 스토리지입니다. 이미지, 문서, 로그, 백업, 정적 웹 자산처럼 파일 형태의 데이터를 저장할 때 가장 많이 사용합니다.
사용자 업로드 파일을 EC2 로컬 디스크에만 저장하면 Auto Scaling으로 서버가 여러 대가 되었을 때 파일이 특정 서버에만 존재하거나, 서버 교체·종료 시 파일을 잃을 수 있습니다. S3에 저장하면 애플리케이션 서버 수명주기와 파일 수명주기를 분리할 수 있습니다.
Bucket = 창고, Object = 창고에 넣은 물건, Key = 물건을 찾는 전체 이름표, Prefix = 이름표 앞부분을 묶어 폴더처럼 보이게 하는 분류입니다.
예를 들어
uploads/2026/photo.jpg라는 Key라면 실제 물건은 photo.jpg 객체이고, uploads/2026/ 부분을 Prefix로 묶어 볼 수 있습니다.S3 기본 구조
| 용어 | 의미 | 예시 |
|---|---|---|
| Bucket | 객체를 담는 최상위 컨테이너. 일반 목적 버킷은 기본적으로 shared global namespace를 사용하며 이 경우 partition 내에서 이름이 고유해야 합니다. 필요하면 계정·리전 전용 account regional namespace도 선택할 수 있습니다. | company-prod-assets |
| Object | 실제 데이터 + 메타데이터로 구성된 저장 단위 | 이미지, PDF, 로그 파일 |
| Key | 버킷 안에서 객체를 식별하는 전체 이름 | uploads/2026/photo.jpg |
| Prefix | Key 앞부분을 묶어 폴더처럼 보이게 하는 논리적 구분 | uploads/2026/ |
콘솔에서는
/가 포함된 Key를 폴더처럼 보여주지만 실제 저장 단위는 객체와 Key입니다.스토리지 클래스 — 접근 패턴에 맞춰 비용 최적화
S3는 접근 빈도와 복구 속도에 따라 여러 스토리지 클래스를 제공합니다. 저장 단가만 비교하면 안 되고 최소 보관기간, 검색 비용, 복구 시간, 요청 비용까지 함께 봐야 합니다.
| 클래스 | 적합한 데이터 | 특징 |
|---|---|---|
| S3 Standard | 자주 읽는 이미지·정적 파일·업로드 파일 | 기본 범용 클래스, 즉시 접근 |
| Intelligent-Tiering | 접근 패턴을 예측하기 어려운 데이터 | 접근 빈도에 따라 계층을 자동 조정 |
| Standard-IA | 가끔 읽지만 필요 시 즉시 복구해야 하는 데이터 | 저장 비용은 낮고 검색 비용이 발생할 수 있음 |
| One Zone-IA | 재생성 가능한 비핵심 데이터 | 단일 AZ 저장 특성을 이해하고 사용 |
| Glacier 계열 | 장기 보관·아카이브 | 클래스별 복구 시간과 비용 차이가 큼 |
S3 비용은 리전, 스토리지 클래스, 저장 용량, 요청 수, 데이터 검색·전송량에 따라 달라집니다. 설계할 때는 현재 AWS 가격표와 실제 접근 패턴을 기준으로 계산합니다.
버전 관리 — 덮어쓰기와 삭제 실수에 대비
S3 Versioning을 활성화하면 같은 Key로 객체를 다시 업로드해도 이전 객체를 덮어 없애는 대신 여러 버전을 보존할 수 있습니다. 실수로 파일을 덮어썼거나 삭제했을 때 이전 버전으로 복구할 수 있습니다.
이전 버전 복원, 실수 삭제 복구, 변경 이력 보존에 유리합니다.
이전 버전도 저장 용량을 차지합니다. Lifecycle과 함께 관리하지 않으면 저장비가 계속 늘 수 있습니다.
Lifecycle — 오래된 객체를 자동 정리
Lifecycle 규칙은 객체가 일정 조건을 만족하면 다른 스토리지 클래스로 이동시키거나 만료시키는 자동화 기능입니다. Versioning을 사용하는 버킷에서는 현재 버전과 이전 버전(Noncurrent Version)을 따로 관리할 수 있습니다.
보안 — 공개하지 않는 것을 기본값으로
새 S3 버킷과 객체는 기본적으로 퍼블릭 접근을 허용하지 않으며, Block Public Access를 이용해 정책이나 ACL이 실수로 공개 권한을 부여하는 상황을 막을 수 있습니다. 공개가 꼭 필요한 경우에도 버킷 전체를 공개하기보다 목적에 맞는 접근 방식을 선택하는 것이 안전합니다.
서버 측 암호화
Amazon S3의 새 객체는 기본적으로 SSE-S3 서버 측 암호화가 적용됩니다. 별도의 키 관리·감사 요구가 있다면 SSE-KMS를 선택할 수 있으며, KMS 사용 시에는 키 정책과 KMS 요청 비용·쿼터도 함께 고려해야 합니다.
| 방식 | 키 관리 | 사용 판단 |
|---|---|---|
| SSE-S3 | S3 관리 키 | 기본적인 저장 데이터 암호화 |
| SSE-KMS | AWS KMS 키 | 키 정책·감사·세부 권한 제어가 필요한 경우 |
| DSSE-KMS | AWS KMS 기반 이중 계층 | 이중 암호화 요구가 있는 워크로드 |
Presigned URL — 비공개 객체에 임시 접근 권한 주기
Presigned URL은 버킷 정책을 공개로 바꾸지 않고도 특정 객체에 시간 제한 접근 권한을 부여하는 방식입니다. 다운로드뿐 아니라 특정 Key에 업로드하도록 허용하는 데도 사용할 수 있습니다.
필요 이상으로 긴 만료시간을 주지 말고, URL을 생성한 IAM 주체의 권한도 최소화해야 합니다. 같은 Key로 업로드하면 기존 객체를 대체할 수 있으므로 Key 설계도 중요합니다.
정적 콘텐츠 배포 — S3 + CloudFront + OAC
정적 웹 자산을 인터넷에 제공할 때는 S3 버킷을 직접 공개하기보다 비공개 S3 버킷을 CloudFront의 Origin으로 연결하고 OAC(Origin Access Control)를 사용하는 구성이 권장됩니다.
CloudFront OAC를 사용하는 보안 구성은 일반 S3 버킷 Origin을 사용합니다. S3 정적 웹사이트 엔드포인트를 CloudFront의 Custom Origin으로 쓰는 방식과는 구조가 다릅니다.
안전한 구성 순서
| 단계 | 작업 | 핵심 포인트 |
|---|---|---|
| 1 | S3 버킷 생성 | Block Public Access 유지 |
| 2 | 빌드 파일 업로드 | index.html, CSS, JS, 이미지 등 |
| 3 | CloudFront Distribution 생성 | 일반 S3 Bucket Origin 선택 |
| 4 | OAC 연결 | CloudFront가 S3에 서명된 요청을 보내도록 설정 |
| 5 | Bucket Policy 확인 | CloudFront Distribution만 필요한 객체를 읽도록 제한 |
실무 설계 체크 — 무엇을 어디에 저장할까
비공개 버킷 + IAM Role + Presigned URL을 기본으로 검토합니다. 객체 Key는 사용자 원본 파일명만 믿지 말고 충돌·노출을 피하도록 별도 규칙으로 생성합니다.
Private S3 + CloudFront + OAC 조합을 우선 검토합니다. 캐시 정책과 무효화 전략은 CH07에서 이어서 학습합니다.
Versioning과 Lifecycle을 함께 설계해 복구 가능성과 장기 저장 비용을 균형 있게 관리합니다.
최소 권한 정책, 암호화 방식, 접근 로그·감사 요구를 함께 검토합니다. 단순히 버킷을 비공개로 만드는 것만으로 끝나지 않습니다.