概览

本文档概述了对 AWS 边缘服务（例如 CloudFront、Lambda@Edge 和 AWS WAF）配置进行更改的最佳实践。这些更改可能包括更新 CloudFront Function 代码、修改 Lambda@Edge 函数的运行时、在 CloudFront 中添加新的缓存行为、更新 WAF 规则或启用新的 CloudFront 功能（例如 HTTP/3）。如果您的配置相对静态且简单，并且更喜欢使用 UI 进行手动管理，则可以依靠 AWS 管理控制台。但是，对于更复杂的设置，建议利用 CI/CD 管道以受控方式部署配置更改和代码更新。

CI/CD 管道

基础设施即代码（IaaC）

CI/CD 管道可提高开发速度和代码质量以及通过自动化减少人为错误，从而缩短软件发布周期。可以通过基础设施即代码（IaC）在 CI/CD 管道中管理 CloudFront 等 AWS 边缘服务和边缘功能。边缘资源可以通过 API（例如 CloudFront 的 API）、AWS CLI 或更高级别的抽象工具（例如 CloudFormation、Terraform 和 AWS 云开发工具包[CDK]）进行部署。

基于 CDK 的 IaC

基于 CloudFormation 的 CDK 让您可以使用编程语言部署 AWS 资源，从而提供最高级别的抽象。例如，以下三行 JavaScript 代码可以部署以 CloudFront 为源的 S3 存储桶：

const myBucket = new s3.Bucket(this, 'myBucket');
new cloudfront.Distribution(this, 'myDist', {
  defaultBehavior: { origin: new origins.S3Origin(myBucket) },
});

查看 CDK 构造库以获取要包含在 CDK 代码中的可重用构造。

部署和编排

在 CI/CD 管道中，您需要一个用来存储代码（CDK 代码、边缘函数代码）的存储库（例如 AWS CodeCommit）、一个部署基础设施的工具（例如 AWS CodeDeploy），以及一个管理管道步骤的编排工具（例如 AWS CodePipeline）。这篇博客文章演示了如何使用 AWS 开发人员工具为 CloudFront 实施 CI/CD 管道，但您也可以使用自己喜欢的 CI/CD 工具执行此操作。为 AWS Edge 服务构建 CI/CD 管道时，请考虑以下限制：

  • 可以从任何 AWS 区域部署 CloudFront、CloudFront Functions 和区域性 AWS WAF WebACL
  • Lambda@Edge 以及适用于 CloudFront 的 WAF WebACL 只能从弗吉尼亚北部的 us-east-1 区域部署。
  • 必须在 Firewall Manager 管理员的 AWS 账户中部署 Firewall Manager 策略

测试和暂存

可以在不同的级别测试您的边缘配置。首先，可以复制您的基础设施，例如在测试账户中使用 AWS WAF WebACL 测试 CloudFront 分发。可以在开发阶段完成此操作，也可以在转到生产环境之前执行自动化功能测试。请注意，您不能使用两个具有相同 CNAME 的 CloudFront 分发。因此，您需要根据 CI/CD 阶段区分 CloudFront 资源的 CNAME 配置。例如，可以将 CloudFront 的域名（例如 xyz.cloudfront.net）用于开发阶段，使用专用的 CNAME 进行暂存（例如 staging.www.example.com），并使用公共 CNAME 进行生产环境部署（例如 www.example.com）。还可以按阶段区分安全控制措施，例如在暂存阶段使用 AWS WAF 限制对特定 IP 进行的访问。

当新的配置通过测试之后，可以使用 CloudFront 的持续部署功能实施一种金丝雀发布方法，以测试一小部分流量导致生产环境发生的变化。使用此功能，可以为生产分发创建一个不同的配置，并只向其发送一部分全局流量。可以通过两种方式将流量路由到新的配置：使用特定的请求标头（这对于合成测试非常有用），或者使用加权策略将可配置的流量百分比路由到新的配置，并可以选择启用粘性。在当前版本的此功能中，只能测试对 CloudFront 配置参数中的一部分进行的更改。请参阅此文档，以便更好地了解使用此功能可以测试的内容。

动态配置

考虑这样一个场景：多个团队对 CloudFront 配置进行更改，但单个团队负责管理所有团队的 CI/CD 管道。例如，不同的团队可能管理不同的微服务，所有微服务都将其 API 暴露在由单个 CloudFront 分发托管的主域上。如果您允许每个团队访问 CloudFront 分发的完整配置，则会导致单个错误更改的影响范围扩大。反之，如果只允许 CI/CD 团队更改 CloudFront 分发，将会降低开发速度并在发布生命周期中引入瓶颈。相反，可以根据每个微服务团队所拥有的部分配置来动态生成配置。在一个简单的实施中，每个团队都可以在 S3 存储桶中托管的基于文本的文件中管理自己的路由配置（缓存、边缘功能等）。在 CI/CD 管道中，可以引入一个额外的步骤，以使用不同的部分配置文件动态创建最终的 CloudFront 配置。

AWS WAF 和 AWS Shield 部署

可以使用前面介绍的相同工具，在 CI/CD 管道中部署 Shield 和 WAF 服务。

不过，建议使用 AWS Firewall Manager 来部署 WAF 规则和 Shield 保护措施，以获得以下优势：

  • 它便于实施中央安全治理（例如部署中央规则以及应用程序团队管理的规则）
  • 它的部署速度更快，这对于使用 AWS WAF 修补关键漏洞至关重要。
  • 它简化了跨账户和异构 CI/CD 管道（例如，从收购继承的）的部署。但是，使用这种方法时，如果您使用具有漂移检测功能的 CI/CD 管道，则需要管理漂移。

此外，还可以使用 CI/CD 管道在管理员账户中更改 Firewall Manager 策略，然后，Firewall Manager 将在 AWS 组织中部署这些策略，如 OLX 所示。

可以使用不同的策略将 WAF 规则安全地部署到生产环境中。可以在计数模式下向一个现有的 WebACL 添加新的规则，然后将其切换到阻止模式。不过，采用这种方法时，需要注意 WebACL 的最大 WCU。另一种方法是将更改部署到暂存 WebACL，并在暂存环境中测试更改。

资源

此页内容对您是否有帮助？

 反馈