准备回应个人开发AWS账户的过度使用

时间:2017-04-30 01:39:29

标签: security amazon-web-services disaster-recovery

AWS未提供限制使用费用的方法。人们经常指出,如果收费超过预算,关闭商业网站是没有用的,没有关于业务本身所拥有的适当回应的信息。但是,对于那些想在家中进行实验以进行学习的人来说,这种情况并不适用。

预防是一件好事,但不可能防止所有事故和袭击。这个问题是关于反应而不是预防。

一个标准建议是使用某种方法快速关闭帐户中的所有AWS资源。

另一项标准建议是利用预算警报等功能。作为个体公民,对这种警报作出反应的时间可能是一天,或者可能是一周或更长时间,如果生病,这可能会导致非常高的费用。所以自动化在这里可能很有用。

如何以适合个人开发人员在自己的时间内自费实验的方式解决这些问题?特别是,我该怎么做:

  1. 准备快速,经过充分测试的可靠响应,以关闭AWS账户中的所有资源使用情况
  2. 自动触发该响应(例如,由AWS预算警报或其他形式的成本监控触发)
  3. 一些潜在的并发症:

    一个。在故意攻击而非纯用户错误的情况下,攻击者利用EC2终止保护等功能可能会使其复杂化。

    B中。攻击者还可能使用许多不同的AWS服务。因此,考虑到大型且不断扩展的AWS产品系列,尝试维护一个库,删除每种类型的资源(EC2实例,RDS实例等),使用特定于特定资源类型的代码,可能是不切实际的。

    ℃。此rather old forum post表明,在未取消所有选择加入服务的情况下,无法关闭AWS账户。

    注意我无法使用免费套餐,因为我想使用该套牌中没有的功能。

2 个答案:

答案 0 :(得分:1)

首先,root帐户凭据的正确安全性和管理至关重要。在所有帐户上启用MFA,包括root。除非绝对必要,否则请勿使用root帐户。限制具有广泛权限的帐户。启用CloudTrail,如果需要,请提醒使用提升的权限。这些行为肯定会抵御几乎所有攻击者,因为这是一个个人帐户,可能逃避这些控制的攻击者类型可能没有兴趣造成个人伤害,他们对大型组织更感兴趣

至于事故,你认为会发生什么类型的事故?您是否有基于队列深度等因素使用自动缩放的大型计算作业?您在此处采取的最佳操作可能是设置ASG最大大小,使用CloudWatch事件来监控和重新调解资源使用问题,甚至使用处理此类事情的第三方工具。

需要记住的是,AWS实施的帐户限制会限制您的某些限制,但对于个人帐户,即使这些限制也可能过于宽松。我只有要求限制增加的经验但是,如果他们也执行限制减少,可能值得询问AWS。

答案 1 :(得分:0)

您已经提出了由于以下原因而产生的过高成本的担忧:

  • 正常使用:如果您需要计算资源,那么它们最有可能为公司带来足够的利益以保证成本。因此,过度使用应该会产生警告,但您不想关闭它。
  • 意外使用:这是授权人员使用过多资源的地方,例如开启服务而忘记关闭服务。再一次,监控可以给你一个提示,发生这种情况。许多AWS客户创建了一个沙盒帐户,他们可以在这里进行试验,然后使用自动脚本关闭此帐户中的资源(不用于实际业务目的)。
  • 攻击者:这是向您的服务发送过度使用的外部方(例如,向您的网站发出许多请求)但无法访问您的实际AWS账户。这也可能是由拒绝服务攻击引起的。有大量关于处理DDOS风格攻击的文档,但一种安全的方法是限制Auto Scaling组中允许的最大实例数。
  • 访问您的AWS账户的人:您提到使用EC2终止保护的攻击者。这是一个可以应用于您自己的EC2实例的选项,以防止意外终止。除非获得访问您的AWS账户的凭据,否则公司外部的人员无法控制。如果您对此感到担心,请在登录时激活多重身份验证(MFA)。

如果您担心成本过高,则值得考虑产生成本的因素:

  • 亚马逊EC2实例按小时收费。如果您担心他们的成本,那么您可以阻止他们,但这意味着他们不再为您的公司和客户提供服务。
  • 存储服务(例如Amazon EBS和Amazon S3)根据存储的数据量收取费用:您很可能因为过多而自动删除数据成本,因为数据可能对贵公司有价值。
  • 数据库服务(例如Amazon RDS)每小时收费。您可能不想关闭它们,因为它们也包含贵公司的有价值数据。
  • 某些服务是根据吞吐量收费的(例如AWS API Gateway,Amazon Kinesis),但关闭此类服务也会影响您继续为客户提供服务的能力。

如果您所谈论的是未向客户提供服务的AWS的个人使用,那么最佳做法是始终关闭不需要的服务,例如计算和数据库服务。 AWS是一种按需服务,因此您只需为已请求的服务付费。

此外,创建Billing Alarms可在超过特定成本阈值时提醒您。这些可以进一步细分为budgets,当您接近某些支出阈值时会通知您。

底线:您应该只运行目前需要的服务,而不是专注于自动应对高支出和删除事物的系统。设置警报/预算以了解超出所需阈值的成本。