S3와 오브젝트 스토리지

객체 모델 — 버킷과 키, 그리고 폴더가 없다는 사실

Amazon S3는 파일 시스템이 아니라 객체 스토리지(object storage)입니다. 데이터는 버킷(bucket) 안에 객체(object)로 저장되고, 객체는 키(key)라는 문자열로 식별됩니다. 블록 단위로 일부만 고쳐 쓰는 동작이 없고, 객체는 통째로 올리거나 통째로 대체합니다.

logs/2026/07/app.log처럼 슬래시가 들어간 키를 콘솔이 폴더처럼 보여 주지만, S3에 디렉터리 구조는 존재하지 않습니다. 슬래시는 키 문자열의 일부일 뿐이고, 앞부분은 접두사(prefix)로 불립니다. 이 사실은 뒤의 성능 절에서 요청 분산의 근거가 됩니다.

객체에는 데이터 외에 메타데이터가 붙습니다. Content-Type 같은 시스템 메타데이터, 사용자가 붙이는 사용자 정의 메타데이터, 그리고 접근 제어와 수명 주기 규칙의 필터로 쓰이는 객체 태그가 있습니다. 메타데이터만 따로 고칠 수는 없고, 메타데이터를 바꾸려면 객체 전체를 다시 올려야 합니다.

일관성 모델 — 강력한 읽기 후 쓰기 일관성 SAA 빈출

Amazon S3는 모든 AWS 리전에서 강력한 읽기 후 쓰기 일관성(strong read-after-write consistency)을 제공합니다. 신규 객체를 올린 직후에도, 기존 객체를 덮어쓴 직후에도, 삭제한 직후에도 다음 읽기는 항상 최신 상태를 반환합니다.

• 신규 객체 PUT · 기존 객체를 덮어쓰는 PUT · DELETE 모두 강력한 일관성
• 객체 목록 조회(LIST)도 강력한 일관성 — 새 객체를 쓴 직후 목록을 조회하면 그 객체가 보인다
• ACL · 객체 태그 · 객체 메타데이터 읽기도 강력한 일관성
• 단일 키에 대한 갱신은 원자적(atomic)이다 — 동시에 읽으면 이전 데이터나 새 데이터를 받고, 부분적으로 섞인 데이터는 절대 반환되지 않는다

추가 요금도, 성능 저하도, 별도 설정도 없습니다. "쓰고 나서 잠깐 기다렸다 읽어야 한다", "재시도 루프를 넣어야 한다" 같은 설계는 이제 필요하지 않습니다.

신규 버킷의 현행 기본값 SAA 빈출

지금 새로 만드는 버킷은 기본적으로 닫혀 있고 기본적으로 암호화됩니다. 이 사실을 모르면 시나리오 문항에서 불필요한 조치를 정답으로 고르게 됩니다.

객체 소유권이 BucketOwnerEnforced라는 것은 ACL이 아예 동작하지 않는다는 뜻입니다. 다른 계정이 이 버킷에 객체를 올려도 소유자는 버킷 소유자가 되고, 접근 제어는 전적으로 버킷 정책과 IAM 정책으로 합니다. AWS는 특별한 사유가 없는 한 이 상태를 유지할 것을 권장합니다.

스토리지 클래스 — 접근 빈도와 검색 시간이 기준

스토리지 클래스는 객체 단위 속성입니다. 같은 버킷 안에서 객체마다 다른 클래스를 쓸 수 있고, 올릴 때 지정하거나 나중에 수명 주기 규칙으로 바꿉니다. 지정하지 않으면 S3 Standard입니다.

선택 기준은 두 가지뿐입니다. 얼마나 자주 읽는가와 읽어야 할 때 얼마나 빨리 필요한가입니다. 여기에 최소 저장 기간이라는 제약이 붙어서, 자주 지우는 데이터를 차가운 클래스에 두면 오히려 손해가 나는 구간이 생깁니다.

One Zone-IA — 무엇을 내주고 싼가

S3 One Zone-IA는 데이터를 단 하나의 가용 영역에만 저장합니다. 그래서 Standard-IA보다 저렴하지만, 그 대가가 명확합니다 — 해당 가용 영역이 물리적으로 손실되면 데이터도 손실됩니다. 다른 클래스는 세 개 이상의 지리적으로 분리된 가용 영역에 저장되므로 가용 영역 하나가 사라져도 데이터가 남습니다.

따라서 One Zone-IA가 맞는 데이터는 다시 만들 수 있거나 다른 곳에 원본이 있는 데이터입니다. 원본에서 다시 생성할 수 있는 썸네일, 다른 리전에 복제본이 있는 보조 사본, 온프레미스에 원본이 남아 있는 백업의 2차 사본 같은 것들입니다.

Intelligent-Tiering — 접근 패턴을 모를 때

S3 Intelligent-Tiering은 접근 패턴을 모니터링해서 객체를 자동으로 옮기는 클래스입니다. 선택 기준은 단 하나입니다 — 접근 패턴을 모르거나 계속 변할 때 씁니다. 패턴을 이미 안다면 해당 클래스를 직접 지정하는 편이 낫습니다.

중요한 성질이 셋 있습니다. (1) 검색 요금이 없습니다 — 티어가 어디든 읽는 데 추가 검색 요금이 붙지 않습니다. (2) 최소 저장 기간이 없습니다. (3) 대신 객체당 모니터링·자동화 요금이 붙습니다 — 그래서 아주 작은 객체가 아주 많으면 오히려 불리할 수 있습니다.

기본 세 티어는 모두 밀리초 접근이지만, 선택 티어인 Archive Access와 Deep Archive Access는 비동기 접근입니다. 이 두 티어에 있는 객체는 RestoreObject로 먼저 복원해야 읽을 수 있으므로, 애플리케이션이 즉시 읽어야 한다면 켜지 않습니다.

128 KB 미만 객체는 모니터링 대상이 아니며 자동 계층화되지 않고 Frequent Access 티어에 남습니다.

Glacier 계열 — 검색 시간이 클래스를 가른다

Glacier 계열 세 클래스의 차이는 저장 비용이 아니라 읽어야 할 때 얼마나 걸리는가입니다.

복원 요청의 티어는 Expedited · Standard · Bulk 세 가지입니다. Flexible Retrieval에서 대량(Bulk) 검색은 무료이고, 신속 검색은 가장 빠른 대신 비쌉니다. 두 클래스 모두 복원 요청은 계정당 초당 최대 1,000 트랜잭션까지 처리됩니다.

수명 주기 규칙 — 전환, 만료, 그리고 비용 누수 차단

수명 주기 구성(lifecycle configuration)은 버킷에 붙이는 규칙 집합입니다. 규칙 하나는 필터(어떤 객체에), 상태(켜짐/꺼짐), 동작(무엇을)으로 이루어집니다. 필터는 키 접두사 · 객체 태그 · 객체 크기 또는 이들의 조합으로 지정할 수 있고, 한 버킷의 수명 주기 구성은 최대 1,000개 규칙까지 가질 수 있습니다.

전환 규칙의 제약

수명 주기 전환에는 시험에서 반복되는 제약이 셋 있습니다.

• Standard-IA 또는 One Zone-IA로 전환하려면 객체가 최소 30일 저장되어 있어야 합니다. "업로드 즉시 IA로 보내 비용을 아낀다"는 규칙은 만들 수 없습니다.
• 버전 관리 버킷의 비현재 버전도 최소 30일 비현재 상태여야 전환됩니다.
• 128 KB 미만 객체는 전환되지 않습니다. 최소 청구 크기 때문에 작은 객체를 옮겨도 절감 효과가 없거나 오히려 손해이기 때문입니다.

만료와 비현재 버전 정리

만료(expiration) 동작은 객체를 지웁니다. 버전 관리가 켜진 버킷에서는 현재 버전의 만료가 삭제 마커를 남기는 것이고, 실제로 저장 용량을 줄이려면 비현재 버전 만료를 함께 설정해야 합니다. 만료된 삭제 마커를 정리하는 동작도 따로 있습니다.

불완전 멀티파트 업로드 정리 SAA 빈출

멀티파트 업로드를 시작하고 완료도 중단도 하지 않으면, 이미 올라간 파트가 계속 저장되고 계속 과금됩니다. 이 파트들은 객체 목록에 보이지 않습니다. 그래서 "버킷에 든 게 별로 없는데 요금이 계속 늘어난다"는 상황이 만들어집니다. 전형적인 비용 누수이고, 원인을 모르면 영원히 찾지 못합니다.

해결은 수명 주기 규칙의 AbortIncompleteMultipartUpload 동작입니다. 시작 후 지정한 일수가 지난 불완전 업로드의 파트를 S3가 자동으로 지웁니다. 신규 버킷을 만들 때 기본으로 넣어 두는 규칙이라고 생각하는 편이 좋습니다.

{
  "Rules": [
    {
      "ID": "logs-tiering",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30,  "StorageClass": "STANDARD_IA" },
        { "Days": 90,  "StorageClass": "GLACIER" },
        { "Days": 180, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 }
    },
    {
      "ID": "expire-noncurrent-versions",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 },
      "ExpiredObjectDeleteMarker": true
    },
    {
      "ID": "abort-incomplete-multipart-uploads",
      "Status": "Enabled",
      "Filter": {},
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration \
  --bucket example-app-logs \
  --lifecycle-configuration file://lifecycle.json

# 목록에 보이지 않는 미완료 멀티파트 업로드를 직접 확인합니다.
aws s3api list-multipart-uploads \
  --bucket example-app-logs \
  --query 'Uploads[].[Key,Initiated,UploadId]' \
  --output table

버저닝, 삭제 마커, MFA Delete, Object Lock

버전 관리를 켜면 같은 키에 쓸 때마다 새 버전 ID가 붙은 버전이 쌓입니다. 상태는 비활성 · Enabled · Suspended 세 가지이고, 한 번 켠 뒤에는 완전한 비활성 상태로 되돌릴 수 없습니다. 중지(Suspended)하면 새 버전이 더 생기지 않을 뿐, 이미 쌓인 버전은 그대로 남습니다.

삭제 마커 — 지운 게 아니라 가린 것

버전 관리 버킷에서 버전 ID 없이 DELETE를 호출하면 객체가 지워지는 것이 아니라 삭제 마커(delete marker)가 최신 버전으로 올라갑니다. 이후 일반 GET은 404를 반환하지만, 데이터는 이전 버전으로 그대로 남아 있고 계속 과금됩니다.

• 복구 — 삭제 마커를 지우면 직전 버전이 다시 최신 버전이 됩니다.
• 영구 삭제 — 버전 ID를 명시해서 DELETE를 호출해야 합니다.
• 비용 — 정리 규칙이 없으면 버전이 무한정 쌓입니다. 비현재 버전 만료와 짝지어 쓰는 이유입니다.

MFA Delete

MFA Delete를 켜면 다음 두 작업에 MFA 장치의 인증 코드가 추가로 필요합니다.

• 객체 버전의 영구 삭제
• 버킷의 버전 관리 상태 변경

제약이 까다롭습니다. 버킷을 소유한 계정의 루트 사용자만 활성화할 수 있고, 콘솔로는 켤 수 없어 AWS CLI나 API를 써야 하며, 수명 주기 구성과 함께 쓸 수 없습니다. 요청은 HTTPS여야 합니다.

aws s3api put-bucket-versioning \
  --bucket example-app-data \
  --versioning-configuration Status=Enabled

# MFA Delete 는 루트 사용자만, CLI 또는 API 로만 켤 수 있습니다.
aws s3api put-bucket-versioning \
  --bucket example-app-data \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::123456789012:mfa/root-account-mfa-device 123456"

Object Lock — WORM 보존

S3 Object Lock은 한 번 쓰면 여러 번 읽을 수 있는(write-once-read-many, WORM) 모델로 객체 버전을 보호합니다. 규정 준수 요구를 만족시키는 장치입니다. 버전 관리가 켜져 있어야 하고, 보호는 객체 버전 단위로 적용됩니다.

보존 기간은 객체마다 직접 지정하거나 버킷 기본 설정으로 줄 수 있습니다. 기본 설정을 쓰면 객체가 들어올 때마다 생성 시각에 기간을 더해 보존 만료 시각이 계산됩니다. 같은 키에 새로 PUT하면 새 버전이 만들어지고 이전 버전은 원래 보존 기간을 유지합니다.

복제 — CRR과 SRR은 목적이 다르다

복제(replication)는 버킷 사이에 객체를 자동으로, 비동기적으로 복사합니다. 원본과 대상 버킷은 같은 계정일 수도 다른 계정일 수도 있습니다.

복제의 전제 조건과 기본 동작

• 원본과 대상 버킷 양쪽에 버전 관리가 켜져 있어야 합니다.
• S3가 대신 복사할 수 있도록 IAM 역할을 지정해야 합니다.
• 기본적으로 복제 규칙을 추가한 뒤에 생성된 객체만 복제됩니다. 이미 있던 객체를 옮기려면 S3 배치 복제(Batch Replication)를 별도로 실행합니다.
• 원본 버킷에 Object Lock이 켜져 있으면 대상 버킷에도 켜져 있어야 합니다.
• 대상 버킷은 Requester Pays 버킷일 수 없습니다(교차 계정 구성에서).

삭제 동작이 특히 자주 출제됩니다. 버전 ID를 명시한 삭제는 대상 버킷에 전파되지 않습니다 — 악의적·실수 삭제로부터 사본을 지키기 위한 설계입니다. 버전 ID 없이 삭제해 생긴 삭제 마커는 최신 규칙 형식에서 기본적으로 복제되지 않고, 필요하면 삭제 마커 복제를 따로 켜야 합니다.

복제로 함께 넘어가는 것과 넘어가지 않는 것도 구분해 둡니다. 객체 메타데이터·태그·ACL 갱신·Object Lock 보존 정보는 함께 복제되고, 다른 규칙이 만들어 낸 복제본은 다시 복제되지 않습니다(연쇄 복제 없음). 복제 시 대상의 스토리지 클래스를 바꾸거나 복제본 소유자를 대상 계정으로 바꿀 수 있습니다.

복제 시간이 예측 가능해야 한다면 S3 복제 시간 제어(S3 RTC)를 켭니다. 신규 객체의 99.99%를 15분 안에 복제하며 서비스 수준 계약이 뒷받침합니다. 배치 복제에는 적용되지 않습니다.

{
  "Role": "arn:aws:iam::123456789012:role/s3-replication-role",
  "Rules": [
    {
      "ID": "crr-to-dr-region",
      "Priority": 1,
      "Status": "Enabled",
      "Filter": { "Prefix": "critical/" },
      "DeleteMarkerReplication": { "Status": "Enabled" },
      "Destination": {
        "Bucket": "arn:aws:s3:::example-dr-bucket",
        "StorageClass": "STANDARD_IA"
      }
    }
  ]
}

암호화 — 키를 누가 쥐는가 SAA 빈출

서버 측 암호화에는 서로 배타적인 네 가지 옵션이 있습니다. 기능 차이가 아니라 키를 누가 만들고, 누가 보관하고, 사용 기록이 어디에 남는가가 다릅니다. 선택 기준도 거기서 나옵니다.

SSE-KMS에서 키를 지정하지 않으면 AWS 관리형 키(aws/s3)가 쓰이고, 고객 관리형 키를 지정하면 키 정책·권한 부여·교체를 직접 통제할 수 있습니다. 키 사용은 KMS API 호출이므로 CloudTrail에 남고, 이것이 감사 요구가 있을 때 SSE-KMS가 답이 되는 이유입니다.

대신 객체마다 KMS 호출이 발생하므로 요청량이 많으면 KMS 요청 한도에 걸릴 수 있습니다. S3 버킷 키(S3 Bucket Key)를 켜면 KMS 호출 횟수를 줄일 수 있습니다.

SSE-C는 키를 요청마다 함께 보내고 S3는 그 키를 저장하지 않습니다. 암호화에 쓴 뒤 폐기하므로, 키를 분실하면 객체를 복호화할 방법이 없습니다. 키가 요청에 실려 가므로 HTTPS가 필수입니다.

네 가지 모두 서버 측 암호화입니다. 클라이언트 측 암호화(client-side encryption)는 별개로, 데이터를 S3에 보내기 전에 애플리케이션이 직접 암호화하는 방식입니다. "AWS가 평문을 절대 볼 수 없어야 한다"는 요구에만 씁니다.

{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:ap-northeast-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"
      },
      "BucketKeyEnabled": true
    }
  ]
}

접근 제어 — 요청은 어디서 막히는가

버킷 정책과 ACL

접근 제어 수단은 세 가지입니다. IAM 정책(주체에 붙임), 버킷 정책(리소스에 붙임), 그리고 ACL(현행 기본값에서는 비활성)입니다.

• 버킷 정책은 리소스 기반 정책이므로 다른 계정에 권한을 줄 수 있습니다. 교차 계정 접근의 기본 수단입니다.
• IAM 정책은 같은 계정 안의 주체에게 권한을 줍니다. 자격 증명 기반 정책과 리소스 기반 정책은 같은 계정에서 합집합으로 동작합니다 (2장 IAM과 자격 증명).
• ACL은 BucketOwnerEnforced에서 완전히 비활성입니다. ACL로 접근을 제어하는 설계는 더 이상 기본 구성이 아닙니다.

퍼블릭 액세스 차단은 이 모든 것보다 앞에서 동작합니다. 버킷 정책이 퍼블릭 접근을 허용하더라도 차단이 켜져 있으면 요청은 거부됩니다. 계정 수준과 버킷 수준 양쪽에서 설정할 수 있고, 어느 한쪽이라도 차단하면 차단됩니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-app-data",
        "arn:aws:s3:::example-app-data/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "DenyUnencryptedUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-app-data/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    }
  ]
}

프리사인 URL — 서명자의 권한을 빌린다

프리사인 URL(presigned URL)은 버킷 정책을 고치지 않고 한시적으로 객체를 내려받거나 올릴 수 있게 하는 장치입니다. 핵심 성질은 하나입니다 — URL은 그것을 만든 주체의 자격 증명과 권한으로 동작합니다. 받는 쪽은 AWS 자격 증명이 없어도 되고, 만든 쪽이 권한이 없으면 URL도 동작하지 않습니다.

콘솔에서 만들면 1분에서 12시간 사이로 지정할 수 있고, AWS CLI나 SDK로 만들면 최대 7일까지 지정할 수 있습니다. 임시 자격 증명으로 만들었다면 URL에 적힌 만료 시각과 무관하게 자격 증명이 만료되는 순간 URL도 만료됩니다. 만료 전까지는 여러 번 재사용할 수 있습니다.

aws s3 presign s3://example-app-data/reports/2026-07.pdf \
  --expires-in 3600

정적 웹사이트 호스팅

버킷을 정적 웹사이트로 게시할 수 있습니다. 인덱스 문서와 오류 문서를 지정하고 리다이렉션 규칙을 줄 수 있습니다. 시험에서 주의할 점은 두 가지입니다.

• S3 웹사이트 엔드포인트는 HTTPS를 제공하지 않습니다. HTTPS가 필요하면 앞에 Amazon CloudFront를 둡니다.
• 웹사이트 엔드포인트로 서비스하려면 객체가 공개되어야 합니다. 버킷을 비공개로 유지하면서 배포하는 방법이 CloudFront + 오리진 액세스 제어(OAC)이고, 이쪽이 대부분 문항의 정답입니다.

Requester Pays

기본적으로 버킷 소유자가 저장 요금과 데이터 전송 요금을 모두 냅니다. Requester Pays를 켜면 요청자가 요청 요금과 다운로드 요금을 내고, 소유자는 저장 요금만 냅니다. 공개 데이터셋을 배포하되 전송 비용을 떠안고 싶지 않을 때 씁니다.

• 익명 요청을 허용하지 않습니다. 모든 요청이 인증되어야 요금을 청구할 대상을 특정할 수 있습니다.
• 요청자는 x-amz-request-payer 헤더를 붙여 과금에 동의했음을 밝혀야 합니다. 빠뜨리면 403이 반환되고 그 요청 요금은 버킷 소유자가 냅니다.
• 요청자가 IAM 역할을 맡아 호출하면 역할이 속한 계정이 청구 대상입니다.

성능 — 접두사, 멀티파트, 전송 가속화

접두사별 요청 성능

S3는 요청률에 맞춰 자동으로 확장합니다. 확인된 기준은 파티션된 접두사 하나당 초당 최소 3,500건의 PUT·COPY·POST·DELETE와 초당 최소 5,500건의 GET·HEAD입니다. 버킷 안의 접두사 개수에는 제한이 없습니다.

그래서 읽기 성능을 늘리는 방법은 단순합니다 — 접두사를 나눠 병렬화합니다. 접두사 10개로 나누면 초당 55,000건의 읽기까지 확장할 수 있습니다. 다만 확장은 점진적이며 즉시 일어나지 않습니다. 확장이 진행되는 동안 503 Slow Down 오류가 보일 수 있고, 확장이 끝나면 사라집니다.

멀티파트 업로드

큰 객체는 멀티파트 업로드로 나누어 병렬 전송합니다. 처리량이 올라가고, 실패한 파트만 다시 올리면 되며, 업로드를 중간에 멈췄다 재개할 수 있습니다.

• 파트 번호는 1부터 10,000까지입니다.
• 각 파트는 최소 5 MB여야 합니다. 마지막 파트에는 최소 크기 제한이 없습니다.
• 같은 파트 번호로 다시 올리면 이전 파트를 덮어씁니다.
• 완료(CompleteMultipartUpload)하거나 중단(AbortMultipartUpload)하기 전까지 올라간 파트에 저장 요금이 계속 부과됩니다 (불완전 멀티파트 업로드 정리).

내려받을 때는 바이트 범위 요청(byte-range fetch)으로 한 객체를 여러 구간으로 나누어 병렬로 받을 수 있습니다. 앞부분만 필요할 때 앞부분만 받는 용도로도 씁니다.

# 상위 수준 명령은 임계값을 넘는 파일을 자동으로 멀티파트 업로드합니다.
aws configure set default.s3.multipart_threshold 64MB
aws configure set default.s3.multipart_chunksize 16MB

aws s3 cp ./large-dataset.tar s3://example-app-data/datasets/

# 전송 가속화 엔드포인트를 사용하려면 설정을 켭니다.
aws configure set default.s3.use_accelerate_endpoint true

Transfer Acceleration

S3 Transfer Acceleration은 버킷 단위 기능으로, Amazon CloudFront의 엣지 로케이션에 먼저 데이터를 받은 뒤 AWS 내부의 최적화된 경로로 버킷까지 전달합니다. 멀리 떨어진 클라이언트가 한 버킷으로 대용량을 올릴 때 효과가 있습니다.

• 버킷 이름이 DNS 규칙에 맞아야 하고 마침표를 포함하면 안 됩니다.
• 가상 호스팅 방식 요청만 지원하며 s3-accelerate 엔드포인트를 씁니다.
• 켠 뒤 전송 속도가 올라가기까지 최대 20분이 걸릴 수 있습니다.
• 모든 리전에서 지원하지는 않으며, 추가 데이터 전송 요금이 발생할 수 있습니다.

흔한 오해

시험 포인트 정리

확인 문제

이 장의 핵심을 확인하는 10문항입니다. 키보드만으로 완주할 수 있습니다 — 숫자키 1~5로 선택지를 고르고 Enter로 제출합니다.

이어서 볼 곳

• 9장 · 파일 스토리지와 데이터 전송 객체가 아니라 파일 시스템이 필요할 때, 그리고 대용량 데이터를 S3로 옮기는 수단을 다룹니다. 기본개념
• 6장 · EBS와 블록 스토리지 같은 스토리지라도 블록과 객체는 쓰임새가 다릅니다. 두 모델의 경계를 확인합니다. 기본개념
• 16장 · 보안·암호화·거버넌스 SSE-KMS가 기대는 AWS KMS의 키 종류와 키 정책, 봉투 암호화를 정면으로 다룹니다. 기본개념 · SAA 최우선
• 14장 · 엣지와 DNS 버킷을 비공개로 둔 채 배포하는 CloudFront와 오리진 액세스 제어를 이어서 봅니다. 기본개념
• 케이스 3 · S3 비용이 매달 늘어난다 스토리지 클래스, 수명 주기, 불완전 멀티파트 업로드가 실제 청구서에서 어떻게 얽히는지 추적합니다. 아키텍처 케이스
• 실습 3 · S3 정적 사이트 + CloudFront + OAC 버킷을 비공개로 유지하면서 정적 사이트를 배포하는 구성을 직접 만들어 봅니다. 실습 예제
• 한도와 기본값 빠른참조 최소 저장 기간과 최소 청구 크기처럼 반드시 외워야 하는 숫자를 확인된 값만 모아 두었습니다. 빠른참조
• 비용 최적화 아키텍처 설계 (20%) 스토리지 비용 최적화는 이 도메인의 첫 번째 과제 진술에 해당합니다. 시험 대비

공식 문서 출처

이 장의 수치 · 기본값 · 동작은 모두 아래 문서에서 확인했습니다.

• Amazon S3 사용 설명서 — Amazon S3란 무엇인가 — 모든 리전에서 제공되는 강력한 읽기 후 쓰기 일관성, 목록 조회 포함, 단일 키 갱신의 원자성
• Amazon S3 API 레퍼런스 — CreateBucket — 파티션 단위 전역 이름 공간, 퍼블릭 액세스 차단이 켜진 상태로 생성된다는 서술
• Amazon S3 API 레퍼런스 — ListBuckets — 계정당 범용 버킷 기본 할당량 10,000개와 페이지네이션 요건
• Amazon S3 API 레퍼런스 — PutBucketOwnershipControls — ObjectOwnership 기본값이 BucketOwnerEnforced이며 ACL이 비활성이라는 서술
• Amazon S3 사용 설명서 — 기본 암호화 FAQ — 모든 신규 객체가 SSE-S3로 자동 암호화되며 추가 요금이 없다는 서술
• AWS What's New — Amazon S3가 최대 객체 크기를 50 TB로 상향 — 2025년 12월 상향, GovCloud (US)를 제외한 모든 리전, 모든 스토리지 클래스 적용
• Amazon S3 사용 설명서 — 스토리지 클래스 사용 — 클래스별 가용 영역 수, 최소 저장 기간 30·90·180일, 최소 청구 크기 128 KB·40 KB, Intelligent-Tiering의 티어 이동 조건(30·90·180일)과 128 KB 미만 객체 제외, One Zone-IA가 단일 가용 영역이라는 서술
• Amazon S3 사용 설명서 — 수명 주기 전환 일반 고려 사항 — IA 계열 전환의 30일 하한, 비현재 버전의 30일 조건, 128 KB 미만 객체 전환 제외
• Amazon S3 API 레퍼런스 — PutBucketLifecycleConfiguration — 규칙 최대 1,000개, 접두사·태그·객체 크기 필터, AbortIncompleteMultipartUpload 동작
• Amazon S3 사용 설명서 — MFA Delete 구성 — 루트 사용자만 활성화 가능, 콘솔 불가, 수명 주기 구성과 병용 불가
• Amazon S3 사용 설명서 — Object Lock 동작 방식 — 거버넌스 모드와 규정 준수 모드의 차이, 법적 보존, 버킷 기본 보존 기간
• Amazon S3 사용 설명서 — 객체 복제 — 양쪽 버전 관리 필수, IAM 역할, CRR과 SRR의 용도, S3 RTC의 15분 · 99.99% 서비스 수준 계약
• Amazon S3 사용 설명서 — 무엇이 복제되는가 — 규칙 생성 이후 객체만 복제, 삭제 마커 기본 미복제, 버전 ID 지정 삭제 미전파, 연쇄 복제 없음
• Amazon S3 API 레퍼런스 — PutObject — 서버 측 암호화 네 가지가 상호 배타적이라는 서술, SSE-C 키를 S3가 저장하지 않는다는 점, BucketKeyEnabled의 역할, ACL 비활성 시 버킷 소유자가 모든 객체를 소유한다는 점
• Amazon S3 API 레퍼런스 — CopyObject — 단일 호출 복사 상한 5 GB와 그 이상은 UploadPartCopy를 써야 한다는 서술
• Amazon S3 API 레퍼런스 — UploadPart — 파트 번호 1–10,000, 각 파트 최소 5 MB(마지막 파트 제외), 같은 번호 재업로드 시 덮어쓰기
• Amazon S3 API 레퍼런스 — CreateMultipartUpload — 완료하거나 중단하기 전까지 파트 저장 요금이 계속 부과된다는 서술
• Amazon S3 사용 설명서 — 성능 최적화 모범 사례 — 파티션된 접두사당 초당 3,500 쓰기 / 5,500 읽기, 접두사 수 무제한, 확장 중 503 Slow Down
• Amazon S3 사용 설명서 — Transfer Acceleration — CloudFront 엣지 경유, 마침표 없는 DNS 규칙 준수 버킷 이름, 활성화 후 최대 20분
• Amazon S3 사용 설명서 — 프리사인 URL 사용 — 서명한 주체의 자격 증명으로 동작, 인스턴스 프로파일 6시간 · STS 36시간 · IAM 사용자 7일, 콘솔 1분–12시간, 만료 전 재사용 가능
• Amazon S3 사용 설명서 — Requester Pays 버킷 — 요청자가 요청·다운로드 요금, 소유자가 저장 요금, 익명 요청 불가, x-amz-request-payer 헤더 누락 시 소유자에게 청구
• Amazon S3 사용 설명서 — 정적 웹사이트 호스팅 — 인덱스·오류 문서 지정과 웹사이트 엔드포인트의 성격