在亚马逊云科技上打造合规的应用架构

专题摘要

本专题系列，围绕着客户 VPC 内部的服务，VPC 外部的托管服务以及两者之间的交互进行了深入分析。这些分析有助于我们理解亚马逊云科技上更加复杂的架构。本章节中，我们对一些具有代表性的架构进行分析，来进一步加深理解。

本文是“在亚马逊云科技上围绕 Amazon VPC 打造内外兼修的合适架构”系列主题的第八部分，也是最后的总结部分。

本系列专题由如下几部分组成：

场景介绍

在亚马逊云科技上，可以根据需求，结合 VPC 内部的服务和 VPC 外部无服务器的托管服务，构建灵活的，安全的架构。本文着重对一些比较经典的架构进行分析。

场景一：对亚马逊云科技 Amazon EKS 服务的分析

亚马逊云科技提供的 Amazon EKS 服务是一个典型的客户 VPC 外部的托管服务和 VPC 内部的实例进行相互通信的场景。EKS 集群由两个 VPC 组成：托管的 Kubernetes 控制平面运行在由亚马逊云科技直接管理的 VPC 中，容器的 Kubernetes 工作节点（EC2 实例）以及其他集群使用的基础设施（如负载均衡器）运行在由客户管理的 VPC 中。为了能够使 EKS 集群运行，托管的 Kubernetes 控制平面中的 Kubernetes API 服务需要和 EC2 工作节点进行双向通信：

一方面，EKS 控制平面中的 Kubernetes API 服务，会在客户 VPC 中创建弹性网络接口 ENI 作为私有端点，用于下发从 Kubernetes API server 发起的到集群工作节点的编排命令，这和我们在前面讲到的 VPC 外部的托管服务访问 VPC 内资源时，通过创建弹性网络接口 ENI 和 VPC 内部的资源进行通信是一致的。
另一方面，数据平面的工作节点中的 Kubelet 需要向 Kubernetes 控制平面发送注册和状态信息，因此所有在客户 VPC 中的工作节点（Worker Node）都需要能够连接到托管的 Kubernetes API 服务器。该连接的路由有两种方式，或者通过互联网连接到 Kubernetes API 服务的公有端点（Endpoint public access = Enabled），或者复用前面已经创建的私有端点（Endpoint private access = Enabled），这取决于在创建集群时的配置。这两种方式特别类似于我们前面讲到的 VPC 中的服务要调用 VPC 外部托管服务时，可以通过互联网或者接口终端节点的方式进行访问，后者私密性更高。

另外，从管理员的角度，用户可以直接访问位于 Kubernetes 控制平面内的 API 服务，来发送 kubectl 命令。访问的方式根据设置也分为通过互联网还是通过创建的私有端点进行访问：

如果存在公网访问的通道，即 Endpoint public access = Enabled，则通过互联网直接访问 EKS 服务中的 Kubernetes API 服务，运行 kubectl 命令。
当不存在公网访问的通道的私有部署的模式下，即 Endpoint public access = Disabled 并且 Endpoint private access = Enabled，则会通过前面创建的私有端点进行访问，这种情况下，该私有端点承接了双向通信。这也意味着用户需要通过堡垒机或者别的方式例如 VPN 等接入到该 VPC 中才能访问。

在集群私有部署模式下，工作节点无法访问互联网，那么如果集群上的 Pod 要访问其他的 VPC 外部的托管服务，例如 Amazon S3， Amazon SNS，则需要创建单独的 VPC 终端节点。另外，Amazon EKS 的 API 并不等同于保证集群正常运行的 Kubernetes API， EKS 的 API 和其他的托管服务的 API 完全一样，可以通过互联网直接访问，或者通过创建专门的 VPC 终端节点，从 VPC 内部发起私密访问。

场景二：部署私有 Amazon API Gateway 私有集成后端服务

目前应用程序开发的一个大趋势，就是大量使用 API 来支持产品的后端技术，以满足和移动端、物联网以及 Web 应用程序的前端通信。而随着微服务应用程序设计模式的流行，重量级应用程序的后端内部服务相互通信也越来越多使用 API。大规模、安全且以最小的运营开销管理 API 成为了客户的一个重要需求。

Amazon API Gateway 有许多高级的功能，例如和 Amazon Cognito 用户池集成进行用户权限验证、分级定价、访问限流、阶段部署和 API 密钥等，因而是客户管理 API 的有力工具。对于满足互联网应用的前后端通信，我们可以使用边缘端或者区域的 API Gateway。

API Gateway 可以和后端服务例如 Amazon Lambda、Amazon EC2 或 Amazon ECS 等私有集成。通常，前端应用通过互联网访问 API Gateway 的公有访问端点进行交互。而对于企业内部 API 服务，我们可以借助私有部署的 REST API Gateway，和后端的各种私有服务进行集成，来提供更加安全的内部 API 服务，私有部署的 REST API Gateway 无法通过互联网直接访问。

由于 API Gateway 是在客户 VPC 外部的托管服务，因此，对于私有部署的 REST API，需要在客户 VPC 建立接口终端节点，通过 PrivateLink 来访问（invoke）在私有部署的 API Gateway。而私有的 API Gateway 同样可以通过基于 PrivateLink 的 VPC Link 技术来私有集成客户在该 VPC 或者其他 VPC 中的后端服务。前者是一个客户 VPC 内部访问外部托管服务的过程，而后者是客户 VPC 外部的托管服务访问 VPC 内部服务的过程，都是基于 PrivateLink 技术。

如上图所示，在客户 VPC 内部配置访问私有部署的 API Gateway 端点的 VPC 接口终端节点后，通过在客户 VPC 中指定的子网中创建弹性网络接口 ENI，来私有地访问 API Gateway 的私有接口，进而通过 VPC Link 私有地访问后端集成的服务。

这里需要明确一点：客户 VPC 中的接口终端节点和私有部署的 REST API Gateway 不是一一对应的，可以是多对多的关系。我们可以在访问 API Gateway 的 VPC 终端节点上设置资源策略（Resource Policy），来设定哪些私有 API Gateway 可以通过该终端节点访问，还可以在 API Gateway 中设置资源策略来限制该 API Gateway 只接受来自于哪些 VPC 中的访问。

场景三：创建 Amazon Glue 连接，通过互联网访问其他云上的数据库

通过 Glue 可以和各类数据源建立连接，通常这些数据源在亚马逊云科技的某个 VPC 里面，所以我们只需要在相应的 VPC 里面建立连接就可以访问到。然而，在某些场景下，我们需要通过互联网直接访问本地数据中心或其他的云平台的数据库来获取数据，在这种情况下，我们可以在亚马逊云科技中单独创建一个 VPC，通过在 VPC 的私有子网里构建 Glue Connection 来访问数据库。如下图所示：

这里，Glue 的连接会在 VPC 的私有子网而不是公有子网中生成弹性网络接口 ENI。数据访问过程，经过公有子网的 NAT 网关后，经 IGW 连接互联网，访问本地数据中心的数据库。本质上，这是一个客户 VPC 外的托管服务 Amazon Glue 访问客户 VPC 内部的资源的场景。这里的 NAT 网关非常有必要，因为即使为 Glue Connection 配置了公有子网，也无法获得公有 IP，因而无法访问本地数据库。因此需要配置私有子网，经过 NAT 网关通过互联网才能访问本地数据库。另外 NAT 网关可以绑定 EIP，这样，在本地数据中心可以根据 EIP 的地址进行防火墙过滤设置。

在上面的架构中由于 Glue Connection 可以访问到互联网，所以不需要创建 VPC 终端节点就可以访问 Amazon S3 的公开 API 访问端点。而如果要建立这类服务的私密连接，则需要创建相应的 VPC 终端节点。另外，如果 Glue 中的代码涉及到对 Glue 本身的操作，例如：对 Glue 上下文的一些配置进行重新设置等，则需要同时构建访问 Glue 的终端节点。

场景四：在亚马逊云科技上构建安全的，可扩展的的无服务器 Web 应用

在亚马逊云科技上构建安全的，可扩展的 Web 应用，是一个普遍的需求，下图展示了一个经典 Web 应用的无服务器架构图。

在上面的架构中，我们创建公有的区域 REST API Gateway，利用其流量管理，访问控制，访问限流，API 版本管理的功能，更好的管理后端服务。该 Web 应用结合 Amazon Cognito 进行认证，并为 API Gateway 提供鉴权。

为了提升最终用户端的访问效率，我们部署了 CloudFront 服务，通过边缘站点为客户提供内容缓存。后端集成 Amazon API Gateway 作为源站。由于 API Gateway 为公有部署，因此会面临潜在网络攻击，因此我们部署了 Amazon WAF，并设置 WAF ACL 来提供风险防护措施。该 WAF ACL 中只允许来自于 CloudFront 的请求，拒绝其服务的直接请求。

我们为了能够让 WAF 信任 Cloud Front 服务，会在 Cloud Front 服务的请求中增加 HTTP Header“X-Origin-Verify”作为凭据，而 WAF ACL 会检查这个 Header 信息的正确性，如果此 Header 值和 WAF ACL 中的配置一致，则通过，否则拒绝。

为了保证该 Header 的安全性，需要对此 Header 内容进行轮换。我们通过在 Amazon Secrets Manager 中进行定期轮换，并触发 Lambda 来更新 CloudFront 和 WAF ACL 中的对应值。

API Gateway 后面可以私有集成完全无服务器的服务 Amazon Lambda。Lambda 后端是完全无服务器的设计，可以将文件存储到 Amazon S3 对象存储中，键值缓存存储到 Amazon DynamoDB 中，而关系型数据则可以存放到 Amazon Aurora Serverless 数据库当中。Aurora Serverless 数据库提供了单独的 Data API 获取，这样避免了通过设置 VPC 和子网访问 Aurora Serverless 造成的 Lambda 冷启动问题。

REST API Gateway 还可以通过 VPC Link 私密连接后端的 NLB，NLB 可以集成不同的目标组，也可以集成 ALB 来达到网络第 7 层的负载均衡。这里需要注意 REST API Gateway 的 VPC Link 基于 PrivateLink 技术，不可以直接集成 VPC 中的 ALB。

结论和总结

Amazon VPC 为用户提供了一个逻辑隔离的虚拟私有云环境。VPC 内部的资源可以看做是用户私有资源的集合。客户可以利用子网（Subnet）和安全组（Security Group）进行各种细粒度的网络规划并对 VPC 内部资源和服务的网络交互进行管控。除了这些，让 VPC 变得更加强大的，是围绕着 VPC 的各种连接技术，使得 VPC 不再是自嗨的孤岛。借助不同的技术，一个 VPC 可以和别的 VPC，本地数据中心以及互联网进行互联。除此之外，还可以和 VPC 外部的亚马逊云科技的托管服务交互。这样对用户来说，既保证了必要的网络隔离，又能按需提供网络的连通。

本系列专题，围绕着 VPC 内外资源和服务的交互进行了深入的探讨，以期给读者一个宏观的、整体的认识。我们在专题中分析了一些常用的场景，并对一些重点场景进行了实验。根据实验结果，对重点的，容易疏忽的知识点进行了总结。我们还基于这些知识点，对亚马逊云科技中的一些典型架构进行了分析，以帮助读者更好的理解和消化本系列专题中的内容。

我们在分析的时候，为了使主题更加集中，没有过多讨论其他的设计要素。在实际的架构中，还需要按照亚马逊云科技的优良架构方法，结合卓越运营、安全性、可靠性、性能效率、成本优化、可持续等方面进行架构设计。

希望这样的整体介绍，能够帮助读者，尤其是初学者理清亚马逊云科技上的一些重要设计理念，这对于在亚马逊云科技上打造合适的架构有着重要的意义。