Amazon VPC Lattice 的多账户设计 - RAM 共享与服务网络的配置模式
讲解在多账户环境中运营 VPC Lattice 时的 RAM 共享设计、服务网络的拆分策略以及 Auth Policy 的分层设计。
多账户环境中 VPC Lattice 的挑战
在 AWS 的多账户策略中，按工作负载分离账户，以建立安全边界。然而，微服务之间的通信需要跨越账户边界，以往是通过 VPC 对等连接、Transit Gateway、PrivateLink 的组合来实现的。VPC Lattice 可以在应用层建立跨账户通信，但在多账户环境中的设计有其特有的考虑事项。将服务网络的所有权、服务的共享范围、Auth Policy 的管理责任放在哪个账户，是设计上的重要判断点。
通过 RAM 共享服务网络
VPC Lattice 的跨账户连接通过 AWS Resource Access Manager（RAM）实现。服务网络的所有者账户创建 RAM 资源共享，并向参与账户授予关联到服务网络的权限。共享目标可以指定单个账户 ID、Organizations 的组织单位（OU）或整个组织。推荐的模式是将服务网络集中到网络管理专用账户（Networking Account），并以 OU 为单位进行共享的配置。这样，服务网络的生命周期管理得以集中，新的工作负载账户在添加到 OU 的那一刻，会自动获得对服务网络的访问权限。通过利用 Organizations 的信任关系将 RAM 共享的接受设为自动接受，可以减轻运维负担。
服务网络的拆分策略
如何拆分服务网络，取决于组织的规模和安全要求。在小规模组织（账户数不足 10 个）中，将所有服务注册到单一服务网络的简单配置易于管理。在中等规模以上的组织中，建议按环境（生产 / 预发布 / 开发）或按领域（支付 / 认证 / 通知等）拆分服务网络。按环境拆分消除了生产环境的服务被开发环境调用的风险。按领域拆分明确了团队之间的责任边界，并可以分散 Auth Policy 的管理。但是，如果将服务网络拆分得过细，服务之间的通信路径会变得复杂，运维负担也会增加。以每个服务网络约 50 到 100 个服务为参考，在超过这一数量时考虑拆分，是实用的做法。
Auth Policy 的分层设计
VPC Lattice 的 Auth Policy 在服务网络级别和服务级别这 2 个层级上应用。在多账户环境中，利用这种分层结构来设计职责划分。服务网络级别的策略由网络管理账户管理，从整体上控制“哪个账户的主体可以访问服务网络内的服务”。服务级别的策略由各工作负载账户管理，细致地控制“允许来自哪些主体对自己服务的访问”。通过这种分离，网络管理员可以统一管控安全的大框架，同时各团队自主管理自己服务的访问控制。策略评估以 AND 条件进行，因此在服务网络级别被拒绝的访问，即使在服务级别允许也无法通过。
组织中的运维与审计
在多个账户之间共享服务网络时，掌握并管控谁在使用哪些服务变得重要。在利用共享机制将服务网络部署到各账户的同时，通过认证策略进行控制，使通信仅限于获得许可的账户和服务之间。如果汇总通信日志，可以横向监控跨账户的服务间交互，并检测意外的访问。由中央团队管理共享框架和策略、各账户的团队在其中发布 / 使用服务，这样的角色分工支撑着大规模组织中有序的运维。
总结
在 VPC Lattice 的多账户设计中，主要的设计模式是通过 RAM 共享对服务网络进行集中管理、按环境或领域拆分服务网络、通过 Auth Policy 的 2 个层级划分职责。请以将服务网络集中到网络管理账户、并以 OU 为单位进行 RAM 共享的配置为基础，随着组织的成长考虑拆分服务网络。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。