[解决方案] 使用 Amazon VPC Lattice 简化原地应用升级

**发布时间:** 2025-10-21 **厂商:** AWS **类型:** BLOG **原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/streamline-in-place-application-upgrades-with-amazon-vpc-lattice/ --- <!-- AI_TASK_START: AI标题翻译 --> [解决方案] 使用 Amazon VPC Lattice 简化原地应用升级 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析 ## 解决方案概述 该解决方案阐述了如何使用 **Amazon VPC Lattice** 作为统一的服务网络层，来简化和保障应用在云环境中的**平滑升级与迁移**过程。其核心目标是在不中断服务（**零停机**）的前提下，解耦基础设施与应用逻辑，从而降低运维复杂性并提升系统可靠性。 该方案主要解决传统升级方式中存在的挑战，例如需要复杂编排负载均衡器（ELB）、DNS（Route 53）和手动配置，过程易错且耗时。它适用于以下关键业务场景： - **三层Web应用的平滑升级**：例如，在不影响前端服务的情况下，安全地更新后端应用逻辑或数据库模式。 - **从 EC2 到容器的现代化迁移**：为运行在 **Amazon EC2** 上的传统应用提供一条低风险、增量式的路径，迁移至 **Amazon EKS** 或 **Amazon ECS** 等容器化环境。 - **EKS 集群的受控周期性升级**：在升级 Kubernetes 版本时，安全地将工作负载从旧集群迁移到新集群，避免因 API 废弃或控制器不兼容导致的服务中断。 技术原理上，VPC Lattice 在 VPC 内部及跨 VPC 之间提供了一个抽象的应用层网络。它通过**服务网络 (Service Network)**、**服务 (Service)** 和 **目标组 (Target Group)** 等概念，将服务间通信从底层 IP 地址和基础设施中解耦。利用其内置的**加权路由 (Weighted Routing)** 和基于路径/标头的流量控制能力，开发者可以精确地管理流向不同服务版本的流量，从而实现金丝雀发布、蓝绿部署等高级部署策略。 ## 实施步骤 该方案根据不同场景提供了具体的实施路径： 1. **场景一：三层Web应用升级** - **并行部署**：同时部署新旧两个版本的后端服务（如 `backend-v1` 和 `backend-v2`）。 - **注册目标组**：将每个版本的服务实例注册为 VPC Lattice 服务下独立的**目标组**。 - **初始流量路由**：通过配置监听器规则，初始将 100% 的流量指向 `backend-v1` 目标组。 - **渐进式流量切换**：逐步修改目标组的权重（例如，从 90/10 调整到 50/50，最终到 0/100），将流量平滑地迁移至 `backend-v2`。 - **监控与回滚**：在切换过程中持续监控新版本的性能指标。一旦发现问题，可立即将权重调回 `backend-v1`，实现秒级回滚。 2. **场景二：从 EC2 迁移至 EKS** - **服务注册与切换**：首先将现有的 EC2 应用注册为 VPC Lattice 服务，并更新所有客户端，使其通过 Lattice 提供的服务域名进行访问。这是一个一次性的改造。 - **部署容器化版本**：在 EKS 集群中并行部署应用的容器化版本，并将其注册为同一 Lattice 服务下的一个新目标组。 - **流量迁移**：利用加权路由策略，逐步将流量从 EC2 目标组平滑地迁移到 EKS 目标组。 - **下线旧环境**：在确认 EKS 版本稳定运行并承接所有流量后，安全地退役原有的 EC2 实例。 3. **场景三：EKS 集群升级** - **建立新集群**：建立一个运行新版本 Kubernetes 的 EKS 集群（如 `v1.32`），与旧集群（`v1.31`）并行存在。 - **部署并注册服务**：在新集群中部署应用，并将其注册为对应 Lattice 服务下的新目标组。 - **关联服务网络**：通过 **AWS Gateway API Controller**，可以利用 Kubernetes 原生的 Gateway API 资源自动完成服务的注册和关联。 - **跨集群流量切换**：在 Lattice 层面调整监听器规则的权重，将流量从旧集群逐步、可控地切换到新集群。 - **验证与退役**：验证新集群中的服务行为完全符合预期后，完成所有流量的切换，并安全地 decommission 旧集群。 ## 方案客户价值 - **显著降低运维复杂性**：通过统一的服务发现、路由和策略控制平面，替代了传统方案中需要手动配置 ELB、Route 53 和目标组的复杂组合，将基础设施管理转化为简单的服务策略管理。 - **实现零停机升级与迁移**：内置的**加权路由**能力支持金丝雀发布和蓝绿部署，允许企业以可控、渐进的方式发布变更。*即时回滚*机制可在出现故障时最大化保障业务连续性。 - **彻底解耦基础设施与应用**：服务消费者仅需关注稳定的 Lattice 服务名，无需关心后端服务是运行在 EC2、EKS 还是 ECS 上。这种抽象层使得底层架构的演进（如从虚拟机到容器）对上层应用完全透明，极大提升了技术架构的灵活性。 - **加速应用现代化进程**：为企业从单体应用迁移到微服务、从虚拟机迁移到容器提供了安全、低风险的实施路径，避免了“大爆炸式”迁移所带来的高昂成本和业务风险。 - **提升开发敏捷性**：将流量管理、安全策略等通用能力下沉到 VPC Lattice 平台，使应用开发团队可以更专注于业务逻辑本身，而无需为基础设施的变更而分心，从而缩短功能交付周期。 ## 涉及的相关产品 - **Amazon VPC Lattice**：解决方案的核心，提供应用层服务网络，负责服务发现、流量路由、安全策略和监控。 - **Amazon EC2**：作为传统应用的部署环境，是现代化迁移的起点。 - **Amazon EKS / Amazon ECS**：容器编排服务，作为现代化应用的目标部署环境。 - **AWS Gateway API Controller**：一个 Kubernetes 控制器，它将 Kubernetes Gateway API 资源与 VPC Lattice 进行集成，允许用户通过 K8s 原生方式管理 Lattice 服务。 - **Amazon Route 53**：在传统方案中用于实现基于 DNS 的流量切换，VPC Lattice 的使用简化了对其的直接依赖。 - **Elastic Load Balancers (ELB)**：在传统方案中用于流量分发，VPC Lattice 在服务间通信场景下提供了更高级和更简单的替代方案。 - **AWS IAM**：用于配置 EKS Pod Identity 等身份权限，确保跨环境的服务具有一致且最小化的访问权限。 ## 技术评估 该解决方案在技术上具有显著的先进性和可行性。 - **优势**： - **高度抽象与解耦**：其最大的技术优势在于提供了与底层计算资源无关的服务抽象层。这使得在 EC2、EKS、ECS 等混合计算环境中的服务治理变得极为简单和统一。 - **内置高级流量管理**：原生支持加权路由、路径匹配等高级流量控制策略，无需引入和维护复杂的第三方服务网格（Service Mesh）产品即可实现精细化的流量管理。 - **与 Kubernetes 生态深度集成**：通过 **AWS Gateway API Controller**，实现了与云原生生态的无缝对接，允许开发者使用熟悉的 Kubernetes API 来声明和管理外部网络资源，降低了学习和使用门槛。 - **可能的限制与注意事项**： - **API 兼容性依赖**：该方案解决了流量切换的工程问题，但无法解决应用升级本身带来的 API 版本不兼容问题。业务团队仍需在设计上保证 API 的向后兼容性。 - **配置一致性挑战**：在进行 EKS 集群升级等场景时，必须确保新旧环境中的 CRD、控制器版本、IAM 权限等配置高度一致，任何偏差都可能导致路由失败或权限问题。 - **健康检查的重要性**：方案的可靠性高度依赖于精确的健康检查配置。不当的健康检查可能导致流量被错误地路由到功能异常的实例。 - **端到端加密场景**：若应用内部使用 mTLS 等机制实现端到端加密，则需将 VPC Lattice 监听器配置为 **TLS Passthrough** 模式，以避免 Lattice 提前终止 TLS 连接。这增加了特定场景下的配置复杂性。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 使用 Amazon VPC Lattice 简化原地应用程序升级 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/streamline-in-place-application-upgrades-with-amazon-vpc-lattice/](https://aws.amazon.com/blogs/networking-and-content-delivery/streamline-in-place-application-upgrades-with-amazon-vpc-lattice/) **发布时间:** 2025-10-21 **厂商:** AWS **类型:** BLOG --- ## 引言 在本文中，我们将介绍如何使用 [Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/) 执行原地应用程序升级，同时保持系统的可靠性、安全性和性能。无论您是升级经典的三层 Web 应用程序、从 [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) 迁移到容器，还是管理定期的 Kubernetes 升级，都面临一个共同的挑战：在将基础设施与应用程序逻辑解耦的同时，确保零停机。过去，实现这一目标需要结合使用基础设施编排、服务发现 (service discovery) 和流量路由 (traffic routing) 机制。然而，借助 VPC Lattice，您可以简化此过程，从而以最小的中断执行原地升级。 我们假设您已在环境中使用 VPC Lattice。如果您是 VPC Lattice 的新手或尚未实施，我们建议您参考这篇关于 [Amazon VPC Lattice DNS 迁移策略和最佳实践](https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-vpc-lattice-dns-migration-strategies-and-best-practices) 的博客文章。本文将探讨 VPC Lattice 如何简化以下三种场景： 1. 三层 Web 应用程序的原地升级 2. 从 Amazon EC2 迁移到 [Amazon EKS](https://aws.amazon.com/eks/) 或 [Amazon ECS](https://docs.aws.amazon.com/ecs/) 3. EKS 集群的受控定期升级 对于每个用例，我们将定义问题，概述不使用 VPC Lattice 的传统方法，并演示 VPC Lattice 如何简化和增强升级过程。 ## 解决方案概述 以下各节将逐步介绍 VPC Lattice 如何简化三种不同的场景。 ### 场景 1：三层 Web 应用程序的原地升级 在由前端、后端 (应用层) 和数据层 (通常是 [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) 等数据库) 组成的三层架构中，升级任何一层，尤其是后端，都需要精心的编排。当升级涉及 API 接口或数据模式的变更时，挑战会成倍增加，这可能会影响下游消费者和服务的依赖关系。 考虑这样一个场景：您有不同的前端、后端和数据库服务。您可能需要部署一个引入了业务逻辑变更和模式更新的新版本后端服务。升级必须在最小化停机时间的同时执行，并确保不破坏任何 API 约定。层间通信，例如从前端到后端的通信，必须在整个部署过程中保持稳定。部署过程中的任何失败都可能导致前端请求访问到部分升级的后端，从而导致行为不一致或应用程序错误。 #### 不使用 VPC Lattice 您可以通过 Amazon Web Services (AWS) 的网络服务来编排升级，例如 [Elastic Load Balancers (ELBs)](https://aws.amazon.com/elasticloadbalancing/) 、[Amazon Route 53](https://aws.amazon.com/route53/) 和 [Auto Scaling 组 (Auto Scaling groups)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) 。流量切换使用加权 DNS 路由或通过 [Application Load Balancer (ALB)](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) 目标组实现的蓝绿部署 (blue/green deployments)。尽管这种方法可行，但它需要在各层之间进行大量的负载均衡器、路由规则和健康检查的手动配置。基于 DNS 的切换限制和环境同步挑战使渐进式交付 (progressive delivery) 模式变得复杂。缺乏统一的流量控制平面 (traffic control plane) 增加了操作复杂性和回滚风险，使得服务升级更容易出错且安全执行所需的时间更长。 #### 使用 VPC Lattice VPC Lattice 引入了一种内置方式来定义、暴露和控制 VPC 内部及跨 VPC 的服务间通信，而无需管理每个服务各自的负载均衡器，如图 1 所示。  图 1: 使用 Amazon VPC Lattice 的三层 Web 应用程序 使用 VPC Lattice，您三层架构中的每一层 (前端、后端，甚至面向数据库的逻辑) 都可以注册为 [Lattice 服务网络 (Lattice service network)](https://docs.aws.amazon.com/vpc-lattice/latest/ug/service-networks.html) 中的一个 [服务 (Service)](https://docs.aws.amazon.com/vpc-lattice/latest/ug/services.html) 或 [资源 (Resource)](https://docs.aws.amazon.com/vpc-lattice/latest/ug/vpc-resources.html) 。前端服务不是通过硬编码的端点或负载均衡器来访问后端服务，而是通过一个由服务名称派生的 Lattice 管理的 DNS 名称 (例如 `backend-service.1d2.vpc-lattice-svcs.region.on.aws`)，由 VPC Lattice 管理路由、健康检查和策略。虽然 VPC Lattice 提供自动生成的 DNS 名称，但大多数组织更喜欢使用自己的自定义域名 (例如 `backend.internal.example.com`) 以提高可读性和可维护性。 在升级过程中，您可以： - 与现有版本 (`backend-v1`) 并行部署新的后端版本 (`backend-v2`)。 - 将每个版本的服务注册为 Lattice 服务网络中的一个独立 [目标组 (target group)](https://docs.aws.amazon.com/vpc-lattice/latest/ug/target-groups.html) 。 - 使用 Lattice 加权目标组 (weighted target groups) 开始时将 100% 的流量导向 `backend-v1`，然后通过修改权重，以受控的方式逐步将流量切换到 `backend-v2`。 - 如果指标显示失败，可以无缝地将流量回滚到 `backend-v1`，而无需更改 DNS、负载均衡器配置或客户端应用程序。 #### 注意事项 - **API 版本管理:** 保持 API 约定的向后兼容性，以防止服务中断。 - **健康检查配置:** 为新旧后端版本配置适当的健康检查，以确保正确的流量路由。 - **服务发现一致性:** 在 VPC Lattice 中使用一致的服务命名约定，以维持正确的服务发现。 - **流量切换策略:** 为版本间的渐进式流量切换定义明确的指标和阈值。 - **回滚程序:** 保留原始配置的快照，以便在出现问题时能够快速回滚。 ### 场景 2：从 Amazon EC2 迁移到 Amazon EKS 或 Amazon ECS 许多组织因其灵活性和熟悉度，最初将应用程序直接托管在 Amazon EC2 上。随着时间的推移，当可扩展性、可移植性和运营一致性变得更加关键时，他们会寻求容器化解决方案，特别是将 [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) 或 [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/ecs/) 作为其现代化战略的下一步。虽然 ECS 提供了一个更简单、AWS 原生的容器编排解决方案，但许多组织因其 Kubernetes 生态系统而选择 Amazon EKS。 然而，将生产工作负载从 Amazon EC2 迁移到容器化环境会带来一系列独特的挑战。现有的服务或消费者，如内部微服务、API 和第三方合作伙伴，通常与托管在 Amazon EC2 上的端点紧密集成，这些端点通常通过 ELB 暴露，并通过硬编码的 DNS 或 IP 地址访问。这种紧密耦合使得渐进式迁移变得困难，因为变更可能会波及所有消费者。 除了将应用程序容器化，迁移还涉及建立一个并行的容器环境、配置网络、管理 [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) 和安全过渡，并引入流量切换，所有这些都不能破坏 API 约定或影响正常运行时间。一次性全面切换通常耗时且实施复杂。具有实时流量和严格 SLA 的生产系统要求渐进式、低风险的过渡。然而，在不中断消费者或长期重复基础设施的情况下运行迁移仍然是一个运营障碍。在以下部分中，我们将重点关注向 EKS 的迁移，尽管对于 ECS 的实现，总体概念和挑战仍然相似。 #### 不使用 VPC Lattice 我们部署一个 EKS 集群，配置网络，并将应用程序容器化。服务通过 ALB、AWS Gateway API 或 NGINX 暴露，流量通过 Route 53 重定向。IAM 角色、策略和安全组被重构以实现最小权限，流量则通过更改 DNS TTL、加权记录或 ELB 目标切换来转移。这种方法使跨环境的服务发现、端点管理和安全同步变得复杂。没有统一的路由层，管理传统服务和现代化服务之间的流量会很麻烦，从而造成运营拖累。 #### 使用 VPC Lattice VPC Lattice 通过将服务间通信和流量路由抽象成一个统一的、策略驱动的框架，为服务迁移提供了一条简化且更安全的路径。您的服务无论是托管在 Amazon EC2 上还是 Amazon EKS 上，都可以注册为单个 Lattice 服务下的目标，而无需依赖紧密耦合的 IP、负载均衡器或 DNS。 图 2 和以下几点展示了使用 VPC Lattice 进行迁移的过程： 1. **注册托管在 Amazon EC2 上的服务** (例如 `ec2-service-v1`) 为一个 VPC Lattice 服务，并使用自定义域名 (例如 `ec2-service-v1.lattice.local`) 将其暴露。 2. **更新所有消费者** (前端、API、合作伙伴) 以将流量路由到 Lattice 服务名称，而不是 Amazon EC2 特定的端点。这是一次性变更。 3. **并行部署托管在 Amazon EKS 上的服务版本** (`eks-service-v1`)，并将其注册到同一个 Lattice 服务下的新目标组中。 4. **使用 Lattice 侦听器规则 (listener rules)** 最初将 100% 的入站流量路由到 Amazon EC2 后端。 5. 通过更新侦听器规则中的加权目标组，**逐步将流量从 Amazon EC2 切换到 Amazon EKS**，从而实现渐进式部署，而无需修改 DNS 记录或更换负载均衡器。 6. **监控性能并在需要时立即回滚**，只需将路由权重调整回 Amazon EC2，所有操作都无需修改客户端。  图 2: 使用 VPC Lattice 从 Amazon EC2 迁移到 Amazon EKS VPC Lattice 通过将流量路由与基础设施解耦，消除了从 Amazon EC2 到 Amazon EKS 迁移的复杂性和风险。它使团队能够逐步演进架构，而无需对上游消费者进行颠覆性更改或彻底改造旧的发现机制。Lattice 通过在基础设施层面管理服务端点、流量策略和访问控制，实现了更安全、更快速、更具成本效益的现代化之旅。有了 Lattice，您不再需要围绕 DNS、ELB 和手动安全更新来制定迁移计划。相反，您正在以与基础设施无关的精确度管理服务身份和流量流，这在过渡期间 Amazon EC2 和 Amazon EKS 共存的混合环境中是一项至关重要的能力。 请确保此处也应用与场景 1 中概述的一致的运营注意事项。 ### 场景 3：EKS 集群的受控定期升级 升级 EKS 集群是一项关键操作，会影响控制平面的稳定性和工作负载的可用性。Kubernetes 版本更新可能会弃用 API、改变调度行为并中断控制器交互。这在具有严格服务水平目标的生产环境中会产生重大风险。 关键挑战包括确保所有应用程序都能与新版本的 Kubernetes 协同工作，检查 [自定义资源定义 (custom resources definitions)](https://www.eksworkshop.com/docs/observability/resource-view/workloads-view/extensions_view) (CRDs) 和控制器是否仍能正常工作，以及在不中断的情况下安全地将应用程序迁移到新节点。这些升级方法可能复杂且容易出错。 #### 不使用 VPC Lattice 与前一个场景一样，我们配置一个具有复制配置的并行 EKS 集群，将工作负载部署到新的节点组，并通过污点 (taints) 实现流量隔离。流量切换通过新的 Ingress 资源和 DNS 更新进行。尽管这种模式可行，但它通过 DNS 传播延迟、负载均衡器 IP 变动和集群范围的资源冲突引入了运营摩擦。如果在验证期间集群范围的资源出现偏差，可能会出现 CRD 和控制器冲突。双集群方法分散了安全策略和可观察性，而共享资源依赖关系则使干净的切换和回滚过程变得复杂。 #### 使用 Amazon VPC Lattice VPC Lattice 引入了一个解耦的服务网络抽象，将此过程转变为一个可组合的、策略驱动的迁移。通过将服务提升为控制单元，Lattice 实现了新旧集群之间的无缝互操作。 以下几点展示了使用 VPC Lattice 的升级流程： 1. **启动一个新的 EKS 集群 (v1.32)**，其配置与旧集群对等，包括附加组件、[EKS Pod 身份 (EKS pod identities)](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) 、控制器版本和安全策略。 2. 在新集群中**部署您的工作负载**，并修改节点选择器/标签。 3. 将每个升级后的服务**注册**到相应的 Lattice 服务，作为一个新的目标组。 4. 最初使用 Lattice 侦听器规则将**所有流量路由**到 v1.31 的服务，将 100% 的权重目标指向旧集群。 5. 在侦听器层面**应用加权路由策略** (例如，80% → v1.31 集群，20% → v1.32 集群)。 6. 使用实时的 [Lattice 指标 (Lattice metrics)](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-cloudwatch.html) 和自定义可观察性信号 (例如，5xx 错误率、延迟、请求量) **验证服务行为**。 7. **逐步增加**流向 v1.32 服务的流量份额。与持续集成/持续部署 (continuous integration/continuous deployment) (CI/CD) 管道集成以实现自动化。 8. 如果出现问题，通过恢复流量权重**执行即时回滚**，无需排空 Pod、等待 DNS TTL 延迟或回滚控制器。 9. **完全排空** v1.31 的流量，停用旧集群，并注销目标。  图 3: EKS 集群的受控定期升级 图 3 展示了与 VPC Lattice 集成的 [AWS Gateway API Controller](https://www.gateway-api-controller.eks.aws.dev/latest/) 。这使您能够使用 Kubernetes Gateway API 资源来定义服务网络、服务、侦听器和目标注册。要了解更多信息，请参阅这篇 [AWS 容器博客文章](https://aws.amazon.com/blogs/containers/introducing-aws-gateway-api-controller-for-amazon-vpc-lattice-an-implementation-of-kubernetes-gateway-api/) 。 #### 注意事项 - **控制器偏差:** 确保在新集群中重新安装相同版本的 CRD (例如来自 [AWS Gateway API Controller](https://www.gateway-api-controller.eks.aws.dev/) )。版本不匹配可能导致路由失败或不一致的 Ingress 行为。 - **跨集群服务命名:** 使用相同的服务名称和端口映射，以在 Lattice 服务网络内保持逻辑一致性。 - **健康检查对等:** 验证两个版本都实现了一致的健康检查。Lattice 会自动注销失败的目标。 - **IAM 一致性:** 如果服务依赖 EKS Pod Identity 进行细粒度的 IAM 访问，请确保在新集群中重新创建相应的身份关联和角色权限，以避免授权失败。 - **TLS 终止行为:** 如果 TLS 终止发生在集群内部 (例如通过服务网格实现的 mTLS)，并且您通过 VPC Lattice 暴露服务，请考虑使用 [TLS 侦听器 (TLS Passthrough)](https://aws.amazon.com/about-aws/whats-new/2024/05/amazon-vpc-lattice-tls-passthrough/) 。这可以确保加密流量 (例如客户端证书) 通过 Lattice 而不在 VPC Lattice 中终止 TLS。 VPC Lattice 将 Amazon EKS 升级从颠覆性的基础设施事件转变为平滑、可逆的工作流。逻辑服务名称在不同版本之间保持一致，因此应用程序团队可以在不触及 DNS 或 ELB 的情况下推出变更。团队可以利用内置的指标、健康检查和流量切换功能，自信地进行切换，并在需要时立即回滚。安全策略保持统一，集群操作不再阻碍功能交付。最终实现了一个简化的、以应用程序为中心的升级过程，降低了运营风险并提高了开发人员的敏捷性。 ## 结论 在本文中，我们探讨了 Amazon VPC Lattice 如何简化三种现代化场景：三层 Web 应用程序的原地升级、从 Amazon EC2 迁移到 Amazon EKS，以及受控的定期 EKS 集群升级。VPC Lattice 提供了一个统一的、与基础设施无关的服务网络层，从而抽象了流量路由、安全性和可观察性，消除了运营复杂性。因此，团队可以以最小的中断、一致的安全性和实时的可见性来执行增量升级和迁移。最终，VPC Lattice 使组织能够自信地对其应用程序架构进行现代化改造，在整个云演进过程中保持可靠性和敏捷性。 ## 关于作者  ### Mokshith Kumar Mokshith Kumar 是 AWS 核心网络领域的高级市场推广 (GTM) 专家解决方案架构师，为北美地区的 ISV 和 FSI 客户提供支持。他在制定 GTM 策略、领导战略计划、发现新机会、加速 AWS 网络服务的采用以及推动有影响力的客户和合作伙伴互动方面发挥着关键作用。他喜欢直接与客户合作解决复杂的云网络挑战，并热衷于帮助他们实现架构现代化。  ### Rishi Katdare Rishi Katdare 是一位高级业务战略与管理领导者，帮助组织通过 SaaS 转型加速增长。目前在 AWS，他负责全球专家组织中北美 ISV 和 FSI 领域的核心网络 GTM。Rishi 在产品管理和 GTM 方面拥有超过 20 年的专业知识，领导全球团队执行战略计划。他拥有两项专利、一个技术管理行政工商管理硕士学位，以及新泽西理工学院的计算机工程学士学位。 <!-- AI_TASK_END: AI全文翻译 -->