AWS企業帳號購買 如何設定AWS地理位置路由將流量導向香港伺服器

第一章：先釐清你要解決的問題

AWS企業帳號購買 「把流量導向香港伺服器」聽起來很簡單，但 AWS 裡真正要做的其實是兩件事：第一，判斷使用者大概在哪裡（地理位置）；第二，依判斷結果把請求導到特定資源（例如位於香港區域的網站、API 或代理）。在實作前，你要想清楚：你想導向的是 哪一種入口，以及你希望在不同情境下如何行為。

常見情境包括：

• 用戶在台灣/新加坡/中國大陸等地，網站應盡量走香港後端以減少延遲或符合合規。
• 你有多個區域的站台（例如東京、香港），希望特定地理區域只走香港。
• 你希望路由能在香港後端故障時自動切回其他區域。

要達成以上目標，最重要的是：你使用的服務能否提供「地理位置」判斷與「健康狀態」控制。也因此，通常你會在 Route 53（DNS 層）或應用入口（如 ALB/CloudFront）這兩條路徑做選擇。本文會以「AWS 地理位置路由」為核心，主要示範 Route 53 的做法，因為它在 DNS 層可以直接使用地理位置規則。

第二章：選擇合適的入口與路由層級

你可以把路由分成三層：使用者解析 DNS、連到負載平衡器或服務端、再由應用層做二次處理。

2.1 Route 53 地理位置路由適合什麼情況

Route 53 的「地理位置路由」（Geo routing）是典型的 DNS 解法。它適合：

• 你要用單一網域名稱（例如 api.example.com）對外提供服務。
• 你能接受 DNS 快取（TTL）造成的切換延遲。
• 你想精準控制「來自某些國家/區域的請求」解析結果。

注意：DNS 解析通常由用戶端或中間快取控制。TTL 設得越短，切換越快，但 DNS 查詢成本與穩定性也要更小心。

2.2 ALB 或其他 L7 方式的限制

若你在 ALB 上做地理路由，你需要先取得地理資訊（例如用 IP 地理庫或自建邏輯），再決定轉發。AWS 原生在 ALB 層不提供像 Route 53 那樣直接的「地理位置規則」。因此，如果你的目標是快速、可控、以 DNS 解決，就以 Route 53 最省事。

第三章：準備工作清單（不做會卡住）

開始前，把下列項目準備好，會節省大量除錯時間。

3.1 你需要至少兩個後端端點

例如：

• 香港端：位於香港（ap-east-1 或你實際使用的香港區域）的 ALB、NLB 或 EC2 公開端點。
• 預設端：若你希望「不在指定地理範圍」就走其他區域，至少也要準備一個 fallback 端點。

AWS企業帳號購買 建議用 ALB 作為端點：它有健康檢查、可管理路徑、也方便做 TLS 與重定向。DNS 最終會把使用者導到「目標」上，所以端點必須穩定且可被 Route 53 驗證。

3.2 檢查網域與憑證

如果你用的是 HTTPS，通常你的網域會搭配證書（ACM）。Route 53 路由本身不管證書內容，但你的端點（ALB/CloudFront）需要正確的證書與網域名稱對應。

若你用多區域後端，證書要一致或能在各端點自動完成對應。

3.3 決定你要用「國家」還是「更細的區域」

Geo routing 主要可用於國家層級（有些設定也可針對州/領域，但以你的帳號與地區可用性為準）。你的規則要能解釋：你要把「香港以外」的什麼地區導去香港？還是只要「某些國家」導向香港？規則越細，測試越重要。

第四章：用 Route 53 實作地理位置路由的基本架構

以下以「api.example.com」為例：你有香港後端（例如香港 ALB）與其他後端（例如台灣/新加坡 ALB）。你希望某些地理範圍的使用者解析到香港端點。

4.1 建立一個 Hosted Zone

AWS企業帳號購買 先確認你的網域已存在 Hosted Zone。通常你會在 Route 53 的控制台中建立或選擇現有的 Hosted Zone。

4.2 建立健康檢查（强烈建議）

AWS企業帳號購買 如果你只做地理路由但不做健康檢查，當香港後端壞掉時，DNS 仍可能把使用者導向壞的端點。那會造成使用者體感非常差。

Route 53 可建立 Health Check，判斷端點是否可用。你要把健康檢查與「路由策略」結合，才能在故障時自動切換。

健康檢查的設定重點：

• 檢查協定與路徑：例如 HTTPS 的某個固定路徑（/healthz）回傳 200。
• 頻率與容忍：避免過度頻繁導致誤判，也不要太慢。
• 目標：健康檢查目標要與你的後端端點一致（例如 ALB 的 DNS 名稱或特定 URL）。

4.3 建立地理位置（Geo）類型的 Record Set

在 Hosted Zone 裡建立 Record。你會看到 Route 53 Record Set 的類型選擇，例如 A、AAAA、CNAME（若你使用 ALB 通常會是 Alias）。

此處最關鍵的是：把「路由策略」設定為地理位置。

你會建立兩組（或多組）記錄：

• 地理位置：針對目標國家（例如「香港希望承接的來源國家」）指向香港後端。
• 預設/其他：對剩餘地區指向其他端點或同樣香港，但使用不同規則。

若你目標是「導向香港伺服器」，最直覺的規劃是：

• 把你想導到香港的國家/區域設定到一筆 Geo Record。
• 把其他國家設定到一筆「default」或「其他地區」Record。

4.4 檢查 TTL 與快取策略

TTL 是用戶端與快取伺服器決定多久再去查一次 DNS。一般建議：

• AWS企業帳號購買 上線初期 TTL 可以短一些，便於快速驗證與調整。
• 穩定後再依業務需求延長。

若你用健康檢查做切換，即使 DNS TTL 較長，仍可能依賴地理/故障切換的機制，但總體切換時間仍受 TTL 影響。

第五章：更進階的設計——讓故障切換也符合你的地理規則

地理路由只負責「依地理判斷導到哪個端點」，而故障切換通常需要健康狀態配合。你可以用幾種常見策略達到更好的可靠性。

5.1 方案 A：地理路由 + 健康檢查切換

在最理想的狀況下，你希望：

• 來源國家在正常時導向香港。
• 香港健康檢查失敗後，改導向其他區域端點。

實作方式通常是把地理記錄對應到不同端點，並把健康狀態綁到路由結果上。具體 UI 操作會因你使用的 Record 類型（Alias、帶權重/Failover 的組合）而略有差異，但核心概念是：讓 DNS 回傳結果能受健康狀態影響。

這裡有個常見誤區：健康檢查只設了但沒有真正影響路由結果。你要確認你的 Record Set 在建立時有正確選擇「Failover」或讓健康狀態被納入判斷（視你採用的路由類型）。

5.2 方案 B：多層策略（先地理，再權重或 failover）

如果你的目標不是單一切換，而是想在香港內部也做流量分散（例如香港有兩台 ALB/兩個區域但仍在香港周邊），你可能會加入權重或更多目標。但這會讓規則複雜度上升。

建議原則是：先把「地理 → 正確目標」做對，再談「細節分流」；否則除錯會變得非常慢。

第六章：操作實例——從 0 設到能用

下面用較貼近實務的方式描述一個流程。假設你已經在 AWS 有兩個端點：

• AWS企業帳號購買 香港端：負責處理請求的 ALB（例如 hk-alb.example internal 或它的公開 DNS）。
• 預設端：其他區域 ALB（例如 default-alb）。

你的網域是 api.example.com。你希望「指定來源國家/地區」的使用者解析到香港端。

6.1 建立健康檢查

在 Route 53 的 Health checks 裡建立：

• Protocol：HTTP 或 HTTPS（建議用 HTTPS，能驗證證書與路徑是否正確）。
• Endpoint：對準 hk-alb 所提供的某個穩定路徑，例如 /healthz。
• 期望狀態碼：200。
• 頻率：從較常見的預設開始，確保能快速感知失效。

同理，若你要做故障切換，也可對 default 端建立健康檢查。

6.2 在 Hosted Zone 建立地理位置記錄（對香港）

進入 Hosted Zone → Create record。

設定：

• Name：api
• Type：A 或 AAAA（若使用 Alias，依你的端點支援情況選擇）。
• Routing policy：Geolocation（地理位置）。
• Geolocation：選擇你要導向香港的來源國家/區域。
• Target：指向香港 ALB（使用 Alias 的話通常選擇 ALB/ELB 目標）。
• Evaluate target health：若你的端點與健康檢查能整合，務必確認設定。

AWS企業帳號購買 這一筆記錄會讓符合條件的使用者拿到「指向香港端點」的 DNS 回應。

6.3 建立「其他」或預設記錄

你需要至少一筆「非上述地理範圍」的記錄，否則某些使用者可能拿不到你想像中的結果或被分配到非預期資源。

做法是建立一筆預設（通常 UI 會顯示 default 或用「其他國家」概念）。其目標是 default-alb。

若你也要故障切換，這筆記錄也要有適當的健康狀態評估。

6.4 上線前的測試方式：不要只靠感覺

地理路由的驗證不能只看控制台是否顯示設定成功。你要做的是：從不同來源環境測試 DNS 解析結果。

常見測試方法：

• 在不同網路環境（或不同地區的測試機）進行 dig/nslookup，查看解析結果是否落在你期望的 ALB。
• 確認用戶實際使用的子網域（例如 api.example.com vs www.example.com）完全對上。
• 檢查 TTL，必要時在測試期間降低影響。

此外，還要驗證應用層是否符合：香港端的證書、後端路徑、重定向策略、CORS（若是前端呼叫 API）都要正常。DNS 做對，但應用端錯了，仍會被用戶判定為故障。

第七章：你一定會遇到的坑（以及如何避免）

7.1 地理判斷不是「精確到城市」

Route 53 的地理解析通常依賴商用 IP 定位資料。這表示它可能：

• 把邊界地區的 IP 導到附近國家。
• 在 VPN/代理存在時，判斷結果與真實所在地不同。

因此，當你做測試時要考慮：測試來源是否真的反映真實使用者行為。

7.2 DNS 快取讓切換看起來「沒生效」

AWS企業帳號購買 這是最常見的誤會。你以為你改了規則，但用戶端可能仍在用快取。建議做兩件事：

• 測試時尽量在可控環境重置 DNS cache 或使用不同解析工具。
• 在調整期採用較短 TTL。

7.3 健康檢查路徑不穩或回應慢

健康檢查要選穩定的端點。若你用的 /healthz 會因部署、資料庫重啟而偶發超時，就可能造成不必要切換。規劃健康檢查時，讓它只做最基本的可用性判斷，例如：

• 能連上依賴服務（或至少能返回穩定狀態）。
• 不要把大查詢或需要大量資料的邏輯放進健康檢查。

7.4 ALB/安全群組規則讓健康檢查失敗

健康檢查的請求通常會從 AWS 的來源發出。若安全群組只允許某些 IP 範圍或只允許內網，你會看到「設定正確但一直不健康」。解法是確保 ALB 的安全設定允許健康檢查的來源（依 AWS 的健康檢查機制與你的端點類型而定）。

7.5 Alias 與記錄類型選錯

若你要指向 ALB，Route 53 常用 Alias（A/AAAA）。但如果你用錯記錄類型（例如純 CNAME 對 ALB 的相容性不足），就會導致解析無法如預期。做之前先確認你的目標端點與 Route 53 的記錄類型支援關係。

第八章：把它做成可維運的方案，而不是一次性設定

當路由上線後，你要考慮日後如何維運：新增國家規則、切換目標端點、調整健康檢查、甚至擴充到更多區域。

8.1 變更要可追蹤

建議你在每次更新記錄前先留下變更紀錄（例如：新增哪些國家導向香港、TTL 是否調整、健康檢查是否變更）。DNS 變更不會像程式碼一樣有自然的回滾流程，所以可追蹤性會救你很多時間。

8.2 監控：把「路由是否正確」納入指標

最終你要知道的是：使用者是否真的被導到香港端，且成功率如何。你可以從幾個面向監控：

• ALB 的存活與 5xx/4xx 比率。
• 健康檢查狀態變化（是否頻繁 flapping）。
• 應用日誌：依來源區域/節點標記請求落點。

如果你有能力在應用層加上節點標記（例如響應 Header 或 log tag），就能更快確認路由是否生效，而不必猜。

8.3 逐步擴展規則，避免一次改太多

例如你第一階段只導向 1~2 個目標國家到香港；確認成功後再擴展。這樣當問題發生時，你才知道是哪個規則引入的。

第九章：結論——你真正要記住的三件事

設定 AWS 地理位置路由把流量導向香港伺服器，核心其實可以濃縮成三句話：

• 目標清楚：你要在 DNS 層做路由，並確定你的端點（香港 ALB/服務）能穩定接收流量。
• 健康狀態要完整：有健康檢查與故障切換，才能避免「路由對了但後端壞了」的體感。
• 測試要真實：考慮 DNS 快取、地理解析的誤差，以及應用層相容性（HTTPS、路由、CORS、安全群組）。

當你把這三點做到位，地理路由不只是設定完成，而是能長期維運、遇到故障也能快速恢復的可靠方案。