AWS服务陷阱 没有一劳永逸


一个常见的误解是AWS服务满足了所有的IT需求,Bhargava说:“你搞错了,AWS提供的是拥有巨大价值和良好设计的基础设施即服务(IaaS)解决方案,但我觉得仍有大批人相信AWS负责诸如安全、补丁、用户管理等事务。”大部分情况下并非如此,“如果企业认为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等设计处理动态模型的现代化管理工具” .