How to point an apex domain to CloudFront without using a CNAME
If your website, app, or API is hosted on AWS, there's a good chance you're already using CloudFront - Amazon's global content delivery network (CDN) that helps improve performance, scalability, and security.
But until now, pointing an apex domain like example.com directly at CloudFront has been... fiddly.
Because CloudFront requires a CNAME, and CNAMEs aren't supported at the apex level in DNS, many teams have found themselves jumping through hoops. That might mean transferring the domain to Route 53 so you can use an ALIAS record, or Cloudflare for their CNAME flattening - or perhaps an another third-party service with redirection support for apex CNAMEs.
Migrating a domain's DNS can be a pain, particularly for an established business with a wide range of IT services hanging off their primary domain. There's likely to be email MX, DKIM and DMARC records, verification TXT records for TLS certificates and integrations with other tools like CRM, analytics, or newsletter platforms.
That workaround of moving DNS just became unnecessary. AWS has introduced Anycast Static IPs for apex domains, letting you connect your apex domain directly to CloudFront using simple A records - no tricks, no DNS migrations.
What is CloudFront and why use it?
CloudFront is AWS's global content delivery network. When someone visits your site or hits your API, CloudFront routes their request to the nearest edge location to the user. At this edge location content such as images, web pages and data can be cached - stored for repeated use without needing to go all the way from the origin server which may be in a different country.
By delivering content in this way CloudFront reduces latency and boosts the speed of your web service. CloudFront also helps reduce load on your origin servers and offers built-in security benefits like DDoS protection and TLS.
From marketing sites to complex applications, CloudFront is a solid default for modern web delivery.
But until now, its reliance on CNAMEs has meant some friction when it comes to domain setup.
What's new: static Anycast IPs for apex domains in CloudFront
In late 2024, AWS rolled out a new Anycast IP option for CloudFront, allowing single static IPs to route traffic to the nearest CloudFront edge location. It was a quiet but welcome improvement to network routing.
Now in April 2025, they've gone a step further: you can request three Anycast static IPs that support apex domains. These IPs work globally and can be pointed to from your domain's A records.
No more workarounds. No need to change DNS providers. Just three IPs you can drop into your existing setup.
Why apex domains are tricky with traditional CDN setups
While many sites use www.example.com for their front-end, most modern sites and services want their main site or app served from the root domain - example.com. It's cleaner and more memorable. But it's also important to support both www and non-www, choosing one as the primary source of the website.
But root domains can't have CNAMEs, which CloudFront has historically required. That's what's made this problem so persistent. It wasn't a blocker, but it was a hassle - especially for businesses who didn't want to move DNS providers just to get their domain to work with CloudFront.
How to use Anycast Static IPs with your CloudFront distribution
There are some prerequisites for your CloudFront distribution: IPv6 disabled and price class set to "Use all edge locations". AWS will provide you with three Anycast static IPs, and these three IPs can be added as three A records to your DNS. These IPs act globally, meaning requests from users in different regions will be routed to the nearest edge location, just like before. But now, everything is behind simple A records.The benefits: simpler setups, no DNS migration, and better control
When you're trying to deliver a reliable, fast experience to users - whether they're customers, staff, or API consumers - it's these kinds of infrastructure details that quietly make a difference.
This update reduces complexity, removes an awkward dependency, and gives you more control over how your domain is managed. And the less time spent fiddling with DNS or migrating providers, the more time can be spent on the things that actually create value.
A small change, but one that will tidy up a corner of many AWS setups and make things a little easier for the next person who picks up the domain config.
