오토스케일링을 붙였더니(오토스케일링 + 로드밸런서) 새 문제가 터졌습니다. 사용자가 올린 프로필 사진이 "어떤 인스턴스에 접속했느냐"에 따라 보이기도, 안 보이기도 합니다. 각 인스턴스의 로컬 디스크에 파일을 저장한 탓입니다. 게다가 로그·백업이 인스턴스 디스크에 쌓여 용량이 꽉 찼습니다. 데이터를 '어떤 종류의 저장소'에 두느냐가 확장성과 비용을 가릅니다.
- 1오브젝트·블록·파일 스토리지의 근본 차이를 설명할 수 있다
- 2각 스토리지가 어떤 접근 패턴에 적합한지 판단할 수 있다
- 3오토스케일링 환경에서 파일을 어디에 둬야 하는지 안다
- 4스토리지 클래스·수명주기로 비용을 최적화하는 법을 안다
- 5내구성과 가용성의 의미 차이를 구분할 수 있다
세 가지 저장 방식
오브젝트 · 블록 · 파일 — 접근 방식이 다르다
- 오브젝트 스토리지(S3): 파일을 '객체(데이터+메타데이터+키)'로 저장, HTTP API로 접근. 사실상 무한 용량, 매우 높은 내구성. 정적 자산·이미지·백업·로그·데이터레이크에 적합. 부분 수정·랜덤 액세스엔 부적합(통째 교체).
- 블록 스토리지(EBS): 인스턴스에 디스크처럼 붙여 OS가 파일시스템을 올림. 낮은 지연·랜덤 R/W. DB 데이터파일·OS 디스크에 적합. 보통 한 인스턴스 전용.
- 파일 스토리지(EFS): NFS 등으로 여러 인스턴스가 동시 마운트하는 공유 파일시스템. 레거시 공유 디렉터리, 다중 워커 공유에 적합.
오토스케일링이라면 — 업로드 파일은 오브젝트 스토리지로
인스턴스가 수시로 생기고 사라지는 환경(오토스케일링 + 로드밸런서)에서 사용자 업로드를 인스턴스 로컬 디스크(블록)에 두면, 그 인스턴스가 죽을 때 파일이 사라지고 다른 인스턴스는 그 파일을 모릅니다.
정답은 업로드 파일을 오브젝트 스토리지에 두는 것입니다. 모든 인스턴스가 같은 객체를 API로 접근하고, CDN(DNS와 CDN)을 앞에 붙여 빠르게 제공합니다. 무상태 설계의 핵심 조각입니다.
내구성 vs 가용성 — 다른 약속
오브젝트 스토리지가 말하는 내구성(durability) 은 '데이터가 유실되지 않을 확률'(예: 99.999999999%, 11 9's)입니다. 여러 시설에 복제해 사실상 안 잃습니다. 가용성(availability) 은 '필요할 때 접근 가능한 시간 비율'로 별개입니다. 내구성이 높다고 항상 즉시 접근된다는 뜻은 아닙니다(아카이브 클래스는 꺼내는 데 시간).
오브젝트 스토리지 사고의 압도적 원인은 '실수로 공개된 버킷'입니다. 퍼블릭 차단이 켜져 있는지 확인합니다.
aws s3api get-public-access-block --bucket my-bucket \
--query "PublicAccessBlockConfiguration"
{
"BlockPublicAcls": true,
"IgnorePublicAcls": true,
"BlockPublicPolicy": true,
"RestrictPublicBuckets": true
}
aws s3api get-public-access-block오래된 로그·백업이 비싼 Standard에 쌓이면 비용 누수입니다. 수명주기 규칙을 확인합니다.
aws s3api get-bucket-lifecycle-configuration --bucket my-logs \
--query "Rules[].{Id:ID,Days:Transitions[0].Days,Class:Transitions[0].StorageClass}"
[ { "Id": "to-ia-then-archive", "Days": 90, "Class": "STANDARD_IA" } ]
aws s3api get-bucket-lifecycle-configuration- get-public-access-block의 네 값이 모두 true가 아니면 — 공개 노출 위험. 의도된 정적 호스팅이 아니면 즉시 차단
- 수명주기 규칙 없는 로그/백업 버킷 — 오래된 객체가 비싼 클래스에 무한 누적. Days 기준 이전/만료 규칙 추가
- 업로드 파일이 인스턴스 로컬에 저장되는 코드 — 오토스케일/재배포 시 유실. 오브젝트 스토리지로 이전
- 버전 관리(versioning)·삭제 방지 설정 — 실수/랜섬 대비. 중요 버킷은 버전 관리+MFA 삭제 검토
상황: 오브젝트 접근 권한이 의도와 다름(너무 막히거나 너무 열림).
원인: 오브젝트 공개 여부는 ① 계정/버킷의 퍼블릭 액세스 차단, ② 버킷 정책, ③ 객체 ACL이 함께 작용. 비공개가 기본이며, 일부만 공유하려면 정책 대신 사전 서명 URL(presigned URL) 로 한시적 접근을 주는 게 안전.
진단: get-public-access-block → 버킷 정책 → 해당 객체 ACL 순으로 확인.
해결: 공개 호스팅이 목적이면 CDN 경유로만 노출(원본 버킷은 비공개, OAC로 CDN만 접근). 임시 공유는 presigned URL(만료 시간 지정). "전체 공개로 열어 해결"은 사고로 가는 지름길.
스토리지 선택은 비용과 직결됩니다. "왜 클라우드 비용이 높냐"를 파면 ① 안 끄는 인스턴스, ② 수명주기 없는 스토리지가 단골입니다. 오래된 객체를 IA/Archive로 자동 이전하면 저장비가 수십 % 줄기도 합니다(클라우드 비용 최적화).
또한 데이터 유출 사고의 상당수가 '공개된 버킷'에서 납니다. 보안 감사에서 가장 먼저 스캔하는 항목이며, 퍼블릭 차단을 계정 차원에서 강제하고 예외만 검토하는 가드레일(관측과 거버넌스)을 둡니다.
다음 모듈에서는 블록 스토리지 위에서 도는 데이터의 핵심 — 관리형 데이터베이스(RDS) 의 멀티AZ·읽기 복제·백업을 다룹니다.