Yes, S3 now encrypts objects by default, but your job is not done yet

Yan Cui

I help clients go faster for less using serverless technologies.

This article is brought to you by

Is your CI build step taking too long? Try Depot for free today and experience up to 40x faster build speed!

Unlock faster CI for FREE

Update 06/04/2023:

AWS announced that S3 now enables the “block public access” and “disable ACL” settings for all new buckets. It’s great to see these being enabled by default. But the points I raised in the post still stand.

The default encryption (SSE-S3) only protects against situations when someone has stolen data from AWS servers/disks (similar to the LastPass incident). It doesn’t protect you against your mistakes – e.g. leaving an existing bucket public, or someone compromising one of your developer’s credentials.


Encryption at rest has long been a cornerstone in data security and it’s something that everyone should take seriously. If an attacker is able to get a hold of your data, encryption at rest becomes your last line of defence.

For instance, in the recent LastPass security breach, the attacker was able to steal customers’ vault data after compromising one of LastPass’s employees’ cloud accounts. The only saving grace from this terrible situation was that the data was encrypted at rest using 256-bit AES.

There have been speculations that the attacker might have been able to break through the encryption and access the unencrypted data for some customers. Perhaps, through a combination of brute force and customers using weak or previously compromised passwords for their vault.

But, nonetheless, without encryption at rest, the situation would have been a lot worse and could have spelt the end of one of the more popular password managers out there.

S3 now encrypts new objects by default

S3 has long supported server-side encryption and as of Jan 5th 2023, it would encrypt any new objects you store by default using SSE-S3. See this launch blog post for more details.

The best thing about this update is that you don’t have to change your application at all. Existing S3 buckets with encryption enabled will not change. But any unencrypted buckets will now use the SSE-S3 encryption automatically.

This is a great update. But it doesn’t mean you don’t have to ever think about S3 encryption again.

You should still use SSE-KMS with a CMK

Having encryption at rest with SSE-S3 means if AWS is compromised and an attacker is able to get to your data, at least they are encrypted.

What if AWS didn’t mess up, but you did?

For example, what if your AWS credentials are compromised (e.g. you accidentally checked them into a public repo!), or you accidentally left a bucket public?

Any request through the AWS SDK, AWS CLI or via the public URL of an object would give the attacker access to the unencrypted object contents. S3 would decrypt the data and return the unencrypted data because it owns the encryption keys.

So what can you do?

The simple answer is to use SSE-KMS with a KMS CMK (Customer Managed Key). With this encryption mode, you tell S3 to encrypt the objects with a KMS key that you control. Anyone who wishes to access the unencrypted content must have the kms:decrypt permission for the CMK.

Even if a bucket is accidentally left public, this would still protect you from unauthorized access. Attempts to access the objects via their public URL would be met with a swift unauthorized response.

You will need to manage access to this KMS CMK. In production, none of your IAM users and roles your employees would assume should have direct access to it. Only Lambda functions that need to access the data should have decrypt permission.

Follow the principle of least privilege.


The recent S3 update is great and deserves all the excitement and praise that it received. But keep in mind that it adds a baseline level of security to data stored in S3.

It provides a valuable layer of defence against compromises to AWS’s own infrastructure. But it doesn’t protect you from many attack vectors that affect the security of your AWS environment.

Having this baseline security is great, but it’s not enough to safeguard your customers’ data. So no, your job is not done yet!

If you want to learn more about building serverless architecture, then check out my upcoming workshop where I would be covering topics such as testing, security, observability and much more.

Hope to see you there.

Whenever you’re ready, here are 4 ways I can help you:

  1. Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop for quickly levelling up your serverless skills.
  2. Do you want to know how to test serverless architectures with a fast dev & test loop? Check out my latest course, Testing Serverless Architectures and learn the smart way to test serverless.
  3. I help clients launch product ideas, improve their development processes and upskill their teams. If you’d like to work together, then let’s get in touch.
  4. Join my community on Discord, ask questions, and join the discussion on all things AWS and Serverless.