從網際網路接收 Amazon ECS 傳入連線的最佳實務 - Amazon Elastic Container Service

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

從網際網路接收 Amazon ECS 傳入連線的最佳實務

如果執行公有服務,則必須接受來自網際網路的傳入流量。例如,公有網站必須接受來自瀏覽器的傳入 HTTP 請求。在這種情況下,網際網路上的其他主機也必須啟動與應用程式主機的傳入連線。

解決此問題的一個方案,是在具有公有 IP 位址的公有子網路中的主機上啟動容器。不過,我們不建議將此方案用於大規模應用程式。對於這類應用程式,更優的方案是在網際網路與您的應用程式之間,部署一個可擴展的輸入層。採用此方案時,您可以使用本節所列的任一 AWS 服務作為輸入層。

Application Load Balancer

Application Load Balancer 在應用程式層運作。這是開放式系統互連 (OSI) 模型的第七層。此特性使得 Application Load Balancer 適用於公有 HTTP 服務。若您擁有網站或 HTTP REST API,則 Application Load Balancer 是適合此工作負載的負載平衡器。如需詳細資訊,請參閱 User Guide for Application Load Balancers 中的 What is an Application Load Balancer? 章節。

此圖表顯示使用 Application Load Balancer 的網路架構。

您可以使用此架構在公有子網路中建立 Application Load Balancer,使其具有公有 IP 位址,並可接收來自網際網路的傳入連線。當 Application Load Balancer 收到傳入連線 (更具體地說為 HTTP 請求) 時,會透過私有 IP 位址與應用程式建立連線。接著,該服務會透過這條內部連線轉送該請求。

Application Load Balancer 具備以下優勢。

  • SSL/TLS 終止:Application Load Balancer 可維持與用戶端通訊所需的安全 HTTPS 通訊及憑證。您可選擇在負載平衡器層級終止 SSL 連線,無需在自身應用程式中處理憑證。

  • 進階路由:Application Load Balancer 可以具有多個 DNS 主機名稱。其還具有進階路由功能,可根據主機名稱或請求路徑等指標,將傳入的 HTTP 請求傳送至不同的目的地。這表示您可以使用單一 Application Load Balancer 作為許多不同內部服務的輸入,甚至是 REST API 不同路徑上微服務的輸入。

  • gRPC 支援與 Websocket:Application Load Balancer 可處理的不僅限於 HTTP。其也能在支援 HTTP/2 的基礎上,對 gRPC 與 WebSocket 服務進行負載平衡。

  • 安全性:Application Load Balancer 有助於保護您的應用程式免遭惡意流量攻擊。它包含 HTTP 取消同步緩解等功能,並與 AWS Web Application Firewall (AWS WAF) 整合。 AWS WAF 可以進一步篩選可能包含攻擊模式的惡意流量,例如 SQL Injection 或跨網站指令碼。

Network Load Balancer

Network Load Balancer 是在開放系統互連 (OSI) 模型的第四層運作。其適用於非 HTTP 通訊協定或需要端到端加密的案例,但不具備 Application Load Balancer 特有的 HTTP 相關功能。因此,Network Load Balancer 最適用於不使用 HTTP 協定的應用程式。如需詳細資訊,請參閱 User Guide for Network Load Balancers 中的 What is a Network Load Balancer? 章節。

此圖表顯示使用 Network Load Balancer 的網路架構。

使用 Network Load Balancer 作為輸入時,其運作方式與 Application Load Balancer 類似。這是因為其是在公有子網路中建立,且具有可在網際網路上存取的公有 IP 位址。然後,Network Load Balancer 會開啟與執行您容器之主機私有 IP 位址的連線,並將封包從公有端傳送至私有端。

Network Load Balancer 功能

由於 Network Load Balancer 運作於聯網堆疊的較底層,因此沒有與 Application Load Balancer 相同的功能集。不過,仍具備以下重要功能。

  • 端對端加密:由於 Network Load Balancer 在 OSI 模型的第四層運作,因此不會讀取封包的內容。這使其適用於需端對端加密的通訊負載平衡。

  • TLS 加密:除了端對端加密之外,Network Load Balancer 也可以終止 TLS 連線。如此,後端應用程式就無需自行實現 TLS 加密功能。

  • UDP 支援:由於 Network Load Balancer 在 OSI 模型的第四層運作,因此適用於非 HTTP 工作負載以及 TCP 以外的通訊協定。

關閉連線

由於 Network Load Balancer 未在 OSI 模型的較高層偵測到應用程式通訊協定,因此無法透過這些協定向用戶端傳送關閉訊息。與 Application Load Balancer 不同,這類連線需要由應用程式自行關閉;您也可以設定 Network Load Balancer,在任務停止或取代時關閉第四層連線。請參閱 Network Load Balancer documentation 中 Network Load Balancer 目標群組的連線終止設定。

若用戶端未妥善處理第四層連線終止,透過 Network Load Balancer 關閉連線可能導致用戶端顯示非預期的錯誤訊息。有關建議用戶端組態的詳細資訊,請參閱這裡的建置程式庫。

關閉連線的方法因應用程式而異,但其中一種方式是確保 Network Load Balancer 目標取消註冊延遲時間長於用戶端連線逾時設定。如此一來,用戶端會先逾時並透過 Network Load Balancer 優雅地重新連線至新任務,而舊任務則能逐步排空所有現有連線。如需有關 Network Load Balancer 目標取消註冊延遲的詳細資訊,請參閱 Network Load Balancer documentation

Amazon API Gateway HTTP API

Amazon API Gateway 適用於請求量突增或請求量偏低的 HTTP 應用程式。如需詳細資訊,請參閱 API Gateway Developer Guide 中的 What is Amazon API Gateway? 章節。

此圖表顯示使用 API Gateway 的網路架構。

Application Load Balancer 與 Network Load Balancer 的定價模式,均包含讓負載平衡器隨時保持可用以接收傳入連線的每小時費用。與之相對,API Gateway 採用按請求獨立計價的模式。該模式的作用在於,如果沒有請求傳入,就不會產生任何費用。在高流量負載下,Application Load Balancer 或 Network Load Balancer 能以比 API Gateway 更低的單次請求成本,處理更大規模的請求量。不過,如果整體請求數量較少,或具有低流量時段,則為了維持未充分利用的負載平衡器,使用 API Gateway 的累積價格應該比支付每小時費用更具成本效益。API Gateway 也能快取 API 回應,有助於降低後端請求速率。

使用 VPC 連結的 API Gateway 函數,允許 AWS 受管服務使用其私有 IP 地址連接到 VPC 私有子網路內的主機。它可以透過查看由 Amazon ECS Service Discovery 管理 AWS Cloud Map 的服務探索記錄來偵測這些私有 IP 地址。

API Gateway 支援以下功能。

  • API Gateway 的運作方式類似負載平衡器,但具備 API 管理專屬的額外功能

  • API Gateway 提供用戶端授權、用量方案與請求/回應修改等額外功能。如需詳細資訊,請參閱 Amazon API Gateway features

  • API Gateway 可以支援邊緣、區域與私有 API 閘道端點。Edge 端點可透過受管的 CloudFront 分發取得。區域端點與私有端點皆為特定區域的本機端點。

  • SSL/TLS 終止

  • 將不同的 HTTP 路徑路由至不同的後端微服務

除上述功能外,API Gateway 還支援使用自訂 Lambda 授權方,您可以使用這些授權方來保護 API 免受未經授權的使用。如需詳細資訊,請參閱 Field Notes: Serverless Container-based APIs with Amazon ECS and Amazon API Gateway