AWS國際帳號註冊 AWS ALB如何配置基於網域名稱的流量轉發路由

第一章：為什麼要用「網域名稱」路由

在雲端服務的實務裡，同一套基礎架構要承載多個站點並不罕見。你可能有幾個子網域：例如 app.example.com、admin.example.com、api.example.com；也可能是一個域名下有不同路徑與不同服務。這時如果每個站點都用獨立的負載平衡器，成本與維運壓力會明顯上升。

ALB 的優勢在於：它能根據請求的「Host」資訊（也就是網域名稱）來決定把流量導向哪個目標群組。簡單說，你用同一個 ALB 接入口，只要在 Listener 規則裡定義「如果 Host 是 X，就轉到 Y 目標群組」，就能在同一套入口完成多站點分流。

這種做法尤其適合以下情境：

• 多個子網域指向同一個入口，但分別對應不同服務（前台、後台、API）。
• AWS國際帳號註冊 想把 TLS 憑證集中管理，並對不同網域提供不同證書或同一張證書涵蓋多網域。
• 希望未來擴充站點時，主要在 Listener 規則層面調整，而不是新增整套入口資源。

下面我們就用一個可落地的流程，把「基於網域名稱的流量轉發路由」完整做出來。

第二章：前置條件與整體架構

先釐清角色，避免後面卡在名詞混淆。

2.1 你會用到哪些 AWS 元件

• ALB：負責接收外部流量，並在 Listener 裡根據規則轉發。
• Listener：定義「接收什麼協定/埠」以及「匹配後導向哪裡」。常見是 443（HTTPS）。
• Rule：規則由條件（Condition）與動作（Action）組成。條件可以是 Host header、path、HTTP 方法等。
• Target Group：目標集合，例如一組 EC2、或一組容器（ECS/ EKS）、或 IP。每個目標群組都有 health check。
• ACM 憑證：提供 HTTPS 使用的 TLS 證書。
• Route 53（可選但常見）：把網域（A/AAAA 或 CNAME）指向 ALB。

2.2 建議的目標設計範例

假設你有兩個站點：

• app.example.com → 導向服務 A（例如運行在 EC2 instance 的 80 埠）
• api.example.com → 導向服務 B（例如運行在 ECS task 的 8080 埠）

兩個站點共用同一個 ALB：

• 對外使用 443 HTTPS
• 在 Listener 設定規則：Host = app.example.com → forward 到目標群組 A；Host = api.example.com → forward 到目標群組 B
• 再設定一個 default action：未匹配到的 Host，導向預設群組或回傳 404

第三章：建立或確認 ALB 基礎設定

如果你已經有 ALB，可以直接跳到憑證與 Listener 規則。但若是從零開始，這段要打牢。

3.1 設定 ALB 的網路與埠

ALB 必須部署在 VPC 裡，並選擇適當的子網（通常是不同可用區的公有子網）。你需要確保：

• ALB 所在的子網能接收外部流量（IGW 路由或公有子網設定）。
• 安全群組（Security Group）允許入站 443（以及你若要同時提供 80 的 HTTP）。
• 目標群組背後的服務安全群組允許 ALB 的連線到目標埠（例如 80 或 8080）。

這一步常見問題是：ALB 看得到、但後端連不到。表面上 443 正常接入，實際轉發時後端一直 health check 失敗或連線被拒絕。

3.2 建立 Target Group（先別急著配規則）

你需要至少兩個 Target Group：

• tg-app：目標是服務 A
• tg-api：目標是服務 B

建立 Target Group 時，注意幾件事：

• 協定與埠：例如 HTTP:80 或 HTTP:8080。
• Target type：若是 EC2 instance，選 instance；若是容器或 IP，則選 IP（依你的運行方式）。
• Health check：設定可用的路徑（例如 /health）或使用預設 HTTP health check。務必確認後端實際有回應且狀態碼正確。

AWS國際帳號註冊 在你 Listener 設定前先把 Target Group 的健康狀態跑起來，會少很多挫折。否則你會以為是 Host 規則沒匹配，結果其實是轉發目標一直 unhealthy。

第四章：憑證（ACM）與 HTTPS 基礎

基於網域名稱路由通常跑在 HTTPS 上，因為現代瀏覽器對 HTTP/HTTPS 有更嚴格的預設行為。當你用 443 建 Listener，必須綁定有效憑證。

4.1 ACM 憑證要涵蓋哪些網域

這裡有個容易被忽略的點：TLS 是在更早的階段就完成握手。當客戶端連到 app.example.com 時，ALB 需要用對應的憑證完成 handshake。若你用同一張證書覆蓋多個網域（Subject Alternative Name），通常沒問題；若證書只覆蓋其中一個網域，另一個網域會因憑證不匹配而出現瀏覽器警告。

建議做法：

• 使用一張多網域（SAN）憑證涵蓋所有你要路由的網域（例如 app.example.com、api.example.com）。
• 或視需求使用多張證書並搭配 ALB 的憑證選擇機制（這會更複雜，本文聚焦於「網域名稱路由」的核心）。

4.2 憑證必須和 ALB 同一個區域

ALB 只能引用同 Region 的 ACM 憑證。你若發現綁定失敗，通常不是 Host 規則問題，而是區域或憑證狀態。

4.3 建議同時支援 80 → 443

實務上常見的是：

• HTTP:80 只做導向 HTTPS（301 或 302）。
• HTTPS:443 做真正的 Host routing。

這不只是使用者體驗，也能避免一些 OAuth、Cookie、Referer 等情境下因協定混用造成的安全與一致性問題。

第五章：建立 Listener 規則（核心：Host header 条件）

現在進到最重要的部分：在 ALB 的 HTTPS Listener 上建立規則。

5.1 Listener 的基本結構

Listener 通常包含：

• default rule：預設動作。當 Host 不符合你自訂條件時，會走這個。
• 自訂 rules：依序比對（由上到下）。你要確保規則的順序不會被意外擋住。

AWS國際帳號註冊 5.2 建立條件：匹配 Host header

在規則新增時，你會看到條件類型（例如 Path、Host header、HTTP header 等）。我們要用：

• Host header 或類似名稱（UI 可能翻譯為「主機標頭」）。

接著輸入要匹配的網域（建議使用完整 FQDN）：

• Rule 1：Host header 為 app.example.com → forward to tg-app
• Rule 2：Host header 為 api.example.com → forward to tg-api

幾個關鍵提醒：

• Host header 不是你在 ALB 上的 DNS 名稱，而是客戶端請求帶的 Host。例如你在瀏覽器打 https://app.example.com/，Host header 就是 app.example.com。
• AWS國際帳號註冊 匹配要精準：app.example.com 和 www.app.example.com 不是同一個。
• 如果你要匹配多個網域，規則通常允許多個條件值。你也可以加更多規則，但要留意順序。

5.3 動作：forward 到指定 Target Group

AWS國際帳號註冊 每個 rule 的 action 選擇 forward，並指向對應的 target group：

• app.example.com → tg-app
• AWS國際帳號註冊 api.example.com → tg-api

如果你後端是 HTTP，Listener 的 HTTPS 會在 ALB 層解密後轉成 HTTP（或你也可以配置對後端使用 HTTPS，但那又牽涉到後端憑證與安全設定）。多數情況先從簡單 HTTP 開始。

5.4 設定 default rule：避免「有網域但沒路由」的黑洞

建議你在 default rule 設定一個明确的行為，否則遇到未匹配 Host 的請求，你可能會得到難以理解的錯誤。

兩種常見策略：

• 導向某個預設站點（例如網站首頁或維護頁）。
• 回傳固定回應（例如 404），告訴使用者這個網域未被支援。

第六章：DNS 連動到 ALB（Route 53 與驗證）

Listener 規則能不能生效，還取決於 DNS 是否把你的網域指向 ALB。

6.1 用 Route 53 建立 A/AAAA 或 CNAME

若你的網域目前還沒有指到 ALB，你需要：

• 建立 app.example.com 指到 ALB
• 建立 api.example.com 指到 ALB

在 Route 53 裡，常見是 alias A record（指向 ALB）。不同情況你也可能需要 CNAME，但對 ALB alias 的作法通常更直覺。

6.2 TTL 與等待時間

DNS 變更不一定立刻生效。你應預估幾分鐘到數小時的延遲（取決於 TTL、快取與解析器）。在測試時，別只在同一台電腦上反覆刷新，否則快取會讓你誤判規則是否成功。

第七章：除錯與常見坑（把問題定位做對）

當你配置好規則後，如果訪問仍失敗，通常不是「Host header 設錯一個字」那麼單純，而是整條鏈路中的某一環節斷掉。下面列出最常見問題與檢查順序。

7.1 先確認 ALB 後端健康狀態

到 Target Group 看健康狀態。如果 health check 一直是 unhealthy：

• 檢查後端服務是否真有提供目標埠。
• 檢查 security group 是否允許 ALB 連入。
• 檢查 health check 路徑是否存在且回應正確狀態碼。

AWS國際帳號註冊 這一步正確，後面 Listener 才有意義。

7.2 確認規則是否真的匹配到 Host

你可以用以下方式驗證：

• 確保你測試的是對應網域（瀏覽器網址列）而不是用 ALB 的 DNS 名稱。
• 確認你沒有因為瀏覽器重新導向而改成其他網域。

如果你使用 ALB 的 DNS 名稱直接訪問（例如 xxxxx.elb.amazonaws.com），Host header 會是那個名稱而不是 app.example.com，自然匹配不到 Host 規則。

7.3 憑證問題：不是路由錯，是 TLS 先失敗

若瀏覽器直接顯示憑證不受信任或網域不匹配，那通常發生在 TLS 握手階段，根本還沒走到你寫的 Host header 規則。你需要檢查：

• 憑證是否涵蓋該網域。
• ALB 是否綁定到正確憑證（HTTPS Listener 的證書列表）。
• 是否有 HTTP → HTTPS 導向造成看似路由失效。

7.4 規則順序造成的意外匹配

ALB 規則一般是依序判斷，匹配到第一個就不再往下。因此若你不小心加入了過於寬鬆的規則（例如寬泛 Host），可能會擋住更精確的規則。

建議實務：

• 先放最精確的 Host 規則。
• 寬泛或 default 規則放在後面。

7.5 轉發協定與後端行為不一致

即使規則正確匹配，如果後端對來自 ALB 的流量有額外要求（例如只接受特定 header、只接受某些來源或要求一定路徑），也可能導致看似「路由失敗」。

這時候你需要看 ALB 的 access logs（若有啟用）或後端應用程式的日誌，確認是否真的進入對應服務。

7.6 Cookie、重定向與絕對 URL 的常見坑

當 app 從站點 A 重定向到站點 B，或使用後端程式生成的絕對 URL 帶錯網域，就會造成「明明已導到正確目標群組，卻看不到正確頁面」。

對依賴 Host 的應用程式（例如使用框架設定 base URL、反向代理參數），要確認 ALB 會把原始 Host 傳到後端。常見做法是讓後端從 Host 或 X-Forwarded-Host 取得正確網域（視你的應用配置）。

第八章：完整配置示例（把步驟串起來）

下面用一個串起來的流程，讓你能照著做出類似結果。

8.1 前提

• VPC 與公有子網已準備好
• 服務 A 可在 80 埠提供 HTTP
• 服務 B 可在 8080 埠提供 HTTP
• ACM 憑證涵蓋 app.example.com 與 api.example.com

8.2 建立 Target Group

• 建立 tg-app：HTTP、port 80，health check 路徑 /health
• 建立 tg-api：HTTP、port 8080，health check 路徑 /health
• 把對應的 EC2 instance 或容器任務加入 target group
• 等待健康狀態變為 healthy

8.3 建立 Listener

• 在 ALB 建立 HTTPS listener：port 443，選擇 ACM 憑證
• 可選：新增 HTTP listener：port 80，將請求導到 HTTPS

8.4 新增規則（Host header）

• Rule 1（優先）：
  • Condition：Host header is app.example.com
  • Action：forward to tg-app
• AWS國際帳號註冊 Rule 2（次優先）：
  • Condition：Host header is api.example.com
  • Action：forward to tg-api
• Default rule：回傳 404 或導向維護頁目標群組

8.5 DNS 指向 ALB

• 在 Route 53 設定 app.example.com alias 到 ALB
• AWS國際帳號註冊 設定 api.example.com alias 到 ALB
• 等待解析完成

8.6 測試

• AWS國際帳號註冊 用瀏覽器打 https://app.example.com/，確認回到服務 A
• 用瀏覽器打 https://api.example.com/，確認回到服務 B
• 用未配置網域例如 unknown.example.com 測試 default rule（應回 404 或預設頁）

第九章：進階延伸：同時結合 Path 與 Host

Host header 路由解決的是「網域層級」的分流。若你還希望同一網域下再區分不同路徑（例如 /v1、/admin），ALB 允許你在同一條規則中同時使用多個條件。

但要留意一點：多條件通常是「全部同時符合才匹配」。這很好用，卻也容易因為你以為只匹配 Host 而忽略了 Path。

例子：

• Host = api.example.com 且 Path = /v1/* → tg-api-v1
• Host = api.example.com 且 Path = /v2/* → tg-api-v2

當你把規則變複雜，強烈建議使用清晰命名與審核順序，否則除錯會變得像解謎遊戲。

第十章：維運建議：讓規則可管理、可交付

當你的站點越來越多，Listener 規則會迅速膨脹。這時候你需要一些原則來維運。

10.1 規則命名與目標群組一致性

建議以「網域 → 目標群組」建立對應命名，例如：

• tg-app-example-com
• tg-api-example-com

這能讓你快速看出規則最後會導向哪裡。

10.2 記錄變更：用版本化方式管理配置

即便你是手動在 Console 上操作，也要在流程中留有可回溯記錄。當出現事故（例如剛上線某網域出問題），你才能快速回到哪個規則、哪個目標群組被更動。

10.3 限制規則數量與頻率

Host 規則通常比 Path 規則更直觀，但也可能因公司內部頻繁新增網域導致規則越來越多。你可以考慮：

• 把相似服務集中在同一個網域下再用 Path/條件分流
• 或使用標準化的服務部署流程，讓新服務一定符合 health check 與安全策略

結語：把「網域」當成路由訊號，你就掌握了入口的秩序

基於網域名稱的 ALB 路由，本質上是把「請求的 Host header」當成決策訊號：ALB 在 Listener 規則中比對網域，然後把流量轉發到對應目標群組。只要你把憑證、DNS、Target Group 健康狀態與規則匹配理解清楚，整個流程就會非常穩定。

更重要的是：它讓入口資源從一堆分散的負載平衡器變成一個可治理的入口。你會在規則層面做清晰分工，在維運層面降低成本與心智負擔。當你下一次新增子網域或切換後端服務時，也能快速確認哪一條規則在起作用，並在分鐘內定位問題。