本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 在內部部署操作的服務消費者 本節討論 中的 SaaS AWS 雲端 工作負載與內部部署資料中心之間的連線選項。許多具有內部部署需求的消費者，特別是在企業層級，將雲端視為實體網路的延伸，而且他們想要在架構中反映這一點。這表示透過邏輯通道或甚至是私有實體連線，在雲端中私有連線至 SaaS 產品。其他消費者將透過公有網際網路接受連線，本節也討論此部分。 **Topics** + [使用 連線 AWS Site-to-Site VPN](#options-onprem-site-to-site) + [使用 連線 AWS Direct Connect](#options-onprem-direct-connect) + [與傳輸 VPC 架構連線](#options-onprem-transit-vpc) + [透過公有網際網路連線](#options-onprem-internet) 下列聯網值映射摘要說明每個評估指標的這些選項分數。如需評估指標的詳細資訊，請參閱本指南中的[評估指標](evaluating.md#evaluating-metrics)。在地圖中，五代表最佳分數，例如最低 TCO、最佳網路隔離或最低修復時間。如需如何讀取此雷達圖的詳細資訊，請參閱本指南[網路值映射](evaluating.md#evaluating-map)中的 。 **注意** 供應商管理的傳輸 VPC 選項會被排除，因為分數很大程度上取決於正在操作的服務。 ![顯示每個評估指標分數的雷達圖。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-network-access-options/images/radar-chart-onprem.png) 雷達圖顯示下列值。 | | | **評估指標** | **AWS Site-to-Site VPN** | **AWS Direct Connect** | **消費者受管傳輸 VPC** | **公有網際網路存取** | | --- |--- |--- |--- |--- | | **易於整合** | 3 | 1 | 4 | 5 | | **TCO** | 2 | 1 | 5 | 4 | | **可擴展性** | 3 | 1 | 5 | 5 | | **適應性** | 3 | 2 | 4 | 5 | | **網路隔離** | 3 | 4 | 5 | 1 | | **可觀測性** | 3 | 4 | 5 | 5 | | **修復時間** | 3 | 2 | 5 | 5 | ## 使用 連線 AWS Site-to-Site VPN [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) 連線可以在虛擬私有閘道或傳輸閘道上終止。*虛擬私有閘道*是站台對站台 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 中的資源。 下圖顯示此架構。 ![AWS 雲端 透過虛擬閘道從內部部署資料中心連線至 。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-network-access-options/images/consumer-onprem-site-to-site-vpn-through-virtual-gateway.png) 以下是此方法的優點： + 修復時間：受管容錯移轉至次要 VPN 通道 + 可觀測性：使用 [Network Synthetic Monitor ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html)整合受管主動監控 + 易於整合：透過 BGP 的動態路由支援 + 適應性：與大多數內部部署聯網設備的相容性 + 適應性：IPv6 支援 + TCO： AWS Site-to-Site VPN 是全受管服務，因此需要的營運工作較少 + TCO：虛擬閘道不收取費用，但每個閘道上的兩個公有 IPv4 地址都會收費 + 網路隔離：透過網際網路啟用安全的私有通訊 以下是此方法的缺點： + 易於整合：消費者必須設定其客戶閘道 + 可擴展性：缺少 ECMP 支援會將頻寬限制為每個虛擬閘道 1.25 Gbps + 可擴展性：由於網路複雜性和營運開銷增加，擴展受限 + 適應性：[IPv6 ](https://docs.aws.amazon.com/vpn/latest/s2svpn/ipv4-ipv6.html)僅支援 VPN 通道的內部 IP 地址 + 適應性：無暫時性路由 + TCO：維護、管理和設定 SaaS 供應商許多 VPN 連線的操作額外負荷 ### 透過傳輸閘道的連線 透過傳輸閘道的連線類似於虛擬閘道。不過，需要記住一些差異。 首先，VPN 連接的路由可以在傳輸閘道路由表中自動傳播，但您必須手動將路由新增至連接的 VPCs。 與虛擬閘道相比，Transit Gateway 支援 ECMP。如果客戶閘道支援 ECMP，則可以使用兩個通道來達到 2.5 Gbps 的總輸送量上限。您可以在相同的內部部署網路與傳輸閘道之間建立多個連線。使用此方法，您可以為每個連線增加高達 2.5 Gbps 的最大頻寬。 下圖顯示此架構。 ![AWS 雲端 透過傳輸閘道從內部部署資料中心連線至 。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-network-access-options/images/consumer-onprem-site-to-site-vpn-through-transit-gateway.png) 以下是此方法的優點： + 修復時間：受管容錯移轉至次要 VPN 通道 + 可觀測性：使用 [Network Synthetic Monitor ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html)整合受管主動監控 + 易於整合：透過 BGP 的動態路由支援 + 可擴展性：ECMP 支援允許[擴展 VPN 輸送量](https://aws.amazon.com/blogs/networking-and-content-delivery/scaling-vpn-throughput-using-aws-transit-gateway/)以滿足大型頻寬需求 + 可擴展性：單一傳輸閘道支援的大量 VPN 連線 （最多近 5，000 個） + 可擴展性：管理和監控所有 VPN 連線的一處 + 適應性：與大多數內部部署聯網設備的相容性 + 適應性：IPv6 支援 + 適應性： 的繼承彈性 AWS Transit Gateway + TCO： AWS Transit Gateway 是全受管服務，因此需要的營運工作較少 + TCO：虛擬閘道不收取費用，但每個閘道上的兩個公有 IPv4 地址都會收費 + 網路隔離：透過網際網路啟用安全的私有通訊 以下是此方法的缺點： + 易於整合：消費者必須設定其客戶閘道 + 可擴展性：由於網路複雜性和營運開銷增加，擴展受限 + 適應性：[IPv6 ](https://docs.aws.amazon.com/vpn/latest/s2svpn/ipv4-ipv6.html)僅支援 VPN 通道的內部 IP 地址 + TCO：維護、管理和設定 SaaS 供應商許多 VPN 連線的操作額外負荷 + TCO：使用 的額外費用 AWS Transit Gateway + TCO：管理傳輸閘道路由表的額外複雜性 ## 使用 連線 AWS Direct Connect [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) 會透過標準乙太網路光纖纜線將您的內部網路連結至某個 Direct Connect 位置。與其他架構選項不同，無法在幾分鐘內建立[專用連線](https://docs.aws.amazon.com/directconnect/latest/UserGuide/dedicated_connection.html)。相反地，如果符合所有要求，此程序最多可能需要幾天的時間。如果沒有，則可能需要更長的時間。因此，我們建議您聯絡您的 AWS 客戶團隊或 AWS 支援 取得此方法的協助。或者，您可以選擇由 AWS 合作夥伴提供並與其他客戶共用的[託管連線](https://docs.aws.amazon.com/directconnect/latest/UserGuide/hosted_connection.html)。無論如何，架構都是相同的。您可以選擇 Direct Connect ，因為它可以減少延遲、改善頻寬或符合法規要求。 若要使用 Direct Connect 連線，消費者必須建立公有、私有或傳輸虛擬介面。有不同的[架構選項](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)可用。將多個現場部署位置連接到 最靈活的 AWS 雲端 是連接到 [Direct Connect 閘道](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html)的傳輸虛擬介面。 Direct Connect 閘道是全域邏輯元件，可讓服務供應商最多連接六個傳輸閘道。此外，您最多可以將 30 個虛擬介面連接到閘道。對於擴展，您可以建立其他 Direct Connect 閘道。在 SaaS 提供者帳戶中，傳輸閘道接著會連接至 VPCs，如先前所述。 消費者可以使用一到四個來自一或兩個[Direct Connect 位置](https://aws.amazon.com/directconnect/locations/)的 Direct Connect 連線進行連線，具體取決於所需的彈性層級。如需詳細資訊，請參閱[設定 Direct Connect 以取得最大彈性](https://docs.aws.amazon.com/directconnect/latest/UserGuide/max-resiliency-set-up.html)。透過網際網路的 AWS Site-to-Site VPN 連線也可以做為 Direct Connect 連線成本較低的備份路徑。支援的 Direct Connect 專用連線可以使用 [MACsec](https://docs.aws.amazon.com/directconnect/latest/UserGuide/MACsec.html) 來加密 Direct Connect 位置與資料中心之間的第 2 層連結。通常會有Site-to-Site連線，以便對資料進行額外的機密性。Site-to-Site VPN 連接可以使用正常的 VPN 連接在傳輸閘道上終止。下圖顯示此架構。 ![透過 從內部部署資料中心連線至 AWS 雲端 AWS Direct Connect。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-network-access-options/images/consumer-onprem-direct-connect.png) 以下是此方法的優點： + 可觀測性：使用 [Network Synthetic Monitor ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html)整合受管主動監控 + 可擴展性：支援增加頻寬輸送量 + 適應性：IPv6 支援 + TCO：可能減少資料傳輸 + TCO：一致的網路體驗 + 網路隔離：可滿足法規要求的私有連線 以下是此方法的缺點： + 易於整合：設定時間和手動工作 + 可擴展性：超過數十個 Direct Connect 連線的可擴展性有限，因為有多個要追蹤[的配額](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html) + 適應性：組態選項取決於可用的 Direct Connect 位置 + TCO：排定的 Direct Connect 維護可能會導致需要採取動作的停機時間 ## 與傳輸 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 AWS 雲端。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-network-access-options/images/consumer-onprem-transit-vpc-customer-managed.png) 以下是此方法的優點： + 修復時間：營運開銷主要卸載至 SaaS 消費者 + 適應性：SaaS 消費者可以從不同的存取選項中選擇 + 適應性：即使使用Site-to-Site或 Direct Connect + 所有指標：服務供應商繼承 AWS PrivateLink 利益 以下是此方法的缺點： + 易於整合：SaaS 消費者至少需要一個 AWS 帳戶 + TCO：傳輸 VPC 是一種架構，而不是全受管服務，因此需要更多的操作工作 ### 供應商受管傳輸 VPC 這種方法使用相同的技術，但帳戶界限和責任會變更。在這裡，SaaS 供應商擁有傳輸 VPCs，最好是在與 SaaS 產品不同的帳戶中。此解耦可降低成本、降低風險，並允許傳輸帳戶獨立擴展。對於需要高度隔離的環境，您可以使用子網路或為每個消費者建立單獨的傳輸 VPC，在租用戶之間建立額外的分隔。然後，消費者可以選擇如何連接到傳輸 VPC。這種方法提供更多選項來擴展總可定址市場，但由於需要操作和監控其他架構元件，因此 SaaS 供應商擁有更高的 TCO。 ![SaaS 提供者會在 中管理一或多個傳輸 VPCs AWS 雲端。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-network-access-options/images/consumer-onprem-transit-vpc-provider-managed.png) 以下是此方法的優點： + 適應性：SaaS 消費者可以從不同的存取選項中選擇 + 適應性：SaaS 消費者不需要擁有 AWS 帳戶 + 適應性：即使使用Site-to-Site或 Direct Connect 以下是此方法的缺點： + TCO：傳輸 VPC 是一種架構，而不是全受管服務，因此需要更多的操作工作 + TCO：SaaS 供應商需要操作和監控其他架構元件 ## 透過公有網際網路連線 公有網際網路存取也是提供 SaaS 產品存取權的有效選項，雖然傳統上不提供私有連線。有些消費者可能仍然偏好公開存取方法，因為其與 SaaS 供應商之間不需要額外的聯網基礎設施。它可降低複雜性、成本和整合時間，以換取增加的攻擊面。強大的身分驗證和授權機制有助於緩解增加的威脅層級，您應該一律加密流量。在此案例中，仍建議您多加一層安全性，例如使用 [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html)。 此案例中的架構非常簡單。消費者透過網際網路連線至公有主機 (SaaS 供應商）。應用程式可以直接託管在具有[彈性 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)的公有 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上。偏好的選項是在 Application Load Balancer 或類似服務後方託管它。為了獲得更好的效能和快取靜態資產，您可以使用內容交付網路，例如 [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)。若要為具有兩個全域靜態 Anycast IP 地址之最低延遲的應用程式提供服務，您可以將 [AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 放置在 Amazon EC2 執行個體、Network Load Balancer 或 Application Load Balancer 前面。此外，CloudFront AWS AppSync、Application Load Balancer 和 Amazon API Gateway 全都與 整合 AWS WAF。下圖提供公有網際網路存取連線選項的概觀。 ![透過公有網際網路連線至 SaaS 產品。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/saas-network-access-options/images/consumer-onprem-public.png) 下表說明此案例支援的通訊協定和整合。 | | | **服務或資源** | **IPv6** | **AWS WAF 整合** | **可以是 Global Accelerator 端點** | | --- |--- |--- |--- | | **Amazon CloudFront** | 支援 | 支援 | 不支援 | | **Amazon API Gateway** | 支援 | 支援 | 不支援 | | **AWS AppSync** | 部分支援 | 支援 | 不支援 | | **具有彈性 IP 地址的 Amazon EC2 ** | 支援 | 不支援 | 支援 | | **Application Load Balancer** | 支援 | 支援 | 支援 | | **Network Load Balancer** | 支援 | 不支援 | 支援 | 以下是此方法的優點： + 易於整合：簡易性和可存取性 + 可擴展性：無限制擴展 + 適應性：不可能發生 CIDR 範圍衝突 + 適應性：CloudFront 支援 以下是此方法的缺點： + 網路隔離：無私有連線 + 網路隔離：需要強大的安全措施 視您選擇的服務而定，適用其他優點和缺點。