公司一般会采取内网+域账号+动态口令+跳板机的方式来保证生产环境的安全。这套机制确实好用，但是也有一些问题，比如需要单独的服务器，耗费资源；大家共用跳板机，使得跳板机可能成为瓶颈。在云计算时代，跳板机不能很好地满足公有云环境的安全了。
针对传统跳板机的问题，AWS推出了EC2 Systems Manager。EC2 Systems Manager不需要单独的机器，拥有完善的IAM控制，还可以通过CloudTrail收集操作信息，优点很多。
这篇文站：使用Amazon EC2 Systems Manager取代堡垒机详细介绍了EC2 Systems Manager的优势，并且给出了体验的方法。下面就根据这篇文章体验一下EC2 Systems Manager功能。
- 通过文章里面给出的CloudFormation创建好相关的资源。
- 进入EC2控制，侧边栏选择
托管实例，然后点击上面的运行命令按钮。
- 接着选择
AWS-RunShellScript
- 我们执行一下
uname -a命令。设置好SNS需要的配置，这样执行完命令之后会有通知。如果要将命令执行结果保存到S3里面，也可以设置上S3 bucket。CloudFormation已经创建好了一个名为ssm-output-history-${account_id}-us-east-1的S3 bucket。
- 执行完命令之后，可以查看一下命令具体的执行结果。
- SNS也把命令的执行结果发到邮箱里了。
EC2 Systems Manager不需要独立的机器，需要在执行命令的机器上安装SSM Agent。登录到EC2，可以发现这个agent进程。
SSM Agent通过IAM角色与Systems Manager进行通信。这个角色必须具有足够权限与Systems Manager及其辅助服务进行交互。IAM已经提供了一个名为AmazonEC2RoleforSSM的托管策略，为您预先定义了这些权限：允许代理程序获取并回复Systems Manager消息、发布CloudWatch指标、并将日志文件写入S3。
授予Systems Manager策略的角色使用的是EC2的附加角色功能。
命令运行完成之后，可以去OSS里面看日志。但是我在OSS里面并没有发现相关的日志，于是去配置好CloudTrail和CloudWatch排查问题。通过CloudTrail收集OSS的操作信息，通过CloudWatch分析数据。
发现是权限出了问题，于是去S3 bucket里面把存储桶策略里面的policy删除掉了，然后就可以在这个bucket里面看到日志了。具体原因要分析一下这个policy。
