You create a new Amazon S3 bucket, set no encryption configuration, and upload objects without sending any encryption header. Is that data encrypted at rest, and what does S3 server-side encryption actually protect you against?
answer
- nothing to turn on any more
- AES-256, keys S3 owns
- free, invisible, no request header
- protects the disk, not the caller
- default for every bucket since 2023
basics
~20 sYes. Since January 2023 S3 encrypts every new object with SSE-S3 (AES-256) automatically and at no charge. That protects the data on AWS's disks; it does nothing against a caller whose IAM permissions already allow GetObject.
solid answer
~50 sYes — S3 applies server-side encryption with S3-managed keys (SSE-S3, AES-256) to every new object as a baseline, with no configuration, no request header, no extra cost and no measurable latency. That has been the default for all buckets since January 2023; before then an unconfigured bucket really did store plaintext, which is why older checklists still ask the question. What that buys you is protection of the bytes on AWS's storage media and a tick in the "encrypted at rest" compliance box. What it does not buy you is access control: S3 decrypts transparently for anyone the authorization layer lets through, so an over-broad `s3:GetObject` grant, a leaked credential or a public bucket hands over plaintext regardless. You can confirm what was used per object from the `x-amz-server-side-encryption` response header on a HEAD request.
code
bash · 4 linesaws s3api head-object \
--bucket my-bucket \
--key reports/q3.csv \
--query '{sse: ServerSideEncryption, kmsKey: SSEKMSKeyId}'go deeper
Know that S3 encrypts new objects with SSE-S3 by default and that you do not have to configure anything. Be able to say plainly that this protects the stored bytes, not who is allowed to call GetObject.
Explain that the key is S3-managed and invisible, that no KMS request is involved so there is no per-request cost or audit trail, and that the setting applies at write time so existing objects are unaffected by a later change.
Show you audit the real state rather than the configuration: read x-amz-server-side-encryption per object or from S3 Inventory, and plan a Batch Operations copy when a bucket's historical objects must be converted. Be explicit that encryption did not prevent any real S3 exposure incident.
Own the framing that at-rest encryption is a media-protection and compliance control, and that spending on stronger key custody buys nothing if the access path is loose. Decide where the organisation's effort actually goes: identity, Block Public Access and credential lifetime first, key ownership second.
## The short answer, and why the question is still asked Every object written to Amazon S3 is encrypted at rest. If the request carries no encryption header and the bucket carries no default-encryption configuration, S3 applies **SSE-S3** — server-side encryption with keys that S3 itself manages, using AES-256. There is no setting to turn on, no charge, and no request-latency difference. This has been true for all buckets in all Regions since January 2023. Before that, an unconfigured bucket stored objects unencrypted, and "is encryption enabled on the bucket?" was a real audit finding. A lot of interview material, runbooks and compliance checklists were written in that era, which is why interviewers still ask — they want to know whether you are reciting a five-year-old checklist or describing the platform as it behaves now. ## Where the key lives under SSE-S3 S3 encrypts each object under a unique data key and protects that data key with a key S3 owns and rotates. All of this is internal: you never see, name, or manage a key, and there is nothing to lose. Because no AWS KMS key is in the path, there is also no per-request KMS charge, no KMS request quota to exhaust, and no per-key CloudTrail record telling you who decrypted which object. Those three absences are exactly what you are trading away when you choose SSE-S3 over SSE-KMS. ## The threat model — the part interviews actually probe Server-side encryption means **S3 decrypts on the way out for anyone the authorization layer admits**. So be precise about what it covers: It protects against: physical compromise or theft of storage media, media that leaves the fleet at decommissioning time, and offline access to the raw bytes. It satisfies regulatory language that requires stored data to be encrypted. It does **not** protect against: an IAM policy that grants `s3:GetObject` too widely, a bucket left publicly readable, leaked long-lived access keys, a presigned URL pasted into a ticket, or an application bug that returns the wrong object to the wrong user. In every one of those cases the caller is authorized as far as S3 is concerned, so S3 decrypts and hands over plaintext. The one-line version worth saying out loud: **encryption at rest is not an access control.** A candidate who answers "the bucket is fine, it's encrypted" to a question about exposure has failed the question. ## Verifying what a given object used The encryption applied to an object is reported back on HEAD and GET: ``` aws s3api head-object --bucket my-bucket --key reports/q3.csv ``` The `ServerSideEncryption` field in that response is `AES256` for SSE-S3, `aws:kms` for SSE-KMS, or `aws:kms:dsse` for dual-layer KMS encryption; when a KMS key was used, `SSEKMSKeyId` names it. This is the honest way to audit a bucket — the bucket's default-encryption configuration tells you what *new* uploads will get, not what the existing objects actually have. ## Existing objects and changed defaults Default encryption is applied at write time. If you set or change a bucket's default encryption configuration, objects already in the bucket are untouched: they keep whatever they were written with, forever, until something rewrites them. Re-encrypting a populated bucket means copying every object over itself with the new encryption specified — for a large bucket that is an S3 Batch Operations copy job, not a one-line CLI command. Interviewers like this detail because it is the difference between "we enabled encryption" and "our data is actually encrypted the way the policy says". ## Encryption in transit is a separate axis At rest and in transit are two independent controls. S3 endpoints accept both HTTPS and plain HTTP, and the fact that an object is encrypted on disk says nothing about how it travelled. Forcing TLS is a bucket-policy matter — a Deny on the `aws:SecureTransport` condition — and is a distinct piece of work from choosing an at-rest scheme. Saying "encrypted at rest and in transit" as a single phrase, without being able to name the two different mechanisms behind it, is a common way to lose ground on this question.
- You change a bucket's default encryption from SSE-S3 to SSE-KMS. What happens to the ten million objects already in the bucket?Nothing. Default encryption applies at write time only, so existing objects keep SSE-S3 indefinitely. To convert them you must rewrite each one — copy the object over itself specifying the new encryption, which for a large bucket means an S3 Batch Operations copy job. Audit the actual state with HeadObject, not with the bucket's default-encryption setting.
- How would you prove to an auditor which encryption a specific object actually used?Call HeadObject or GetObject and read the `x-amz-server-side-encryption` response header: `AES256` means SSE-S3, `aws:kms` means SSE-KMS, `aws:kms:dsse` means dual-layer KMS. When a KMS key was used, the response also returns the key ID. S3 Inventory can produce the same fields for every object in the bucket as a scheduled report.
- A colleague says the bucket is safe because it is encrypted. What is wrong with that reasoning?Server-side encryption is transparent to authorized callers — S3 decrypts for anyone the policy admits. It defends the physical media, not the API surface. The controls that actually protect the bucket are Block Public Access, least-privilege identity and bucket policies, and short-lived credentials. Encryption at rest and access control answer different questions.
saying these in an interview costs you the question
- Says objects are plaintext unless you enable encryption on the bucket
- Thinks SSE-S3 adds a per-object or per-request charge
- Claims encryption at rest stops an over-permissive IAM role
- Assumes changing default encryption rewrites existing objects
- Treats at rest and in transit as one single setting