Elastic Load Balancing 常見問答集

Application Load Balancer 可在 Amazon EC2 服務目前所支援的任何作業系統支援目標。

Application Load Balancer 支援對使用 HTTP 和 HTTPS (安全 HTTP) 協定的應用程式執行負載平衡。

是。Application Load Balancer 原本就已啟用 HTTP/2 支援。支援 HTTP/2 的用戶端可以透過 TLS 連接到 Application Load Balancer。

您可以轉送來自 Network Load Balancer 的流量，此工具依可用區域提供 PrivateLink 與靜態 IP 位址支援給 Application Load Balancer。建立 Application Load Balancer 類型目標群組、將您的 Application Load Balancer 註冊到該群組，然後將 Network Load Balancer 設定為轉送流量至 Application Load Balancer 類型目標群組。

您可以為下列 TCP 連接埠執行負載平衡：1-65535

是。Application Load Balancer 原本就已提供 WebSocket 和安全 WebSocket 支援，且隨時可以使用。

是。Application Load Balancer 預設會啟用請求追蹤。

儘管有一些重疊，但這兩種類型的負載器之間沒有相同的功能。Application Load Balancer 是我們未來應用程式層負載平衡平台的基礎。

是。

是。

否。Application Load Balancer 需要一組新的應用程式介面 (API)。

ELB 主控台可讓您從相同的界面管理 Application Load Balancer 和 Classic Load Balancer。如果您使用 命令列介面 (CLI) 或軟體開發套件 (SDK)，則需要在 Application Load Balancer 使用不同的「服務」。例如，在 CLI 中，您將使用 `aws elb describe-load-balancers` 描述 Classic Load Balancer，並使用 `aws elbv2 describe-load-balancers` 描述 Application Load Balancer。

否。您無法將負載平衡器從一種類型轉換成另一種類型。

是。您可以使用本文件所列的其中一個選項，從 Classic Load Balancer 遷移到 Application Load Balancer。

否。如果您需要 Layer-4 功能，則應該使用 Network Load Balancer。

是，您可以在單一 Application Load Balancer 新增 HTTP 連接埠 80 和 HTTPS 連接埠 443 的接聽程式。

是。要取得從您的帳戶發出的應用程式負載平衡 API 呼叫歷史記錄，請使用 AWS CloudTrail。

是。您可以在 Application Load Balancer 上終止 HTTPS 連接。您必須在負載平衡器上安裝 Secure Sockets Layer (SSL) 憑證。負載平衡器使用此憑證終止連接，然後解密用戶端的請求，再將它們傳送到目標。

您可以使用 AWS Certificate Manager 佈建 SSL/TLS 憑證，或者透過下列步驟從其他來源取得憑證：建立憑證請求、取得由 CA 簽署的憑證請求，然後使用 AWS Certification Manager 或 AWS Identity and Access Management (IAM) 服務上傳憑證。

Application Load Balancer 已與 AWS Certificate Management (ACM) 整合。與 ACM 的整合簡化了將憑證繫結到負載平衡器的程序，從而簡化了整個 SSL 卸載程序。購買、上傳和續約 SSL/TLS 憑證是複雜而耗時的手動程序。ACM 與 Application Load Balancer 整合之後，這整個程序已簡化為只要請求信任的 SSL/TLS 憑證，然後選取 ACM 憑證就能將它佈建到負載平衡器。

否，Application Load Balancer 僅支援後端加密。

當您將一個以上的 TLS 憑證關聯到負載平衡器上相同的安全接聽程式時，就會自動啟用 SNI。同樣地，當您只將一個憑證關聯到一個安全接聽程式時，則安全接聽程式的 SNI 模式就會自動停用。

是，您可以將相同網域的多個憑證關聯到一個安全接聽程式。例如，您可以關聯以下憑證：

• ECDSA 和 RSA 憑證
• 針對 SSL/TLS 憑證使用含有不同金鑰大小 (例如，2K 和 4K) 的憑證
• 單一網域、多個網域 (SAN) 和萬用字元憑證

是，Application Load Balancer 支援 IPv6。

您可以為負載平衡器上的每個接聽程式設定規則。這些規則包含條件，以及滿足這些條件時的對應動作。支援的條件包括主機標頭、路徑、HTTP 標頭、方法、查詢參數和來源 IP 無類別網域間路由 (CIDR)。支援的動作包括重新導向、固定回應、驗證和轉發。設定完成之後，負載平衡器會使用規則判斷應如何路由特定 HTTP 請求。您可以在原則中使用多個條件和動作，而且可在每個條件中指定多個值的相符項目。

您的 AWS 帳戶會提供這些 Application Load Balancer 限制。

您可將 Application Load Balancer 與 AWS Web Application Firewall (WAF) 整合，AWS WAF 是一種 Web 應用程式防火牆，可讓您根據 IP 位址、HTTP 標頭和自訂統一資源識別符 (URI) 字串來設定規則，協助保護 Web 應用程式不受攻擊。AWS WAF 可使用這些規則封鎖、允許或監控 (計算) Web 應用程式的 Web 請求。如需詳細資訊，請參閱 AWS WAF 開發人員指南。

您可以使用來自負載平衡器 VPC 內目標的負載平衡器 VPC CIDR 的任何 IP 位址，以及來自位於負載平衡器 VPC 外部目標 (例如，可透過 AWS Direct Connect 或 VPN 連接進行連線之對等 VPC、Amazon EC2 Classic 及內部部署位置的目標) 的 RFC 1918 範圍 (10.0.0.0/8、172.16.0.0/12 及 192.168.0.0/16) 或 RFC 6598 範圍 (100.64.0.0/10) 的任何 IP 位址。

有多種方式可以達到混合負載平衡目的。如果應用程式於分散在 VPC 和現場部署位置的目標上執行，您可以使用它們的 IP 地址將它們新增至相同的目標群組。若要在不影響應用程式的情況下遷移至 AWS，請以逐步新增方式將 VPC 目標新增至目標群組，然後將現場部署目標從目標群組中移除。 

如果您有兩個不同的應用程式，其中一個應用程式的目標位於 VPC，另一個應用程式的目標位於現場部署位置，您可以將 VPC 目標放在一個目標群組，將現場部署目標放在另一個目標群組，然後使用以內容為基礎的路由功能，將流量路由到每個目標群組。您也可以針對 VPC 和現場部署目標使用個別的負載平衡器，以及在 VPC 和現場部署目標之間使用 DNS 加權來實現加權負載平衡。

將 EC2-Classic 執行個體的執行個體 ID 註冊為目標時，無法對這些執行個體進行負載平衡。但是，如果您使用 ClassicLink 將這些 EC2-Classic 執行個體連結至負載平衡器的 VPC，然後使用這些 EC2-Classic 執行個體的私有 IP 做為目標，就可以對 EC2-Classic 執行個體進行負載平衡。如果您目前使用 EC2 Classic 執行個體搭配 Classic Load Balancer，可以輕鬆地遷移至 Application Load Balancer。

Application Load Balancer 已預設為啟用跨區域負載平衡。

您應該在下列情況下，透過 Amazon Cognito 進行身份驗證：

• 您想為使用者提供彈性，透過社交網路身分 (Google、Facebook 和 Amazon) 或企業身分 (SAML) 來驗證身分，或者透過 Amazon Cognito 使用者集區所提供您自己的使用者目錄。
• 您管理多個身分供應商 (包含 OpenID Connect)，但想在 Application Load Balancer (ALB) 建立單一身份驗證規則，以使用 Amazon Cognito 來聯合您的多個身分供應商。
• 您需要從一個集中的位置主動管理含有一或多個社交或 OpenID Connect 身分供應商的使用者設定檔。例如，您可以將使用者分成群組，然後新增自訂屬性代表使用者狀態，以及控制付費使用者的存取。

或者，如果您已投資在開發自訂 IdP 解決方案，且只想要透過與 OpenID Connect 相容的單一身分供應商來驗證身分，則可使用 Application Load Balancer 原生 OIDC 解決方案。

支援以下三種重新導向類型。

HTTP 到 HTTP
http://hostA 到 http://hostB

HTTP 到 HTTPS
http://hostA 到 https://hostB
https://hostA:portA/pathA 到 https://hostB:portB/pathB

HTTPS 到 HTTPS
https://hostA 到 https://hostB

支援以下內容類型：text/plain、text/css、text/html、application/javascript、application/json。

負載平衡器收到的 HTTP(S) 請求是由內容型路由規則處理。如果請求內容與規則匹配 (透過 Lambda 函數將其轉送到目標群組作為目標的操作)，則叫用相應的 Lambda 函數。請求的內容 (包括標頭和內文) 以 JavaScript Object Notation (JSON) 格式傳送至 Lambda 函數。來自 Lambda 函數的回應應該採用 JSON 格式。來自 Lambda 函數的回應會轉換為 HTTP 回應，並傳送至用戶端。負載平衡器會使用 AWS Lambda 呼叫 API，來呼叫您的 Lambda 函數，而且需要您已將 Lambda 函數的呼叫許可提供給 Elastic Load Balancing 服務。

是。Application Load Balancer 支援對同時透過 HTTP 和 HTTPS 通訊協定的請求進行 Lambda 呼叫。

您可在美國東部 (維吉尼亞北部)、美國東部 (俄亥俄)、美國西部 (加利佛尼亞北部)、美國西部 (奧勒岡)、亞太地區 (孟買)、亞太地區 (首爾)、亞太地區 (新加坡)、亞太地區 (雪梨)、亞太地區 (東京)、加拿大 (中部)、歐洲 (法蘭克福)、歐洲 (愛爾蘭)、歐洲 (倫敦)、歐洲 (巴黎)、南美洲 (聖保羅)，以及 GovCloud (美國西部) AWS 區域，使用 Lambda 做為目標與 Application Load Balancer 搭配。

是，Application Load Balancer 於洛杉磯本地區域提供。在洛杉磯本地區域內，Application Load Balancer 會在單一子網路內營運並自動擴展，以符合不同的應用程式負載程度，不必手動介入。

我們按 Application Load Balancer 執行小時數及每小時使用的負載平衡器容量單位 (LCU) 數計算，不足一小時按一小時計費。

LCU 是決定 Application Load Balancer 付費方式的新指標。LCU 可定義 Application Load Balancer 處理流量時在各定價方式 (新連線、作用中連線、頻寬和規則評估) 消耗的最高資源量。

否，Classic Load Balancer 將持續以頻寬和每小時用量計費。

我們透過 Amazon CloudWatch 公開四個組成 LCU 的維度用量。

否。每小時的 LCU 數是依據組成 LCU 的四種定價方式中最高的資源消耗量計費。

是。

是。對於新的 AWS 帳戶，Application Load Balancer 免費方案提供 750 小時和 15 個 LCU。此免費方案僅適用於 AWS 新客戶，註冊 AWS 後的 12 個月內均可使用。

是。您可以同時使用 Classic 和 Application Load Balancer，且可個別使用 15 GB 和 15 個 LCU。750 個負載平衡器小時數則由 Classic 和 Application Load Balancer 共用。

規則評估的算法是將處理的規則數量乘以一個小時的平均請求率。

以 LCU 運算計費時，憑證金鑰大小只會影響每秒新連線數。下表針對不同 RSA 和 ECDSA 憑證金鑰大小列出此計費方式的值。

RSA 憑證
金鑰大小：<=2K 
新連線/秒：25

金鑰大小：<=4K 
新連線/秒： 5

金鑰大小：<=8K 
新連線/秒： 1

金鑰大小： >8K
新連線/秒： 0.25

ECDSA 憑證
金鑰大小： <=256
新連線/秒：25

金鑰大小： <=384
新連線/秒： 5

金鑰大小： <=521 
新連線/秒： 1

金鑰大小： >521 
新連線/秒： 0.25

否。由於 Application Load Balancer 的跨區域負載平衡一直處於開啟狀態，您不需支付此類型的區域資料傳輸費用。

否。在 Application Load Balancer 啟用身份驗證功能無須另外付費。使用 Amazon Cognito 搭配 Application Load Balancer 時，需支付 Amazon Cognito 定價。

我們一如往常按 Application Load Balancer 執行小時數及每小時使用的負載平衡器容量單位 (LCU) 數計算，不足一小時按一小時計費。對於 Lambda 目標，每個 LCU 提供每小時 0.4 GB 已處理位元組、每秒 25 個新連線、每分鐘 3,000 個作用中連線，以及每種 1000 個規則評估。對於已處理位元組維度，每個 LCU 為 Lambda 目標提供每小時 0.4 GB，而為所有其他目標 (如 Amazon EC2 執行個體、容器和 IP 地址) 提供每小時 1GB。請注意，平常的 AWS Lambda 計費適用於 Application Load Balancer 進行的 Lambda 呼叫。

Application Load Balancer 發出兩個新的 CloudWatch 指標。LambdaTargetProcessedBytes 指標表示 Lambda 目標處理的位元組，而 StandardProcessedBytes 指標表示所有其他目標類型處理的位元組。

是。Network Load Balancer 同時支援 TCP、UDP 和 TCP+UDP (Layer 4) 接聽程式，也支援 TLS 接聽程式。

Network Load Balancer 提供 TCP 和 UDP (Layer 4) 負載平衡。其架構每秒可處理數百萬個請求、突然變化的流量模式，以及提供極低的延遲。此外，Network Load Balancer 還支援 TLS 終止，保留用戶端的來源 IP，並提供穩定的 IP 支援和可用區域隔離。同時還支援對 WebSocket 類型應用程式實用的長時間執行連線。

是。要這麼做，您可以使用 TCP+UDP 接聽程式。例如，如果是使用 TCP 和 UDP 的 DNS 服務，您可以在連接埠 53 建立 TCP+UDP 接聽程式，負載平衡器就會處理該連接埠上的 UDP 和 TCP 請求流量。您必須將 TCP+UDP 接聽程式與 TCP+UDP 目標群組建立關聯。

Network Load Balancer 可保留用戶端的來源 IP，但在 Classic Load Balancer 中不保留。客戶可使用代理協定搭配 Classic Load Balancer 取得來源 IP。Network Load Balancer 自動為負載平衡器提供每個可用區域 (AZ) 的靜態 IP，同時在每個 AZ 為負載平衡器指派一個彈性 IP。Classic Load Balancer 不支援這些功能。

是。您可以使用本文件所列的其中一個選項，從 Classic Load Balancer 移轉到 Network Load Balancer。

是，請參閱 Network Load Balancer 限制文件以取得詳細資訊。

是，您可以使用 AWS 管理主控台、AWS CLI 或 API 設定 Network Load Balancer。

否。若要建立 Classic Load Balancer，請使用 2012-06-01 API。若要建立 Network Load Balancer 或 Application Load Balancer，請使用 2015-12-01 API。

是，建立負載平衡器時提供一個子網路，即可在單一 AZ 建立 Network Load Balancer。

是，您可以使用 Amazon Route 53 運作狀態檢查和 DNS 備援功能來增強在 Network Load Balancer 監管之下執行的應用程式可用性。使用 Route 53 DNS 備援，您可以在多個 AWS 可用區域執行應用程式，並跨區域指定備用負載平衡器以進行容錯移轉。 

在 Network Load Balancer 已設定異地同步備份的情況下，如果該 AZ 的負載平衡器沒有已註冊的運作狀態良好 Amazon EC2 執行個體，或者該區域的負載平衡器節點運作狀態不良，則 Route 53 會容錯移轉到其他運作狀態良好 AZ 的備用負載平衡器節點。

否。Network Load Balancer 地址只能由您完全掌控，或由 ELB 完全掌控。這樣才能確保在 Network Load Balancer 使用彈性 IP 時，用戶端已知的所有地址都不會改變。

否。在 Network Load Balancer 所在的每個關聯子網路，Network Load Balancer 只能支援一個與公有/網際網路面向的 IP 位址。

與負載平衡器關聯的彈性 IP 位址將會傳回您分配的集區以供日後使用。

您可以將 Network Load Balancer 設定為與網際網路連結的負載平衡器或內部負載平衡器，與 Application Load Balancer 和 Classic Load Balancer 類似。

否。在負載平衡器所在的每個關聯子網路，Network Load Balancer 只能支援一個私有 IP。

是，將 TCP 接聽程式設為將流量路由到實作 WebSockets 協定 (https://tools.ietf.org/html/rfc6455) 的目標。由於 WebSockets 是 layer 7 協定，而 Network Load Balancer 在 layer 4 運作，因此 Network Load Balancer 沒有處理 WebSockets 或其他較高級協定的特殊處理程序。

是。您可以使用來自負載平衡器 VPC 內目標的負載平衡器 VPC CIDR 的任何 IP 地址，以及來自位於負載平衡器 VPC 外部目標 (可透過 AWS Direct Connect 進行連線的 EC2-Classic 及現場部署位置) 的 RFC 1918 範圍 (10.0.0.0/8、172.16.0.0/12 及 192.168.0.0/16) 或 RFC 6598 範圍 (100.64.0.0/10) 的任何 IP 地址。IP 地址目標類型的負載平衡僅支援 TCP 接聽程式，目前不支援 UDP 接聽程式。

是，搭配 TCP 和 TLS 接聽程式的 Network Load Balancer 可用於設定 AWS PrivateLink。您不能在 Network Load Balancer 上透過 UDP 接聽程式設定 PrivateLink。

使用者資料包協定 (UDP) 沒有連線時，負載平衡器會根據 5-tuple 雜湊維持 UDP 流程狀態，確保相同內容中傳送的封包一致地轉送至相同的目標。只要流量持續流動，在閒置逾時到達前，該流程都視為作用中。一旦到達逾時閾值，負載平衡器就會捨棄親和性，而內送 UDP 封包將視為新流程並負載平衡至新目標。

Network Load Balancer 支援的 TCP 連線閒置逾時為 350 秒。UDP 流程的閒置逾時為 120 秒。

執行個體上的每個容器現在都可以擁有自己的安全群組，不需要和其他容器共享安全規則。您可以將安全群組連接至 ENI，且執行個體上的每個 ENI 都可以有不同的安全群組。您可以將容器對應至特定 ENI 的 IP 地址，以依據容器建立與安全群組的關聯。使用 IP 地址進行負載平衡也能夠讓在執行個體上執行的多個容器使用相同連接埠 (例如連接埠 80)。跨容器使用相同連接埠的能力可讓執行個體上的容器透過熟知的連接埠 (而非隨機連接埠) 互相通訊。

有多種方式可以達到混合負載平衡目的。如果應用程式於分散在 VPC 和現場部署位置的目標上執行，您可以使用它們的 IP 地址將它們新增至相同的目標群組。若要在不影響應用程式的情況下遷移至 AWS，請以逐步新增方式將 VPC 目標新增至目標群組，然後將現場部署目標從目標群組中移除。您也可以針對 VPC 和現場部署目標使用個別的負載平衡器，以及在 VPC 和現場部署目標之間使用 DNS 加權來實現加權負載平衡。

將 EC2-Classic 執行個體的執行個體 ID 註冊為目標時，無法對這些執行個體進行負載平衡。但是，如果您使用 ClassicLink 將這些 EC2-Classic 執行個體連結至負載平衡器的 VPC，然後使用這些 EC2-Classic 執行個體的私有 IP 做為目標，就可以對 EC2-Classic 執行個體進行負載平衡。如果您目前使用 EC2 Classic 執行個體搭配 Classic Load Balancer，可以輕鬆地遷移至 Network Load Balancer。

您只能在 Network Load Balancer 建立之後啟用跨區域負載平衡。要啟動此功能，編輯負載平衡屬性部分，然後選取跨區域負載平衡支援核取方塊。

是，啟用 Network Load Balancer 中的跨區域負載平衡，必須支付可用區域間的區域性資料傳輸費。請在 Amazon EC2 隨需定價頁面的資料傳輸費部分查看相關費用。

是。Network Load Balancer 目前每個可用區域支援 200 個目標。例如，如果您在 2 個 AZ，可在 Network Load Balancer 註冊最多 400 個目標。如果啟用跨區域負載平衡，則目標上限會從每個 AZ 200 個目標降低到每個負載平衡器 200 個目標。因此，在上述範例中，啟用跨區域負載平衡時，即使負載平衡器在 2 個 AZ，也只能在負載平衡器註冊 200 個目標。

是，您可以在 Network Load Balancer 上終止 TLS 連接。您必須在負載平衡器上安裝 SSL 憑證。負載平衡器使用此憑證終止連接，然後解密用戶端的請求，再將它們傳送到目標。

即使您在 Network Load Balancer 上終止 TLS，來源 IP 也會繼續保留。

您可以使用 AWS Certificate Manager 佈建 SSL/TLS 憑證，或者透過下列步驟從其他來源取得憑證：建立憑證請求、取得由憑證授權機構 (CA) 簽署的憑證請求，然後使用 AWS Certification Manager (ACM) 或 AWS Identity and Access Management (IAM) 服務上傳憑證。

當您將一個以上的 TLS 憑證關聯到負載平衡器上相同的安全接聽程式時，就會自動啟用 SNI。同樣地，當您只將一個憑證關聯到一個安全接聽程式時，則安全接聽程式的 SNI 模式就會自動停用。

Network Load Balancer 已與 AWS Certificate Management (ACM) 整合。與 ACM 整合可非常輕鬆地將憑證繫結到負載平衡器，進而讓整個 SSL 卸載程序更加容易。購買、上傳和續約 SSL/TLS 憑證是耗時而複雜的手動程序。ACM 與 Network Load Balancer 整合之後，這整個程序已簡化為只要請求信任的 SSL/TLS 憑證，然後選取 ACM 憑證就能將它佈建到負載平衡器。建立 Network Load Balancer 後，您可以立即設定 TLS 接聽程式，然後選擇從 ACM 或 Identity Access Manager (IAM) 選取憑證。此體驗類似於您在 Application Load Balancer 或 Classic Load Balancer 中進行的體驗。

否，Network Load Balancer 僅支援後端加密。

Network Load Balancer 僅支援 2K 金鑰大小的 RSA 憑證。我們目前不支援大於 2K 的 RSA 憑證金鑰大小或 Network Load Balancer 上的 ECDSA 憑證。

您可在美國東部 (維吉尼亞北部)、美國東部 (俄亥俄)、美國西部 (加利佛尼亞北部)、美國西部 (奧勒岡)、亞太地區 (孟買)、亞太地區 (首爾)、亞太地區 (新加坡)、亞太地區 (雪梨)、亞太地區 (東京)、加拿大 (中部)、歐洲 (法蘭克福)、歐洲 (愛爾蘭)、歐洲 (倫敦)、歐洲 (巴黎)、南美洲 (聖保羅)，以及 GovCloud (美國西部) AWS 區域，使用 Network Load Balancer 上的 TLS 終止。

我們按 Network Load Balancer 執行小時數及 Network Load Balancer 每小時使用的負載平衡器容量單位 (LCU) 數計算，不足一小時按一小時計費。

LCU 是決定 Network Load Balancer 付費方式的新指標。LCU 可定義 Network Load Balancer 處理流量時在各定價方式 (新連線/流程、作用中連線/流程和頻寬) 消耗的最高資源量。

TCP 流量的 LCU 指標如下：

• 每秒 800 個新 TCP 連線。
• 100,000 個作用中 TCP 連線 (每分鐘採樣)。
• 若以 Amazon EC2 執行個體、容器和 IP 地址做為目標，每小時 1 GB。

UDP 流量的 LCU 指標如下：

• 每秒 400 個新流程。
• 50,000 個作用中 UDP 流程 (每分鐘採樣)。
• 若以 Amazon EC2 執行個體、容器和 IP 地址做為目標，每小時 1 GB。

TLS 流量的 LCU 指標如下：

• 每秒 50 個新 TLS 連線。
• 3,000 個作用中 TLS 連線 (每分鐘採樣)。
• 若以 Amazon EC2 執行個體、容器和 IP 地址做為目標，每小時 1 GB。

否，針對每個協定，在上述三種方式中，我們只會以該小時用量最高的其中一種方式收取費用。

否。單一連線可傳送多個請求。

否。Classic Load Balancer 將持續以頻寬和每小時用量計費。

我們將透過 Amazon CloudWatch 公開組成 LCU 的三種定價方式用量。

否。每小時的 LCU 數是依據組成 LCU 的三種定價方式中最高的資源消耗量計費。

是。

是。對於新的 AWS 帳戶，Network Load Balancer 免費方案提供 750 小時和 15 個 LCU。此免費方案僅適用於 AWS 新客戶，註冊 AWS 後的 12 個月內均可使用。

是。您可以在 Application 和 Network 個別使用 15 個 LCU，Classic 則可使用 15 GB。750 個負載平衡器小時數則由 Application、Network 和 Classic Load Balancer 共用。

在部署網路流量不流向 Gateway Load Balancer 本身的內嵌虛擬設備時，應使用 Gateway Load Balancer。Gateway Load Balancer 透過第三方虛擬設備透明地傳遞所有 Layer 3 流量，並且對於流量的來源和目的地不可見。如需進一步了解這些負載平衡器的差異，請參閱功能比較頁面。

Gateway Load Balancer 在一個 AZ 中執行。

Gateway Load Balancer 提供 Layer 3 閘道和 Layer 4 負載平衡功能。它是一種透明的內嵌裝置，不會變更封包的任何部分。其架構每秒可處理數百萬個請求、變化的流量模式，以及提供極低的延遲。請參閱此資料表中的 Gateway Load Balancer 功能。 

Gateway Load Balancer 不執行 TLS 終止，也不維護任何應用程式狀態。這些功能由其將流量導向到的第三方虛擬設備和向其傳送流量的第三方虛擬設備執行。

Gateway Load Balancer 不維護應用程式狀態，但會使用 5 元組 (針對 TCP/UDP 流量) 或 3 元組 (針對非 TCP/UDP 流量) 來維持流向特定設備的流量粘性。

依預設，Gateway Load Balancer 將流量定義為由來源 IP、目的地 IP、IP 協定、來源連接埠和目標連接埠組成的 5 元組組合。Gateway Load Balancer 預設使用 5 元組雜湊確保該流量的兩個方向 (即來源到目的地和目的地到來源) 一致轉發到同一目標。只要流量持續流動，在閒置逾時到達前，該流程都視為作用中。一旦到達逾時閾值，負載平衡器就會捨棄親和性，而內送琉璃封包將視為新流程並可能負載平衡至新目標。

預設的 5 元組 (來源 IP、目的地 IP、IP 協定、來源連接埠和目的地連接埠) 黏性能為目標提供最佳流量分配，並且適用於大多數 TCP 和 UDP 型應用程式，但某些例外狀況除外。預設的 5 元組黏性不適用於 TCP 或 UDP 型應用程式，這些應用程式會對控制和資料使用單獨的串流或連接埠號碼，例如 FTP、Microsoft RDP、Windows RPC 和 SSL VPN。此類應用程式的控制的資料流量可能會落在不同的目標設備上，並可能導致流量中斷。如果您想要支援此類協定，應使用 3 元組 (來源 IP、目的地 IP、IP 協定) 或 2 元組 (來源 IP、目的地 IP、IP 協定) 啟用 GWLB 流量黏性。

有些應用程式根本不使用 TCP 或 UDP 傳輸，而是使用 SCTP 和 GRE 等 IP 協定。使用 GWLB 的預設 5 源組黏性，協定流量可能會落在不同的目標設備上，並且可能會導致中斷。如果您想要支援此類協定，應使用 3 元組 (來源 IP、目的地 IP、IP 協定) 或 2 元組 (來源 IP、目的地 IP、IP 協定) 啟用 GWLB 流量黏性。

請參閱流量黏性文件，以了解如何變更流量黏性類型。

Gateway Load Balancer 支援的 TCP 連線閒置逾時為 350 秒。非 TCP 流程的閒置逾時為 120 秒。這些逾時是固定的，無法變更。

GWLB 做為電纜中的透明塊，本身不會碎片化或重新組裝封包。

GWLB 將 UDP 片段來回轉傳至目標設備。但是，GWLB 會捨棄 TCP 和 ICMP 片段，因為這些片段中不存在第 4 層標頭。

此外，如果目標裝置將原始傳入封包轉換為片段，並將新建立的片段傳回 GWLB，GWLB 會捨棄這些新建立的片段，因為它們不包含第 4 層標頭。為防止目標設備上發生碎片化，建議在目標設備上啟用 Jumbo Frame 或將目標設備的網路介面設定為使用所需的最大 MTU，從而透過保持原始封包內容不變來實現透明轉傳行為。 

當單個虛擬設備執行個體發生故障時，Gateway Load Balancer 會將其從路由清單中移除，然後將流量重新路由到正常運作的設備執行個體。

如果某個可用區域中的所有虛擬設備均發生故障，則 Gateway Load Balancer 將丟棄網路流量。我們建議在多個 AZ 中部署 Gateway Load Balancer 以提高可用性。如果某個 AZ 中的所有設備均發生故障，則可以使用指令碼來新增新設備，或將流量導向到另一個 AZ 中的 Gateway Load Balancer。

是的，多個 Gateway Load Balancer 可以指向同一組虛擬設備。

Gateway Load Balancer 是一種透明的內嵌裝置，可以偵聽所有類型的 IP 流量 (包括 TCP、UDP、ICMP、GRE、ESP 等)。因此，僅在 Gateway Load Balancer 上建立 IP 接聽程式。

是，請參閱 Gateway Load Balancer 限制文件以取得詳細資訊。

是，您可以使用 AWS 管理主控台、AWS CLI 或 API 設定 Gateway Load Balancer。

是，建立負載平衡器時提供一個子網路，即可在單一可用區域建立 Gateway Load Balancer。但是，我們建議使用多個可用區來提高可用性。建立好 Gateway Load Balancer 後，您無法為其新增或刪除可用區域。

依預設，會停用跨區域負載平衡。您只能在 Gateway Load Balancer 建立之後啟用跨區域負載平衡。要啟動此功能，編輯負載平衡屬性部分，然後選取跨區域負載平衡支援核取方塊。

是，啟用 Gateway Load Balancer 中的跨區域負載平衡，必須支付可用區域間的資料傳輸費。請在 Amazon EC2 隨需定價頁面的資料傳輸費部分查看相關費用。

是。Gateway Load Balancer 目前每個可用區域支援 300 個目標。例如，如果您在 3 個可用區域中建立了 Gateway Load Balancer，則您可註冊最多 900 個目標。如果啟用跨區域負載平衡，則目標數量上限會從每個可用區域 300 個目標降低到每個 Gateway Load Balancer 300 個目標。

我們按 Gateway Load Balancer 執行小時數及 Gateway Load Balancer 每小時使用的負載平衡器容量單位 (LCU) 數計算，不足一小時按一小時計費。

LCU 是決定 Gateway Load Balancer 付費方式的 Elastic Load Balancing 指標。LCU 可定義 Gateway Load Balancer 處理流量時在各定價方式 (新連線/流程、作用中連線/流程和頻寬) 消耗的最高資源量。

TCP 流量的 LCU 指標如下：

• 每秒 600 個新流程 (或連線)。
• 60,000 個作用中流程 (連線) (每分鐘採樣)。
• 若以 EC2 執行個體、容器和 IP 地址做為目標，每小時 1 GB。

否，在上述三種方式中，我們只會以該小時用量最高的其中一種方式收取費用。

否。單一連線可傳送多個請求。

您可以透過 Amazon CloudWatch 追蹤 LCU 的所有三種維度用量。

是。

為了具有價值，虛擬設備需要引入儘可能少的延遲，並且往返虛擬設備的流量必須使用安全連線。Gateway Load Balancer 端點可建立滿足這些要求的低延遲安全連線。

使用 Gateway Load Balancer 端點時，設備可以駐留在不同的 AWS 帳戶和 VPC 中。這允許將設備集中在一個位置，以簡化管理並減少操作開銷。

Gateway Load Balancer 端點是使用 PrivateLink 技術的新型 VPC 端點。當網路流量從來源 (網際網路閘道、VPC 等) 流向 Gateway Load Balancer 再返回時，Gateway Load Balancer 端點可確保兩者之間使用私有連線。所有流量流經 AWS 網路，並且資料永遠不會公開到網際網路中，從而提高安全性和效能。

PrivateLink 界面端點與 Network Load Balancer (NLB) 配合，以便分發發往 Web 應用程式的 TCP 和 UDP 流量。而 Gateway Load Balancer 端點與 Gateway Load Balancer 搭配使用，以連接流量的來源和目的地。流量透過虛擬設備從 Gateway Load Balancer 端點流向 Gateway Load Balancer ，然後透過安全的 PrivateLink 連線流回目的地。

Gateway Load Balancer 端點是一個 VPC 端點，並沒有限制可以連接多少個 VPC 端點到使用 Gateway Load Balancer 的服務。然而，我們建議每個 Gateway Load Balancer 不要連接超過 50 個 Gateway Load Balancer 端點，以在服務失敗時降低產生更廣泛影響的風險。

Classic Load Balancer 可在 Amazon EC2 服務目前所支援的任何作業系統上支援 Amazon EC2 執行個體。

Classic Load Balancer 支援對使用 HTTP、HTTPS (安全 HTTP)、SSL (安全 TCP) 和 TCP 協定的應用程式執行負載平衡。

您可以為下列 TCP 連接埠執行負載平衡：

• [EC2-VPC] 1-65535
• [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535

是。每個 Classic Load Balancer 都有一個關聯的 IPv4、IPv6，以及雙協議棧 (IPv4 和 IPv6) DNS 名稱。VPC 不支援 IPv6。您可以使用 Application Load Balancer 為 VPC 提供原生 IPv6 支援。

是。

如果您使用的是 Amazon Virtual Private Cloud，則可以為 Classic Load Balancer 的前端設定安全群組。

是，您可以將 HTTP 連接埠 80 和 HTTPS 連接埠 443 對應到單一 Classic Load Balancer。

Classic Load Balancer 並不為其可以嘗試與您已負載平衡的 Amazon EC2 執行個體建立的連接數設置上限。您會發現此數值會隨著並行 HTTP、HTTPS 或 SSL 請求的數量，或者 Classic Load Balancer 收到的並行 TCP 連接數而擴展。

您可以從 AWS Marketplace 對使用已支付 AMI 啟動的 Amazon EC2 執行個體執行負載平衡。但是，Classic Load Balancer 不支援從 Amazon DevPay 網站使用已支付 AMI 啟動的執行個體。

是。請參閱 Elastic Load Balancing 網頁。

是。要收到從您的帳戶發出的所有 Classic Load Balancer API 呼叫的歷史記錄，只需在 AWS 管理主控台中開啟 CloudTrail 即可。

是，您可以在 Classic Load Balancer 上終止 SSL。您必須在每個負載平衡器上安裝 SSL 憑證。負載平衡器使用此憑證終止連接，然後解密用戶端的請求，再將它們傳送到後端執行個體。

您可以使用 AWS Certificate Manager 佈建 SSL/TLS 憑證，或者透過下列步驟從其他來源取得憑證：建立憑證請求、取得由 CA 簽署的憑證請求，然後使用 AWS Identity and Access Management (IAM) 服務上傳憑證。

Classic Load Balancer 現在已與 AWS Certificate Management (ACM) 整合。與 ACM 整合可非常輕鬆地將憑證繫結到每個負載平衡器，進而讓整個 SSL 卸載程序更加容易。購買、上傳和續約 SSL/TLS 憑證通常是耗時而複雜的手動程序。ACM 與 Classic Load Balancer 整合之後，這整個程序已簡化為只要請求信任的 SSL/TLS 憑證，然後選取 ACM 憑證就能將它佈建到每個負載平衡器。

您可以使用主控台、AWS CLI 或 AWS SDK 啟用跨區域負載平衡。如需詳細資訊，請參閱 Cross-Zone Load Balancing 文件。

否，啟用 Classic Load Balancer 中的跨區域負載平衡，無須支付可用區域間的區域性資料傳輸費。