To protect data in transit to S3 and at rest in S3, you can utilize server-side encryption or client-side encryption. Let’s discuss your options for server-side encryption. How does it work in AWS? AWS explains, “Server-side encryption is the encryption of data at its destination by the application or service that receives it. Amazon S3 encrypts your data at the object level as it writes it to disks in its data centers and decrypts it for you when you access it. As long as you authenticate your request and you have access permissions, there is no difference in the way you access encrypted or unencrypted objects.” 

There are three types of server-side encryption in AWS for S3, which each provide a different level of protection. 

Read more about protecting data using server-side encryption in AWS. 

Discussing encryption within an AWS environment really means we need to have a conversation about encryption in S3. The important thing to consider about S3 being object storage is that many of those details are hidden from us. Our only access point to S3 is really through HTTP/HTTPS to a bucket name, which is just a URL that we use. Another important consideration about encryption, especially about encryption in storage, is that if you consider your technology stack, where you have physical resources at the bottom of that technology stack, moving up through operating systems, and application interfaces – the point at which you apply encryption determines the amount of protection that you’re going to be afforded in the event that data is compromised. 

When we’re talking about encryption in S3, those encryption details about encryption and storage are really hidden from us. We do still have some options to control the amount of protection that is provided. Those options, just to list them off quickly, are: The first one is S3-managed encryption keys. These keys are automatically managed by S3. There is no user control of those keys, no key rotation schedule you can manage, or anything like that. The second option is that we can rely on KMS from AWS to provide the keys that S3 will then, in turn, use to write that data off to the Amazon storage devices in an encrypted fashion. The third option is that we can also use KMS, but in this case, these are customer-managed. We load our own key that we generated offline into KMS and the key rotation schedules, the key material, and the management of those keys are exclusively on the Amazon customer. Those are our three options. 

Just a caution against using that first option where it’s “auto-magical” and it just happens, is that the more “magical” something is, the less it protects against us. Just as a concept, not a blanket statement in 100% of the cases. But, in the case of using S3-managed keys, anybody who can make a valid, authenticated call to the S3 bucket, is able to decrypt that data. It just happens automatically, so a word of caution against that. Whereas, at least if we’re using the second option, the KMS-driven key management, we are able to enforce key rotation, we are able to enforce access policies, IAM policies, onto those keys. It is even possible, at that point, to make encrypted calls, to make proper calls, to the S3 bucket, but not have access to the key, and therefore, what you receive is encrypted data back. That’s the kind of protection that we want for the most sensitive of data that we would be using S3 for storage of that data.