Protecting data in transit with encryption

Amazon S3 supports both HTTP and HTTPS protocols for data transmission. HTTP transmits data in plain text, while HTTPS adds a security layer by encrypting data using Transport Layer Security (TLS). TLS protects against eavesdropping, data tampering, and man-in-the-middle attacks. While HTTP traffic is accepted, most implementations use encryption in transit with HTTPS and TLS to protect data as it travels between clients and Amazon S3.

TLS 1.2 and TLS 1.3 Support

Amazon S3 supports TLS 1.2 and TLS 1.3 for HTTPS connections across all API endpoints for all Amazon Web Services Regions. S3 automatically negotiates the strongest TLS protection supported by your client software, and the S3 endpoint you are accessing. Current Amazon tools (2014 or later) including the Amazon SDKs and Amazon CLI automatically default to TLS 1.3 with no action required on your part. You can override this automatic negotiation through client configuration settings to specify a particular TLS version if backward compatibility to TLS 1.2 is needed. When using TLS 1.3, you can optionally configure hybrid post quantum key exchange (ML-KEM) to make quantum-resistant requests to Amazon S3. For more information, see Configuring hybrid post-quantum TLS for your client.

Monitoring TLS usage

You can use either Amazon S3 server access logs or Amazon CloudTrail to monitor requests to Amazon S3 buckets. Both logging options record the TLS version and cipher suite used in each request.

Enforcing encryption in transit

It’s a security best practice to enforce encryption of data in transit to Amazon S3. You can enforce HTTPS-only communication or the use of specific TLS version through various policy mechanisms. These include IAM resource-based policies for S3 buckets (bucket policies), Service Control Policies (SCPs), Resource Control Policies (RCPs), and VPC endpoint policies.

Bucket policy examples for enforcing encryption in transit

You can use the S3 condition key s3:TlsVersion to restrict access to Amazon S3 buckets based on the TLS version that's used by the client. For more information, see Example 6: Requiring a minimum TLS version.

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "DenyInsecureConnections",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket1",
        "arn:aws:s3:::amzn-s3-demo-bucket1/*"
      ],
      "Condition": {
        "NumericLessThan": {
          "s3:TlsVersion": "1.3"
        }
      }
    }
  ]
}

You can use the aws:SecureTransport global condition key in your S3 bucket policy to check whether the request was sent through HTTPS (TLS). Unlike the previous example, this condition does not check for a specific TLS version. For more information, see Restrict access to only HTTPS requests.

{
    "Version":"2012-10-17",		 	 	 		 	 	 
    "Statement": [
     {
        "Sid": "RestrictToTLSRequestsOnly",		 	 	 
        "Action": "s3:*",
        "Effect": "Deny",
        "Resource": [
            "arn:aws:s3:::amzn-s3-demo-bucket1",
            "arn:aws:s3:::amzn-s3-demo-bucket1/*"
        ],
        "Condition": {
            "Bool": {
                "aws:SecureTransport": "false"
            }
        },
        "Principal": "*"
    }
  ]
}

Example policy based on both keys and more examples

You can use both types of condition keys in the previous examples in one policy. For more information and additional enforcement approaches, see the Amazon Storage Blog article Enforcing encryption in transit with TLS1.2 or higher with Amazon S3.