[解决方案] 使用 Amazon VPC Lattice 安全访问多租户 SaaS 中的客户资源

**发布时间:** 2025-10-13 **厂商:** AWS **类型:** BLOG **原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/secure-customer-resource-access-in-multi-tenant-saas-with-amazon-vpc-lattice/ --- <!-- AI_TASK_START: AI标题翻译 --> [解决方案] 使用 Amazon VPC Lattice 安全访问多租户 SaaS 中的客户资源 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析 ## 解决方案概述 该解决方案利用 **Amazon VPC Lattice** 及其对 **TCP 资源** 的新支持，为多租户（Multi-tenant）SaaS 应用提供一种安全、可扩展的方式来访问其客户环境中的私有资源。它旨在解决传统网络架构中常见的挑战，如 **IP 地址重叠**、复杂的 **CIDR 规划**以及大规模客户连接的扩展性问题。该方案适用于任何需要从SaaS平台安全集成并访问客户VPC内资源的场景，例如医疗SaaS应用访问医院内部的患者数据库，或BI工具连接客户的私有数据仓库。其技术原理是通过 **VPC Lattice Resource Gateways** (资源网关) 在SaaS提供商和客户的VPC之间建立一个应用层的、安全隔离的连接，从而避免了网络层的直接打通，实现了对特定端点的精细化访问控制。 ## 方案架构与选型 ### 1. 技术选型：VPC Lattice vs. AWS PrivateLink - **AWS PrivateLink** - 适用于**单租户**或**客户数量较少**的多租户环境。 - **局限性**: 每个客户资源都需要一个独立的VPC Endpoint，当客户和资源数量增多时，管理变得复杂且成本高昂。此外，它依赖网络负载均衡器（NLB），不适用于如Kafka、HPC集群等无需或不兼容负载均衡的后端资源。 - **Amazon VPC Lattice** - 推荐用于**大规模多租户**SaaS环境。 - **优势**: 提供**集中式**的访问日志、使用指标和安全策略管理。通过共享服务网络架构，可以有效优化网络路径和成本，简化运维。 ### 2. 服务网络架构模式 #### 架构 A：每租户一个独立服务网络 (One Service Network per Tenant) - **所有权与控制**: 由**客户**创建、拥有服务网络，并通过AWS RAM将其共享给SaaS提供商。 - **优势**: - **强隔离性**: 每个租户都在其独立的服务网络边界内，提供了最高级别的租户隔离。 - **客户完全控制**: 客户对哪些资源被共享拥有完全的可见性和控制权。 - **成本归属清晰**: 服务网络相关的费用保留在客户的AWS账户中。 - **劣势**: - **管理分散**: SaaS提供商的访问日志和监控指标分布在多个服务网络中，需要规划额外的集中化监控方案。 - **IP规划**: SaaS提供商侧为每个客户网络创建的SNE（Service Network Endpoint）都会消耗其VPC内的IP地址。 - **适用场景**: 适用于客户需要部署自定义代码，或对访问控制和资源隔离有极其严格要求的业务场景。 #### 架构 B：单一共享服务网络 (Single Shared Service Network) - **所有权与控制**: 由**SaaS提供商**创建并拥有一个统一的服务网络，所有租户共享此网络。客户仅共享其**资源配置**（Resource Configuration）。 - **优势**: - **简化管理**: SaaS提供商只需维护一个服务网络，显著提高了运维效率。 - **劣势与风险**: - **网络隔离较弱**: 在SaaS提供商的VPC内部，不同租户的资源处于同一个服务网络中。虽然租户间无法直接互访，但SaaS应用内部的工作负载理论上可以访问所有已连接的客户资源。 - **安全责任**: 必须依赖**资源级别的强认证**（如数据库凭证）来防止跨租户的未授权访问。 - **架构建议**: 当SaaS服务本身也通过VPC Lattice暴露时，建议为资源访问（出向流量）和SaaS服务访问（入向流量）创建**两个独立的服务网络**，以实现流量隔离和策略分离。 ### 3. VPC连接方式：SNA vs. SNE - **Service Network VPC Association (SNA)** - 使用AWS保留地址段将VPC与服务网络关联。 - **限制**: 一个VPC只能与一个服务网络进行SNA关联，因此**不兼容“每租户一个独立服务网络”架构**。 - **Service Network Endpoints (SNE)** - 在VPC中创建弹性网络接口（ENI），消耗VPC自身的CIDR地址。 - **优势**: 一个VPC可以连接到**多个服务网络**，灵活性高。 - **推荐**: 对于多租户架构，**强烈建议使用SNE**。 ## 实施步骤 ### 架构 A：每租户一个独立服务网络 1. **客户侧**: - 在资源所在的VPC中创建 `Resource Gateway`。 - 基于 `Resource Gateway` 创建 `Resource Configuration`，指向具体资源的IP和TCP端口。 - 创建 `Service Network` 并关联上述 `Resource Configuration`。 - 通过 **AWS RAM** 将整个 `Service Network` 共享给SaaS提供商的AWS账户。 2. **SaaS提供商侧**: - 接受来自客户的资源共享邀请。 - 在自己的VPC中，为每个共享的服务网络创建一个 `SNE`。 - 通过系统为每个资源分配的DNS名称来访问客户资源。 ### 架构 B：单一共享服务网络 1. **客户侧**: - 创建 `Resource Gateway`。 - 创建 `Resource Configuration`。 - 通过 **AWS RAM** 仅将 `Resource Configuration` 共享给SaaS提供商的AWS账户。 2. **SaaS提供商侧**: - 接受所有客户的资源共享邀请。 - 创建一个**单一的** `Service Network`。 - 将所有客户共享的 `Resource Configuration` 关联到这个统一的服务网络。 - 为该服务网络创建一个 `SNE`。 - 通过DNS名称访问所有客户的资源。 ## 方案客户价值 - **简化网络架构**: 无需处理IP地址重叠、复杂的CIDR规划和VPC路由配置，显著降低了多租户网络管理的复杂性。 - **提升安全性**: 实现了从网络层连接到**应用层连接**的转变，SaaS提供商只能访问客户明确授权的特定资源端点，遵循最小权限原则，极大地减少了攻击面。 - **增强扩展性**: 能够平滑地从几个客户扩展至数千个客户，而不会遇到传统网络连接方案（如为每个客户部署PrivateLink Endpoint或VPN）带来的管理瓶颈和成本激增问题。 - **集中化管控与可见性**: VPC Lattice为SaaS提供商提供了一个统一的平台来管理跨所有客户的安全策略、监控访问日志和收集使用指标，提升了整体的运维效率和安全态势感知能力。 ## 涉及的相关产品 - **Amazon VPC Lattice**: 提供应用层服务网络的核心服务。 - **Resource Gateway**: VPC Lattice的功能组件，用于将VPC内的TCP资源（如EC2实例、数据库）接入服务网络。 - **AWS PrivateLink**: 作为对比方案被提及，适用于较小规模或特定场景。 - **AWS Resource Access Manager (RAM)**: 用于在不同AWS账户间安全地共享资源，是实现跨账户连接的关键。 - **Amazon EC2 / Amazon EKS**: 作为SaaS服务和客户侧资源的承载平台示例。 - **AWS CloudFormation / AWS CLI**: 用于自动化部署和管理此解决方案。 ## 技术评估 - **技术先进性**: VPC Lattice代表了云网络从传统的IP和路由层面，向更现代化的**应用层服务网络（Service Network）**的演进。它将网络连接的关注点从底层基础设施提升到了服务和策略，更贴合微服务和分布式SaaS架构的需求。 - **优势**: - **网络解耦**: 将SaaS应用与客户的底层网络拓扑完全解耦，SaaS提供商无需关心客户的IP规划。 - **零信任模型**: 方案天然支持零信任安全模型，所有连接默认被拒绝，必须通过显式的关联和策略进行授权。 - **架构灵活性**: 提供了独立网络和共享网络两种模式，允许SaaS提供商根据自身的业务、安全和运维需求选择最合适的架构。 - **限制与考量**: - **IP地址消耗**: 在使用SNE模式时，SaaS提供商仍需为其VPC规划充足的IP地址空间，尤其是在客户和资源规模巨大时，建议使用独立的二级CIDR来承载SNE。 - **共享网络模型的安全责任**: 在“单一共享服务网络”架构中，防止跨租户访问的最终安全防线落在了资源级别的认证上，这对SaaS应用层的安全设计提出了更高的要求。 - **服务成熟度**: 作为一项较新的服务，其周边工具、第三方集成和社区最佳实践可能不如传统的网络方案（如Transit Gateway）丰富。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 使用 Amazon VPC Lattice 在多租户 SaaS 中安全访问客户资源 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/secure-customer-resource-access-in-multi-tenant-saas-with-amazon-vpc-lattice/](https://aws.amazon.com/blogs/networking-and-content-delivery/secure-customer-resource-access-in-multi-tenant-saas-with-amazon-vpc-lattice/) **发布时间:** 2025-10-13 **厂商:** AWS **类型:** BLOG --- 在本文中，我们为构建弹性且可扩展的多租户软件即服务 (SaaS) 网络架构提供了规范性指导，以应对诸如管理 IP 地址重叠 (overlapping IP addresses)、复杂的 CIDR 规划 (CIDR planning) 以及将连接性扩展至数千个客户等常见挑战。我们使用 [带有 TCP 资源的 Amazon VPC Lattice (Amazon VPC Lattice with TCP resources)](https://aws.amazon.com/about-aws/whats-new/2024/12/vpc-lattice-tcp-vpc-resources/) 探讨了多种架构方法，并为每种方案提供了详细的实施指南。 提供多租户解决方案的 SaaS 提供商通常需要访问其客户的资源，无论这些资源位于 Amazon Web Services (AWS)、本地数据中心 (on-premises data centers) 还是其他云平台上。这些由客户管理的资源，例如数据库、企业资源规划 (ERP) 系统、事件订阅者 (event subscribers) 或 Webhook 端点 (web-hook endpoints)，需要集成到 SaaS 提供商的服务中，但仍托管并控制在客户的环境内。例如，一个医疗保健应用程序需要访问医院特定的患者数据库。图 1 描述了这一挑战。  图 1: 传统的多租户架构在跨账户边界访问客户资源时面临挑战。为清晰起见，访问层已被抽象化。 [Amazon VPC Lattice](https://aws.amazon.com/de/vpc/lattice/) 允许在现代分布式架构中的应用程序及其组件之间进行安全通信。这使组织能够跨多个账户和 VPC 连接和管理服务，而无需复杂的网络配置。资源网关 (Resource Gateways) 扩展了 VPC Lattice 的功能，允许直接连接到传统上需要复杂网络设置的资源。此功能使 SaaS 提供商能够如引言所述，为其客户的资源提供安全连接。 在 VPC Lattice 支持 TCP 资源之前，SaaS 提供商访问客户资源的选择有限。[AWS PrivateLink](https://aws.amazon.com/privatelink/) 需要网络负载均衡器 (Network load balancers)，这使其不适用于那些不需要或不适合使用负载均衡的资源，例如 Kafka、高性能计算 (HPC) 集群或分布式文件系统。网络层连接解决方案通常会导致暴露非预期的网段，因为它们通常连接整个 VPC 或子网，而不是将访问隔离到特定的端点。基于互联网的访问意味着额外的安全考量，并且通常需要增强的安全控制和工具，例如 Web 应用程序防火墙 (web application firewalls)，以有效缓解威胁。 ## 为您的用例选择正确的架构方案 在以下部分中，我们探讨了几个决策点，以帮助您有效实施 [VPC Lattice 资源网关 (VPC Lattice resource gateways)](https://docs.aws.amazon.com/vpc/latest/privatelink/resource-gateway.html) 。基于我们 [之前的文章](https://aws.amazon.com/blogs/networking-and-content-delivery/extend-saas-capabilities-across-aws-accounts-using-aws-privatelink-support-for-vpc-resources/) 中关于 PrivateLink 对 VPC 资源的支持及其对 SaaS 提供商影响的见解，我们将引导您完成这些关键的架构决策。 ### 1. PrivateLink 还是带有 TCP 资源的 VPC Lattice？ 当使用带有 TCP 资源的 PrivateLink 和资源网关时，SaaS 提供商会为其需要连接的每个资源在自己的 VPC 中部署一个 VPC 终端节点 (VPC endpoint)。随着租户和资源的增多，终端节点的数量可能很快变得难以管理，同时也会导致成本增加。我们建议您在单租户环境或客户和资源数量较少的多租户环境中使用 PrivateLink。图 2 展示了这种通过 PrivateLink VPC 资源终端节点访问客户资源的多租户设置。  图 2: 使用带有资源网关的 PrivateLink 需要为每个客户资源设置单独的 VPC 资源终端节点，因此主要适用于小规模部署。 您可以使用 VPC Lattice 来优化和简化您的网络设置，并拥有一个集中收集访问日志和使用指标以及编写安全策略的地方。通过 VPC Lattice，您还可以选择为每个租户实施专用的服务网络 (service network)，或使用服务于多个租户的共享服务网络。您可以在服务网络中集中控制访问、整合网络路径并优化成本。 ### 2. 选择正确的 VPC Lattice 服务网络架构 以下两节概述了不同的 VPC Lattice 服务网络架构：A – 每个租户一个服务网络，以及 B – 单个共享服务网络。 #### A – 每个租户一个服务网络 在每个租户一个服务网络的模式下，SaaS 客户将创建服务网络，关联其资源，并与 SaaS 提供商共享。SaaS 提供商可以使用服务网络终端节点 (SNEs) 或服务网络关联 (SNA) 来访问租户的资源。这种方法允许租户控制服务网络的操作和配置，并通过将每个租户维持在其自身服务网络的边界内来促进严格的租户隔离。此外，如果需要，租户可以使用同一个服务网络访问 SaaS 提供商的服务，从而创建一条双向通信路径。图 3 概述了此架构方案。  图 3: 客户拥有的服务网络提供强大的隔离性，但增加了操作复杂性，因为每个客户都需要管理自己的服务网络。 SaaS 客户对 SaaS 提供商访问其资源的情况保持完全可见性，并保留对通过服务网络共享哪些资源的完全控制权。资源和服务的计费也保留在客户的账户内，这对于需要特定成本归因模型的组织可能是有益的。 对于 SaaS 提供商而言，访问日志和指标分布在多个服务网络中，这需要为集中式监控和故障排除工作流程进行规划。每个与服务网络关联并通过 SNE 访问的资源，将在 SaaS 提供商 VPC 的每个可用区 (Availability Zone) 消耗一个 IP 地址。因此，在 SaaS 端使用 SNE 需要进行 IP 规划，我们建议利用 VPC 分段和安全选项，例如不同的子网、网络访问控制列表 (NACLs) 和安全组 (security groups)。当与 [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) 环境中的 Pod 级别安全组相结合时，这将创建一个强大的安全基础。 此架构非常适合客户部署自定义代码且需要强访问控制和资源隔离的应用程序。我们在本文末尾包含了此架构的实施指南。 #### B – 单个共享服务网络 SaaS 提供商可以在其账户中创建一个 VPC Lattice 服务网络，并将多个租户共享的资源配置与之关联。租户与 SaaS 提供商共享其资源配置，从而授予对其资源的访问权限。请考虑网络隔离：虽然租户无法从自己的 VPC 或网络直接访问其他租户的资源，但在 SaaS 提供商 VPC 内部署的任何租户工作负载 (例如，在您的 Kubernetes 集群中的一个 Pod 上) 都有可能连接到任何附加的客户资源。因此，在资源级别进行强大的身份验证 (例如数据库凭据) 对于防止未经授权的跨租户访问至关重要。 这种方法的一个关键优势是，它通过为所有租户使用单个服务网络来简化管理。与每个租户一个服务网络的设计一样，服务网络上的每个资源在 SaaS 提供商 VPC 的每个可用区都会消耗一个 IP 地址。对于拥有大量租户的大规模部署，应在您的网络设计和 CIDR 分配策略中考虑这种 IP 消耗。此方法和专用服务网络方法都可以扩展以支持许多客户，但具有不同的操作和网络设计考量。图 4 展示了此架构的详细图表。  图 4: 使用带有共享服务网络的 VPC Lattice 可实现可扩展的多租户资源访问。 此设计通过提供商发起的连接、安全组和客户控制的资源共享来确保网络安全。然而，它需要仔细考虑端到端的安全性和分段。对于 SaaS 客户可以部署自定义代码或需要在租户之间实现完全网络分离的环境，请考虑前面描述的专用服务网络方法。我们在本文末尾包含了此架构的实施指南。 在这种共享服务网络架构下，当 VPC Lattice 也用于访问服务时，为资源访问流量创建一个独立的服务网络有助于在不同流量流之间保持清晰的隔离。这种隔离有助于监控、故障排除，并对入站和出站连接应用不同的安全策略。图 5 展示了这种网络配置。  图 5: 使用 VPC Lattice 的共享服务网络架构，并使用第二个服务网络访问 SaaS 应用程序。为清晰起见，仅描绘了一个客户账户。 ### 3. 在服务网络 VPC 关联 (SNA) 和 SNE 之间进行选择 您可以使用 SNA 或 SNE 将 VPC 连接到服务网络。SNA 使与服务网络关联的资源可以通过 VPC 内来自 AWS 拥有的 129.224.0.0/17 地址块的 IP 地址进行寻址。此 IP 地址在 VPC Lattice 之外不可路由。一个 VPC 只能以这种方式关联一个服务网络，这使得 SNA 与每个租户专用服务网络的方法不兼容。 或者，SNE 允许您将多个服务网络连接到一个 VPC，每个服务网络使用一个或多个弹性网络接口 (ENIs)。尽管 SNE 会消耗您 VPC CIDR 中的 IP 地址 (在每个 [AWS 可用区 (AZ)](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) 中每个关联资源消耗一个)，但它们的优势是使服务网络可以像任何其他私有 IP 一样从 VPC 外部访问。对于大多数多租户架构，由于其灵活性，我们建议使用 SNE。如果您现有的 VPC 子网中没有足够的私有 IP 地址，您也可以将这些 SNE 放置在来自辅助 VPC CIDR 的新子网中，这些 CIDR 不会路由到 VPC 外部。SNA 和 SNE 是免费的。有关详细的定价维度和组件，请参阅 [VPC Lattice 定价页面](https://aws.amazon.com/vpc/lattice/pricing/) 。 ## 实施 以下各节使用 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 模板和 [AWS 命令行界面 (AWS CLI)](https://aws.amazon.com/cli/) 命令，为先前探讨的架构方法提供了分步实施指南。 ### 先决条件 要完成任一解决方案的实施步骤，需要以下资源： - 最好有三个独立的 AWS 账户，以模拟一个 SaaS 提供商和两个客户。出于测试目的，您也可以为 SaaS 提供商和客户使用同一个账户，并在说明中跳过 AWS Resource Access Manager (RAM) 共享部分。我们在说明中使用三个独立的 AWS 账户，以使其尽可能接近真实场景。 - 每个账户一个 VPC，SaaS 提供商 VPC 中有一个 [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) 实例来模拟服务，每个客户 VPC 中有一个资源 (例如，数据库或在 TCP 端口上侦听的 EC2 实例) 来模拟客户资源。在本文中，我们使用一个在 TCP 端口 1234 上侦听的示例 TCP 应用程序。您可以选择使用 [GitHub 上的这个 CloudFormation 模板](https://github.com/vijumenon/BuildingMulti-tenantSaaSArchitectureswithAWSResourceGatewayandVPCLattice/blob/main/RGBlog.yaml) 来部署基础架构。 - AWS CLI：您需要在将要执行操作的工作站上 [安装](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 和 [配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) AWS CLI。 - 具有足够 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 权限的 AWS CLI 凭证，以便在所有三个账户中创建和修改资源。 - 本文假设使用 us-east-1 区域，并且您的 AWS CLI 默认 AWS 区域是 us-east-1。如果 us-east-1 不是默认区域，则在运行 AWS CLI 命令时使用 –region us-east-1 明确指定区域，或确保始终使用您偏好的 AWS 区域。 ### A – 每个租户一个服务网络的实施指南 #### 客户侧： 1. 在客户账户中，在相关资源所在的 VPC 中创建一个资源网关。创建资源网关时，至少选择跨两个 AZ 的两个子网以及包含必要规则的安全组。 2. 使用上一步创建的资源网关创建一个资源配置。资源配置应使用资源正在侦听的 TCP 端口创建，并且在 `resource-configuration-definition` 中，类型应选择为 `ipResource` 并指向 TCP 服务器的 IP 地址。 3. 创建一个服务网络，并将上一步创建的资源配置与此服务网络关联。 4. 为此服务网络创建一个资源共享，并与 SaaS 提供商账户共享。 5. 为其他客户账户重复这些步骤。 #### SaaS 提供商侧： 1. 在 SaaS 提供商账户中，接受来自所有客户账户的资源共享邀请。 2. 在 SaaS 提供商 VPC 中为每个客户的服务网络创建一个 SNE。确保选择所有 AZ，以避免客户和 SaaS 提供商之间的 AZ 不匹配。或者，您可以在客户 VPC 中的资源网关和 SaaS 提供商 VPC 中的 SNE 之间对齐 AZ。 3. 获取系统为每个客户资源分配的 DNS 名称并测试连接性。 4. (可选) 创建一个私有托管区并与 SaaS 提供商 VPC 关联，然后创建 CNAME 记录，将系统生成的 DNS 名称指向更友好的域名。 实施此方案的详细步骤记录在 [这个](https://github.com/vijumenon/BuildingMulti-tenantSaaSArchitectureswithAWSResourceGatewayandVPCLattice/tree/main) GitHub 仓库的 “Implementation Guide for A – Dedicated Service Network per Customer” 部分。 ### B – 单个共享服务网络的实施指南 #### 客户侧： 1. 在客户账户中，在相关资源所在的 VPC 中创建一个资源网关。创建资源网关时，至少选择跨两个 AZ 的两个子网以及包含必要规则的安全组。 2. 使用上一步创建的资源网关创建一个资源配置。资源配置应使用资源正在侦听的 TCP 端口创建，并且在 `resource-configuration-definition` 中，类型应选择为 `ipResource` 并指向 TCP 服务器的 IP 地址。 3. 为此资源配置创建一个资源共享，并与 SaaS 提供商账户共享。 4. 为其他客户账户重复这些步骤。 #### SaaS 提供商侧： 1. 在 SaaS 提供商账户中，接受来自所有客户账户的资源共享邀请。 2. 创建一个服务网络，并将 `–sharing-config` 设置为 `enabled=false`，因为默认的 `true` 设置会阻止关联共享的资源配置。 3. 在 SaaS 提供商 VPC 中为该服务网络创建一个 SNE。确保选择所有 AZ，以避免客户和 SaaS 提供商之间的 AZ 不匹配。或者，您可以在客户 VPC 中的资源网关和 SaaS 提供商 VPC 中的 SNE 之间对齐 AZ。 4. 获取系统为每个客户资源分配的 DNS 名称并测试连接性。 5. (可选) 创建一个私有托管区并与 SaaS 提供商 VPC 关联，然后创建 CNAME 记录，将系统生成的 DNS 名称指向更友好的域名。 实施此方案的详细步骤记录在 [这个](https://github.com/vijumenon/BuildingMulti-tenantSaaSArchitectureswithAWSResourceGatewayandVPCLattice/tree/main) GitHub 仓库的 “Implementation Guide for B – shared Service Network” 部分。 ## 注意事项 - 确保提供商 VPC 中的 SNE 至少部署在一个与客户资源网关部署的 AZ 相匹配的 AZ 中。 - 在 SaaS 提供商侧的 VPC 中，我们建议在每个 AZ 中为 SNE 创建专用子网。为了获得更好的可扩展性，可以考虑为您的 VPC 附加专门用于这些终端节点的辅助 CIDR 块，例如，每个租户一个辅助 CIDR。子网创建后无法调整大小，因此我们建议分配足够大的子网 (例如 /24 或更大) 以适应未来需要连接的租户资源数量的增长。 - 在遵循实施步骤时，只要资源网关可以连接到计算平台，其类型就无关紧要。在演练中，我们使用 EC2 实例来展示服务和资源之间的连接性。 - 在遵循实施步骤时，如果您想先用一个客户账户测试解决方案，可以跳过在第二个客户账户中创建资源的步骤。 - 查看 [VPC 终端节点的定价](https://aws.amazon.com/privatelink/pricing/) 和 [VPC Lattice 的定价](https://aws.amazon.com/vpc/lattice/pricing/) 。 - 查看 [VPC 终端节点的默认配额](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-limits-endpoints.html) 和 [VPC Lattice 的默认配额](https://docs.aws.amazon.com/vpc-lattice/latest/ug/quotas.html) 。 ## 结论 Amazon VPC Lattice 资源网关和资源配置为 SaaS 提供商在多租户架构中安全访问客户资源提供了一个强大的解决方案。这些技术使您能够克服传统的网络挑战，维持严格的安全边界，并将您的连接性扩展到数千个客户。我们介绍的任何设计方案都是可行的，具体取决于 SaaS 提供商的特定需求。 它们的共同点是，无论客户当前如何访问服务——无论是通过 PrivateLink、VPC Lattice、[AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) 还是通过互联网——这些方案都能正常工作。要了解更多关于使用 VPC Lattice 暴露您的 SaaS 应用程序的信息，[这篇文章](https://aws.amazon.com/blogs/networking-and-content-delivery/connecting-saas-services-within-a-vpc-lattice-service-network/) 是一个很好的起点。 ## 关于作者  ### Luca Schumann Luca Schumann 是 AWS 的一名 ISV 解决方案架构师，居住在德国。他拥有慕尼黑工业大学的计算机科学硕士学位，专注于帮助独立软件供应商使用 AWS 网络服务和 Kubernetes 来架构和优化他们的解决方案。在不设计云解决方案时，Luca 喜欢玩棋盘游戏或通过各种运动保持活力。  ### Vijay Menon Vijay Menon 是一名常驻新加坡的首席解决方案架构师，拥有大规模网络和通信基础设施的背景。他喜欢学习新技术，并通过使用 AWS 产品和服务提供解决方案来帮助客户解决复杂的技术问题。在不帮助客户时，他喜欢长跑并与家人和朋友共度时光。 <!-- AI_TASK_END: AI全文翻译 -->