前一篇文章我們提到， 當我們建立 CloudFront Distirbuiton 時，提供了一組專用域名讓我們透過 CNAME 進行指定。

2023watch-ironman.kgg23.com CNAME d15kpj4cnphd3.cloudfront.net 

當這樣的 record 建立後，後續在不同地方(如 us-east-1 region v.s. 台灣) 的客戶，就可以去不同的 CDN 節點。

這很直觀啊。(是嗎?)

那麼， CloudFront 是如何知道要把台灣來的客戶，送去在台北(TPE)(1) 的節點的呢? 目前根據 AWS 自己在 re:Post 的文章中的排查說明，大概可以反推出跟以下幾個條件有關。

• 你的 Distribution 設定為哪個 price class
• 你的 DNS Resolver IP
• Client 的 IP (eDNS?)
• 其他(沒被列出來的原因)[2]

讓我們逐一來看。

PriceClass(價格分級)

在設置 Distribution 時，需要在 3 種選項中指定，如果選的是 Price Class 100，那麼當你的客戶人在台灣，但解析到去連美國的 CloudFront PoP，理所當然。

肯公公的小建議: 一般而言，直接指定 Price Class=all 的即可，不要因為想省費用而修改設定，那樣通常無法帶來足夠大的效益

Client 端使用的 DNS Resolver 有支持 Anycast Routing

第一次看到這段時，一定很多人看不明白。原文如下:

If the DNS resolver supports Anycast routing, then there are multiple edge locations that the DNS resolver uses. This means that a requester's edge location is based on optimal latency, which might result in an unexpected location for the resolver's IP address.

或許能這樣解讀:
如果你的 CloudFront 會根據你的 DNS 的地理位置，來決定 Client 端該解析到哪個 PoP。
所以如果你的 DNS Resolver 支持 Anycast IP，那麼代表 DNS Resolver 理論上會存在於多個地理位置(a.k.a.有好多台在不同地方的 DNS Resolver)。
也就是說，在這情況下，CloudFront 可能會不小心讓 Client 沒跑到最佳節點。
進一步細想: CloudFront 會依照 DNS Resolver 在哪來決定 Client 去哪。

所以，Client 端的 DNS Server 是否有支援 AnycastIP 呢?
文件提到這指令，且提到

• 你的 DNS Resolver "有"支持 AnycastIP: 如果連續執行多次，而你看到的結果不盡相同。
• 你的 DNS Resolver "不"支持 AnycastIP:

$ dig +nocl TXT o-o.myaddr.l.google.com

但我實際測試，發現我不管是直接以 EC2 or 自己的本機電腦(HiNET)，或者指定了 Google的 DNS(8.8.8.8 or 8.8.4.4) 甚至是 CloudFlare 的 DNS IP(1.1.1.1)，結果都會跳。 (囧)
所以，我建議這段就看成

大家只要知道 Google(8.8.8.8, 8.8.4.4) 以及 CloudFlare(1.1.1.1) 的 DNS 服務有支持 Anycast IP 就好。

DNS Resolver 有支持 EDNS-Clinet-Subnet，如果有，就檢查一下 Client IP 網段的地理位置 Mapping.

濃縮重點，以測試指令就可以看出有無支持 EDNS-Client-Subnet

#直接測試你目前的 DNS Server
$  dig +nocl TXT o-o.myaddr.l.google.com

也可以直接指定 DNS Resolver IP(增加 @DNS-Resolver-IP，如下)

$ $  dig +nocl TXT o-o.myaddr.l.google.com @8.8.8.8

• 如果 DNS Resolver 有支持 EDNS-Client-Subnet: 那麼你會多看到一行 edns0-client-subnet 的字串
• 如果 DNS Resolver 有支持 EDNS-Client-Subnet: 不會出現 edns0-client-subnet 字串

此時，如果 DNS Resolver 有支持 EDNS-Client-Subnet，CloudFront 就可以根據這一組 IP Range，透過內部資料 mapping 將 Traffic 導往對應的節點。

結論

CloudFront 會依照以下順序讓 Client 存取合適的節點。

1. 依照 Price Class
2. 如果 Client 的 DNS Resolver 沒有支持 EDNS-Client-Subnet --> 依照 DNS resolver 對 CloudFront 的 IP 資訊做判斷。
3. 如果 Client 的 DNS Resolver 沒有支持 EDNS-Client-Subnet --> 依照 DNS resolver 對 EDNS-Client-Subnet 回應的 的 IP 資訊做判斷。

OK! 今天的說明到這邊，今天開始進入相對難懂理解的部分，如果有任何問題，歡迎留言給我 :D

[1] 依照網路上搜尋到的資料，CloudFront 是以機場代碼(三位數英文)取名，比方 IAD，TPE 等。

[2] 在AWS 文件 使用的是 Typically(通常) 這字，既然是通常，那麼我們總要理解有一些不常的情況。

DNS routes the request to the CloudFront POP (edge location) that can best serve the request—typically the nearest CloudFront POP in terms of latency—and routes the request to that edge location.