在整個 104 的 AWS 架構中，各單位擁有自己帳號的管理權 (IAM Admin)，自己的帳號自己負責，被罰單懲罰時也自己付錢，看似合理，但若放在整個 Production 的網路結構看時就不是這麼一回事 …
問題
若是採用 Transit VPC 的架構下，必須要思考的安全性遠遠大於方便性，畢竟大家都是被串在同一個窩，只要其中有一個環節產生漏洞，整個 Production 等同於暴露在風險中。
當安全性出現疑慮時，最直接被想到的就是 IAM 跟 Security Group，IAM 可以透過 Policy 的設計避免不當的權限給予，但 Security Group 就比較棘手，尤其是 Bastion 的設定，多數人的家裡 IP 是浮動的，但台灣工程師的奴性就是回家還是會繼續工作，貪圖方便相信很多人都會直接設為 0.0.0.0/0，或者加了當前的浮動 IP 後就忘了拿掉，但實際上你的 IP 已經被別人 reuse。
OKAY，那如果有登入 instance 的需求時怎麼辦，總是會有意外需要 Login 進行 Debug 的時候吧？
有些人可能會說，用 AWS Config 或其他的 Scan Tool 偵測有沒有不符合規範的 Security Group 啊，不符合就把該 SG 幹掉！
沒錯！這是最直接且強硬的作法，但是當人多的時候，這樣的衝擊往往必須接受文化與人的考驗
我當下有緊急的問題要修改啊！
這樣很不方便耶！
我的設備突然被砍掉了，你應該要通知我怎麼做啊！(明明就教過你)
解決方案 – AWS SSM (Session Manage)
所以當下與團隊的思考後 Bastion 是 AWS 標準方法，但因應企業文化不見得是一個很好的解決方式，後來改採用 AWS Systems Manager 中的 Session Manager。
2018 年 AWS 針對 SSM 做了許多改進，其中一個亮點就是 Session Manager，其功能就是讓你可以透過 Web Console / CLI 登入 Instance，「用 Session Manager 取代 Bastion」是我們採用的方式，原因不外乎是解決 Security Group 的問題，可透過 IAM 控管可用 Session Manager 的人，Session Manager 下的操作都會被如實的記錄到 S3，整個 Session history 也完整紀錄了 Login Start / End 等資訊。
AWS 為了讓 SSM 普及，乾脆 AMI 都直接內建 SSM Agent：
SSM Agent is installed, by default, on the following Amazon EC2 Amazon Machine Images (AMIs):
Windows Server (all SKUs)
Amazon Linux
Amazon Linux 2
Ubuntu Server 16.04
Ubuntu Server 18.04
理論上從 2018 下半年的 AMI 都內建支援 SSM Agent。
手動安裝也是簡單到哭，透過 snap 的 app store 安裝 ssm agent：
$ sudo apt update
$ sudo apt install snapd
$ sudo snap install amazon-ssm-agent --classic
amazon-ssm-agent 2.3.274.0 from 'aws' installed
如果設備在純 Private 環境的話
AWS 大概聽到很多人的心聲，「Configure SSM Agent to Use a Proxy」連純 Private 都設想到了，直接加 HTTP_PROXY 的變數，但 Upstart 的方式比較不建議，因為直接 export 會把整個 network traffic 都指向到 Proxy 去，如果可以還是用 Systemd 比較好！
如果 Upstart / Systemd 都不想用，現在 PrivateLink 也支援完整的 Endpoint「Setting Up VPC Endpoints for Systems Manager」，一次會用到四個 VPC Endpoint：
com.amazonaws.
region.ssm: The endpoint for the Systems Manager service.
com.amazonaws.region.ec2messages: Systems Manager uses this endpoint to make calls from SSM Agent to the Systems Manager service.
com.amazonaws.region.ec2: If you’re using Systems Manager to create VSS-enabled snapshots, you need to ensure that you have an endpoint to the EC2 service. Without the EC2 endpoint defined, a call to enumerate attached EBS volumes fails, which causes the Systems Manager command to fail. For more information about using Systems Manager to create VSS-enabled snapshots, see Using Run Command to Take VSS-Enabled Snapshots of EBS Volumes.
com.amazonaws.region.ssmmessages: This endpoint is required only if you are connecting to your instances through a secure data channel using Session Manager. For more information.
整體來說用 SSM 解決了在安全性的問題，也提供稽核的方式，面對不熟悉的工程師可以直接使用 Web Console，而喜好 CLI 有更好的便利性，實測 CLI 的速度並不輸 SSH terminal (Taiwan -> Tokyo)
