AWS DDoS 弹性最佳实践方案 · Amazon Web Services – AWS DDoS 弹性最佳实践方案 2016 年6 月 5 / 19 而在分布式拒绝服务（简称DDoS）攻击当中，攻击者会利用多个源——可能由大量协作者组成或者共同控制

AWS DDoS 弹性最佳实践方案

2016 年 6 月

Amazon Web Services – AWS DDoS 弹性最佳实践方案 2016 年 6 月

2 / 19

© 2016 年，Amazon Web Services 有限公司或其附属公司版权所有。

通告

本文档所提供的信息仅供参考，且仅代表截至本文件发布之日时 AWS 的当前产品与实践情况，若有变更恕不

另行通知。客户有责任利用自身信息独立评估本文档中的内容以及任何对 AWS 产品或服务的使用方式，任何

“原文”内容不作为任何形式的担保、声明、合同承诺、条件或者来自 AWS 及其附属公司或供应商的授权保

证。AWS 面向客户所履行之责任或者保障遵循 AWS 协议内容，本文件与此类责任或保障无关，亦不影响 AWS

与客户之间签订的任何协议内容。


3 / 19

目录

摘要 4

简介 4

DDoS 攻击 4

基础设施层攻击 6

应用层攻击 7

防护技术 8

基础设施层防护(BP1, BP3, BP6, BP7) 9

应用层防护(BP1, BP2, BP6) 12

攻击面削减 13

AWS 资源的模糊处理(BP1, BP4, BP5) 13

运营技术 15

可视化 15

支持 16

总结 17

贡献者 17

备注 17

摘要

本份白皮书面向希望提升运行在 Amazon Web Services（简称 AWS）之上应用的弹性，旨在应对分布式拒绝

服务（简称 DDoS）攻击活动的客户。本文将对 DDoS 攻击、AWS 所提供之功能、防护技术以及 DDoS 弹性

参考架构做出概述，从而作为一份指南性资料帮助大家维持应用程序可用性。

简介

本份白皮书面向 IT 决策制定者与安全人员，旨在帮助已经熟知网络、安全与 AWS 基础概念的用户应对 DDoS

攻击问题。其中各个章节中的 AWS 说明文档链接将提供更为详尽的最佳实践或者功能说明。大家亦可以参考

AWS re:Invent 大会 SEC307——利用 AWS 建立一套 DDoS 弹性架构 1与 SEC306——防御 DDoS 攻击 2作为

补充以获取更多细节信息。

DDoS 攻击

拒绝服务（简称 DoS）攻击是一类旨在令网站或者应用无法正常向最终用户进行服务交付的攻击活动。为实现

这一目标，攻击者利用一系列技术手段大量消耗我们的网络或者其它资源，从而破坏合法最终用户的正常访问。

着眼于最简单的实现方式，DoS 攻击由单一攻击者立足于单一源向目标执行攻击，具体如图一所示。

图一：DoS 攻击示意图


5 / 19

而在分布式拒绝服务（简称 DDoS）攻击当中，攻击者会利用多个源——可能由大量协作者组成或者共同控制

——以编排起规模更大的针对性攻击。如图二所示，在 DDoS 攻击当中，每一协作方或者作为组成部分的主机

都会参与到攻击当中，从而生成足以吞没攻击目标的数据包或请求洪流。

图二：DDoS 攻击示意图

DDoS 攻击常见于开放系统系统互连（简称 OSI）模型中的 3、4、6 与 7 层，如表一所示。其中 3 层与 4 层攻

击对应 OSI 模型中的网络与传输层：本份白皮书将其划归为基础设施层攻击。而 6 层与 7 层攻击则对应此 OSI

模型的表现与应用层：本份白皮书将其划归为应用层攻击。

二者间的区别非常重要，因为攻击活动中的目标层类型不同，构建对应弹性所使用的技术也不尽相同。

# 各层单位描述矢量示例

7 应用层数据指向应用的网络过程 HTTP 洪水、DNS 查询洪水

6 表示层数据数据表示与加密 SSL 滥用

5 会话层数据主机内部通信 N/A

4 传输层分段端到端连接与可靠性 SYN 洪水

3 网络层数据包路径识别与逻辑寻址 UDP 反射攻击

2 数据链路层帧物理寻址 N/A

1 物理层比特媒体、信号与二进制传输 N/A

图一：开放系统互连（简称 OSI）模型


6 / 19

基础设施层攻击

最为常见的 DDoS 攻击——即用户数据报协议（简称 UDP）反射攻击与同步（SYN）洪水——属于基础设施

层攻击。攻击者可以利用此类方案生成庞大的流量，直接淹没网络或者系统的可承载容量，包括其中的服务器、

防火墙、IPS 或者负载均衡器。此类攻击活动拥有一类明显特征，这使其很容易被运维人员所发现。要有效应

对此类攻击，要求基础设施拥有超出攻击者流量产生能力的网络或者系统资源储备。

UDP 是一种无状态协议。其使得攻击者能够伪造请求来源，从而对目标服务器造成更为严重的影响。而放大

系数，即请求规模与响应规模之间的比例，则具体取决于所使用的协议——例如域名系统（简称 DNS）、网络

时间协议（简称 NTP）、简单服务发现协议（简称 SSDP）等等。举例来说，DNS 的放大系数一般在 28 到 54

之间——这意味着攻击者向 DNS 服务器发出一条载荷为 64 字节的请求，则生成的不必要流量将达到 3400 字

节。图三就这一概念进行了展示。

图三：UDP 反射攻击

SYN 洪水在规模上可达到数十 Gbps，但其攻击目标在于消耗系统中的可用资源，即将连接一直保持在半开放

状态。如图四所示，当最终用户接入一项 TCP 服务时，例如一台 Web 服务器，则客户即发送一个 SYN 数据

包。目标服务器将返回 SYN-ACK，此后客户端再返回 ACK 从而完成三方握手。


7 / 19

图四：SYN 三方握手

在 SYN 洪水当中，ACK 永远不会返回，这意味着目标服务器会一直等待其响应。如此一来，新用户将无法正

常接入该服务器。

应用层攻击

作为另一类出现机率较低的作法，攻击者可能会立足于 7 层或者说应用层对目标应用本体发动攻击。此类攻击

与基础设施层攻击有所区别，这是因为攻击者会尝试过度使用应用中的某项功能，从而导致其可用性受到影响。

在某些情况下，攻击者只需要利用极低的请求数量——而无需使用大规模网络流量——即可实现这一目标。这

意味着此类攻击更难被检测与解决。应用层攻击的实例包括 HTTP 洪水、缓存清除攻击以及 WordPress

XML-RPC 洪水。

在 HTTP 洪水当中，攻击者发出的 HTTP 请求在表面上看似乎来自 Web 应用的真实用户。部分 HTTP 洪水将

指向特定资源，但也有部分更为复杂的 HTTP 洪水会尝试模拟人为操作。这将极大增加利用常规防护技术解决

问题的难度，例如请求速率限制。缓存清除攻击属于 HTTP 洪水的一种类别，其利用多种变化查询字符规避内

容交付网络（简称 CDN）的缓存命中机制，从而迫使其通过初始来源提供信息，进而给原始 Web 服务器造成

巨大压力。

在 WordPress XML-RPC 洪水，亦被称为 WordPress pingback 洪水，攻击者可以利用托管于 WordPress 品牌

内容管理软件网站上的 XML-RPC API 功能生成 HTTP 请求洪水。这项 pingback 功能允许网站将指向某

WordPress（站点 A）的通知托管至另一 WordPress 站点（站点 B），即由站点 A 建立指向站点 B 的链接。在

pingback 洪水中，攻击者会滥用这项功能致使站点 B 攻击站点 A。这类攻击同样拥有明显的特征，因为

“WordPress”应当在 HTTP 标题内的“User-Agent”中显示。

应用层攻击也能够指向域名系统（简称 DNS）服务。其中最为常见的攻击为 DNS 查询洪水，攻击者会利用大

量经过精心策划的 DNS 查询耗尽 DNS 服务器资源。这类攻击中往往还包含一套缓存清除组件，攻击者将利用

其对子域名字符串进行随机化扰乱，从而绕过任意给定解析器的本地 DNS 缓存。如此一来，解析器将会把攻

击引导至权威 DNS 服务器处。

在通过安全嵌套层（简称 SSL）交付 Web 应用的情况下，攻击者可以选择攻击 SSL 协商过程。SSL 是一种高


8 / 19

强度计算流程，这使得攻击者能够通过发送难以理解的数据影响目标服务器的可用性。此类攻击的其它变种还

包括由攻击者争夺 SSL 握手，但永远停留在加密方法协商阶段。同样的，也有部分攻击者会选择不断打开并

关闭大量 SSL 会话以耗尽服务器资源。

防护技术

AWS 基础设施在设计当中充分考虑到 DDoS 弹性需求，同时亦配合 DDoS 防护系统以自动检测并过滤多余流

量。为了保护应用程序的可用性，大家有必要建立一套架构以充分发挥这些功能优势。

最为常见的 AWS 用例之一为建立一款 Web 应用，由其向用户通过互联网发送静态与动态内容。而在 Web 应

用当中，常用的 DDoS 弹性参考架构如图五所示。

图五：DDoS 弹性参考架构

这套参考架构当中包含多项 AWS 服务，能够帮助大家改善 Web 应用对 DDoS 攻击的抵御能力。此架构中的

最佳实践将在后文当中具体介绍。举例来说，探讨 Amazon CloudFront 相关功能的章节将作为最佳实践范例

进行引用（例如 BP1）。而各项服务概述及其能够提供的功能，请参见表二。


9 / 19

表二：最佳实践概述

AWS 服务区内的各可用服务，例如 Elastic Load Balancing（即弹性负载均衡）以及 Amazon Elastic Compute

Cloud（即 Amazon 弹性计算云，简称 Amazon EC2）允许大家建立起 DDoS 弹性与规模化体系，从而在给定

区域内处理意料之外的庞大流量。而 AWS 边缘位置中的各可用服务，例如 Amazon CloudFront、AWS WAF、

Amazon Route 53 以及 Amazon API Gateway，则允许大家充分发挥边缘位置全局网络的优势，为应用程序提

供更强的容错能力并提升对超大规模流量的管理能力。使用上述服务构建弹性系统，从而应对基础设施层与应

用层 DDoS 攻击活动的具体收益将在下一章节中进行详细讨论。

基础设施层防护(BP1, BP3, BP6, BP7)

在传统数据中心环境当中，大家可以利用过度配置容量、部署 DDoS 防护系统或者通过 DDoS 防护服务进行流

量过滤等方法抵御基础设施层 DDoS 攻击。而在 AWS 之上，您可通过多种应用程序架构设计选项扩展并吸收

更多网络流量，而无需承担任何资本密集型投入或者不必要的复杂性因素。在防护大规模 DDoS 攻击时，最主

要的考虑因素包括传输容量可用性、多样性并保护 Amazon EC2 实例等 AWS 资源免受攻击流量影响。

AWS 边缘位置 AWS 服务区

Amazon CloudFront 配合 AWS WAF

(BP1, BP2)

Amazon API Gateway

(BP4)

Amazon Route 53

(BP3)

Elastic Load Balancing

(BP6)

Amazon VPC

(BP5)

Amazon EC2 配合 Auto Scaling

(BP7)

3 层(例如 UDP 反射) 攻击防护

✔ ✔ ✔ ✔ ✔

4 层(例如 SYN 洪水) 攻击防护

✔ ✔ ✔ ✔

6 层(例如 SSL) 攻击防护

✔ ✔ N/A ✔

削减攻击面 ✔ ✔ ✔ ✔ ✔

进行规模扩展以消化应

用层流量 ✔ ✔ ✔ ✔ ✔

7 层(应用层) 攻击防护 ✔ ✔ ✔

对突发性峰值与 DDoS

攻击所产生流量进行地

理隔离与分散

✔ ✔ ✔


10 / 19

实例大小(BP7)

大多数 AWS 客户选择 Amazon EC2 是考虑到其灵活的计算容量调整能力，即允许大家根据实际要求快速实现

实例规模伸缩。您可以向应用程序当中添加更多实例以实现横向扩展，亦可以使用规模更大的实例完成纵向扩

展。部分实例类型还支持其它功能，例如包含 10 Gigabit 网络接口与增强网络，这能够改善您应对大规模流量

的能力。

利用 10 Gigabit 网络接口，每项实例都能够支持更高输入流量。这将有助于防止 Amazon EC2 实例中的接口

被流量所彻底堵塞。另外，支持增强网络机制的实例能够提供更高 I/O 性能与更低 CPU 利用率，从而改善实

例处理洪水般的数据包流量。在 AWS 上，您不需要承担任何入站数据传输成本。

要了解更多与 Amazon EC2 实例内 10 Gigabit 网络接口与增强网络支持能力的信息，请参阅 Amazon EC2 实

例类型 3。要了解如何启用增强网络，则参阅在 VPC 内的 Linux 实例中启用增强网络 4。

服务区选择(BP7)

以 Amazon EC2 为典型代表的多种 AWS 服务都可用于全球范围内的各个位置。这些地理划分区域被称为 AWS

服务区。在进行应用程序架构设计时，大家可以根据实际需求选择一个或者多个服务区，其中的常见考量包括

性能、成本与数据所有权法规。在各服务区中，AWS 提供一套惟一的互联网连接组与对等关系，用于帮助大

家获得与最终用户类似的最佳延迟与数据吞吐能力。

同样重要的是，大家还应在选择服务区时将 DDoS 弹性纳入考量。多数服务区接近大型互联网交换枢纽。由于

大部分 DDoS 攻击以跨国形式进行，因此接近交换枢纽有助于借用国际运营商及大型对等网络的频繁维护优势。

这意味着即使已经面对大量流量，最终用户仍然能够顺利接入我们的应用程序。

要了解更多与服务区相关的内容，请参阅服务区与可用区 5，同时向您的客户服务团队询问各服务区的具体特

性，最终做出明智的选择。

负载均衡(BP6)

大规模 DDoS 攻击可能在规模上超出单一 Amazon EC2 实例的承载范围。为了应对此类攻击，大家可能需要

考虑以负载均衡方式进行流量分流。利用 Elastic Load Balancing（即弹性负载均衡，简称 ELB），您可以将应

用程序流量分散至多个后端实例当中，从而降低其过载的风险。ELB 能够自动实现规模伸缩，这意味着我们能

够轻松管理预期之外的大规模流量，例如突发峰值或者 DDoS 攻击。

ELB 只能接受格式良好的 TCP 连接。这意味着大部分 DDoS 攻击，例如 SYN 洪水或者 UDP 反射攻击——会

被 ELB 直接过滤掉，即无法触及您的应用程序。当 ELB 检测到此类攻击活动时，其会自动进行规模扩展以消

化额外流量，而您完全无需承担任何额外费用。

要了解更多与利用 ELB 分发负载以保护 Amazon EC2 实例的细节信息，请参阅 Elastic Load Balancing 上手指

南 6。


11 / 19

利用 AWS 边缘位置实现规模化交付(BP1, BP3)

采用高度规模化与多样化的互联网连接能够显著提高最终用户的延迟与数据吞吐优化效果，同时消化 DDoS

攻击并隔离故障以降低可用性影响。AWS 边缘位置提供额外的网络基础设施层，负责利用 Amazon CloudFront

与 Amazon Route 53 等服务将上述优势带给 Web 应用程序。在这些服务的帮助下，大家的内容与 DNS 查询

将由最接近最终用户的位置负责提供与解析。

在边缘位置交付 Web 应用程序 (BP1)

Amazon CloudFront 是一项内容交付网络（简称 CDN）服务，其可用于交付完整的网站内容，具体包括静态、

动态、数据流以及交互式内容。持续 TCP 连接与可变生存时间（简称 TTL）可用于加快内容交付速度，即使

相关内容无法被缓存在边缘位置。如此一来，大家可以利用 Amazon CloudFront 保护自己的 Web 应用程序，

即使并不提供任何静态内容 Amazon CloudFront 只接受格式良好的连接，这就直接防止了大多数常见 DDoS

攻击——包括 SYN 洪水与 UDP 反射攻击——触及您的应用。DDoS 攻击会被地理隔离在接近其发源位置的区

域，从而避免其它区域受到连带影响。在这些功能的帮助下，您将完全能够在大规模 DDoS 攻击之下继续为最

终用户交付正常流量。另外，您也可以使用Amazon CloudFront保护位于AWS或者其它互联网位置的应用源。

要了解更多与利用 Amazon CloudFront 实现 Web 应用程序性能优化相关的细节信息，请参阅 CloudFront 上

手指南 7。

在边缘位置实现域名解析 (BP3)

Amazon Route 53 是一项具备高可用性与高可扩展性的域名系统（简称 DNS）服务，可用于将流量定向至您

的 Web 应用程序。其中包含多项先进功能，例如流量流、基于延迟路由、地理 DNS、运行状态检查以及监控

等等。这些功能允许大家控制服务响应 DNS 请求的确切方式，从而对延迟、运行状态及其它重要因素做出优

化。大家也可以利用这些功能改进 Web 应用程序的性能并避免站点宕机。

Amazon Route 53 采用缓冲划分与选播划分机制，保证最终用户即使在 DNS 服务被设为 DDoS 攻击目标的情

况下，仍可正常访问您的应用程序。利用缓冲划分机制，每台域名服务器都将对应边缘位置与互联网路径中的

某个惟一集合。这将实现更理想的容错能力，同时降低不同客户间的重叠可能性。如果代表分组内的某域名服

务器不再可用，最终用户可以重试并收到来自其它不同边缘位置的另一域名服务器的响应。任播划分则用于保

证每条 DNS 请求都由最优位置进行响应。这种作法将实现负载分散与 DNS 延迟降低，使得最终用户能够更快

接收到响应结果。另外，Amazon Route 53 还能够检测到 DNS 查询源与总量内的异常情况，同时对已知可靠

用户的请求进行优先级排序。

如果您拥有多个 Amazon Route 53 托管区，则可创建一个可复用代表组，由其为每个域名提供相同的一组权

威域名服务器。这种作法能够简化托管区的维护流程。而在面对 DDoS 攻击时，其还将使 AWS 能够利用单一

防护机制涵盖可复用代表组中使用的全部托管区。

要了解更多与 Amazon Route 53 将最终用户定向至应用的细节信息，请参阅 Amazon Route 53 上手指南。8


12 / 19

要了解更多与可复用代表组相关的细节信息，请参阅可复用代表组操作 9。

应用层防护(BP1, BP2, BP6)

本份白皮书中讨论的大部分技术适用于防护基础设施层 DDoS 攻击。而防御应用层攻击活动，大家需要建立一

套架构以保证自己能够检测并进行规模伸缩以消化并阻断恶意请求。这一点非常重要，因为大部分基于网络的

DDoS 防护系统并不能有效处理复杂的应用层攻击。

检测并过滤恶意 Web 请求 (BP1, BP2)

Web 应用防火墙（简称 WAF）常被用于保护 Web 应用程序免受尝试利用应用内安全漏洞的恶意攻击的影响。

其常见实例包括 SQL 注入与跨站点请求伪造。另外，大家也可以利用 WAF 来检测并防护 Web 应用层 DDoS

攻击。

在 AWS 上，大家可以利用 Amazon CloudFront 以及 AWS WAF 保护自己的应用程序免受此类攻击影响。

Amazon CloudFront 允许大家缓存静态内容，并由 AWS Edge Locations 进行交付，从而降低原始位置受到的

负载压力。另外，Amazon CloudFront 还能够自动关闭慢速读取或者慢速写入攻击者建立的连接（例如

Slowloris）。您可以使用 Amazon CloudFront 进行地理位置限定，避免来自特定地理位置的用户访问您的内容。

这将有效阻断预期最终用户所在位置之外区域内攻击者发起的恶意冲击。

对于其它类型的攻击活动，例如 HTTP 洪水或者 WordPress pingback 洪水，大家可以使用 AWS WAF 以建立

自己的防护体系。如果您知晓需要屏蔽的源 IP 地址，则可创建一条规则进行屏蔽并将其关联至 Web ACL。在

此之后，大家可以在 Web ACL 中创建一条 IP 地址匹配条件，用于阻断该源 IP 地址参与的一切攻击活动。另

外，您也可以创建条件规则根据 URI、查询字符串、HTTP 方法或者头字段键等执行屏蔽操作。后一种方法特

别适用于具备明确特征的攻击活动。举例来说，WordPress pingback 攻击的 User-Agent 中始终包含

“WordPress”内容。

但是，我们往往很难识别出 DDoS 攻击的特征，或者准确发现参与至攻击活动当中的 IP 地址。有时候，我们

可以审查 Web 服务器日志以获取此类信息。另外，大家也可以使用 AWS WAF 控制台以查看 Amazon

CloudFront转发至AWS WAF的请求样本。样本请求能够帮助大家确定需要利用哪些规则以防护应用层攻击。

如果您发现多数请求中包含一条随机查询字符串，则基本可以断定应在 Amazon CloudFront 中禁用查询字符

串转发机制。这项举措能够有效缓解指向原始位置的缓存清除攻击。

部分攻击活动中的网络流量则经过了修改，保证其看起来更接近正常的最终用户流量。为了应对这类攻击活动，

大家可以使用 AWS Lambda 功能以实现基于速率的黑名单过滤机制。利用速率黑名单机制，您可以为自己的

Web 应用程序设置一条请求接纳量阈值。如果恶意流量超过这一水平，大家则可利用 AWS WAF 自动屏蔽额

外请求。

欲了解更多与利用地理限制控制 Amazon CloudFront 访问流量的细节信息，请参阅限制内容的地理分发 10。

欲了解更多 AWS WAF 使用方法的细节信息，请参阅 AWS WAF 上手指南 11与查看 CloudFront 转发至 AWS

WAF 的 Web 请求样本 12。


13 / 19

欲了解更多与利用 AWS Lambda 与 AWS WAF 配置速率黑名单的细节信息，请参阅如何利用 AWS WAF 与

AWS Lambda 配置基于速率的黑名单机制 13。

扩大规模以消化更多流量(BP6)

另一种应对应用层攻击的办法则是进行规模扩展。在 Web 应用程序当中，我们可以使用 ELB 将流量分发至更

多作为超额流量下自动规模伸缩方案的 Amazon EC2 实例当中。如此一来，无论事实证明这部分流量为突发

性使用峰值还是应用层恶意 DDoS 攻击，其都能够得到正常处理。Amazon CloudWatch 警报机制则可用于启

动 Auto Scaling，后者能够自动对 Amazon EC2 集群规模进行扩张，从而应对您所定义的各类事件。这种作法

将保护应用程序可用性，应对意料之外的大量请求。通过使用 Amazon CloudFront 或者 ELB，SSL 协议将由

分发或者负载均衡机制处理，从而避免各实例受到 SSL 攻击活动的影响。

欲了解更多利用 Amazon CloudWatch 调用 Auto Scaling 的细节信息，请参阅利用 Amazon CloudWatch 监控

您的 Auto Scaling 实例与分组 14。

攻击面削减

在进行 AWS 架构设计时，另一大重要注意事项在于控制攻击者将矛头指向其中应用的可能性。举例来说，如

果大家认为最终用户不可能与特定资源直接交互，则应确保这部分资源无法通过互联网进行访问。同样的，如

果大家认为最终用户或者外部应用不可能与应用内的特定端口或者协议通信，则应当确保屏蔽此类流量。这正

是攻击面削减的基本概念。在本章节中，我们将分享多项最佳实践，帮助大家削减攻击面并控制应用程序与互

联网的对接程度。未面向互联网公开的资源将更难受到攻击，这就使得攻击者很难影响到应用程序的可用性。

AWS 资源的模糊处理(BP1, BP4, BP5)

对于大多数应用来讲，您的 AWS 资源都不需要完全面向互联网开放。举例来说，我们可能不需要开放 ELB 之

后的Amazon EC2实例接受公开访问。在这种情况下，大家可以只允许最终用户通过特定TCP端口访问此ELB，

并只允许该 ELB 与对应 Amazon EC2 实例进行通信。我们可以通过配置 Amazon 虚拟专有云（简称 VPC）内

的安全分组与网络访问控制清单（简称 NACL）完成上述目标。Amazon VPC 允许大家配置一套经过逻辑隔离

的 AWS Cloud 分区，大家可以在这里利用所定义的虚拟网络启动 AWS 资源。

安全分组与网络 ACL 的另一相似之处在于，二者都允许大家在 VPC 之内控制指向 AWS 资源的访问活动。安

全分组允许大家在实例层级控制入站与出站流量，而网络 ACL 则在 VPC 子网层级提供类似的功能。另外，

Amazon EC2 安全组（简称 SG）规则或者网络 ACL 上的入站数据传输不会产生任何费用。这就确保了大家即

使将流量交由安全分组或者网络 ACL 打理，也无需承担任何额外成本。

安全分组(BP5)

大家可以在启动实例时为其指定安全分组，或者之后在必要时将该实例关联至某个安全分组。来自互联网且指

向安全组的全部流量都会被直接拒绝，除非您创建了“允许”规则以接纳这部分流量。举例来说，如果您的某

款 Web 应用程序包含 ELB 与多个 Amazon EC2 实例，那么大家可以为该 ELB 创建一个安全分组（即 ELB 安


14 / 19

全组），再为各实例创建另一分组（Web 应用服务器安全组）。在此之后，您可以创建“允许”规则将来自互

联网的特定流量引导至 ELB 安全分组，再进一步由 ELB 安全分组传输至 Web 应用服务器安全分组。这样一

来，来自互联网的流量将无法直接与 Amazon EC2 实例通信，这意味着攻击者将很难确实了解您的应用程序。

网络访问控制列表(简称 ACL) (BP5)

利用网络 ACL，大家可以指定“允许”与“拒绝”规则，从而明确拒绝或者放行指向应用程序的某些特定类型

流量。举例来说，您可以定义 IP 地址范围（作为 CIDR 范围）、协议以及目标端口等，并要求整套子集拒绝接

收此类流量。如果您的应用程序只用于 TCP 流量，则可建立一条“拒绝”规则以屏蔽所有 UDP 流量，反之亦

然。这款工具能够有效应对 DDoS 攻击，因为我们能够利用自己创建的规则对来自已知源 IP 地址或者包含其

它特征的攻击进行阻断。

保护源位置(BP1)

如果大家使用 Amazon CloudFront 并在 VPC 当中设置了源位置，则应利用 AWS Lambda 功能自动更新您的

安全分组规则，从而仅“允许”那些来自 Amazon CloudFront 的流量。这种作法能够确保一切请求无法绕过

Amazon CloudFront 与 AWS WAF，从而提升源位置的安全性水平。

要了解更多利用自动更新安全分组机制保护源位置的细节信息，请参阅如何利用 AWS Lambda 对 Amazon

CloudFront 与 AWS WAF 提供的安全分组进行自动更新 15。

大家可能还需要确保只有由 Amazon CloudFront 负责分发的请求才可接入源位置。利用 Edge-to-Origin 请求

头，大家可以在 Amazon CloudFront 将请求转发至源位置时添加或者覆盖现有请求头。大家可以使用

X-Shared-Secret 标题头帮助验证一切由 Amazon CloudFront 发出并指向源位置的请求。

欲了解更多利用 X-Shared-Secret 标题保护源位置的细节信息，请参阅向您的源位置转发定制化标题头 16。

保护 API 端点(BP4)

一般来讲，公开发布 API 会带来潜在安全风险，这意味着 API 前端有可能被 DDoS 攻击所影响。Amazon API

Gateway 是一项全托管服务，允许大家创建一个 API 充当“前门”，从而保护运行在 Amazon EC2 以及 AWS

Lambda 上的应用程序乃至其它任意 Web 应用。利用 Amazon API Gateway，大家不再需要运行自有服务器充

当 API 前端，并可混合应用程序当中的其它组件。通过这种方式，我们能够防止 AWS 资源被 DDoS 攻击所锁

定。Amazon Gateway 与 Amazon CLoudFront 相集成，这样我们将能够充分发挥 DDoS弹性能力，同时在 REST

API 中配置标准或者突发速率限制以保护后端不致被流量所吞没。

欲了解更多利用 Amazon API Gateway 创建 API 的细节信息，请参阅 Amazon API Gateway 上手指南 17。

运营技术

本份白皮书中提到的各防护技术能够帮助大家构建起更具弹性的应用程序，从而抵御 DDoS 攻击威胁。在多数

情况下，了解 DDoS 攻击的发生时间以及对数据采取的具体操作则使我们能够更具针对性地加以解决。另外，


15 / 19

大家可能还需要收集更多资源以评估威胁、审查应用程序现有架构或者获取其它类型的援助。本章节将探讨异

常行为、警报与自动化等可视化领域的最佳实践，同时分享 AWS 能够提供的其它技术支持。

可视化

了解应用程序的正常行为模式能够帮助我们很好地掌握异常状况并迅速采取行动。当某项关键性指标偏离预期

基准值时，这可能意味着攻击者正试图破坏我们的应用程序可用性。利用 Amazon CloudWatch，大家可以监

控运行在 AWS 之上的应用程序，收集并追踪多项指标、获取并监控日志文件、设置警报并自动就 AWS 资源

使用变化做出反应。表三所示为 Amazon CloudWatch所提供的常用于检测并应对 DDoS攻击活动的各项指标。

表三：推荐 Amazon CLoudWatch 指标

对于按照图五内 DDoS 弹性参考架构构建的应用程序，常规基础设施层攻击将在触及应用之前即被阻断。如此

一来，此类攻击将无法体现在 Amazon CloudWatch 的指标当中。

应用层攻击则可能导致其中部分指标的数值有所上升。举例来说，HTTP 洪水可能导致请求数量、CPU 与网络

名称指标描述

Auto

Scali

ng

分组最大规模 Auto Scaling 各分组的最大规模

Ama

zon

Clou

dFro

nt

请求 HTTP/S 请求数量

Ama

zon

Clou

dFro

nt

总体错误率全部请求中错误请求所占百分比，其中 HTTP 状态码为

4xx 或者 5xx.

Ama

zon

EC2

CPU 使用率分配给 EC2 计算单元的计算资源的当前使用百分比

Ama

zon

EC2

网络该实例全部网络接口接收到的字节总量

ELB 波动队列长度由负载均衡器排列、等待后端实例接收连接并处理其请

求的请求数量

ELB 不正常主机数量每个可用区内运行状态不正常的实例数量

ELB 请求数已注册实例接收并路由的完整请求数量

ELB 延迟请求离开负载均衡器到获取响应之间经过的时间，以秒

为单位

ELB HTTPCode_ELB_4xx

HTTPCode_ELB_5xx

由该负载均衡器产生的 HTTP 4xx 或者 5xx 错误码的数

量

ELB 后端连接错误未成功连接数量

ELB 溢出数量由于队列已满而被拒绝的请求数量

Ama

zon

Rout

e 53

状态检查状态状态检查端点的状态


16 / 19

利用率等 Amazon CLoudFront、ELB 以及 Amazon EC2 指标增加。如果后端实例无法处理超出部分请求，大

家可能会发现 Amazon CLoudFront 的总体错误率提升，甚至同时伴随 ELB 之上波动队列长度、不正常主机数

量、延迟、后端连接错误、溢出数量乃至 HTTPCode 等指标增长。在这种情况下，由于该应用程序无法服务

合法最终用户，因此 HTTP 请求数量可能会降低。要解决这个问题，大家可以扩展应用程序后端规模或者利用

AWS WAF 中的筛选条件屏蔽部分流量。

欲了解更多与利用 Amazon CloudWatch 检测 DDoS 攻击活动的细节信息，请参阅 Amazon CloudWatch 上手

指南 18。

大家可用于对指向您应用程序的流量进行可视化处理的另一款工具为 VPC Flow Logs。在传统网络当中，大家

可能会利用网络流量日志对连接性及安全性问题进行故障排查，同时确保各项网络访问规则按预期正常起效。

在 VPC Flow Logs 的帮助下，您能够捕捉一切指向及来自 VPC 内网络接口的 IP 流量相关信息。

每份数据流日志记录包含来源与目标 IP 地址、来源与目标端口、协议以及捕捉窗口之内传输的数据包与字节

数量。这部分信息可用于确定网络流量中的异常状况，同时识别各类特定攻击矢量。举例来说，大部分 UDP

反射攻击都会使用特殊的来源端口（例如 DNS 反射使用源端口 53）。这种明确的特征可用于判断攻击行为，

并允许大家立足于实例层级创建特定源端口屏蔽机制或者创建一条网络 ACL 规则以完全阻断该非必要端口。

欲了解更多与利用 VPC Flow Logs 识别网络异常与 DDoS 攻击矢量的细节信息，请参阅 VPC Flow Logs19以及

VPC Flow Logs——记录并查看网络数据流量 20。

支持

要应对 DDoS 攻击，最重要的是在实际攻击发生之前制定一项规划。本份白皮书中提供的最佳实践旨在采取主

动举措，在应用程序启动之前即做好 DDoS 攻击的防范工作。您的客户团队亦可帮助审查现有用例及应用程序，

同时协助您确定问题或者可能遇到的挑战。

有时候，您可能需要联系 AWS 以获取更多 DDoS 攻击支持与帮助; 您提供的情况将快速被传递至能够帮助您

解决问题的专家手中。通过订阅 Business Support，您将获得 24 x 7 全天候云支持工程师的协助，且可使用电

子邮件、即时通讯或者电话等多种沟通方式。

如果您在 AWS 之上运行关键性任务工作负载，则应考虑选择 Enterprise Support。利用 Enterprise Support，

您能够在面对紧急情况时获得最高优先级支持，并由高级云支持工程师负责接待。另外，Enterprise Support

还提供一名专门的技术客户经理（简称 TAM），其将为您提供专门的技术建议与联系途径。另外，Enterprise

Support 也将允许您使用基础设施事件管理方案，其中包含事件规划、产品启动以及迁移过程中的全部实时运

营支持协助。

欲了解更多与支持规划相关的细节信息，请参阅 AWS 支持计划比较 21。

总结

本份白皮书中概述的各项最佳实践将帮助大家建立起具备 DDoS 弹性的架构，从而保护您的应用程序在常见基


17 / 19

础设施与应用层 DDoS 攻击当中继续保持正常运行。立足于这些最佳实践，您将能够构建起足以应对不同类型、

矢量与规模的 DDoS 攻击的应用程序。AWS 建议大家使用这些最佳实践以更好地保护应用程序可用性。

贡献者

以下人员为本份白皮书的编撰做出贡献：

AWS 解决方案架构师 Andrew Kiggins

AWS DDoS 运营工程师 Jeffrey Lyon

Notes

1 https://www.youtube.com/watch?v=OT2y3DzMEmQ

2 https://www.youtube.com/watch?v=Ys0gG1koqJA

3 https://aws.amazon.com/ec2/instance-types/

4 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-

networking.html

5 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-

availability-zones.html

6

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb

-getting-started.html

7

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Getti

ngStarted.html


18 / 19

8 http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/getting-

started.html

9 http://docs.aws.amazon.com/Route53/latest/APIReference/actions-on-

reusable-delegation-sets.html

10

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/geor

estrictions.html

11 http://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html

12 http://docs.aws.amazon.com/waf/latest/developerguide/web-acl-

testing.html#web-acl-testing-view-sample

13 https://blogs.aws.amazon.com/security/post/Tx1ZTM4DT0HRH0K/How-to-

Configure-Rate-Based-Blacklisting-with-AWS-WAF-and-AWS-Lambda

14 http://docs.aws.amazon.com/autoscaling/latest/userguide/as-instance-

monitoring.html

15 https://blogs.aws.amazon.com/security/post/Tx1LPI2H6Q6S5KC/How-to-

Automatically-Update-Your-Security-Groups-for-Amazon-CloudFront-and-

AWS-W

16

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forw

ard-custom-headers.html


19 / 19

17 https://aws.amazon.com/api-gateway/getting-started/

18

http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/Get

tingStarted.html

19 http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html

20 https://aws.amazon.com/blogs/aws/vpc-flow-logs-log-and-view-network-

traffic-flows/

21 https://aws.amazon.com/premiumsupport/compare-plans/

Documents

AWS DDoS 弹性最佳实践方案 · Amazon Web Services – AWS DDoS 弹性最佳实践方案 2016 年6 月 5 / 19 而在分布式拒绝服务（简称DDoS）攻击当中，攻击者会利用多个源——可能由大量协作者组成或者共同控制