Set the CloudFront distribution to require HTTPS from viewers and choose a viewer policy that enforces TLS 1.2 or later. Confirm that the distribution responds with redirects or rejects plain HTTP where appropriate, and test with external clients. If legacy clients must connect, decide whether to keep them separate rather than weakening the CloudFront policy.
What it means to enforce HTTPS from viewers in CloudFront
CloudFront viewer security is enforced at the distribution edge, where you decide whether the service accepts plain HTTP, redirects it, or requires encrypted transport end to end for browser and client traffic. The practical goal is not just encryption in transit, it is preventing accidental downgrade paths and making the viewer policy explicit enough that testing and incident review can confirm the intended behaviour.
A useful way to think about this is that the distribution policy is the control point, while the viewer experience is the evidence. If the policy is set correctly, HTTP requests should not be silently accepted. That matters because a weak default, a stray alternate endpoint, or an inconsistent client configuration can undermine the security posture even when the origin is well protected.
How TLS 1.2 or later changes the viewer policy
Requiring TLS 1.2 or later is the compatibility boundary that decides which viewers can negotiate a secure session with CloudFront. For modern clients, this is usually a straightforward hardening step. For older clients, the decision is operational: either keep those clients on a separate path or accept that the CloudFront policy should not be weakened to accommodate them.
The important distinction is between transport enforcement and business tolerance. If a legacy application only works with older protocol support, the safer response is usually segregation rather than relaxing the main distribution. That keeps the stronger policy intact for the general user base and avoids turning a compatibility exception into a permanent exposure.
For AWS-wide hardening, this control sits naturally alongside broader baseline practices in the AWS Security Guide, especially where teams are standardising security settings across multiple services and accounts.
How to verify that HTTPS enforcement is actually working
Configuration alone is not enough. Test the distribution with a browser, a command-line client, and at least one external network path to confirm that HTTP requests are redirected or rejected as intended and that TLS negotiation succeeds only at the expected protocol level. Validation should include a check for any alternate hostname or cached endpoint that might still accept weaker behaviour.
It is also worth confirming the failure mode, not just the success path. A secure configuration should produce a predictable outcome for disallowed traffic, because ambiguous behaviour makes it harder to distinguish a control failure from a client problem during troubleshooting or incident response.
If your viewer policy is part of a wider AWS security baseline, the certificate and transport assumptions should align with the controls described in the CA/Browser Forum, since public trust expectations and certificate handling are part of what makes HTTPS trustworthy to viewers.
Risk and Threat Considerations
Weak viewer transport settings create downgrade and interception risk, especially when users still reach the distribution through bookmarked HTTP links, embedded links, or legacy integrations. If TLS is optional or old protocol support remains enabled on the primary path, the security boundary shifts from enforced to best-effort, which is a poor place to leave a public content delivery entry point.
Failure mechanism: Plain HTTP or outdated TLS support allows a client, intermediary, or misconfigured integration to avoid the intended protection, exposing request metadata and weakening assurance that viewers reached the content securely.
Impact: The result can be credential exposure in adjacent workflows, session risk for sensitive pages, compliance gaps, and a harder-to-detect downgrade condition that undermines trust in the distribution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-14 — Network Monitoring and Defense | Viewer protocol enforcement depends on detecting and validating insecure access attempts. |
| Recommendation — Monitor edge traffic for plain-HTTP access and protocol downgrade attempts. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | HTTPS and TLS 1.2 directly protect data in transit between viewers and CloudFront. |
| IA-5 — Authenticator Management | TLS certificates and related secrets underpin the trust relationship used by HTTPS. | |
| Recommendation — Enforce encrypted transport for viewer sessions and reject weak protocols. Manage certificate and key lifecycle to keep viewer TLS trustworthy. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Forcing HTTPS and TLS 1.2 is a cryptographic transport control for public web delivery. |
| Recommendation — Require approved cryptographic transport for public-facing content delivery. | ||
Practitioner Guidance
What to verify: Confirm the distribution policy, the viewer-facing response, and the TLS negotiation result independently. A correct console setting is not enough if an alternate domain, cached object, or legacy integration still permits weaker access.
Decision rule: If legacy clients cannot meet the TLS 1.2 requirement, isolate them rather than relaxing the main CloudFront policy. Treat broadening the viewer policy as a compatibility exception with explicit risk acceptance, not as a routine fix.
Practitioner takeaway: The strongest implementation is the one that makes insecure viewer access impossible by default, then proves it with live testing instead of assuming the edge policy alone is sufficient.