Rick Delpo

Posted on Jun 18, 2023 • Updated on Sep 12, 2023 • Originally published at javasqlweb.org

AWS Cloudfront DNS Migration Gotchas that no one tells you about

#aws #webdev #programming #networking

My overall observations, it takes a lot of digging to find these gotchas and many times AWS docs leave u hanging.

I migrated from an Apache Server using htaccess all the time, over to Cloudfront...started on June 7 and it is now June 18 and am still have issues but is working for the most part. This article assumes we already have some basic DNS and Networking knowledge but is still good for the beginner too.

I suspect that many developers go the Netlify route vs AWS Cloudfront due to an assumption of AWS complexity. I am not here to bash AWS, I think it is very worthwhile to do and HIGHLY recommend migrating to a better network neighborhood such as AWS S3 and Cloudfront.

first, the 4 major Gotchas

All names (comma separated), not just Alternate names must be in Alternate Domain Name Setting in the General tab on Cloudfront which is marked as 'optional'. The gotcha is that it says optional but wont work till u fill it in. Doesn't 'optional' mean optional?
Cors issue is in 2 places, S3 and Cloudfront, dont forget to enable cors also in Cloudfront. Gotcha is enabling only in s3 while forgetting to do in Cloudfront. Otherwise pre migration links used on the outside will show Cors issue in Dev Tools view. Go to Behavior tab in Cloudfront and under Origin Request policy put in CORS-CustomOrigin and under Response headers policy add Cors with preflight and security.....

Note that both these options are marked as optional (the gotcha here) but should not be skipped or CORS will only be enabled in S3 and not Cloudfront. Don't forget to press Save changes.
Using public DNS other than route53 does not migrate cleanly due to url forwarding issues. Route53 is only 50 cents per month to host DNS on AWS Route53 vs GoDaddy or other dns provider, and IT IS WELL WORTH IT. I was thrilled when I first found out u dont need route53 but ended up using it for a clean migration. The main issue was that my old links stopped working, they did not forward to my new page until I went back to using Route53. The thing about Route53 vs GoDaddy is that Route53 allows an A record to point to an alias and GoDaddy only allows an actual IP address. I think this is 301ing the right way and getting masking without really doing illegal masking.
This is not exactly a gotcha but could be. This is more of an FYI. Upon migration, pages now instantly live in S3 bucket behind a Cloudfront distribution so be sure to change ur canonicals right away on each page with the cloudfront path and submit a new sitemap to Google Search Console if u are on it. Also any links on your homepage need the cloudfront path changed right away. This applies to both buttons and href links. Even though many people say a sitemap is not necessary for a small site I say submit a new sitemap for a migration because if you are registered with Google search console this becomes a must do. Also be sure robots.txt is used and points to ur sitemap so web crawlers can find you.
Also another FYI is that Cloudfront seemlessly does a proper migration which includes your old name on the address bar. But if you do not use Route53 then your new cloudfront address will appear and not your web name. In my case my old links on facebook and twitter stopped working because of this, they timed out. When I changed back to Route53 this fixed all my old link issues. To me I could not have a situation where all my old links to my new home page now fail.

Note, since the original writing I found that this #4 gotcha about the canonicals and file paths is not true and I was given bad advice, please see my gotchas part2.

more Gotchas below - but many are just FYIs

Need to re-seo everything because files now live in a new place, GSC is still favoring my now defunct files and sitemap. When i request indexing a duplicate issue arises where Google chooses old canonical over user declared canonical....... still pending...will have an update on this soon.
My new finding is that we do not have to re seo, please see my updates in gotchas part2.
Beware that s3 requires the html extension until u tell it otherwise.....still pending
My old pages had no file extension as directed by htaccess file in Apache server. Now if user clicks on old page link from twitter or fb they get my 404 page which i finally revamped to accomodate this. Eventually i need to try out the now extension s3 option, but for now it is not a priority.
ps my index page old link works thank God
update.. just rename the page in S3 and remove html extension and all old links will work now

Since the original writing of this article I found that S3 files without extensions need special attention in Cloudfront. Removing the extension like I described above is not working out the way I expected. See my Part 3 of this series (coming soon) to find out why.

304 forwarding not 301, index pg only....impact to seo..but recently requesting indexing on home page returned a 200 response and not the expected 304. This is an SEO issue because if Google sees the 304 response they assume there are no updates to the page and thus will not index the page.

update - found out this is not true, see my gotchas part2 about this.

Best to use an AWS SSL Certificate and not ur own cert. I think that an AWS ssl cert does a proper TLS handshake with Cloudfront and I must say that I do not have direct experience with this but am using my common sense. I always used a free one from lets encrypt so with special certs I am not experienced but I suspect it can be a can of worms. So just get a new cert and dont try to move ur old one over. Not tested, just using my common sense here. PS. You will need a new SSL Certificate anyway because now pages reside at new address, the Cloudfront Endpoint.
Remember to have a separate S3 bucket for a www version. All the web crawlers take into consideration your
a. https://www
b. http://www
c. https://naked domain
d. http://naked domain
But I presume everyone already knows this part. Do this part only if u care about SEO. Perhaps it is best practice to do this otherwise site health gets dinged by Semrush, Ahrefs and GSC. All 4 DNS versions need to resolve to one https version (best practice).
Remember to have both A record and AAAA record pointing to cloudfront distribution in route53 and not the IP address of the new server. We use Alias for this, first we have our name and then for value press alias, then press cloudfront distribution then hopefully ur endpoint pops up and if it does not manually enter the new endpoint. Mine was dkrs578h9fllv.cloudfront.net which was assigned to me.
PS, dont forget to enable Brotli compression in cloudfront. Go to Behaviors tab in Cloudfront and be sure that compress objects automatically is set to yes, then go down and choose Cache Policy and Origin Request. Do not choose Legacy Cache Settings unless u need to fix ur TTL. Under Cache Policy choose CachingOptimized recommended for S3 and this will enable Brotli too. Your site will be blazing fast when deployed. Just fyi u can go to dev tools and click the network tab to see if response headers say Brotli is enabled. In addition to clicking network tab u also need to double click the actual html page after u refresh ur site with dev tools open. This is how to see the response header. Also u can find the age of the cached page which I think is very cool. 86400 seconds is the default so when this 24 hour period passes your page will recache and the afe will be 50 seconds approx and counting. For each refresh u can see the new age. Note 304 response code happens here because it is returning a cached page and no changes occur for 24 hours.
Cloudfront serves outdated content for 24 hours using a cached version of the page. This is a pain in the beginning because for a few days we are constantly updating our files, but the solution is not that bad. First of all, I could not get Invalidations to work properly so had to disable my cache only for a couple of days during the dev process. Also note that S3 files cannot be edited. You first need to delete them and then upload a new version of the page or just overwrite the existing file with a new one. Then I reset my cache to 24 hours when I was done. Note that I originally reset the default cache TTL to 3600 seconds but still needed to wait one hour to see my changes.
Note on URL masking, dont do this yourself from GoDaddy, (u can do url forwarding with masking) Dont do this!! Cloudfront will do it the correct way when u are on Route53. My lesson learned here was to just use route53 for my DNS and not my DNS provider which is Name.com
Using WAF on Cloudfront distribution incurs charges. Will work fine without WAF even though message comes up saying that WAF is recommended.
Remember that u need 2 cloudfront distributions one for main index page and other for your www page originally set up as a separate s3 bucket. Beware of enabling WAF, we easily live without it. Check your AWS cost explorer to find out current charges. I am not sure if u are still in the 12 month free tier if these charges apply.
It can take up to 48 hours for Cloudfront to fully propagate so be patient. Also the new SSL cert needs time to be cached too.

Conclusion - not sure if Netlify has any of these gotchas. Would be interesting to get some feedback on this. ALSO, fyi, I am not an expert at any of this just a casual ordinary Joe making my observations. But certainly would welcome feedback.

ps. more edits coming on this article, just wanted to get it out there for now

also find out more about Rick Delpo at my website
JavaSQLWeb.org Home Page
and don't forget to read more of my Dev.to articles. Thanks for reading and Happy Coding !!