AWS服务陷阱 没有一劳永逸

一个常见的误解是AWS服务满足了所有的IT需求，Bhargava说：“你搞错了，AWS提供的是拥有巨大价值和良好设计的基础设施即服务（IaaS）解决方案，但我觉得仍有大批人相信AWS负责诸如安全、补丁、用户管理等事务。”大部分情况下并非如此，“如果企业认为AWS需要负责上述事情而实际上AWS又没有做，他们就将处于严重风险之中。”

从更加宽泛的角度来看待AWS服务陷阱，Orchestratus的CEO，Shlomo Swidler分享了他所认为的四大陷阱，分别是：

无法隔离生产环境与开发测试环境。在开发测试环境下发生的错误不应影响上线的服务，但是在统一的集成账户管理下，这种分隔很难实现。Swidler表示：“你还要严格控制生产环境配置，因为生产环境中包含机密信息，如支付网关电子凭证以及密码等。”简言之，使用独立的AWS账户来管理生产环境和开发测试环境是一个好办法。

失去账单追踪能力。Swidler解释说，由于对大量的AWS资源使用是建立在一个用户账户中，审计和追踪AWS服务使用情况将变得日益困难。在此情况下，Swidler推荐使用AWS的合并账单（Consolidated Billing）功能，该功能允许用户将多个独立账户归集到一个主账户下来管理，展示统一的使用信息并可统一支付。他还推荐在每个账户上设置消费警报，以此通知用户达到预设的消费级别的时刻。

跟上需求的变化。Swidler表示：“启动AWS内的资源并长期使用是容易的，但是你会忽略云服务的一大特色：适应变化需求的灵活性。”他推荐通过定期检查自身需求（至少每季度一次）来解决此问题，他补充道，一旦AWS降低了价格或者增加了新服务，你会发现通过及时变更资源配置能够更加有效地满足需求。

依靠传统数据中心管理工具来管理AWS资源。“数据中心管理工具在管理相对静态的服务器资源上是非常优秀的，但云服务模型允许用户动态添加和删除后台的服务器资源，这种使用模式使得面向数据中心管理的工具无法良好地应对，”Swidler说。相反，AWS的客户应该使用“诸如Chef、Puppet、RunDeck等设计处理动态模型的现代化管理工具” .