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

在內部部署操作的服務消費者

本節討論 中的 SaaS AWS 雲端 工作負載與內部部署資料中心之間的連線選項。許多具有內部部署需求的消費者，特別是在企業層級，將雲端視為實體網路的延伸，而且他們想要在架構中反映這一點。這表示透過邏輯通道或甚至是私有實體連線，在雲端中私有連線至 SaaS 產品。其他消費者將透過公有網際網路接受連線，本節也討論此部分。

下列聯網值映射摘要說明每個評估指標的這些選項分數。如需評估指標的詳細資訊，請參閱本指南中的評估指標。在地圖中，五代表最佳分數，例如最低 TCO、最佳網路隔離或最低修復時間。如需如何讀取此雷達圖的詳細資訊，請參閱本指南網路值映射中的 。

雷達圖顯示下列值。

使用 連線 AWS Site-to-Site VPN

AWS Site-to-Site VPN 連線可以在虛擬私有閘道或傳輸閘道上終止。虛擬私有閘道是站台對站台 VPN 連接 AWS 端的 VPN 端點，可連接到單一 VPC。 Site-to-Site 傳輸閘道是一種傳輸中樞，可用於互連多個 VPCs 和內部部署網路。它也可以用作站台對站台 VPN 連接端 AWS 的 VPN 端點。 Site-to-Site 本節討論這兩個選項。

透過虛擬私有閘道的連線

建立虛擬私有閘道之後，您可以將它連接到包含 SaaS 產品的 VPC。然後，您可以啟用路由傳播，將 VPN 路由傳播到 VPC 路由表。這些路由可以是靜態或 BGP 公告的動態路由。

為了實現高可用性，Site-to-Site連接有兩個 VPN 通道，其終止於 AWS 側面的兩個可用區域中。如果無法使用，第二個通道可以接管。單一通道允許最大頻寬 1.25 Gbps。由於虛擬私有閘道不支援等成本多路徑路由 (ECMP)，因此您一次只能使用一個通道。

若要提高容錯能力，您可以設定第二個實體客戶閘道的 VPN 連接。建立連線後，消費者可以連接 SaaS 提供者 VPC 中的資源。

下圖顯示此架構。

以下是此方法的優點：

以下是此方法的缺點：

透過傳輸閘道的連線

透過傳輸閘道的連線類似於虛擬閘道。不過，需要記住一些差異。

首先，VPN 連接的路由可以在傳輸閘道路由表中自動傳播，但您必須手動將路由新增至連接的 VPCs。

與虛擬閘道相比，Transit Gateway 支援 ECMP。如果客戶閘道支援 ECMP，則可以使用兩個通道來達到 2.5 Gbps 的總輸送量上限。您可以在相同的內部部署網路與傳輸閘道之間建立多個連線。使用此方法，您可以為每個連線增加高達 2.5 Gbps 的最大頻寬。

下圖顯示此架構。

以下是此方法的優點：

以下是此方法的缺點：

使用 連線 AWS Direct Connect

AWS Direct Connect 會透過標準乙太網路光纖纜線將您的內部網路連結至某個 Direct Connect 位置。與其他架構選項不同，無法在幾分鐘內建立專用連線。相反地，如果符合所有要求，此程序最多可能需要幾天的時間。如果沒有，則可能需要更長的時間。因此，我們建議您聯絡您的 AWS 客戶團隊或 AWS 支援 取得此方法的協助。或者，您可以選擇由 AWS 合作夥伴提供並與其他客戶共用的託管連線。無論如何，架構都是相同的。您可以選擇 Direct Connect ，因為它可以減少延遲、改善頻寬或符合法規要求。

若要使用 Direct Connect 連線，消費者必須建立公有、私有或傳輸虛擬介面。有不同的架構選項可用。將多個現場部署位置連接到 最靈活的 AWS 雲端 是連接到 Direct Connect 閘道的傳輸虛擬介面。 Direct Connect 閘道是全域邏輯元件，可讓服務供應商最多連接六個傳輸閘道。此外，您最多可以將 30 個虛擬介面連接到閘道。對於擴展，您可以建立其他 Direct Connect 閘道。在 SaaS 提供者帳戶中，傳輸閘道接著會連接至 VPCs，如先前所述。

消費者可以使用一到四個來自一或兩個Direct Connect 位置的 Direct Connect 連線進行連線，具體取決於所需的彈性層級。如需詳細資訊，請參閱設定 Direct Connect 以取得最大彈性。透過網際網路的 AWS Site-to-Site VPN 連線也可以做為 Direct Connect 連線成本較低的備份路徑。支援的 Direct Connect 專用連線可以使用 MACsec 來加密 Direct Connect 位置與資料中心之間的第 2 層連結。通常會有Site-to-Site連線，以便對資料進行額外的機密性。Site-to-Site VPN 連接可以使用正常的 VPN 連接在傳輸閘道上終止。下圖顯示此架構。

以下是此方法的優點：

以下是此方法的缺點：

與傳輸 VPC 架構連線

Transit VPC 是一種架構選項，可為消費者提供連線彈性 AWS，並允許 SaaS 供應商透過 統一存取其服務。 AWS PrivateLink消費者從現場部署連線到僅包含進入點 （例如虛擬私有閘道） 和介面 VPC 端點的傳輸 VPC，這是 AWS PrivateLink 資源。傳輸 VPCs 應由 SaaS 提供者或消費者擁有。本節討論這兩個選項。

您可以使用與現場部署資料中心相容的 CIDR 範圍來建立傳輸 VPC 和子網路。如果需要私有連線，消費者可以透過 AWS Direct Connect 或 連線到該 VPC AWS Site-to-Site VPN。您也可以使用指向 VPC 端點的 Application Load Balancer 或 Network Load Balancer，設定從公有網際網路對傳輸帳戶的存取。

消費者受管傳輸 VPC

在此方法中，SaaS 提供者會將傳輸 VPCs 的管理留給消費者。從技術角度來看，SaaS 提供者的架構與透過 AWS 雲端 連線至消費者時相同 AWS PrivateLink。從銷售和產品的觀點來看，這是額外的努力，因為有些消費者 AWS 帳戶 還沒有。他們可能會對開立和操作帳戶感到遲疑。SaaS 提供者應該為消費者提供有關如何建立 AWS 帳戶 和連接現場部署資料中心的指導。下圖顯示公有和私有存取的混合，其中消費者擁有傳輸 VPCs。

以下是此方法的優點：

以下是此方法的缺點：

供應商受管傳輸 VPC

這種方法使用相同的技術，但帳戶界限和責任會變更。在這裡，SaaS 供應商擁有傳輸 VPCs，最好是在與 SaaS 產品不同的帳戶中。此解耦可降低成本、降低風險，並允許傳輸帳戶獨立擴展。對於需要高度隔離的環境，您可以使用子網路或為每個消費者建立單獨的傳輸 VPC，在租用戶之間建立額外的分隔。然後，消費者可以選擇如何連接到傳輸 VPC。這種方法提供更多選項來擴展總可定址市場，但由於需要操作和監控其他架構元件，因此 SaaS 供應商擁有更高的 TCO。

以下是此方法的優點：

以下是此方法的缺點：

透過公有網際網路連線

公有網際網路存取也是提供 SaaS 產品存取權的有效選項，雖然傳統上不提供私有連線。有些消費者可能仍然偏好公開存取方法，因為其與 SaaS 供應商之間不需要額外的聯網基礎設施。它可降低複雜性、成本和整合時間，以換取增加的攻擊面。強大的身分驗證和授權機制有助於緩解增加的威脅層級，您應該一律加密流量。在此案例中，仍建議您多加一層安全性，例如使用 AWS WAF。

此案例中的架構非常簡單。消費者透過網際網路連線至公有主機 (SaaS 供應商）。應用程式可以直接託管在具有彈性 IP 地址的公有 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上。偏好的選項是在 Application Load Balancer 或類似服務後方託管它。為了獲得更好的效能和快取靜態資產，您可以使用內容交付網路，例如 Amazon CloudFront。若要為具有兩個全域靜態 Anycast IP 地址之最低延遲的應用程式提供服務，您可以將 AWS Global Accelerator 放置在 Amazon EC2 執行個體、Network Load Balancer 或 Application Load Balancer 前面。此外，CloudFront AWS AppSync、Application Load Balancer 和 Amazon API Gateway 全都與 整合 AWS WAF。下圖提供公有網際網路存取連線選項的概觀。

下表說明此案例支援的通訊協定和整合。

以下是此方法的優點：

以下是此方法的缺點：

視您選擇的服務而定，適用其他優點和缺點。