Skip to content

Amplify Web Compute apex domain still routing to deleted app after new app created

1

After deleting an Amplify app and creating a new one with the same custom domain, the apex domain still routes to the old deleted app's load balancer. The new app shows custom domain status "Available" but sub-routes on the apex return 404.

Details:

  • New app ID: d2oktj4sxkfk68 (us-east-1)
  • Custom domain: livingpatternsreadings.com
  • Domain status in new app: Available
  • www subdomain works correctly — all routes return 200 via CloudFront d3sbizcitmqxxw.cloudfront.net
  • Apex sub-routes (e.g. /about, /testimonials) return 404 from ip-10-124-5-46.us-west-2.compute.internal — this is the old deleted app's ALB in us-west-2 (wrong region)
  • Apex A records in GoDaddy: 3.33.251.168 and 15.197.225.128 (Amplify standard IPs, locked/uneditable)
  • GoDaddy does not support ANAME/ALIAS record type for the apex — only A, CNAME, MX, TXT etc. are available. The locked A records (3.33.251.168, 15.197.225.128) were pre-existing from the original Amplify app and cannot be edited or deleted in GoDaddy.

Steps already tried:

  • Deleted and recreated custom domain in new app multiple times
  • Added apex→www 301 redirect rule in Amplify Rewrites and Redirects — has no effect because apex traffic never reaches the new app's edge (hits old ALB first)
  • Removed all rewrite/redirect rules
  • Verified DNS is correct
  • Waited 24+ hours after domain activation completed — no change
  • Added GoDaddy domain forwarding as workaround — only redirects / (root), not sub-paths
  • Created the new app 3x from scratch specifically to resolve this issue — the original app was deleted weeks ago
  • Checked us-west-2 region in Amplify console — no apps exist there. The old app is fully deleted. The routing to us-west-2 infrastructure is occurring at Amplify's backend edge layer with no visible app or domain association on our end.

Note: the issue appears intermittent because desktop browsers with cached pages or aggressive redirect-following show the pages correctly. The 404 is consistently reproducible via curl or on a fresh mobile Safari session with no cache.

I am on the AWS free tier and do not have access to technical support cases, which is why I am posting here instead of opening a support ticket.

The Amplify edge routing table was not updated when the domain was migrated to the new app. How do I force Amplify to update its internal edge routing for the apex domain?

edit: reordered a couple steps, added that im on a free account

asked 16 days ago60 views
2 Answers
3
Accepted Answer

Since you are on the Free Tier and cannot contact AWS Support directly, the advice from the re:Post Agent is technically correct but practically difficult. Here are three ways to resolve or bypass this "stale edge routing" issue yourself:

1. Force a Backend Refresh via GitHub

The AWS Amplify hosting team monitors their GitHub repository specifically for issues like this that users can't fix themselves.

  • Go to: aws-amplify/amplify-hosting/issues
  • Open a new issue with the title: "Stale Edge Routing: Apex domain pointing to deleted app in different region".
  • Include your App ID, Region, and the Domain Name.
  • The engineers there can often manually clear the internal cache for you.

2. „Cloudflare/Route53" Bypass

The issue persists because GoDaddy's static A-records point to a generic Amplify entry point. If you move your DNS management (Nameservers) to Cloudflare (Free) or Route 53

  • You can use CNAME Flattening (Cloudflare) or ALIAS records (Route 53) for the apex domain.
  • Instead of pointing to the static IPs (3.33...), you point your apex domain directly to the unique CloudFront distribution URL provided by your new Amplify app (e.g., d3sbiz...cloudfront.net).
  • This completely bypasses Amplify's problematic internal IP-routing table.

3. 48-Hour Hard Reset If you want to stay with GoDaddy:

  • Remove the custom domain from the Amplify console entirely.
  • Wait at least 48 hours. This is often necessary for the global internal TTL of the Amplify edge config to fully purge.
  • Re-add the domain. This sometimes triggers a fresh propagation across all edge locations.

Summary: If you need it fixed ASAP without Support Plan, I guess Option 1 (GitHub) is your best bet to get an AWS engineer's attention.

EXPERT
answered 16 days ago
1

This is a known edge routing issue that occurs when reusing a custom domain after deleting an Amplify app. The problem is that Amplify's internal edge routing table hasn't been updated to point your apex domain to the new app, causing traffic to still route to the old (now deleted) app's infrastructure.

Since you're using GoDaddy which doesn't support ALIAS/ANAME records for the apex domain, and the locked A records are pointing to Amplify's standard IP addresses that route through Amplify's edge layer, you're encountering the routing table issue at Amplify's edge infrastructure level—not at the DNS level.

The solution requires AWS Support intervention. This is not something you can resolve through the Amplify console or by recreating the app. You need to contact AWS Support and provide them with:

  1. Your new app ID (d2oktj4sxkfk68)
  2. The custom domain (livingpatternsreadings.com)
  3. The region (us-east-1)
  4. Details that the apex domain is routing to old infrastructure while the www subdomain works correctly

AWS Support will need to manually update Amplify's internal edge routing table to map your apex domain to the new app's infrastructure. This is a backend operation that only AWS can perform.

Workaround until resolved: Since your www subdomain works correctly, you could temporarily use an Amplify rewrite rule to redirect all apex traffic to www, but as you've discovered, this won't work because the traffic never reaches your new app's edge. The GoDaddy forwarding you tried has the same limitation—it only handles the root path.

The intermittent behavior you're seeing (working on some browsers) is likely due to browser caching of successful redirects or cached DNS responses, not actual resolution of the underlying routing issue.

Contact AWS Support through your AWS account to get the edge routing table updated for your domain.

answered 16 days ago
EXPERT
reviewed 16 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.