How to Redirect an Apex Domain on Route 53 (Without the S3 Workaround)

Route 53 rejects CNAME records at the zone apex outright — AWS's own documented answer has always been to configure an S3 bucket for website redirects and point an Alias A record at it, which works but means managing an S3 bucket purely as DNS plumbing. RedirectIQ replaces that entirely: add one plain A record at the apex, pointed at the static IP address RedirectIQ shows you, and the bare domain gets full HTTPS, a real 301, and path passthrough — no S3 bucket, no Alias record, no AWS CLI required.

Why Route 53 blocks CNAME at the apex

Same underlying reason as most DNS providers: the apex often needs to hold other record types (MX, TXT) that can't coexist with a CNAME per the DNS specification. Route 53 enforces this strictly — there's no flattening feature like Cloudflare's. A static A record doesn't hit this restriction at all: A records are exactly what the apex is built to hold, alongside MX, TXT, and everything else, so there's no coexistence problem to route around in the first place.

The fix: point the apex straight at RedirectIQ

1. In Route 53, open the hosted zone for your domain.
2. Create a record: Record name blank (this represents the apex), Record type A, Value the static IP address RedirectIQ shows you when you add the domain, TTL default.
3. Add yourdomain.com in your redirect service's dashboard.
4. Set your redirect rule (301, destination, path passthrough if /old-page should land on the matching new path).

That's the whole setup — no aws s3api calls, no fixed hosted-zone ID to look up, no separate SSL gap to work around.

AWS's own S3 workaround, for reference

AWS's documented answer, without a redirect service, is an S3 bucket configured for website redirects plus an Alias A record pointing at it. It works, but it has real limits the A record above doesn't: the S3 bucket has no SSL certificate of its own (so the apex hop isn't HTTPS), and it can't do path passthrough — every request lands on the same destination regardless of the original path.

Step A — create an S3 bucket configured for website redirects:

aws s3api create-bucket --bucket yourdomain.com --region us-east-1 && \
aws s3api put-bucket-website --bucket yourdomain.com --website-configuration \
  '{"RedirectAllRequestsTo":{"HostName":"www.yourdomain.com","Protocol":"https"}}'

Step B — add an Alias A record pointing at the S3 website endpoint:

aws route53 change-resource-record-sets \
  --hosted-zone-id YOUR_ZONE_ID \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "yourdomain.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z3AQBSTGFYJSTF",
          "DNSName": "yourdomain.com.s3-website-us-east-1.amazonaws.com",
          "EvaluateTargetHealth": false
        }
      }
    }]
  }'

Z3AQBSTGFYJSTF is AWS's fixed hosted-zone ID for S3 website endpoints in us-east-1 — not your own zone ID. Only replace YOUR_ZONE_ID with your actual hosted zone.

Also want www.yourdomain.com to work?

Add it as a second hostname with a normal CNAME — this part hasn't changed:

1. Create a record: Record name www, Record type CNAME, Value the target RedirectIQ's dashboard shows you, TTL default.
2. Add www.yourdomain.com as a separate domain in your redirect service's dashboard.

RedirectIQ automatically groups a matched www/apex pair onto a single plan slot once both exist in your account, so covering both doesn't cost anything extra.

Verifying it worked

Check the result with the free redirect checker — confirm the status code, destination, and certificate are what you expect on both the apex and the www version.

RedirectIQ provisions and renews SSL automatically on both — no S3 bucket to provision or maintain. Start free →