GAT技術ブログ

株式会社ギブ・アンド・テイクの技術ブログ

低コストで完全性を確保するAWS Session Managerログ保管方法

AWS

こんにちは！インフラ事業部のナガレダキです。

今回は、EC2インスタンスのSession Manager（セッションマネージャー）セッションログを、CloudWatch Logs・Firehose経由でS3バケット（以降S3と表記）に保管する方法をご紹介します。

「わざわざCloudWatch LogsとFirehose使わなくてもSession ManagerのセッションログならS3に直接出力できるのでは？」と思われた人。そのとおりです。
しかしながら、コストを抑えてSession Managerのセッションログの完全性を確保しつつログ保管するためには、CloudWatch Logsの経由が必要です。

今回ご紹介する構成は以下です。

1. Session Manager（セッションマネージャー）とは？

Session Managerは、AWSのサービス「Systems Manager（SSM）」に含まれる機能です。
SSMエージェントがインストールされたEC2インスタンスやオンプレミスサーバーに、ブラウザベースのシェルやAWS CLIから安全にアクセスできます。
SSHキーや踏み台サーバーを必要とせず、IAMポリシーによるアクセス制御や監査ログ取得が可能です。

公式ドキュメントは以下です。 https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager.html

2. Session Managerのセッションログ出力方法

Session Managerでは、セッションログ（接続したOS上で実行したコマンド履歴）を出力を設定できます。
ログの出力先は2パターンあり、CloudWatch Logs/S3の片方もしくは両方を設定できます。

2.1. Session Managerのログ出力方法（CloudWatch Logs）

ストリーミングで、Session ManagerのセッションログをCloudWatch Logsに出力できます。

メリット

  • ストリーミングでログが出力されるため、ログの完全性がある。
  • 簡易的なログの検索や分析が手軽にできる。

デメリット

  • ストレージ料金が高い（画像は2025年8月時点）。

    aws.amazon.com
  • 対話型コマンドのストリーミングはサポートされていない（これはS3も同じ。2025年8月時点）。
  • SQL等の詳細なログ分析ができない（2025年8月時点）。

2.2. Session Managerのログ出力方法（S3）

Session Manager接続の終了後に、Session Manager接続におけるOS上のコマンド実行ログを、S3に出力できます。

メリット

  • セッション終了時にログがまとめて出力されるため、ログの確認が比較的容易。
  • ストレージ料金が安い（画像は2025年8月時点）。

    aws.amazon.com
  • Athena等の後続のログ分析に流用できる。

デメリット

  • セッション中にストリーミングでログを確認することはできない。
  • EC2インスタンスの強制終了や再起動では、ログが出力されないため、ログの完全性がない。
  • SSMエージェントの停止や強制終了では、ログが出力されないため、ログの完全性がない。

3. Session ManagerのセッションログをCloudWatch Logs経由でS3に出力して何が嬉しいのか？

Session ManagerのログをCloudWatch Logs経由でS3に出力するメリットは、完全性のあるセッションログを長期間保管・分析できることです。

セッションログのCloudWatch Logs出力では、ログの完全性があるものの、ストレージ料金が高く、ログの詳細な分析ができないデメリットがあります。
一方でS3出力では、ストレージ料金が安く、後続のログ分析に流用しやすいものの、ログの完全性がないというデメリットがあります。

これらのデメリットを補完するため、CloudWatch Logs出力→サブスクリプションフィルター（Data Firehose）→S3という構成が考えられます。

※注意
CloudWatch Logsの保管期限設定でストレージ料金は抑えられますが、Session Managerの使用頻度が高いほど、FirehoseやS3へのリクエスト料金が割高になりますのでご注意ください。

4. Session ManagerのログをCloudWatch経由でS3に出力する手順

Session ManagerのログをCloudWatch経由で出力する手順をご説明します。

▼構成図

おおまかには以下の項目順に対応します。

  • Session Managerで接続するEC2インスタンス作成
  • セッションログの出力設定
  • セッションログをS3に配信するサブスクリプションフィルター作成
  • セッションログの出力確認（CloudWatch Logs・S3）

各項目の手順は次のとおりです。

4.1. Session Managerで接続するEC2インスタンス作成

Session Managerで接続するEC2インスタンスを作成します。

4.1.1. EC2インスタンス用IAMロール作成

  • IAMロールを作成します。
    信頼ポリシーは以下です。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
  • IAMロールに以下のIAMポリシーをアタッチします。
    検証環境で便宜上、CloudWatch Logsに関してはCloudWatchLogsFullAccessを付与していますが、過度な権限であるため適切に権限を絞り込むことをオススメします。
    • AmazonSSMManagedInstanceCore
      Session Managerで接続するときに必要な権限。
    • CloudWatchLogsFullAccess
      Session ManagerのセッションログをCloudWatch Logsに出力するときに必要な権限。

4.1.2. EC2インスタンス作成

  • EC2インスタンスを作成します。
    設定値は以下とします（記載のない設定値はデフォルト）。
    • AMI：x86のAmazonLinux2023の最新
    • インスタンスタイプ：t3.micro
    • キーペア：キーペアなし
    • パブリックIPアドレス：パブリックIPアドレス有効
    • サブネット：パブリック（インターネットへ直接通信できるルートテーブルがアタッチされている）
      検証環境で便宜上、パブリックサブネットにEC2インスタンスを配置していますが、インターネットへ制限なくアクセスできる脆弱性が生まれるため、プライベートサブネット＋NAT GatewayやVPCエンドポイントの構成をオススメします。
    • セキュリティグループ：インバウンドなし、アウトバウンドは443ポートで0.0.0.0/0を許可
    • IAMロール：前述「EC2インスタンス用IAMロール作成」で作成したIAMロール

4.2. セッションログの出力設定

Session Managerのログ出力先となるロググループを作成して、SessionManagerのログ出力を設定します。

4.2.1. CloudWatch Logsのロググループ作成

  • CloudWatch Logsのロググループを作成します（記載のない設定値はデフォルト）。
    設定値は以下とします。
    • 保持期間：3日
      ※最終的にログはS3に配信しますが、直近はCloudWatch Logsでも確認できるようにしておきたい期間を保持期間に設定します。
      最小限の保持でコスト削減したいのであれば1日でもOKです。
    • ログクラス：スタンダード
      　※infrequent Accessの場合、後述で設定するサブスクリプションフィルターが設定できません。

4.2.2. Session Managerのセッションログ出力設定

  • Systems Manager＞Session Managerの画面に移動して、設定タブを押下します。
    編集ボタンを押下して、設定値は以下とします（記載のない設定値はデフォルト）。
    • CloudWatchログ記録：チェックボックスをオン
    • ログ記録のオプション：セッションログをストリーミング
    • CloudWatchロググループ：前述「CloudWatch Logsのロググループ作成」で作成したロググループ

4.3. セッションログをS3に配信するサブスクリプションフィルター作成

Session Managerのセッションログを配信先S3および、配信するためのFirehoseを作成します。

4.3.1. セッションログの配信先となるS3作成

  • S3をデフォルト値で作成します。
    汎用バケットとしてクラスはスタンダードとします。

4.3.2. Firehose用IAMロール作成

  • IAMロールを作成します。
    信頼ポリシーは以下です。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "firehose.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
  • IAMロールに以下のIAMポリシーをアタッチします。
    検証環境で便宜上、AmazonS3FullAccessおよびCloudWatchLogsFullAccessを付与していますが、過度な権限であるため適切に権限を絞り込むことをオススメします。
    • AmazonS3FullAccess
      S3バケットにSession Managerのログを配信するために必要な権限。
    • CloudWatchLogsFullAccess
      Firehose自身のエラーログをCloudWatch Logsに出力するときに必要な権限。

4.3.3. Firehose作成

  • Firehoseストリームを作成します。
    設定値は以下とします（記載のない設定値はデフォルト）。

4.3.4. サブスクリプションフィルター用IAMロール作成

  • IAMロールを作成します。
    信頼ポリシーは以下です。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "logs.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
  • IAMロールに以下のIAMポリシーをアタッチします。
    検証環境で便宜上、AmazonKinesisFirehoseFullAccessを付与していますが、過度な権限であるため適切に権限を絞り込むことをオススメします。
    • AmazonKinesisFirehoseFullAccess
      Session ManagerのセッションログをFirehoseに連携するために必要な権限。

4.3.5. サブスクリプションフィルター作成

  • 前述「CloudWatch Logsのロググループ作成」で作成したロググループの画面に移動します。
  • 「サブスクリプションフィルター」タブを押下して、「Amazon Data Firehose サブスクリプションフィルターを作成」を選択します。
    設定値は以下とします（記載のない設定値はデフォルト）。
    • 送信先アカウント：現在のアカウント
    • Amazon Data Firehose ストリーム：前述「Firehose作成」で作成したFirehose
    • 既存のロールを選択：前述「サブスクリプションフィルター用IAMロール作成」で作成したIAMロール
    • ログの形式：JSON

4.4. セッションログの出力確認（CloudWatch Logs・S3）

EC2インスタンスに接続して、CloudWatch Logsへのセッションログ出力、そこからFirehoseでS3にセッションログが配信されているかを確認します。

4.4.1. Session ManagerでEC2インスタンス接続

  • 前述「EC2インスタンス作成」で作成したEC2インスタンスを選択します。
  • 「接続」ボタンを押下して、「セッションマネージャー」タブに移動して、「接続」ボタンを押下します。
  • EC2インスタンスのOSにログインしたら、セッションログを残すために、「pwd」などのコマンドを実行します。
  • 「終了」ボタンを押下して、セッションを終了します。

4.4.2. セッションログの出力確認（CloudWatch Logs）

  • 前述「CloudWatch Logsのロググループ作成」で作成したロググループの画面に移動します。
  • ログストリームが作成されていることを確認して、アクセスします。
  • セッションログ（EC2インスタンスのOS上で実行したコマンドとその出力）を確認します。
    実行したコマンドはsessionDataフィールドで確認できます。

4.4.3. セッションログの出力確認（S3）

  • 前述「セッションログの配信先となるS3作成」で作成したS3バケットの画面に移動します。
  • フォルダsession-logs/の最下層に、gzファイルが格納されているので、ダウンロードします。
  • gzファイルを解凍すると、「セッションログの出力確認（CloudWatch Logs）」で確認したログと同じログとなっていることを確認します。

    ※Firehoseで配信する過程でメタ情報が付与されている影響でコマンド結果などが入れ子の情報になっていますが、GlueでAthenaを利用すれば分析可能です。

5. まとめ

今回は、EC2インスタンスのSession ManagerのセッションログをCloudWatch LogsとFirehoseを経由してS3に保管する方法をご紹介しました。

もちろん、セッションログはS3へ直接出力することも可能ですし、わざわざCloudWatch Logsを挟むのは一見遠回りに見える構成かもしれません。
しかし、この構成にすることでログ欠落のリスクを抑えつつ、安価なS3に安全に蓄積できるという利点があります。

さらに、この方法で保管したログはAthenaを使って柔軟に分析できるというメリットもありますので、その活用方法についてはまた次回お伝えします。

この記事を通して、どなたかのお役に立てられたら幸いです。