Answers:
我将建议如上所述的自动缩放，并添加一些CloudWatch警报，以在特定阈值开始增加时开始自动缩放过程，而不是在已经很远的时候开始。
例如; 当CPU处于50％或更高的状态持续30秒或更长时间时，将CloudWatch配置为监视服务器。
这可能并非完全没有问题，但是可以通过一些在线指南轻松完成，并且可以通过GUI进行全部配置。
另外，如果您的着陆页是静态的，为什么不将其托管在免费的t2.micro上，并为您的应用程序使用另一个t2.micro的免费层呢？
解决流量激增的一般策略有两种：增加容量和降低成本。
容量增加意味着自动扩展，当公有云首次可用时，每个人都为之兴奋。从最基本的意义上讲，这将根据负载为您启动更多的Web服务器，并将它们添加到负载平衡器中，但是由于管理起来很麻烦，因此还有更多自动解决方案，例如Elastic Beanstalk。
自动扩容的麻烦在于，它还会自动进行账单扩容-10倍的正常流量意味着10倍的服务器意味着您必须支付的10倍的钱。这就是为什么尽管要记住这是一种有用的策略，但我认为您应该始终从了解自己可以作弊的数量开始。
所谓作弊，是指缓存，它基于这样的想法：大多数情况下，您可以为用户提供一些过时的数据，而他们不会注意到，这可以节省大量时间。想象一下，如果您有一个页面，如果它过时了五秒钟，您就认为可以，并且速度为20 req / s。如果不使用缓存，则每分钟运行1200次该计算，而使用缓存则只有12次。您可以看到它如何产生巨大的变化。
当然，缓存类型很多，一个成功的网站将使用其中的几种。但是对于您的用例，有两个非常好的和简单的选择。
首先是使站点完全静态。假设您可以这样做，但是如果可以的话，您只需让Nginx直接提供html，它就可以无休止地处理大量请求。
如果需要某种程度的动态性，那么进行一些全页缓存是一个不错的选择。Nginx可以做到这一点，但是我非常喜欢Varnish，因为它具有灵活性。
无论使用什么选项，请确保进行负载测试以验证是否已正确设置；有时修复一个点会暴露出新的瓶颈。
我想分享我们在AWS方面的经验。我们将应用程序部署在EC2上，面临同样的问题，而且成本很高。尽管我们的应用程序是整体的，但是我们部署了应用程序Amazon EC2 Container Service，但是我们实现了
应用程序负载平衡器将处理流量，并将流量路由到运行状况良好的实例，您可以运行相同服务的多个任务，而不必担心扩展和平衡负载。
这种体系结构使实现故障隔离更加容易。运行状况检查，缓存，隔板或断路器等技术使您能够减小发生故障的组件的爆炸半径，并提高给定应用程序的总体可用性。