本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Network Load Balancer 的目標群組 每個*目標群組*會用來將請求轉送到一個或多個註冊的目標。當您建立接聽程式時，可以為其預設動作指定一個目標群組。流量會轉送至接聽程式規則中指定的目標群組。您可以針對不同類型的請求，建立不同的目標群組。例如，針對一般請求建立一個目標群組，然後再針對應用程式微型服務的請求，建立其他的目標群組。如需詳細資訊，請參閱[Network Load Balancer 元件](introduction.md#network-load-balancer-components)。 您可以針對每個目標群組，指定負載平衡器的運作狀態檢查設定。除非您在建立目標群組時覆寫這些設定，或是在之後修改設定，否則每個目標群組都會使用預設的運作狀態檢查設定。當您在接聽程式的規則中指定目標群組後，負載平衡器會針對自己已啟用可用區域中的目標群組，持續地監控透過該目標群組註冊的所有目標，以了解目標的運作狀態。負載平衡器會將請求路由至運作狀態良好的已註冊目標。如需詳細資訊，請參閱[Network Load Balancer 目標群組的運作狀態檢查](target-group-health-checks.md)。 **Topics** + [路由組態](#target-group-routing-configuration) + [Target type (目標類型)](#target-type) + [IP 地址類型](#target-group-ip-address-type) + [已登記的目標](#registered-targets) + [目標群組屬性](#target-group-attributes) + [目標群組運作狀態](#target-group-health) + [建立目標群組](create-target-group.md) + [更新運作狀態設定](modify-target-group-health-settings.md) + [設定運作狀態檢查](target-group-health-checks.md) + [編輯目標群組屬性](edit-target-group-attributes.md) + [登記目標](target-group-register-targets.md) + [使用 Application Load Balancer 做為目標](application-load-balancer-target.md) + [標記目標群組](target-group-tags.md) + [刪除目標群組](delete-target-group.md) ## 路由組態 根據預設，負載平衡器會使用您在建立目標群組時所指定的通訊協定和埠號，來將請求路由至其目標。或者，您可以在使用目標群組來登錄目標時，覆寫用來將流量轉傳到目標的連接埠。 Network Load Balancer 目標群組支援下列的通訊協定與連接埠： + **通訊協定**：TCP、TLS、UDP、TCP\_UDP、QUIC、TCP\_QUIC + **Ports (連接埠)**：1-65535 如果使用 TLS 通訊協定設定目標群組，則負載平衡器會使用您在目標上安裝的憑證，與目標建立 TLS 連線。負載平衡器不會驗證這些憑證。因此，您可以使用自我簽署的憑證或已過期的憑證。由於負載平衡器位於虛擬私有雲端 (VPC)，系統會在封包層級對負載平衡器與目標之間的流量進行驗證，因此即使目標上的憑證無效，也不會遭受中間人攻擊或詐騙的風險。 下表總結接聽程式通訊協定和目標群組設定的支援組合。 | 接聽程式通訊協定 | 目標群組通訊協定 | 目標群組類型 | 運作狀態檢查通訊協定 | | --- | --- | --- | --- | | TCP | TCP \| TCP\_UDP \| TCP\_QUIC | 執行個體 \| ip | HTTP \| HTTPS \| TCP | | TCP | TCP | alb | HTTP \| HTTPS | | TLS | TCP \| TLS | 執行個體 \| ip | HTTP \| HTTPS \| TCP | | UDP | UDP \| TCP\_UDP | 執行個體 \| ip | HTTP \| HTTPS \| TCP | | TCP\_UDP | TCP\_UDP | 執行個體 \| ip | HTTP \| HTTPS \| TCP | | QUIC | QUIC \| TCP\_QUIC | 執行個體 \| ip | HTTP \| HTTPS \| TCP | | TCP\_QUIC | TCP\_QUIC | 執行個體 \| ip | HTTP \| HTTPS \| TCP | ## Target type (目標類型) 在建立目標群組時，您會指定其目標類型，這會決定您指定其目標的方式。在建立目標群組之後，您無法變更其目標類型。 下列是可能的目標類型： `instance` 以執行個體 ID 來指定目標。 `ip` 以 IP 地址來指定目標。 `alb` 目標是 Application Load Balancer。 如果目標類型是 `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 區塊都可讓您將下列目標註冊至目標群組： + AWS 可依 IP 地址和連接埠定址的 資源 （例如資料庫）。 + 透過 AWS Direct Connect 或 Site-to-Site VPN 連線連結至 的內部部署資源。 當您的目標群組停用用戶端 IP 保留時，負載平衡器每分鐘可支援 55,000 條連線，每個 Network Load Balancer IP 地址與唯一目標 (IP 地址與連接埠) 組合。若超過上述連線數量，將提高連接埠配置錯誤機率。若發生連接埠配置錯誤，請將更多目標新增至目標群組。 在共用 VPC （以參與者身分） 中啟動 Network Load Balancer 時，您只能在已與您共用的子網路中註冊目標。 當目標類型為 `alb`時，您可以將單一 Application Load Balancer 登錄為目標。如需詳細資訊，請參閱[使用 Application Load Balancer 做為 Network Load Balancer 的目標](application-load-balancer-target.md)。 Network Load Balancer 不支援 `lambda` 目標類型。Application Load Balancer 是唯一支援 `lambda` 目標類型的負載平衡器。如需詳細資訊，請參閱 *Application Load Balancer 使用者指南*的 [Lambda 函數做為目標](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html)。 如果您在使用 Network Load Balancer 登錄的執行個體上有微型服務，除非負載平衡器是連線到網際網路，或執行個體是依 IP 地址登錄，否則您無法使用負載平衡器來在這兩者之間提供通訊。如需詳細資訊，請參閱[目標向其負載平衡器發出的請求連線逾時](load-balancer-troubleshooting.md#loopback-timeout)。 ### 請求路由與 IP 地址 如果使用執行個體 ID 來指定目標，會利用在執行個體主要網路界面所指定的主要私有 IP 地址，將流量轉送到執行個體。負載平衡器會重新寫入資料封包的目的地 IP 地址，再轉送至目標執行個體。 如果使用 IP 地址來指定目標，您可以利用來自一個或多個網路界面的任何私有 IP 地址，將流量轉送到執行個體。這可讓執行個體上的多個應用程式，使用相同的連接埠。請注意，每個網路界面都可以有自己的安全群組。負載平衡器會先重新寫入目的地 IP 地址，再轉送至目標。 有關允許流量至您執行個體的更多資訊，請參閱 [目標安全群組](target-group-register-targets.md#target-security-groups)。 ### 在內部部署資源作為目標 當目標類型為 時，透過 Direct Connect 或 Site-to-Site VPN 連接連結的內部部署資源可以做為目標`ip`。 ![使用 AWS Direct Connect 或 將 Network Load Balancer 與內部部署伺服器連線 AWS Site-to-Site VPN。](http://docs.aws.amazon.com/zh_tw/elasticloadbalancing/latest/network/images/nlb-on-prem-resources.png) 當使用內部部署資源時，這些目標的 IP 地址仍必須來自下列其中一個 CIDR 區塊： + 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) 如需詳細資訊 Direct Connect，請參閱[什麼是 Direct Connect？](https://docs.aws.amazon.com/directconnect/latest/UserGuide/) 如需詳細資訊 AWS Site-to-Site VPN，請參閱[什麼是 AWS Site-to-Site VPN？](https://docs.aws.amazon.com/vpn/latest/s2svpn/) ## IP 地址類型 建立新目標群組時，您可以選取目標群組的 IP 地址類型。這會控制用來與目標通訊並檢查目標運作狀態的 IP 版本。 Network Load Balancer 的目標群組支援下列 IP 地址類型： **`ipv4`** 負載平衡器會使用 IPv4 與目標通訊。 **`ipv6`** 負載平衡器會使用 IPv6 與目標通訊。 **考量事項** + 負載平衡器會根據目標群組的 IP 地址類型與目標進行通訊。IPv4 目標群組的目標必須接受來自負載平衡器的 IPv4 流量，而 IPv6 目標群組的目標必須接受來自負載平衡器的 IPv6 流量。 + 您無法搭配`ipv4`負載平衡器使用 IPv6 目標群組。 + 您無法將 IPv4 目標群組與`dualstack`負載平衡器的 UDP 接聽程式搭配使用。 + 您無法向 IPv6 目標群組註冊 Application Load Balancer。 + 您無法搭配 QUIC 或 TCP\_QUIC 通訊協定使用 IPv6 目標群組。 ## 已登記的目標 您的負載平衡器可做為用戶端的單一聯絡窗口，並將傳入的流量分配到各個運作狀態良好的已登錄目標。在負載平衡器能夠使用的每個可用區域中，每個目標群組都必須擁有至少一個已登錄的目標。您可以利用一個或多個群組來登錄每個目標。 如果對應用程式的需求增加，您可以利用一個或多個目標群組來登錄額外的目標，來應付需求。一旦註冊程序完成且目標通過第一個初始運作狀態檢查，負載平衡器就會開始將流量路由到新註冊的目標，無論設定的閾值為何。 如果對您應用程式的需求減少，或者您需要為目標提供服務，可以從目標群組取消目標的登錄。取消目標的登錄，會將該目標從目標群組中移除，但不會影響到目標。取消目標的登錄之後，負載平衡器就會立即停止將流量轉傳到目標。目標會進入 `draining` 狀態，直到處理中的請求已完成。當您準備讓目標再繼續接收流量時，可以將目標登錄到目標群組。 如果是根據執行個體 ID 來註冊目標，您可以使用負載平衡器搭配 Auto Scaling 群組。在將目標群組連接到 Auto Scaling 群組之後，自動擴展會在該群組啟動這些目標時，將目標註冊到目標群組。如需詳細資訊，請參閱《*Amazon EC2 Auto Scaling 使用者指南*》中的[連接負載平衡器到 Auto Scaling 群組](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html)。 **需求和考量事項** + 如果執行個體如下類型之一：C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3, 或 T1，無法透過執行個體 ID 來登錄執行個體。 + 按照 IPv6 目標群組的執行個體 ID 註冊目標時，目標必須具有指派的主要 IPv6 地址。若要進一步了解，請參閱《*Amazon EC2 使用者指南*》中的 [ IPv6 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing) + 依執行個體 ID 註冊目標時，執行個體必須與 Network Load Balancer 位於相同的 VPC 中。如果執行個體位於與負載平衡器 VPC 互連的 VPC 中 (相同區域或不同區域)，則您無法依執行個體 ID 註冊執行個體。您可以依照 IP 地址來註冊這些執行個體。 + 如果您依照 IP 地址註冊目標，且 IP 地址與負載平衡器位於相同的 VPC 中，則負載平衡器會驗證它來自於其可連上的子網路。 + 負載平衡器只會將流量路由到已啟用可用區域的目標。未使用未啟用區域的目標。 + 對於 UDP、TCP\_UDP、QUIC 和 TCP\_QUIC 目標群組，如果執行個體位於負載平衡器 VPC 之外，或使用下列其中一個執行個體類型，則請勿透過 IP 地址註冊執行個體：C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3 或 T1。位於負載平衡器 VPC 外部或使用不支援的執行個體類型的目標，可能能夠從負載平衡器接收流量，但隨後無法回應。 ## 目標群組屬性 您可以編輯目標群組的屬性來設定目標群組。如需詳細資訊，請參閱[編輯目標群組屬性](edit-target-group-attributes.md)。 支援下列目標群組屬性。只有當目標群組類型為 `instance` 或 `ip`時，您才能修改這些屬性。如果目標群組類型為 `alb`，則這些屬性一律使用其預設值。 `deregistration_delay.timeout_seconds` 將取消註冊目標的狀態從 `draining` 變更為 `unused` 之前，Elastic Load Balancing 要等待的時間量。範圍介於 0 到 3600 秒之間。預設值為 300 秒。對於 QUIC 流量，值一律為 300 秒。 `deregistration_delay.connection_termination.enabled` 指示負載平衡器是否在取消登錄逾時結束時終止連線。此值為 `true` 或 `false`。對於新的 UDP/TCP\_UDP 目標群組，預設值為 `true`。否則預設值為 `false`。此屬性不適用於 QUIC 流量。 `load_balancing.cross_zone.enabled` 表示是否已啟用跨區域負載平衡。此值為 `true`、`false` 或 `use_load_balancer_configuration`。預設值為 `use_load_balancer_configuration`。 `preserve_client_ip.enabled` 指示是否啟用用戶端 IP 保留。此值為 `true` 或 `false`。如果目標群組類型為 IP 地址，且目標群組通訊協定為 TCP 或 TLS，則預設會停用。否則預設會啟用。無法停用 UDP、TCP\_UDP、QUIC 和 TCP\_QUIC 目標群組的用戶端 IP 保留。 `proxy_protocol_v2.enabled` 顯示是否已啟用 Proxy Protocol 第 2 版。預設會停用 Proxy Protocol。 `stickiness.enabled` 指出是否已啟用黏性工作階段。此值為 `true` 或 `false`。預設值為 `false`。此屬性不適用於 QUIC 流量。 `stickiness.type` 黏性的類型。可能的值為 `source_ip`。 `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`。 `target_health_state.unhealthy.connection_termination.enabled` 指出負載平衡器是否終止與運作運作狀態不佳目標的連線。此值為 `true` 或 `false`。預設值為 `true`。 `target_health_state.unhealthy.draining_interval_seconds` Elastic Load Balancing 在將運作狀態不佳的目標狀態從 變更為 `unhealthy.draining` 之前等待的時間量`unhealthy`。範圍為 0-360000 秒。預設值為 0 秒。 **注意：**只有在 `target_health_state.unhealthy.connection_termination.enabled`為 時，才能設定此屬性`false`。 ## 目標群組運作狀態 依預設，只要目標群組至少有一個運作狀態良好的目標，就會被視為運作狀態良好。如果您擁有龐大的機群，則只有一個運作狀態良好的目標服務流量是不夠的。相反地，您可以指定必須為運作狀態良好的目標最小計數或百分比，以及當運作狀態良好目標低於指定臨界值時，負載平衡器會採取哪些動作。這可改善應用程式的可用性。 **Topics** + [運作運作狀態不佳](#unhealthy-state-actions) + [需求和考量事項](#target-group-health-considerations) + [範例](#target-group-health-examples) + [針對您的負載平衡器使用 Route 53 DNS 備援](#r53-dns-failover) ### 運作運作狀態不佳 您可以針對下列動作設定運作狀態良好的臨界值： + **DNS 容錯移轉** – 當區域中運作狀態良好的目標低於閾值時，我們會將該區域的負載平衡器節點 IP 地址標記為 DNS 運作狀態不佳。因此，當用戶端解析負載平衡器 DNS 名稱時，流量只會路由至運作狀態良好的區域。 + **路由容錯移轉** – 當區域中運作狀態良好的目標低於閾值時，負載平衡器會將流量傳送至負載平衡器節點可用的所有目標，包括運作狀態不佳的目標。這會增加用戶端連線成功的機會，尤其是當目標暫時無法通過運作狀態檢查時，並降低運作狀態良好目標超載的風險。 ### 需求和考量事項 + 如果您為動作指定兩種類型的臨界值 (計數和百分比)，則當違反任一臨界值時，負載平衡器會採取動作。 + 如果您指定這兩個動作的臨界值，DNS 備援的臨界值必須大於或等於路由容錯移轉的臨界值，以便 DNS 備援發生在路由容錯移轉或之前。 + 如果您將臨界值指定為百分比，我們會根據向目標群組註冊的目標總數來動態計算值。 + 目標總數取決於是關閉還是開啟跨區域負載平衡。如果關閉跨區域負載平衡，則每個節點只會將流量傳送到其自身區域中的目標，這代表臨界值會分別套用至每個已啟用區域中的目標數目。如果開啟跨區域負載平衡，則每個節點會將流量傳送到所有已啟用區域中的所有目標，這代表指定的臨界值會套用至所有已啟用區域中的目標總數。如需詳細資訊，請參閱[跨區域負載平衡](edit-target-group-attributes.md#target-group-cross-zone)。 + 發生 DNS 容錯移轉時，會影響與負載平衡器相關聯的所有目標群組。確保剩餘區域中有足夠的容量來處理這些額外的流量，尤其是在跨區域負載平衡關閉的情況下。 + 使用 DNS 容錯移轉時，我們會將運作狀態不佳區域的 IP 地址從負載平衡器的 DNS 主機名稱中移除。不過，本機用戶端 DNS 快取可能會包含這些 IP 地址，直到 DNS 記錄中的存活期 (TTL) 到期 (60 秒) 為止。 + 使用 DNS 容錯移轉時，如果有多個目標群組連接到 Network Load Balancer，且一個目標群組在區域中運作狀態不佳，則即使另一個目標群組在該區域中運作狀態良好，也會發生 DNS 容錯移轉。 + 使用 DNS 備援時，如果將所有負載平衡器區域視為運作狀態不佳，負載平衡器會將流量傳送到所有區域，包括運作狀態不佳的區域。 + 除了是否有足夠運作狀態良好的目標可能導致 DNS 備援之外，還有其他因素，例如區域的運作狀況。 ### 範例 以下範例示範如何套用目標群組運作狀態設定。 **案例** + 支援 A 和 B 兩個可用區域的負載平衡器 + 每個可用區域包含 10 個已註冊目標 + 目標群組具有下列目標群組運作狀態設定： + DNS 備援 - 50% + 路由容錯移轉 - 50% + 可用區域 B 中有六個目標失敗 ![針對兩個區域啟用負載平衡器。AZ A 有 10 個運作狀態良好的目標，AZ B 有 4 個運作狀態良好的目標和 6 個運作狀態不佳的目標。](http://docs.aws.amazon.com/zh_tw/elasticloadbalancing/latest/network/images/tg-health-example.png) **如果停用跨區域負載平衡** + 每個可用區域中的負載平衡器節點只能將流量傳送到其可用區域中的 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 會引導流量到可用的主要負載平衡器，或是次要負載平衡器。 **評估目標運作狀態的運作方式** + 如果 Network Load Balancer 的別名記錄`Yes`上的評估目標運作狀態設為 ，Route 53 會評估`alias target`值指定的資源運作狀態。Route 53 使用目標群組運作狀態檢查。 + 如果連接至 Network Load Balancer 的所有目標群組都正常運作，Route 53 會將別名記錄標記為正常運作。如果您已設定目標群組的閾值，且符合其閾值，則會通過運作狀態檢查。否則，如果目標群組包含至少一個運作狀態良好的目標，則會通過運作狀態檢查。如果運作狀態檢查通過，Route 53 會根據您的路由政策傳回記錄。如果使用容錯移轉路由政策，Route 53 會傳回主要記錄。 + 如果連接至 Network Load Balancer 的所有目標群組運作狀態不佳，別名記錄會失敗 Route 53 運作狀態檢查 （故障開啟）。如果使用 評估目標運作狀態，這會導致容錯移轉路由政策將流量重新導向至次要資源。 + 如果 Network 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