Between October 6, 2026 and November 16, 2026, server-side encryption with Akamai-managed keys (also referred to as "SSE-S3") will be enabled by default for all E2 and E3 endpoints. Once enabled, whenever you upload content to an E2 or E3 endpoint, your objects will be automatically encrypted at rest using AES256 encryption.

What's required from you

There's nothing you need to do to take advantage of SSE-S3 by default.

Also, there are no additional fees and no impact to the quotas or limits on your account. This new feature will be enabled transparently and you'll automatically receive the benefit of encryption at rest for all data stored on E2 and E3 endpoints.

How to verify object encryption

To verify that your newly uploaded objects are encrypted, use the AWS CLI to send the head-object API request to see the current encryption status of that object:

aws s3api head-object --bucket <bucket-name> --key <object-key> --endpoint-url <endpoint URL>

Examples

Here are a couple of usage examples:

aws s3api put-object --bucket test-bucket --key testfile.txt --endpoint-url <https://us-ord-10.linodeobjects.com>

aws s3api head-object --bucket test-bucket --key testfile.txt --endpoint-url <https://us-ord-10.linodeobjects.com>

When enabled on your endpoint, you will see a response similar to this:

{  
    "AcceptRanges": "bytes",  
    "LastModified": "2025-06-19T17:15:00+00:00",  
    "ContentLength": 10,  
    "ETag": "\"\"",  
    "ContentType": "text/plain",  
    "ServerSideEncryption": "AES256", <== SSE-S3 is enabled
    "Metadata": {}  
}

📘

If you're using a version of the AWS SDK released on or after January 15, 2025, you may need to configure this value to ensure that PutObject works for all platforms:

AWS_REQUEST_CHECKSUM_CALCULATION=when_required

For more details, see AWS CLI and SDKs support details.

Content uploaded before SSE-S3 enablement

Any content you uploaded before SSE-S3 support enablement will remain unencrypted. You can use the process described in the prior section to validate the encryption status of each object.

Apply SSE-S3 to existing objects

In cases where objects have a fixed lifecycle, encryption may be applied naturally over time. If your objects are static, you’ll have to rewrite the object, to have it encrypted at rest.

Encryption may be applied naturally

In some cases, your workflow may encrypt all of your objects, naturally over time. For example, consider a logging use case:

• New objects will be uploaded regularly with a lifecycle policy to delete objects after a retention period.
• Once SSE-S3 is enabled on your endpoint, all of your logging-related objects will be encrypted after that retention period—New logging objects will be encrypted immediately, while older objects that were not encrypted will be deleted by the 30-day retention period lifecycle policy.

Apply encryption manually

For other static content, you can use the copy-object command to replace the object and have encryption applied.

aws s3api copy-object \
  --bucket <bucket-name> \
  --key <key> \
  --copy-source <bucket-name>/<key> \
  --server-side-encryption AES256 \  <== Include to apply encryption
  --metadata-directive REPLACE \
  --endpoint-url <endpoint>

Prerequisite

You need to ensure that SSE-S3 is enabled on the endpoint before you move forward with this process. If it's not, you'll receive a 400 - Bad request error when including --server-side-encryption AES256 as part of the copy-object CLI command.

Example

Here's an example of using the copy-object command:

aws s3api copy-object \
  --bucket test-bucket \
  --key test-object \
  --copy-source test-bucket/test-object \
  --server-side-encryption AES256 \
  --metadata-directive REPLACE \
  --endpoint-url https://us-ord-10.linodeobjects.com

📘

The --metadata-directive REPLACE line is also required. Without it, S3 will copy the existing metadata as-is, and ignore the new encryption setting.

You should see a response similar to this:

{
    "CopyObjectResult": {
        "ETag": "\"e7ae7fad1cc554a945fa4491a645ebb3\"",
        "LastModified": "2026-09-17T18:30:00.000000+00:00"
    },
    "ServerSideEncryption": "AES256"
}

Manage your own encryption

Customer key-based encryption (SSE-C) is still fully supported if you need to supply and manage your own encryption keys. All of your objects that are already encrypted using SSE-C remain encrypted with the keys you've specified.

You can continue to upload new objects using SSE-C if desired.