技術》使用 Route53 完成同 Domain 依據不同的地區提供對應的端點

前幾天在聊天時有聊到如何用 Route53 在同一組 Domain 的情境下,依據不同的地區提供不同的端點(endpoint),其中不同的地區可能只是台灣北部跟南部的差別。


Geolocation Routing


依照需求,一開始會馬上聯想到 Route53 Routing Policy 的 Geolocation Routing 來滿足這個需求,畢竟這個策略就是針對地域來分配流量的。

不過仔細閱讀文件及實作驗證之後會發現裡面定義的 Location 基本上最低的層級只有定義到國家,所以並沒有辦法符合一開始的需求。

Geoproximity Routing

說好要試著用 Route53 解決這個問題,這時便將思考的路轉到同樣也是 Geo 相關的 Geoproximity Routing 看這個 Traffic Flow 有沒有辦法解決這個問題。

會考慮用 Geoproximity 的原因,主要是可以依據使用者的地區,來決定目的端點是什麼,5乍看似乎跟 Geolocation 沒有太大差別,但其實它對於地區分析的層級可以調整到依據經、緯度且可加上誤差值的條件設置,可將範圍鎖定的的更小,開發者文件下面的敘述也講的挺清楚。

Geolocation routing policy – Use when you want to route traffic based on the location of your users.
Geoproximity routing policy – Use when you want to route traffic based on the location of your resources and, optionally, shift traffic from resources in one location to resources in another.

另外開發文件的示意圖,個人是覺得就算沒仔細閱讀文件,也可以理解它的概念。


至於它的運作原理就目前文件得到的資訊,應該是 EDNS0 加上 Geo-IP 的實現。

實驗及小結

依靠 Geoproximity Routing 這個 Route53 的 Traffic Flow ,的確實現了台北跟高雄在我設計的特定區域會被導向指定的不同站台。

另外這個實驗的代價有點高,我只是做個 Routing 的小測試啊!按照 Route53 Pricing 來看 1 條 Traffic Flow 的收費為 $50.00 per policy record/month ,真的是我的媽呀!

下一步是?

個人認為 AWS 服務的層級,絕大多數都是較符合流量跟規模有一定級別會更加合適。

以這次的實驗來說,這些 Taffice Rule 對高流量的服務來說,無疑能提供使用者有更好的用戶體驗,但反過來只是拿來做一些環境的區隔,這樣的成本可能就有點高了。

所以下一步,我應該會試著同樣支援 EDNS0 的 BIND 9 來做同樣的實驗。

留言

這個網誌中的熱門文章

執行 StrongLifts 5x5 三個月心得

第一次教召就上手

2018 公司內部敏捷開發調訓