本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Application Load Balancer 的目標群組
目標群組使用您指定的通訊協定和連接埠號碼將請求路由到單獨已註冊的目標，例如 EC2 執行個體。您可以向多個目標群組註冊任一目標。您可以針對每個目標群組設定運作狀態檢查。凡已註冊至負載平衡器的接聽程式規則中指定之目標群組的所有目標，系統將對其執行運作狀態檢查。
每個目標群組會用來將請求轉送到一個或多個註冊的目標。在建立每個接聽程式規則時，您會指定目標群組和條件。規則的條件符合時，會將流量轉送到對應的目標群組。您可以針對不同類型的請求，建立不同的目標群組。例如，針對一般請求建立一個目標群組，然後再針對應用程式微型服務的請求，建立其他的目標群組。每個目標群組只能搭配一個負載平衡器使用。如需詳細資訊，請參閱[Application Load Balancer 元件](introduction.md#application-load-balancer-components)。
您可以針對每個目標群組，指定負載平衡器的運作狀態檢查設定。除非您在建立目標群組時覆寫這些設定，或是在之後修改設定，否則每個目標群組都會使用預設的運作狀態檢查設定。當您在接聽程式的規則中指定目標群組後，負載平衡器會針對自己已啟用可用區域中的目標群組，持續地監控透過該目標群組註冊的所有目標，以了解目標的運作狀態。負載平衡器會將請求路由至運作狀態良好的已註冊目標。
**Topics**
+ [路由組態](#target-group-routing-configuration)
+ [Target type (目標類型)](#target-type)
+ [IP 地址類型](#target-group-ip-address-type)
+ [通訊協定版本](#target-group-protocol-version)
+ [已登記的目標](#registered-targets)
+ [目標最佳化工具](#target-optimizer)
+ [目標群組屬性](#target-group-attributes)
+ [目標群組運作狀態](#target-group-health)
+ [建立目標群組](create-target-group.md)
+ [設定運作狀態檢查](target-group-health-checks.md)
+ [編輯目標群組屬性](edit-target-group-attributes.md)
+ [登記目標](target-group-register-targets.md)
+ [使用 Lambda 函數做為目標](lambda-functions.md)
+ [標記目標群組](target-group-tags.md)
+ [刪除目標群組](delete-target-group.md)
## 路由組態
根據預設，負載平衡器會使用您在建立目標群組時所指定的通訊協定和埠號，來將請求路由至其目標。或者，您可以在使用目標群組來登錄目標時，覆寫用來將流量轉傳到目標的連接埠。
目標群組支援下列的通訊協定和連接埠：
+ **Protocols (通訊協定)**：HTTP、HTTPS
+ **Ports (連接埠)**：1-65535
使用 HTTPS 通訊協定設定目標群組或使用 HTTPS 運作狀態檢查時，如果任何 HTTPS 接聽程式使用 TLS 1.3 安全政策，則`ELBSecurityPolicy-TLS13-1-0-2021-06`安全政策將用於目標連線。否則，會使用`ELBSecurityPolicy-2016-08`安全政策。負載平衡器會使用您在目標上安裝的憑證，與目標建立 TLS 連線。負載平衡器不會驗證這些憑證。因此，您可以使用自我簽署的憑證或已過期的憑證。由於負載平衡器及其目標位於虛擬私有雲端 (VPC) 中，負載平衡器與目標之間的流量會在封包層級進行驗證，因此即使目標上的憑證無效，也不會面臨man-in-the-middle攻擊或詐騙的風險。離開 的流量 AWS 不會有這些相同的保護，而且可能需要其他步驟才能進一步保護流量。
## Target type (目標類型)
建立目標群組時，您會指定其目標類型，這會決定您對此目標群組註冊目標時指定的目標類型。在建立目標群組之後，您無法變更其目標類型。
下列是可能的目標類型：
`instance`
以執行個體 ID 來指定目標。
`ip`
目標為 IP 地址。
`lambda`
目標是 Lambda 函數。
如果目標類型是 `ip`，您可以從下列其中一個 CIDR 區塊指定 IP 地址：
+ 目標群組 VPC 的子網路
+ 10.0.0.0/8 ([RFC 1918](https://tools.ietf.org/html/rfc1918))
+ 100.64.0.0/10 ([RFC 6598](https://tools.ietf.org/html/rfc6598))
+ 172.16.0.0/12 (RFC 1918)
+ 192.168.0.0/16 (RFC 1918)
**重要**
您無法指定可公開路由傳送的 IP 地址。
所有支援的 CIDR 區塊都可讓您將下列目標註冊至目標群組：
+ 與負載平衡器 VPC (相同區域或不同區域) 對等之 VPC 中的執行個體。
+ AWS 可透過 IP 地址和連接埠 （例如資料庫） 定址的 資源。
+ 透過 AWS Direct Connect 或 Site-to-Site VPN 連線連結至 的內部部署資源。
**注意**
對於在 Local Zone 內部署的 Application Load Balancer，`ip` 目標必須位於相同的 Local Zone，才能接收流量。
如需詳細資訊，請參閱[什麼是 AWS Local Zones？](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html)
如果使用執行個體 ID 來指定目標，會利用在執行個體的主要網路界面中，所指定的主要私有 IP 地址，來將流量轉送到執行個體。如果使用 IP 地址來指定目標，您可以利用來自一個或多個網路界面的任何私有 IP 地址，將流量轉送到執行個體。這可讓執行個體上的多個應用程式，使用相同的連接埠。每個網路界面都可以有自己的安全群組。
如果目標群組的目標類型是 `lambda`，則可以註冊單一 Lambda 函數。當負載平衡器收到 Lambda 函數的請求時，它會呼叫 Lambda 函數。如需詳細資訊，請參閱[使用 Lambda 函數作為 Application Load Balancer 的目標](lambda-functions.md)。
您可以將 Amazon Elastic Container Service (Amazon ECS) 設定為 Application Load Balancer 的目標。如需詳細資訊，請參閱《[Amazon Elastic Container Service 開發人員指南》中的使用適用於 Amazon ECS 的 Application Load Balancer](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/alb.html)。 **
## IP 地址類型
建立新目標群組時，您可以選取目標群組的 IP 地址類型。這會控制用來與目標通訊並檢查目標運作狀態的 IP 版本。
Application Load Balancer 的目標群組支援下列 IP 地址類型：
**`ipv4`**
負載平衡器會使用 IPv4 與目標通訊。
**`ipv6`**
負載平衡器會使用 IPv6 與目標通訊。
**考量事項**
+ 負載平衡器會根據目標群組的 IP 地址類型與目標進行通訊。IPv4 目標群組的目標必須接受來自負載平衡器的 IPv4 流量，而 IPv6 目標群組的目標必須接受來自負載平衡器的 IPv6 流量。
+ 您無法搭配`ipv4`負載平衡器使用 IPv6 目標群組。
+ 您無法向 IPv6 目標群組註冊 Lambda 函數。
## 通訊協定版本
根據預設，Application Load Balancer 會使用 HTTP/1.1 將請求傳送至目標。您可以使用通訊協定版本，使用 HTTP/2 或 gRPC 將請求傳送至目標。
下表摘要說明請求通訊協定與目標群組通訊協定版本組合的結果。
| 請求通訊協定 | 通訊協定版本 | 結果 |
| --- | --- | --- |
| HTTP/1.1 | HTTP/1.1 | 成功 |
| HTTP/2 | HTTP/1.1 | 成功 |
| gRPC | HTTP/1.1 | 錯誤 |
| HTTP/1.1 | HTTP/2 | 錯誤 |
| HTTP/2 | HTTP/2 | 成功 |
| gRPC | HTTP/2 | 如果目標支援 gRPC，則成功 |
| HTTP/1.1 | gRPC | 錯誤 |
| HTTP/2 | gRPC | 如果是 POST 請求，則成功 |
| gRPC | gRPC | 成功 |
**gRPC 通訊協定版本的考量事項**
+ 唯一支援的接聽程式通訊協定是 HTTPS。
+ 接聽程式規則唯一支援的動作類型為 `forward`。
+ 支援的目標類型僅為 `instance` 和 `ip`。
+ 負載平衡器會剖析 gRPC 請求，並根據套件、服務和方法將 gRPC 呼叫路由至適當的目標群組。
+ 負載平衡器支援一元、用戶端串流、伺服器端串流和雙向串流。
+ 必須以 `/package.service/method` 格式提供自訂運作狀態檢查方法。
+ 必須指定在檢查是否有來自目標的成功回應時要使用的 gRPC 狀態程式碼。
+ 您無法使用 Lambda 函數做為目標。
**HTTP/2 通訊協定版本的考量事項**
+ 唯一支援的接聽程式通訊協定是 HTTPS。
+ 接聽程式規則唯一支援的動作類型為 `forward`。
+ 支援的目標類型僅為 `instance` 和 `ip`。
+ 負載平衡器支援一元、用戶端串流、伺服器端串流和雙向串流。每個用戶端 HTTP/2 連線的串流數目上限為 128。
## 已登記的目標
您的負載平衡器可做為用戶端的單一聯絡窗口，並將傳入的流量分配到各個運作狀態良好的已登錄目標。您可以利用一個或多個群組來登錄每個目標。
如果對應用程式的需求增加，您可以利用一個或多個目標群組來登錄額外的目標，來應付需求。無論設定的閾值為何，只要註冊程序完成且目標通過第一個初始運作狀態檢查，負載平衡器就會開始將流量路由到新註冊的目標。
如果對您應用程式的需求減少，或者您需要為目標提供服務，可以從目標群組取消目標的登錄。取消目標的登錄，會將該目標從目標群組中移除，但不會影響到目標。取消目標的註冊之後，負載平衡器就會立即停止將請求路由到目標。目標會進入 `draining` 狀態，直到處理中的請求已完成。當您準備讓目標再繼續接收請求時，可以將目標註冊到目標群組。
如果是根據執行個體 ID 來註冊目標，您可以使用負載平衡器搭配 Auto Scaling 群組。在將目標群組連接到 Auto Scaling 群組之後，自動擴展會在該群組啟動這些目標時，將目標註冊到目標群組。如需詳細資訊，請參閱 *Amazon EC2 Auto Scaling User Guide* 中的 [Attaching a load balancer to your Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html)。
**限制**
+ 您無法在相同的 VPC 中註冊另一個 Application Load Balancer 的 IP 地址。如果另一個 Application Load Balancer 位於與負載平衡器 VPC 對等的 VPC 中，您可以註冊其 IP 地址。
+ 如果執行個體位於與負載平衡器 VPC （相同區域或不同區域） 對等的 VPC 中，則無法依執行個體 ID 註冊執行個體。您可以依照 IP 地址來註冊這些執行個體。
## 目標最佳化工具
您可以在目標群組上啟用目標最佳化工具。目標最佳化工具可讓您準確強制執行目標的並行請求數量上限。它使用您在目標上安裝和設定的代理程式的協助。若要啟用目標最佳化工具，您可以指定目標群組的目標控制連接埠。此連接埠用於管理代理程式和負載平衡器之間的流量。目標最佳化工具只能在建立目標群組期間啟用。指定的目標控制連接埠無法修改。如需詳細資訊，請參閱[目標最佳化工具](target-group-register-targets.md#register-targets-target-optimizer)。
## 目標群組屬性
您可以編輯目標群組的屬性來設定目標群組。如需詳細資訊，請參閱[編輯目標群組屬性](edit-target-group-attributes.md)。
如果目標群組類型為 `instance` 或 `ip`，則支援以下目標群組屬性：
`deregistration_delay.timeout_seconds`
取消註冊目標之前，Elastic Load Balancing 要等待的時間量。範圍介於 0–3600 秒之間。預設值為 300 秒。
`load_balancing.algorithm.type`
路由演算法會決定負載平衡器在路由請求時如何選取目標。值為 `round_robin`、 `least_outstanding_requests`或 `weighted_random`。預設值為 `round_robin`。
`load_balancing.algorithm.anomaly_mitigation`
只有在 `load_balancing.algorithm.type`為 時才可用`weighted_random`。指出是否啟用異常緩解。此值為 `on` 或 `off`。預設值為 `off`。
`load_balancing.cross_zone.enabled`
表示是否已啟用跨區域負載平衡。此值為 `true`、`false` 或 `use_load_balancer_configuration`。預設值為 `use_load_balancer_configuration`。
`slow_start.duration_seconds`
時間期間 (秒)，在此期間負載平衡器會將新註冊的目標流量的線性增加共用傳送至目標群組。此範圍介於 30–900 秒之間 (15 分鐘)。預設值為 0 秒 (已停用)。
`stickiness.enabled`
指出是否已啟用黏性工作階段。此值為 `true` 或 `false`。預設值為 `false`。
`stickiness.app_cookie.cookie_name`
應用程式 Cookie 名稱。應用程式 Cookie 名稱不能有下列字首：`AWSALB`、 `AWSALBAPP`或 `AWSALBTG`；它們會保留供負載平衡器使用。
`stickiness.app_cookie.duration_seconds`
應用程式型 Cookie 過期期間 (秒)。在此期間之後，便會將 Cookie 視為過時。最小值為 1 秒，最大值為 7 天 (604800 秒)。預設值為 1 天 (86400 秒)。
`stickiness.lb_cookie.duration_seconds`
持續時間型 Cookie 過期期間 (秒)。在此期間之後，便會將 Cookie 視為過時。最小值為 1 秒，最大值為 7 天 (604800 秒)。預設值為 1 天 (86400 秒)。
`stickiness.type`
黏性的類型。可能的值為 `lb_cookie` 和 `app_cookie`。
`target_group_health.dns_failover.minimum_healthy_targets.count`
運作狀態必須良好的目標數量下限。如果運作狀態良好的目標數量低於此值，請在 DNS 中將節點標示為運作狀態不佳，讓流量只會路由至運作狀態良好的節點。可能的值為 `off`，或從 1 到最高目標數量的整數。當 時`off`，DNS 故障停用，這表示即使目標群組中的所有目標都運作狀態不佳，節點也不會從 DNS 中移除。預設為 1。
`target_group_health.dns_failover.minimum_healthy_targets.percentage`
運作狀態必須良好的目標最低百分比。如果運作狀態良好的目標百分比低於此值，請在 DNS 中將節點標記為運作狀態不佳，讓流量只會路由至運作狀態良好的節點。可能的值為 `off`，或介於 1 到 100 之間的整數。當 時`off`，DNS 故障停用，這表示即使目標群組中的所有目標都運作狀態不佳，節點也不會從 DNS 中移除。預設值為 `off`。
`target_group_health.unhealthy_state_routing.minimum_healthy_targets.count`
運作狀態必須良好的目標最低數量。如果運作狀態良好的目標數量低於此值，請將流量傳送至所有目標，包括運作狀態不佳的目標。範圍介於 1 到目標最高數量。預設為 1。
`target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage`
運作狀態必須良好的目標最低百分比。如果運作狀態良好的目標百分比低於此值，請將流量傳送至所有目標，包括運作狀態不佳的目標。可能的值為 `off`，或介於 1 到 100 之間的整數。預設值為 `off`。
如果目標群組類型為 `lambda`，則支援以下目標群組屬性：
`lambda.multi_value_headers.enabled`
指出負載平衡器與 Lambda 函數之間的請求和回應標頭交換是否包含值或字串的陣列。可能的值為 `true` 或 `false`。預設值為 `false`。如需詳細資訊，請參閱[多值標頭](lambda-functions.md#multi-value-headers)。
## 目標群組運作狀態
依預設，只要目標群組至少有一個運作狀態良好的目標，就會被視為運作狀態良好。如果您擁有龐大的機群，則只有一個運作狀態良好的目標服務流量是不夠的。相反地，您可以指定必須為運作狀態良好的目標最小計數或百分比，以及當運作狀態良好目標低於指定臨界值時，負載平衡器會採取哪些動作。這可改善應用程式的可用性。
**Topics**
+ [運作運作狀態不佳](#unhealthy-state-actions)
+ [需求和考量事項](#target-group-health-considerations)
+ [監控](#target-group-health-monitoring)
+ [範例](#target-group-health-examples)
+ [針對您的負載平衡器使用 Route 53 DNS 備援](#r53-dns-failover)
### 運作運作狀態不佳
您可以針對下列動作設定運作狀態良好的臨界值：
+ **DNS 容錯移轉** – 當區域中運作狀態良好的目標低於閾值時，我們會將該區域的負載平衡器節點 IP 地址標記為 DNS 運作狀態不佳。因此，當用戶端解析負載平衡器 DNS 名稱時，流量只會路由至運作狀態良好的區域。
+ **路由容錯移轉** – 當區域中運作狀態良好的目標低於閾值時，負載平衡器會將流量傳送至負載平衡器節點可用的所有目標，包括運作狀態不佳的目標。這會增加用戶端連線成功的機會，尤其是當目標暫時無法通過運作狀態檢查時，並降低運作狀態良好目標超載的風險。
### 需求和考量事項
+ 如果您在目標群組上啟用目標最佳化工具，建議您將目標群組的運作狀態檢查連接埠設定為與 TARGET\_CONTROL\_DATA\_ADDRESS 中的連接埠相同。這可確保如果代理程式運作狀態不佳，目標將無法通過運作狀態檢查。如需詳細資訊，請參閱[目標最佳化工具](target-group-register-targets.md#register-targets-target-optimizer)。
+ 您無法在目標為 Lambda 函數的目標群組中使用此功能。如果 Application Load Balancer 是 Network Load Balancer 或 Global Accelerator 的目標，請勿設定 DNS 備援的閾值。
+ 如果您為動作指定兩種類型的閾值 (計數和百分比)，則當違反任一閾值時，負載平衡器都會採取動作。
+ 如果您指定這兩個動作的臨界值，DNS 備援的臨界值必須大於或等於路由容錯移轉的臨界值，以便 DNS 備援發生在路由容錯移轉或之前。
+ 如果您將臨界值指定為百分比，我們會根據向目標群組註冊的目標總數來動態計算值。
+ 目標總數取決於是關閉還是開啟跨區域負載平衡。如果關閉跨區域負載平衡，則每個節點只會將流量傳送到其自身區域中的目標，這代表臨界值會分別套用至每個已啟用區域中的目標數目。如果開啟跨區域負載平衡，則每個節點會將流量傳送到所有已啟用區域中的所有目標，這代表指定的臨界值會套用至所有已啟用區域中的目標總數。如需詳細資訊，請參閱[跨區域負載平衡](edit-target-group-attributes.md#modify-cross-zone)。
+ 發生 DNS 容錯移轉時，會影響與負載平衡器相關聯的所有目標群組。確保剩餘區域中有足夠的容量來處理這些額外的流量，尤其是在跨區域負載平衡關閉的情況下。
+ 使用 DNS 容錯移轉時，我們會將運作狀態不佳區域的 IP 地址從負載平衡器的 DNS 主機名稱中移除。不過，本機用戶端 DNS 快取可能會包含這些 IP 地址，直到 DNS 記錄中的存活期 (TTL) 到期 (60 秒) 為止。
+ 使用 DNS 容錯移轉時，如果有多個目標群組連接到 Application Load Balancer，且一個目標群組在區域中運作狀態不佳，則 DNS 運作狀態檢查會成功，如果該區域中至少有一個其他目標群組運作狀態良好。
+ 使用 DNS 備援時，如果將所有負載平衡器區域視為運作狀態不佳，負載平衡器會將流量傳送到所有區域，包括運作狀態不佳的區域。
+ 除了是否有足夠運作狀態良好的目標可能導致 DNS 備援之外，還有其他因素，例如區域的運作狀況。
### 監控
若要監控目標群組的運作狀態，請參閱[目標群組運作狀態的 CloudWatch 指標](load-balancer-cloudwatch-metrics.md#target-group-health-metric-table)。
### 範例
以下範例示範如何套用目標群組運作狀態設定。
**案例**
+ 支援 A 和 B 兩個可用區域的負載平衡器
+ 每個可用區域包含 10 個已註冊目標
+ 目標群組具有下列目標群組運作狀態設定：
+ DNS 備援 - 50%
+ 路由容錯移轉 - 50%
+ 可用區域 B 中有六個目標失敗
**如果停用跨區域負載平衡**
+ 每個可用區域中的負載平衡器節點只能將流量傳送到其可用區域中的 10 個目標。
+ 可用區域 A 中有 10 個運作狀態良好的目標，符合運作狀態目標的必要百分比。負載平衡器會繼續在 10 個運作狀態良好的目標之間分配流量。
+ 可用區域 B 中只有 4 個運作狀態良好的目標，這是可用區域 B 中負載平衡器節點目標的 40%，因為小於運作狀態良好目標的必要百分比，所以負載平衡器會採取下列動作：
+ DNS 備援 - 可用性區域 B 在 DNS 中標示為運作狀態不良。由於用戶端無法將負載平衡器名稱解析為可用區域 B 中的負載平衡器節點，且可用區域 A 運作狀態良好，因此用戶端會將新的連線傳送至可用區域 A。
+ 路由容錯移轉 - 當新連線明確傳送至可用區域 B 時，負載平衡器會將流量分配給可用性區域 B 中的所有目標，包括運作狀態不佳的目標。這樣可以防止剩餘運作狀態良好的目標中斷。
**如果啟用跨區域負載平衡**
+ 每個負載平衡器節點都可以將流量傳送到兩個可用區域的所有 20 個已註冊目標。
+ 可用區域 A 中有 10 個運作狀態良好的目標，而可用區域 B 中有 4 個運作狀態良好的目標，總共有 14 個運作狀態良好目標。這是兩個可用區域中負載平衡器節點目標的 70%，符合運作狀態良好目標的必要百分比。
+ 負載平衡器會在兩個可用區域中 14 個運作狀況良好的目標之間分配流量。
### 針對您的負載平衡器使用 Route 53 DNS 備援
如果您使用 Route 53 將 DNS 查詢路由傳送到負載平衡器，您也可以使用 Route 53 設定負載平衡器的 DNS 備援。在容錯移轉組態中，Route 53 會檢查負載平衡器的目標群組目標的運作狀態，以判斷是否可用。如果沒有負載平衡器註冊的狀態良好目標，或者負載平衡器本身運作狀態不佳，Route 53 會將流量路由到另一可用資源，例如運作狀態良好的負載平衡器或 Amazon S3 中的靜態網站。
例如，假設您有一個 `www.example.com` Web 應用程式，而且您需要在後方執行兩個負載平衡器備援執行個體，位於不同的區域。您希望流量在一個區域主要路由到負載平衡器，而且您想要在其他區域使用負載平衡器，以供失敗時備份。如果您設定 DNS 容錯移轉，您可以指定您的主要和次要 (備份) 負載平衡器。Route 53 會引導流量到可用的主要負載平衡器，或是次要負載平衡器。
**評估目標運作狀態的運作方式**
+ 如果 Application Load Balancer 的別名記錄`Yes`上的評估目標運作狀態設為 ，Route 53 會評估`alias target`值所指定資源的運作狀態。Route 53 使用目標群組運作狀態檢查。
+ 如果連接至 Application Load Balancer 的所有目標群組都正常運作，Route 53 會將別名記錄標記為正常運作。如果您已設定目標群組的閾值，且符合其閾值，則會通過運作狀態檢查。否則，如果目標群組包含至少一個運作狀態良好的目標，則會通過運作狀態檢查。如果運作狀態檢查通過，Route 53 會根據您的路由政策傳回記錄。如果使用容錯移轉路由政策，Route 53 會傳回主要記錄。
+ 如果連接到 Application Load Balancer 的任何目標群組運作狀態不佳，別名記錄會失敗 Route 53 運作狀態檢查 （故障開啟）。如果使用 評估目標運作狀態，容錯移轉路由政策會將流量重新導向至次要資源。
+ 如果連接到 Application Load Balancer 的所有目標群組都是空的 （沒有目標），Route 53 會將記錄視為運作狀態不佳 （故障開啟）。如果使用 評估目標運作狀態，容錯移轉路由政策會將流量重新導向至次要資源。
如需詳細資訊，請參閱《*Amazon Route 53 開發人員指南*》中的[使用負載平衡器目標群組運作狀態閾值來改善部落格中的可用性](https://aws.amazon.com/blogs/networking-and-content-delivery/using-load-balancer-target-group-health-thresholds-to-improve-availability/)和[設定 DNS 容錯移轉](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)。 AWS