Introduction

Forcing SSL on S3 means rejecting any request that arrives over plain HTTP and allowing only HTTPS. The usual way to do that is not a checkbox in the bucket settings, but a bucket policy that denies requests when the AWS aws:SecureTransport condition is false.

Why HTTPS Enforcement Matters

S3 already supports HTTPS, but support is not the same as enforcement. If clients can still use HTTP, then data in transit is exposed to interception or tampering.

HTTPS enforcement matters for:

• Uploads containing sensitive data
• Downloads consumed by browsers or mobile apps
• Compliance controls that require encrypted transport
• Shared buckets accessed by many tools and teams

The goal is simple: make insecure transport impossible, not merely discouraged.

Enforce SSL With a Bucket Policy

The standard S3 approach is to attach a deny policy to the bucket.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Sid": "DenyInsecureTransport",
6      "Effect": "Deny",
7      "Principal": "*",
8      "Action": "s3:*",
9      "Resource": [
10        "arn:aws:s3:::my-secure-bucket",
11        "arn:aws:s3:::my-secure-bucket/*"
12      ],
13      "Condition": {
14        "Bool": {
15          "aws:SecureTransport": "false"
16        }
17      }
18    }
19  ]
20}

This policy does not grant access. It explicitly denies all S3 actions when the request is not using secure transport. In AWS policy evaluation, an explicit deny wins.

Apply the Policy

You can add the policy in the S3 console, through CloudFormation, Terraform, or the AWS CLI.

With the CLI:

aws s3api put-bucket-policy \
  --bucket my-secure-bucket \
  --policy file://bucket-policy.json

After that, HTTP requests should fail while HTTPS requests continue working if the caller is otherwise authorized.

Test the Behavior

After you apply the policy, verify both paths:

• An HTTPS request should succeed if the IAM permissions are correct
• An HTTP request should be denied

That test matters because it confirms you are not just relying on intended configuration but on actual runtime behavior.

If your access path goes through CloudFront, the same principle applies, but S3 bucket policy and CloudFront viewer protocol settings solve different parts of the transport chain. S3 policy protects direct bucket access. CloudFront settings protect the edge-to-viewer path.

Watch for Exceptions and AWS Service Access

In some architectures, AWS services or integrations access S3 on your behalf. The secure-transport deny is still the right default, but review service integrations if a workflow stops working after enforcement. The important question is whether the access path is genuinely HTTPS and whether the calling principal still has the required permissions.

Do not weaken the deny policy unless you have a specific, justified exception and understand the transport implications.

Keep the Policy in Infrastructure Code

Because HTTPS enforcement is a security control, it is usually best managed in Terraform, CloudFormation, or another infrastructure workflow rather than by hand in the console. That makes reviews, drift detection, and environment promotion much safer.

Common Pitfalls

• Assuming "S3 supports HTTPS" means HTTP is already blocked is incorrect.
• Applying the deny policy only to the bucket ARN and forgetting the object ARN leaves object requests uncovered.
• Mixing allow and deny statements without understanding evaluation order can make policy debugging harder.
• Protecting CloudFront with HTTPS does not automatically stop direct HTTP access to the bucket unless the bucket policy also denies insecure transport.

Summary

• Force SSL on S3 by denying requests where aws:SecureTransport is false.
• Apply the policy to both the bucket ARN and the object ARN pattern.
• Test both HTTPS success and HTTP failure after deployment.
• Treat HTTPS enforcement at S3 and HTTPS enforcement at CloudFront as related but separate controls.