本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 在 上操作的 SaaS 消費者 AWS
如果您和您的消費者都在 中操作，本節會討論連線選項 AWS 雲端。此案例提供最大的彈性，因為許多 AWS 服務 原生整合 和 ，因為雙方都可以存取整個 AWS 服務 產品組合。
**Topics**
+ [與 整合 AWS PrivateLink](#options-aws-privatelink)
+ [共用 Amazon VPC Lattice 服務](#options-amazon-vpc-lattice)
+ [建立 VPC 對等互連](#options-aws-vpc-peering)
+ [使用 VPCs AWS Transit Gateway](#options-aws-transit-gateway)
下列聯網值映射摘要說明每個評估指標的這些選項分數。如需評估指標的詳細資訊，請參閱本指南中的[評估指標](evaluating.md#evaluating-metrics)。在地圖中，5 代表最佳分數，例如最低 TCO、最佳網路隔離或最低修復時間。如需如何讀取此雷達圖的詳細資訊，請參閱本指南[網路值映射](evaluating.md#evaluating-map)中的 。
雷達圖顯示下列值。
| 評估指標 | AWS PrivateLink | Amazon VPC Lattice | VPC 對等互連 | AWS Transit Gateway |
| --- | --- | --- | --- | --- |
| 易於整合 | 5 | 5 | 4 | 3 |
| TCO | 5 | 5 | 3 | 4 |
| 可擴展性 | 5 | 4 | 1 | 4 |
| 適應性 | 4 | 5 | 2 | 3 |
| 網路隔離 | 5 | 5 | 2 | 3 |
| 可觀測性 | 4 | 5 | 4 | 4 |
| 修復時間 | 5 | 5 | 5 | 4 |
## 與 整合 AWS PrivateLink
[AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) 是整合 SaaS 產品最雲端原生的方式。SaaS 供應商可以在 [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 後方託管其應用程式。Network Load Balancer 會直接與 [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)、[Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)、[Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) 和 [Auto Scaling 群組](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)整合。您也可以將流量從 Network Load Balancer 路由到 SaaS 供應商帳戶中的 VPC 端點。這可協助您使用 API 來連接應用程式，例如透過 [Amazon API Gateway](https://repost.aws/knowledge-center/invoke-private-api-gateway) 或 [AWS AppSync](https://docs.aws.amazon.com/appsync/latest/devguide/what-is-appsync.html)。如果您的應用程式需要存取客戶環境中未平衡負載的資源，例如資料庫，您可以使用[資源 VPC 端點](https://docs.aws.amazon.com/vpc/latest/privatelink/use-resource-endpoint.html)。
AWS PrivateLink 支援每個可用區域高達 100 Gbps 的頻寬。下圖顯示具有一些可能整合的基本組態。它透過 將兩個消費者帳戶連接到 SaaS 提供者帳戶 AWS PrivateLink。消費者帳戶中有服務端點，SaaS 供應商帳戶中有 Network Load Balancer。
以下是此方法的優點：
+ 易於整合：不需要變更路由表
+ 易於整合：您可以透過 [提供端點服務 AWS Marketplace](https://docs.aws.amazon.com/marketplace/latest/userguide/privatelink.html)
+ 易於整合：VPC 端點支援[易記的 DNS 名稱](https://docs.aws.amazon.com/vpc/latest/privatelink/manage-dns-names.html)
+ 可擴展性：它可以擴展到數千個 SaaS 消費者
+ 適應性：支援重疊 CIDR 範圍
+ 適應性：支援 IPv6
+ 適應性：跨區域支援
+ TCO： AWS PrivateLink 是全受管服務，因此需要的營運工作較少
+ 網路隔離：SaaS 消費者的安全優勢，因為流量無法從 SaaS 供應商啟動
+ 網路隔離：SaaS 供應商的安全優勢，因為它們不會暴露整個子網路或 VPC
以下是此方法的缺點：
+ 適應性：SaaS 供應商必須使用與消費者相同的可用區域
+ 適應性：僅支援用戶端起始的連線，服務起始的通訊需要資源 VPC 端點
+ 適應性：Network Load Balancer 是 的唯一直接整合 AWS PrivateLink
## 共用 Amazon VPC Lattice 服務
若要使用 [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) 做為 SaaS 應用程式的連線選項，您必須先建立一或多個代表 SaaS 應用程式元件的 VPC Lattice 服務。您可以設定接聽程式和路由規則，將流量導向後端目標，例如 Amazon EC2 執行個體、容器或 AWS Lambda 函數。如需詳細資訊，請參閱[在 VPC Lattice 服務網路中連接 Saas 服務](https://aws.amazon.com/blogs/networking-and-content-delivery/connecting-saas-services-within-a-vpc-lattice-service-network/) (AWS 部落格文章）。就概念而言，這幾乎與設定 Application Load Balancer 相同。然後，您可以使用 [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) 指定他們擁有的許可，安全地與客戶 AWS 帳戶 或組織共用 SaaS 服務。客戶接受資源共享後，可以將 SaaS 服務與其現有或新建立的 VPC Lattice 服務網路建立關聯，以啟用service-to-service通訊。
每個 VPC Lattice 服務每秒每個可用區域最多可支援 10 Gbps 和 10，000 個請求。透過實作身分驗證政策，您的客戶可以精細控制哪些 服務和資源可以存取 SaaS 應用程式。您可以使用[資源閘道](https://docs.aws.amazon.com/vpc-lattice/latest/ug/resource-gateway.html)來存取需要 TCP 連線的資源。例如，這可能是您管理的 Amazon EKS 叢集，也可能是應用程式需要存取的客戶受管資源。如需針對 SaaS 產品使用資源閘道的詳細資訊，請參閱[AWS 帳戶 使用 VPC 資源 AWS PrivateLink 支援將 SaaS 功能延伸到 ](https://aws.amazon.com/blogs/networking-and-content-delivery/extend-saas-capabilities-across-aws-accounts-using-aws-privatelink-support-for-vpc-resources/)(AWS 部落格文章）。
下圖顯示具有一些範例整合的高階 VPC Lattice 組態。它使用客戶管理的服務網路來存取 SaaS 應用程式。
以下是此方法的優點：
+ 易於整合：不需要變更路由表
+ 易於整合：開箱即用的 服務探索
+ 可擴展性：它可以擴展到數千個 SaaS 消費者
+ 適應性：支援重疊 CIDR 範圍
+ 適應性：支援 IPv6
+ 適應性：整合任何 AWS 運算服務做為 VPC Lattice 服務
+ TCO：VPC Lattice 是全受管服務，因此需要的營運工作較少
+ TCO：具有進階流量路由的內建負載平衡
+ 網路隔離：具有身分驗證政策的精細授權
+ 網路隔離：SaaS 消費者的安全優勢，因為流量無法從 SaaS 供應商啟動
+ 網路隔離：SaaS 供應商的安全優勢，因為您未公開整個子網路或 VPC
以下是此方法的缺點：
+ 適應性：僅支援用戶端起始的連線，服務起始的通訊需要資源閘道
+ 適應性：無跨區域支援
## 建立 VPC 對等互連
當您使用 [VPC 對](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)等互連將 SaaS 提供者的 VPC 連接到消費者的 VPC 時，雙方都可以啟動連線。這需要兩個帳戶中安全群組、防火牆和網路存取控制清單 (NACLs的適當組態。否則，不需要的流量可能會透過對等連線進入網路。您可以使用安全群組來參考對等 VPCs的安全群組。這可協助您控制對應用程式的存取，因為相較於允許列出 IP 地址，允許列出安全群組可提供更明確且精細的存取控制。
使用 VPC 對等互連，可透過 VPC 中部署的服務或資源來存取 SaaS 產品。大多數 SaaS 應用程式都位於 Application Load Balancer 或 Network Load Balancer 後方。[AWS AppSync 私有 APIs](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html) 或 [Amazon API Gateway 私有 APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html) 是 SaaS 應用程式的其他常見進入點，因為它們可以透過介面 VPC 端點透過對等連線成為目標。
建立對等連線後，您必須更新兩個帳戶中 VPCs的路由表，將對等連線定義為個別 CIDR 範圍的下一個躍點。此解決方案建議僅適用於擁有幾個消費者的 SaaS 提供者，因為管理多個互連連線很快就會變得太複雜。
下圖顯示具有一些可能整合的基本組態。兩個消費者帳戶中VPCs 與 SaaS 提供者帳戶中的 VPC 具有對等連線。
以下是此方法的優點：
+ 修復時間：沒有單一通訊失敗點
+ 可擴展性：VPC 對等互連沒有頻寬限制
+ TCO：對等連線或相同可用區域內對等連線的流量不收取費用
+ TCO：無需管理基礎設施
+ 適應性：支援 IPv6
+ 適應性：支援區域間對等互連
以下是此方法的缺點：
+ 適應性：不支援暫時性路由
+ 適應性：不支援重疊的 CIDR 範圍
+ 可擴展性：可擴展性有限 （每個 VPC 最多 125 個互連連線）
+ TCO：透過每個額外的互連連線，複雜性呈指數增長
+ TCO：管理路由表、對等連線本身、安全群組規則和流量檢查的開銷
+ 網路隔離：由於雙方的整個 VPCs 都公開，因此需要嚴格的安全控制
## 使用 VPCs AWS Transit Gateway
當您透過 連接 VPCs 時[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)，它會建立 VPC 連接，並在每個可用區域的子網路中部署網路介面，該子網路應路由往返 VPC 的流量。建議在 VPC 連接的每個可用區域中都有專用`/28`子網路。如需詳細資訊，請參閱 [Amazon VPC Transit Gateways 設計最佳實務](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html)。VPCs 需要更新的路由表，才能透過部署的網路界面傳送流量，且 Transit Gateway 路由表需要相應地更新。在多租戶組態中，您希望 SaaS 提供者的 VPC 路由到所有消費者的 VPCs。消費者的 VPCs 應該只有通往 SaaS 提供者 VPC 的路由。
Transit Gateway 透過設計提供高可用性。它支援使用 [VPC 流量日誌進行](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-vpc-flow-logs-for-aws-transit-gateway/)監控，傳輸閘道連接的最大頻寬為每個可用區域 100 Gbps。如同 VPC 對等互連，此方法可啟用跨 VPC 安全群組參考，簡化環境之間的存取控制。
使用 Transit Gateway 將消費者連線至您的 SaaS 產品有兩個主要選項。
**選項 1：使用 RAM**
在第一個選項中，服務提供者[會使用 () 與消費者共用 Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-share.html)。 [AWS Resource Access ManagerAWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)這可讓消費者在自己的帳戶中部署 VPC 連接。下圖顯示此選項的高層級。
**選項 2：對等傳輸閘道**
第二個選項是將傳輸閘道與消費者帳戶中的傳輸閘道對等。這可讓消費者更具彈性，因為他們現在可以完全控制其傳輸閘道內的路由表。例如，他們可以在服務與其工作負載之間設定集中式檢查。此選項的缺點是僅支援傳輸閘道之間的靜態路由。下圖顯示此選項的高層級。
以下是此方法的優點：
+ 可擴展性：支援最多 5，000 個附件
+ 可擴展性：管理和監控所有連線 VPCs單一位置
+ 適應性：傳輸閘道也可以連接到 VPNs、 Direct Connect 閘道和第三方 SD-WAN 設備
+ 適應性：彈性架構，例如[新增檢查 VPC](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)
+ 適應性：支援可轉移路由
+ 適應性：可以對等區域內和區域間傳輸閘道
+ 適應性：支援 IPv6
+ TCO： AWS Transit Gateway 是全受管服務，因此需要的營運工作較少
+ TCO：隨著每個額外的傳輸閘道連接，TCO 會線性成長
以下是此方法的缺點：
+ 易於整合：路由組態需要進階聯網知識
+ 適應性：不支援重疊的 CIDR 範圍
+ TCO：管理路由表項目、安全群組規則和流量檢查的額外負荷
+ 安全性：由於雙方的整個 VPCs 都公開，因此需要嚴格的安全控制