大概4-5年前，客户开始使用AWS作为他们的开发和测试环境，因为澳洲当时没有亚马逊的数据中心，所以只好 使用us-east, us-west这些region。后来澳洲有了AWS的数据中心，应用的产品就都迁移到新的region 和新的AWS账户下。由于这个历史原因，一部分bake AMI的任务以及部署的任务，都是跨账户以及region 的。

这些任务的工具，都是用ruby的aws-sdk包装的，从表面上看，这么做有如下的好处:

1. 更细粒度去控制这些任务以及过程
2. 代码可测试
3. 打包/发布/共享会更加容易些
4. 只要SDK支持，你都可以用自己熟悉的语言去实现这些工具
5. 写代码实现感觉很牛逼

对于程序员来说，这么做感觉棒棒哒，写完很有满足感。但是实际中会带来很大的问题，具体表现在维护方面。 我举两个例子：

1. 不是所有人都喜欢这个工具，有些人会提交patch，改进这个工具，有些人会重新实现一个类似功能的工 具，比如我喜欢用Java，但是现有的工具是用Ruby实现，我表示不服，重头写一个。维护的难度在这种分散 的项目和语言中增大了。
2. 实现者没有在对工具进行维护，其中依赖的sdk已经过期，而作为工具的使用者，并没有察觉到这件事情， 在实际的使用中会遇到问题，面对非常深的stacktrace，debug的难度较高。

最近，我和同事就碰到了这样的问题。我们AMI构建和部署的工具是用Ruby的aws-sdk实现，我们要做的工 作是把构建AMI和部署的任务从一个AWS Account移到另外一个Account，原本的验证方式是通过Hard Code的Credentials如AWS_SECRET_ACCESS_KEY/AWS_ACCESS_KEY_ID。更好的实践是通过STS服务 ，用AssumeRole的方式去获得临时的Credential。听上去并没有什么太大的难度，但是当我们去迁移的时 候，发现始终提示权限不足，而仔细检查role的权限后发现没有任何不妥，于是百思不得其解，尝试追踪 stacktrace也没什么结果。

无意中看了眼Gemfile，感觉aws-sdk的版本有点低，随手升了个级，然后试了下，竟然可以通过验证 了……。

多花了两个小时，就是因为没有再去维护这个工具。而这个工具实际实现的功能，用aws-cli也可 以很容易实现，而且依赖更少：

1. 本地使用，只需要有aws-cli(可能还有python，除了windows，一般的系统默认都会有)和bash就可 以了
2. CI的slave上使用，可以让aws-cli在镜像启动时自动更新，这样就完全不需要维护
3. 如果cli参数有变动，提示会更加直接些，也容易追踪

所以，如果大家要针对AWS做一些开发，比如镜像构建，清理或者自动化部署，推荐使用CLI的方式，而不是 SDK去实现，从使用的角度，依赖更少，从维护的角度，成本更低。