分享一下我们用代码来管理多个 AWS 账号的实践

[xiaket]

这个解决方案是我们这一年来鼓捣出来的东西, 主要思路是不使用跨账号的 IAM Role, 使用 Eventbridge 来传递消息. 把所有的 AWS 账号全部定义到一个配置文件里, 通过 cicd 流程来控制新账号的生成和初始化, 同时也有一些额外的好处.

https://blog.xiaket.org/2021/aws-account-management-using-eventbridge-cn.html

如果有兴趣, 可以对照英文来看:

https://blog.xiaket.org/2021/aws-account-management-using-eventbridge.html

[xderam]

@xiaket 那就是还要手工删除账号？似乎也不是不可以。状态的那个解决方案似乎也没啥毛病。不过这么做的好处和弊端如果能再说说分享下就更好了。

[vindurriel]

@xiaket 原来是 pyyaml 那确实
assumeRole 这套是现成的 RBAC 上下游可以分别控制权限 用 eventbridge 不但得自己搞 发送账号还不好限制接收账号的权限（只能定义谁能看 不能定义看了能做啥）

[xiaket]

@xderam 谢谢, 我们可以自动删账号的, 只不过目前我们觉得相对比较危险, 所以没这样做. 即, 技术上没有问题, 只不过我们没有去这样处理.

好处在于后面如果添加了什么新特性, 可以很方便地加到这个 DSL 里面, 可玩性可扩展性都比较好. 坏处嘛毕竟是自己写的, 有个后续维护的开销.

[xiaket]

@vindurriel 谢谢, 大家对 pyyaml 看来是怨恨都很多. lol

我对 assume-role 的不满仍可以参见我上面的比方, assume-role 给了一台服务器的 shell 权限, 虽然是受限的; 而 eb 给了一个 api, 没有直接暴露 shell, 所以我们觉得放心一点. 不过对于 eventbridge 方案你提到的坏处我有点不太理解. 我为啥要限制接收账号的权限? 我定义好了消息的格式后就把命令丢出去, 这类似一个客户端请求, 受服务端处理的摆布在我理解算是正常的?

[lyhiving]

用法高端，如果是 PHP 的话我觉得已经传疯了