GardenCloud & systems

Redirect a root domain through S3 and CloudFront

Separate the redirect origin, viewer certificate, and DNS alias in an older AWS setup.

The earlier setup redirected a naked domain to a canonical HTTPS hostname using an S3 website redirect, CloudFront, and a Route53 alias. Each service handled a different part of the request.

The redirect is an origin response

The source configured an S3 bucket’s static website hosting mode to redirect requests to the destination hostname using HTTPS. CloudFront used the bucket’s website endpoint, rather than the ordinary S3 REST endpoint, so it could receive the website redirect behavior.

An S3 website endpoint is a custom origin in CloudFront and does not offer the same HTTPS/OAC behavior as a standard S3 bucket origin. The endpoint choice follows the redirect requirement; it is not a general preference for serving private objects.

The viewer certificate belongs to CloudFront

The source requested an ACM certificate in US East (N. Virginia), validated it through DNS, and attached it to a CloudFront alternate domain name. The us-east-1 requirement concerns an ACM certificate used by CloudFront for viewers. It does not mean Route53 is restricted to that region.

DNS points the hostname at the distribution

The final step was a Route53 A alias to the CloudFront distribution. DNS resolution, certificate coverage, and the resulting HTTP redirect target must each agree with the intended hostname.

The old console’s legacy forward-all headers/query/cookie settings are not repeated as a universal cache policy. Verify redirect status, destination, path/query handling, and both HTTP/HTTPS entry points for a real deployment. No AWS resources or DNS records were changed here.

References: CloudFront origin types and certificate requirements.

← Back to the garden