3 ms·

CloudFront has different IPs for different regions and manages this via DNS. So, if you're on an ISP peered directly with CloudFront and make a request using yo

by timdorr 13y ago

CloudFront has different IPs for different regions and manages this via DNS. So, if you're on an ISP peered directly with CloudFront and make a request using your ISPs DNS servers, CloudFront's DNS might give you back the IP to a server directly on that peering circuit. These kinds of relationships and new servers are added/removed all the time, so the IPs change regularly. A hard-coded IP in an A record won't work because of this. It works for your DO VPS because the IP is static and there is only one server.

eli 13y ago
Correct, though actually isn't CloudFront just a CNAME that could work with any provider? One reason you might want something more advanced like Route 53 is if you wanted to point the "naked" domain (example.com vs www.example.com) to CloudFront. You can't just use a CNAME on an apex record, you need to use something like Route 53's "Alias" records.
- jwilliams 13y ago
  One other (minor?) reason is performance. Route 53 allows you to have ALIAS records, which are a single DNS lookup - whereas CNAMES will incur a second lookup.
timrivera 13y ago
there's also the IP Anycast [1] option. That's what you get with OVH CDN [2], for example, but not with CloudFront. Anycast routing is totally independent from DNS, thus it works fine with an A record and also makes it easy to install SSL certificates. [1] http://en.wikipedia.org/wiki/Anycast http://en.wikipedia.org/wiki/Anycast [2] https://www.ovh.co.uk/cdn/ https://www.ovh.co.uk/cdn/
- hhw 13y ago
  Anycast just refers to BGP announcing an IP address/range out of multiple locations. Most commonly, it's done with DNS because UDP is connectionless. It's becoming increasingly acceptable to do full anycast, i.e. have actual TCP/HTTP(S) on an anycast IP, but there are risks to that approach. If routing changes and you end up changing to a different location during a TCP session, the new location won't have all the state information needed, thus dropping the connection. It's theoretically possible to keep such state information synchronized, but it's sufficiently complex that nobody is doing so. This is why most of the larger, more established CDN's anycast DNS only and don't do full anycast.

by timdorr 13y ago

eli 13y ago

Correct, though actually isn't CloudFront just a CNAME that could work with any provider? One reason you might want something more advanced like Route 53 is if you wanted to point the "naked" domain (example.com vs www.example.com) to CloudFront. You can't just use a CNAME on an apex record, you need to use something like Route 53's "Alias" records.

jwilliams 13y ago
One other (minor?) reason is performance. Route 53 allows you to have ALIAS records, which are a single DNS lookup - whereas CNAMES will incur a second lookup.

timrivera 13y ago

there's also the IP Anycast [1] option. That's what you get with OVH CDN [2], for example, but not with CloudFront. Anycast routing is totally independent from DNS, thus it works fine with an A record and also makes it easy to install SSL certificates. [1] http://en.wikipedia.org/wiki/Anycast http://en.wikipedia.org/wiki/Anycast [2] https://www.ovh.co.uk/cdn/ https://www.ovh.co.uk/cdn/

hhw 13y ago
Anycast just refers to BGP announcing an IP address/range out of multiple locations. Most commonly, it's done with DNS because UDP is connectionless. It's becoming increasingly acceptable to do full anycast, i.e. have actual TCP/HTTP(S) on an anycast IP, but there are risks to that approach. If routing changes and you end up changing to a different location during a TCP session, the new location won't have all the state information needed, thus dropping the connection. It's theoretically possible to keep such state information synchronized, but it's sufficiently complex that nobody is doing so. This is why most of the larger, more established CDN's anycast DNS only and don't do full anycast.