AWS endpoints such as S3 accept requests over both HTTP and HTTPS. How do you make TLS a hard requirement for a bucket rather than a convention, and what exactly does the control you use evaluate?

## Available versus required Every AWS API endpoint supports TLS, and every SDK uses it by default. That is a default, not a guarantee: a hand-rolled client, an old script, or a misconfigured proxy can still speak plain HTTP to an endpoint that accepts it, and nothing in the account will notice. Making encryption in transit a *requirement* means having a control that rejects the unencrypted request, which is a policy question rather than a networking one. ## The condition key AWS evaluates a set of global condition keys on every request, independent of which service it is for. `aws:SecureTransport` is a boolean in that set: true when the request arrived over an encrypted connection, false when it did not. Because it is global, it works in identity policies, resource policies and service control policies alike. The canonical use is a bucket policy statement: ```json { "Sid": "DenyInsecureTransport", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3:::example-bucket", "arn:aws:s3:::example-bucket/*" ], "Condition": { "Bool": { "aws:SecureTransport": "false" } } } ``` Three properties make this work. It is an explicit `Deny`, and in AWS policy evaluation an explicit deny beats every allow anywhere — identity policy, bucket policy, or a grant from another account. It uses `Principal: "*"`, so it applies to anonymous callers and to principals in other accounts, not just your own. And the condition is written against the string `"false"` with the `Bool` operator, which is how boolean condition values are expressed in policy JSON. ## The mistake that quietly defeats it The most common defect is listing only `arn:aws:s3:::example-bucket` in `Resource`. In S3, bucket-level actions (`s3:ListBucket`) match the bucket ARN and object-level actions (`s3:GetObject`, `s3:PutObject`) match `bucket/*`. A policy with only the bucket ARN denies insecure *listing* while leaving insecure object reads and writes entirely allowed — which is exactly backwards from what you wanted, and it passes a casual review because the statement looks right. Always list both ARNs. ## What the control does and does not prove `aws:SecureTransport` is a statement about one hop: the connection that terminated at the AWS service endpoint. It does not tell you: - **Which TLS version or ciphers** were negotiated. If you need a floor, S3 exposes `s3:TlsVersion` as a numeric condition key you can use in the same policy shape. - **What happened before that hop.** If a client talks HTTP to a proxy that re-originates the request over HTTPS, the condition sees `true` and the first leg was still in the clear. - **Anything about the data at rest.** Transit and rest are independent controls; each has to be enforced on its own. ## Widening it beyond one bucket A per-bucket policy protects one bucket, which is fine for a sensitive dataset and useless as a posture. Two ways to widen it: - **Service control policies.** The same `Bool` condition in an SCP applied to an organizational unit denies non-TLS calls across every account beneath it, including from the accounts' own administrators. That is what turns the rule from a convention into an invariant. - **Detective coverage.** Because not every service exposes the same knobs, pair the preventive rule with a check that reports resources missing the statement, and report coverage per service rather than claiming the whole estate. ## The other half of in-transit encryption Enforcing TLS to AWS API endpoints is only the AWS-side of the story. For your own traffic, TLS is usually terminated at the edge: a certificate issued by AWS Certificate Manager attached to an Application Load Balancer, a CloudFront distribution or an API Gateway endpoint. ACM issues public certificates at no charge for use with those integrated services and renews them automatically as long as the DNS validation records stay in place — which removes the classic outage of a manually renewed certificate expiring at 3am. The leg *behind* the terminator is a separate decision: traffic from the load balancer to the targets is a fresh connection, and whether it is encrypted is a choice you make explicitly rather than something the front-end certificate implies.