S3 data protection

Exam tasks: 5.2.1 (client- vs server-side encryption), 5.2.2 (integrity: Object Lock, Glacier Vault Lock, versioning), 5.2.3 (lifecycle and retention)

The decision: for this bucket, which key encrypts objects and who can use it, who can reach the bucket and from where, and what stops anyone (including an administrator) from changing or deleting objects before the retention period ends?

Layers on a bucketCopy Anchor Link

Encryption optionsCopy Anchor Link

• Default encryption applies only to new writes. Existing objects keep their original encryption until rewritten, for example with S3 Batch Operations copy.
• SSE-C must now be allowed deliberately: set BlockedEncryptionTypes to NONE in the bucket's encryption configuration. Requests using SSE-C on a blocked bucket get 403 AccessDenied.
• For client-side encryption, use the Amazon S3 Encryption Client or the AWS Encryption SDK with a KMS key.

S3 Bucket KeysCopy Anchor Link

• S3 asks KMS for a short-lived bucket-level key and derives object data keys from it, cutting KMS requests by up to 99%. Fixes both KMS cost and ThrottlingException on busy buckets.
• The encryption context changes from the object ARN to the bucket ARN. Key policies or grants that condition on aws:s3:arn for individual objects need updating, and CloudTrail shows fewer, bucket-level events.

Enforcing a specific keyCopy Anchor Link

Because every object is encrypted anyway, the modern question is "encrypted with which key?"

{
  "Sid": "OnlyTheLedgerKey",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::ledger-exports-5520/*",
  "Condition": {
    "StringNotEqualsIfExists": {
      "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:eu-west-1:210987654321:key/7c1e9f0a-example"
    }
  }
}

• Pair it with default encryption set to SSE-KMS with that key, so uploads that send no headers still land on the right key.
• A deny on s3:x-amz-server-side-encryption being Null rejects every upload that relies on default encryption. That is usually more disruptive than needed.

SSE-KMS permissions that catch people outCopy Anchor Link

Who can reach the bucketCopy Anchor Link

• Block Public Access: four settings (block new public ACLs, ignore public ACLs, block new public policies, restrict public buckets), at account and bucket level. On for new buckets by default. Protect the account-level setting with an SCP that denies s3:PutAccountPublicAccessBlock.
• Object Ownership = bucket owner enforced disables ACLs, so the bucket owner owns every object and only policies grant access. This is the default for new buckets. Use it unless a legacy workload needs ACLs.
• VPC endpoint restriction in the bucket policy: deny unless aws:SourceVpce (a specific gateway or interface endpoint) or aws:SourceVpc matches. Remember this also blocks the console and any admin outside the VPC, so add an exception for an admin role if needed.
• The gateway endpoint policy controls which buckets instances in the VPC can reach. aws:ResourceOrgID limits them to buckets owned by your organization, a key data perimeter control. See Hybrid and private access.
• IAM Access Analyzer flags buckets shared outside your zone of trust.

Integrity: versions, MFA delete and locksCopy Anchor Link

• Object Lock requires versioning and can be turned on for existing buckets. A default retention (mode and period) applies to every new version.
• Locks protect versions. A plain DELETE still adds a delete marker, but the locked version underneath survives.
• A legal hold and a retention period are independent: a version is protected while either applies.
• Test with governance mode first. A compliance-mode mistake (retaining terabytes for 10 years) can only be undone by closing the account.

Glacier Vault LockCopy Anchor Link

Lifecycle and retentionCopy Anchor Link

• Transitions move versions to cheaper classes (Standard-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive). Expiration deletes current versions or, with noncurrent rules, old versions after a number of days.
• Retention usually needs both: Object Lock stops deletion before the period ends, and a lifecycle expiration removes the data after it ends. Lifecycle can't delete a version that is still locked.
• Add rules to abort incomplete multipart uploads and remove expired delete markers.
• For "delete personal data after 30 days", lifecycle expiration is evidence-friendly; a Lambda cleanup job isn't.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• Protecting data with encryption in Amazon S3
• Locking objects with Object Lock
• Reducing the cost of SSE-KMS with S3 Bucket Keys
• Managing your storage lifecycle