AWS SessionManager(セッションマネージャ）でポートフォワーディング３

・2016 年 11 月以降に公開された Windows Server 2008-2012 R2 AMI
・Windows Server 2016 および 2019
・Amazon Linux
・Amazon Linux 2
・Ubuntu Server 16.04
・Ubuntu Server 18.04
・Amazon ECS 最適化

これらのOSは、EC2にIAMロール（AmazonEC2RoleforSSMポリシーをアタッチしたロール）をアタッチすることで、InternetGateway経由でのセッションマネージャの接続が可能になります。

また、仕事でRHEL使う方は手動でSSM Agentをインストールすることになります。
各OSでのSSM Agentのインストール方法は以下が本家です。

SSM エージェントの使用 - AWS Systems Manager

■SSM Agentの手動インストールと注意事項について

Linux 用の EC2 インスタンスに手動で SSM エージェントをインストールする - AWS Systems Manager

現場で「セッションマネージャ導入するぞ！！」って意気込んで、出ばなをくじかれそうなのが、RHEL5はSSM Agentは導入非推奨です。
（そもそも手順がない。RHEL6の手順でインストールできそうですが、やめた方が無難）

■SSM Agentのログ格納先について

SSM エージェントログを表示する - AWS Systems Manager

■SSM Agentのバージョン確認方法について

aws ssm describe-instance-information
{
    "InstanceInformationList": [
        {
            "InstanceId": "i-XXXXXXXXXXXXX",
            "PingStatus": "Online",
            "LastPingDateTime": "2020-05-01T23:31:25.030000+09:00",
            "AgentVersion": "2.3.978.0",
            "IsLatestVersion": false,

■ポートフォワーディングのセッション確立時のawscliコマンドリファレンス

ssm — AWS CLI 1.18.50 Command Reference

■VPC エンドポイントについて

VPC エンドポイント - Amazon Virtual Private Cloud

■「セッションマネージャによるポートフォワーディング」と「踏み台サーバの比較」

「マネージドサービスであるセッションサービス」と「自前の踏み台サーバ」という点で、他のAWSサービス同様にマネージドサービスの利点を享受できるのは嬉しいところです。
ただ、以下4点は気になりました。
①　SSMのSLAは99.9%となっており、ひと月当たり50分程度の停止が許容できるかどうか
②　EC2にインストールしているSSM Agentの定期的なアップデート
③　Clientのsession-manger-pluginの定期的なアップデート
④　ポートフォワーディングをする際にstart-sessionを実行するため、Clientにawscliを導入する必要がある

上記①は、個人的には今まで踏み台サーバを常時起動しておくような現場は少なかったので、セッションマネージャは大いに活躍できる印象を持っています。

上記②は自動化すること（Run-Command）もできるようなのでそんなに問題にはならないかもですが、定期アップデートってあんまりいい思い出がない。。。

上記③はClient側での作業になるため、アップデートタイミングの調整等が大変そうだなと。

上記④はセッション時の監査方法とかきちんと整備した上でなら問題ないと思っていますが、監査対応等を実施する運用工数がかさみそうで・・・。

以上です。この記事は随時アップデートできるようにしたいです。
※ナレッジベース的な扱いにしたいです。

自由気ままに書いちゃおう

好きなことをつらつらと・・・