Data in transit is data being accessed over the network, and therefore could be intercepted by someone else on the network or with access to the physical media the network uses. On an ethernet network, that could be someone with the ability to tap a cable, configure a switch to mirror traffic, or fool your client or a router into directing traffic to them before it moves on to the final destination. Server-side encryption (SSE) is about data encryption at rest—that is, 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.

Amazon S3 offers 3 options of encrypting data at rest, depending on how you choose to manage the encryption keys:

• Use SSE with Amazon S3-Managed Keys
• Use SSE with AWS KMS-Managed Keys
• Use SSE with Customer-Provided Keys

At the time of object creation—that is, when you are uploading a new object or making a copy of an existing object—you can specify if you want Amazon S3 to encrypt your data by adding the “x-amz-server-side encryptionheader” to the request. Set the value of the header to the encryption algorithm AES256 that Amazon S3 supports. Amazon S3 confirms that your object is stored using server-side encryption by returning the response header “x-amz-server-side-encryption”.
No matter which of the three options you choose, you can create and attach a S3 bucket policy, that will deny any object creation S3 API (PUT Object, PUT Object – Copy, POST Object, Initiate Multipart Upload), if the request does not include the “x-amz-server-side-encryption” header requesting server-side encryption, and if the request was not done using SSLTLS.