背景：我正在使用Amazon API Gateway，Amazon S3，AWS Lambda等构buildWeb应用程序。
注意：如果您不了解AWS，欢迎提供任何build议。
search如何保护API网关免受DDoS攻击，我发现了一些关键词，如AWS Shield，AWS WAF等等。 无论如何，除了这些，我已经打了一个想法。但用googlesearch这个想法，search没有任何打击，所以我不能确定这个想法是否正确。
这个想法是如下所示。
经过身份validation的用户dynamic获取端点，这意味着有一个端点可以让端点访问资源。 现在，由于DDoS攻击，某些端点发生故障，用户得到503错误，但用户通过“端点获取端点”自动获得备份端点，因为我像这样编写了前端代码，并在Amazon API Gateway中创build了一些复制的备份端点。
我想知道这是否会工作正常。
如果您担心API GW后面的端点，则可以将GW实例configuration为添加每个用户的限制，以便经过身份validation的用户不能运行比您允许的更多的请求。 您可以添加参数检查，以便格式不正确的请求不会打到您的后端。
此外，API GW是容错和高度可用的服务，所以你不能把它放下（但可以超出预算），因此GW端点（从d123456.cloudfront.net这个世界可见）不会降低。
听起来就像你正在描述一个CDN（内容交付networking）。 这基本上是您的静态网站的只读副本，作为您的新前端。 其中一个重要方面就是CDN前端没有更多的服务器端代码，因为前端是用浏览器生成的，然后在解释之后重新显示，因此可以在S3中托pipeEC2实例，以前需要一个Web服务器 – 使您能够更好地扩展和控制DDoS攻击下的情况。 这对静态网站是有效的，但显然不适用于dynamic应用程序。
如果您正在运行dynamic应用程序，并且需要防止这种types的攻击，则WAF非常有效，并且具有足够灵活的规则来限制任何types的stream量。 当你看到这些攻击发生的时候，WAF将允许你充分地适应，而不必花费昂贵的解决scheme，例如F5 ASM。 虽然API网关的使用为您的问题提供了高度容错的容错解决scheme，但是攻击实际上可能会搞乱帐单。 API网关的规则将允许您保持这种过度使用状态，并与WAF结合使用，从而可以locking该业务。
最后，你可能会考虑边缘networkingcaching。 边缘caching服务器将允许您通过全球分布的前端caching服务器拥有这个“端点端点”。 当您的原始服务器closures时，您的caching将使您的网站和潜在的应用程序保持在停机时间之前的状态。 有几个产品可以做到这一点，最显着的是CloudFront或Akamai。
在所有这些解决scheme之间，您应该对大多数types的DOS攻击具有大量的抵抗力，并且能够在以后适应新的types。