トップ > AWS Systems Manager > AWS Systems Manager ジャストインタイムノードアクセス及び統合コンソールの構築・設計における注意点

AWS Systems Manager ジャストインタイムノードアクセス及び統合コンソールの構築・設計における注意点

AWS Systems Manager
記事タイトルとURLをコピーする

AWS Systems Manager & JITノードアクセス 設計・構築における注意点

はじめに

AWS Systems Manager の Just-in-Time (JIT) ノードアクセスは、EC2 インスタンスへの接続を「承認フロー付きの一時的なアクセス権」で制御する機能です。バスティオンホストや SSH ポートを不要にしながら、誰が・いつ・どのノードに接続したかを厳格に管理できます。

本記事では、実際に構築・運用する際に必ずハマる落とし穴と設計のポイントを整理します。

JIT ノードアクセスは 統合コンソール (以下、Unified Console) の設定が必須の前提条件です。Unified Console を設定せずに JIT だけ有効化することはできません。

ジャストインタイムノードアクセスを使用するように統合コンソールを設定する必要がありますか?

はい。統合コンソールの設定は、ジャストインタイムノードアクセスの前提条件です。ただし、統合コンソールを設定してジャストインタイムノードアクセスを有効にした後は、ノードに接続する方法がいくつかあります。例えば、Amazon EC2 コンソールと AWS CLI からジャストインタイムノードアクセスセッションを開始できます。統合コンソールの設定の詳細については、「組織用の Systems Manager 統合コンソールのセットアップ」を参照してください。

参照：Just-in-time node access FAQ

イメージ図

※ 公式なアーキテクチャ図は公開されていないため、上記の図はあくまで筆者のイメージです。

1. Unified Console のセットアップと制約

Unified Console のセットアップは AWS Organizations の管理アカウントから行い、委任管理者アカウントを別途指定する必要があります。日常の運用は委任管理者アカウントで行います。

管理アカウントは JIT の対象外

管理アカウント自体は JIT ノードアクセスの対象となりませんので、ご注意ください。JIT で管理するノードは、メンバーアカウント（ワークロードアカウントや委任管理者アカウント等）に配置する必要があります。

リージョン選択の制約

Unified Console セットアップ時に選択したリージョンが、JIT で使用できるリージョンの上限になります。セットアップ後に追加できるリージョンは、Unified Console で選択済みのリージョンのみです。

Unified Consoleの選択

たとえば東京リージョン（ap-northeast-1）のみを選択していた場合、JIT も東京リージョンのノードにしか使用できません。

上記のパターンの場合、JIT設定画面で東京リージョンしか選択できない

リージョン追加の制限

Unified Console 設定時に選択しなかったリージョンを、後から JIT に追加することはサポートされていません。将来的に複数リージョンで使う可能性がある場合は、初期セットアップ時に想定するすべてのリージョンを選択してください。

Unified Console がセットアップする依存サービス

セットアップ時に以下のサービスへのトラステッドアクセスと委任管理者の登録が自動で行われます。これらのサービスで委任管理者のクォータを超えていると、セットアップが失敗するため事前確認が必要です。

依存サービス 用途
AWS CloudFormation SSM に必要なリソースを各アカウントにデプロイ
AWS Resource Explorer EC2 インスタンスの検索・フィルタリング
AWS Systems Manager Explorer デプロイリソースの監視・トラブルシュート
AWS Systems Manager Quick Setup 必要な Quick Setup 設定のデプロイ

参照：Setting up Systems Manager unified console for an organization

2. IAM ポリシーの設計

JIT ノードアクセスを有効化するには、4 つの異なる IAM ポリシーが必要です。

ポリシー 付与対象 主な権限
JIT 有効化ポリシー 管理者 ssm-quicksetup:*、CloudFormation、Organizations 関連
JIT 設定ポリシー 委任管理者 承認ポリシーの CRUD
承認者ポリシー 承認担当者 アクセスリクエストの承認・拒否
ユーザーポリシー 接続するユーザー アクセスリクエストの作成・セッション開始

Session Manager の StartSession 権限を削除すること

JIT に移行する場合、既存の ssm:StartSession 権限を IAM ポリシーから削除しないと Session Manager を直接使う抜け穴が残ります。移行時は少数のユーザー・ノードで試験運用し、動作確認後に段階的に StartSession 権限を撤廃してください。

認証情報の制限

JIT ノードアクセスは AWS STS の AssumeRole による一時クレデンシャルのみをサポートします。IAM ユーザーの長期クレデンシャル（アクセスキー）は使用できません。また、Windows への RDP 接続で Single Sign-On 認証タイプはサポートされていません。

参照：Setting up just-in-time access with Systems Manager — IAM policies

IAM Identity Centerをマルチリージョン化する際の注意点

IAM Identity Center がマルチリージョン構成の場合、下記のkms:Decryptポリシーを追加しないと、申請者権限を持っていても申請画面が表示されず、代わりに以下のエラー画面が表示されます。

blog.serverworks.co.jp

エラー内容：

User: AWSReservedSSO_JIT-User is not authorized to perform: ssm:StartSession
on resource: SSM-SessionManagerRunShell
because no identity-based policy allows the ssm:StartSession action

通常時の挙動

kms:Decrypt 権限が不足している場合の挙動

追加ポリシー：

{
    "Sid": "AllowKMSDecrypt",
    "Effect": "Allow",
    "Action": "kms:Decrypt",
    "Resource": "arn:aws:kms:XXX:XXX:key/mrk-XXX (IAM Identity Centerマルチリージョン化のKMSキーARN)"
}

3. 承認ポリシーの設計と優先順位

承認ポリシーの評価順序

複数の承認ポリシーが存在する場合、以下の順序で評価されます。

  1. アクセス拒否 (Deny-access) — 最優先。マッチすれば即座に拒否
  2. 自動承認 (Auto-approval) — 拒否に引っかからなければ自動承認
  3. 手動承認 (Manual) — 自動承認もなければ承認者に通知

手動承認が複数ある場合、JIT はより具体的なポリシーを優先します。

  1. タグ指定ターゲット（具体的）
  2. 全ノードターゲット（汎用）

ポリシーを設定するアカウントの違い

ポリシー種別 設定するアカウント
アクセス拒否 JIT が委任されたアカウント（組織レベル設定）
自動承認 対象 EC2 と同じアカウント（ローカル設定）
手動承認 対象 EC2 と同じアカウント（ローカル設定）

承認者はどのアカウントで承認するか

手動承認ポリシーは対象 EC2 と同じアカウントのローカル設定のため、承認者も対象 EC2 と同じアカウントにスイッチして承認操作を行う必要があります。委任管理者アカウントから別アカウントのリクエストを承認することはできません。

管理アカウントの EC2 は JIT 対象外 以下の 2 つの理由から、管理アカウントの EC2 は JIT の対象外となります。

  • コンソール上に「Systems Manager 統合エクスペリエンスは、組織の管理アカウントでは使用できません」と表示される
  • JIT は Unified Console の対象にのみ対応しており、管理アカウントは Unified Console の対象外

したがって、管理アカウントに EC2 を配置しても JIT で接続することはできません。EC2 は必ずメンバーアカウントに配置してください。

承認ポリシーがないノードにはアクセス不可 マッチする承認ポリシーが一つも存在しないノードには、ユーザーはアクセスリクエスト自体を送れません。ノードをカバーする承認ポリシーが必ず存在するようにタグ設計・ポリシー設計を行ってください。

参照：What is the precedence for just-in-time node access approval policies?

承認者権限あっても承認できないパターン

ユーザーAが申請権限を使用して申請した場合、同じユーザーAが承認権限を持っていても、自身の申請を承認することはできません。設計時には、この制約を考慮してください。

4. タグ設計の落とし穴

大文字・小文字は完全一致

承認ポリシーでターゲットとして指定するタグは、EC2 のタグと大文字・小文字を含めて完全一致する必要があります。たとえばポリシーで Env = dev（大文字 E）と指定していても、EC2 のタグが env = dev（小文字 e）であればマッチしません。マッチしない場合は「一致する承認ポリシーがない」として自動拒否されます。

【最も重要】タグの重複によるコンフリクト

一つのノードに複数の手動承認ポリシーが適用されるとコンフリクトが発生し、そのノードへのアクセスリクエストが一切できなくなります。

EC2 に複数のタグが付いている場合、各タグに対して別々の承認ポリシーを作成するとこの問題が起きます。

コンフリクト例

EC2 に env=prod と role=web の 2 タグが付いている状態で、

  • Policy A → env=prod をターゲット
  • Policy B → role=web をターゲット

→ 両方が同一 EC2 に適用されるためコンフリクト → アクセス不可

ケース EC2 タグ Approval Policy 結果
✅ OK env=prod Policy A → env=prod 1 つのみ適用 → 正常
✅ OK env=prod role=web Policy A → env=prod のみ 1 つのみ適用 → 正常
❌ NG env=prod role=web Policy A → env=prod、Policy B → role=web 2 つが同一 EC2 に適用 → コンフリクト
❌ NG env=prod Policy A, Policy B ともに env=prod 同じタグに 2 ポリシー → コンフリクト

対策：1 ノード = 1 ポリシーのルール

ポリシー設計前に EC2 のタグ体系を整理し、1 つのノードにマッチする手動承認ポリシーが必ず 1 つだけになるようにタグ設計・ポリシー設計を行うことが重要です。承認ポリシーのターゲットに使うタグは、EC2 の識別タグから 1 種類に絞ることを推奨します。

参照：What happens if multiple manual approval policies apply to a node?

5. ネットワーク要件

EC2 から SSM エンドポイントへの通信方法は 2 択です。どちらか一方があれば動作します。 セキュリティ要件次第どちらかを選択する必要があります。

方法 条件
インターネット経由 VPC からインターネットへ通信可能な場合（Internet Gateway または NAT Gateway を利用）
VPC エンドポイント（PrivateLink） VPC からインターネットへ通信できない場合

VPC エンドポイントは必須ではない

Internet Gateway があり、EC2 が SSM エンドポイントへ HTTPS (443) でアウトバウンド通信できる環境であれば、VPC エンドポイントは不要です。VPC エンドポイントは「インターネットを経由させたくない」場合のセキュリティ強化オプションです。

参照：Step 6: (Optional) Use AWS PrivateLink to set up a VPC endpoint for Session Manager

必須エンドポイント

エンドポイント タイプ 役割 用途
com.amazonaws.{region}.ssm Interface コントロールプレーン セッション開始時の認証・認可、SSM Agentのハートビート（5分間隔）
com.amazonaws.{region}.ssmmessages Interface データプレーン セッションの実データ（シェル入出力、Port Forwardingストリーム）をWebSocket over HTTPS/443で中継
com.amazonaws.{region}.sts Interface 認証プレーン DHMCによるIAMロール一時クレデンシャル取得、IMDSv2経由のSTS認証等
com.amazonaws.{region}.ec2messages※1 Interface レガシーメッセージ配信 SSM Agent 3.3.40.0以降ではssmmessagesが優先される

※1 ec2messages エンドポイントについて

com.amazonaws.{region}.ec2messages は、SSM Agent が Systems Manager と通信するために従来利用されていた Amazon Message Delivery Service のエンドポイントです。過去には Run Command や Session Manager の通信で利用されていました。

しかし、SSM Agent 3.3.40.0 以降では、利用可能な場合に ec2messages よりも ssmmessages が優先的に使用されるようになっています。

また AWS では、2024 年以降に開設されたリージョンでは ec2messages:* API はサポートされておらず、ssmmessages:* のみが利用可能です。そのため、新規構築環境では ssmmessages の利用を前提とし、ec2messages の VPC エンドポイントは原則不要です。

東京リージョン（ap-northeast-1）や大阪リージョン（ap-northeast-3）など、2024 年以前に開設されたリージョンでは現在も ec2messages を利用できます。

ただし、SSM Agent 3.3.40.0 以降では ssmmessages が優先的に使用されるため、通常は ec2messages の VPC エンドポイントを作成する必要はありません。

なお、古い SSM Agent を利用している環境では ec2messages が使用される可能性があるため、削除する場合は事前にエージェントのバージョンを確認してください。

ec2messages: API operations are supported only in AWS Regions that launched before 2024. In Regions launched in 2024 and later, only ssmmessages: API operations are supported.

Beginning with version 3.3.40.0 of SSM Agent, Systems Manager began using the ssmmessages: endpoint (Amazon Message Gateway Service) whenever available instead of the ec2messages: endpoint (Amazon Message Delivery Service).

参照：docs.aws.amazon.com

オプションエンドポイント（用途に応じて追加）

エンドポイント タイプ 用途
com.amazonaws.{region}.kms Interface セッションデータの KMS 暗号化（デフォルト TLS のみなら不要）
com.amazonaws.{region}.s3 Gateway または Interface セッションログ・RDP 録画の S3 保存
com.amazonaws.{region}.ec2 Interface VSS スナップショット（SSM 経由）
com.amazonaws.{region}.logs Interface CloudWatch Logs用

S3 エンドポイントの選択：Gateway vs Interface

コスト最優先なら Gateway 型（無料） ですが、オンプレミスや別リージョンからのアクセス、SG による細かいアクセス制御が必要な場合は Interface 型（有料） を選択してください。Gateway 型は Route Table への追加が必要（SG 不要）です。

ec2 エンドポイントが必要なケース

SSM 経由で VSS スナップショット（ボリュームシャドウコピー）を取得する場合に必要です。このエンドポイントがないと、Run Command（SendCommand API）でスナップショット取得が失敗します。ただし、実際には AWS Backup 経由でシャドウコピーするパターンが多いため、通常は不要です。設計次第で判断してください。

参照：Application-consistent snapshots troubleshooting

Gateway エンドポイント Interface エンドポイント
ネットワーク AWS ネットワーク内に留まる AWS ネットワーク内に留まる
IP アドレス S3 パブリック IP を使用 VPC のプライベート IP を使用
オンプレミスからのアクセス ❌ 不可 ✅ Direct Connect/VPN 経由で可能
別リージョンからのアクセス ❌ 不可 ✅ VPC Peering/Transit Gateway 経由で可能
セキュリティ制御 Route Table + Endpoint Policy SG による細かい制御が可能
料金 無料 有料

基本的にGatewayを選ぶとコスト節約になります。ただし、別リージョンやオンプレミスからのアクセスが必要な場合はInterfaceを選定してください。本番環境でEndpoint Policyによる制御では不十分な場合や、SGによるより厳密なアクセス制御が必要な場合はInterfaceエンドポイントが適しています。

エンドポイント用セキュリティグループ

Interface タイプのエンドポイントには、インバウンドのみ次のルールを設定します。

タイプ プロトコル ポート ソース
HTTPS TCP 443 EC2インスタンスが存在するサブネットのCIDR

参照：Step 6: Use AWS PrivateLink to set up a VPC endpoint for Session Manager

対象EC2のセキュリティグループ

対象EC2のセキュリティグループでは、SSM 接続のためにインバウンドルールを追加する必要はありません。

必要なのはアウトバウンド通信のみで、EC2 から SSM 関連エンドポイントへ HTTPS (TCP/443) で到達できることです。

Interface VPC Endpoint を利用する場合

アウトバウンドルールの送信先として、SSM 用 Interface VPC Endpoint が配置されているサブネットの CIDR を許可します。

タイプ プロトコル ポート 宛先
HTTPS TCP 443 VPC Endpoint 配置サブネットの CIDR

S3 Gateway Endpoint を利用する場合

Session Manager のログ保存や RDP 録画保存などで S3 Gateway Endpoint を利用する場合は、上記に加えて S3 Gateway Endpoint の Prefix List を許可する必要があります。

タイプ プロトコル ポート 宛先
HTTPS TCP 443 S3 Gateway Endpoint の Prefix List

S3 Gateway Endpoint はセキュリティグループを持たないため、EC2 側のアウトバウンドルールで Prefix List を許可します。

6. SSM Agent の管理

SSM Agent 自動更新オプションの注意点

Unified Console の設定で「SSM Agent 自動更新」を有効にし、更新頻度（例：14 日ごと）を指定できます。ただし、実際の更新タイミングは AWS 側が自動制御するため、任意の日時を指定することはできません。

更新タイミングを自分で制御したい場合は、委任管理アカウントにてSSM Agent 自動更新オプションを無効化し、代わりに各対象ワークロードAWSアカウントにてState ManagerとMaintenance Windowを組み合わせて更新スケジュールを個別に設定してください。

例えば、Env：dev-lin または Env：dev-win タグが付与された EC2 インスタンスに対して、毎日 23:00（JST）に SSM Agent を自動更新する必要がある場合は、下記の設定を行います。

[AWS Systems Manager] > [ステートマネージャー] > [関連付けの作成]をクリックします。

名前 値
名前 例：SSMAgentUpdate-Dev
ドキュメント AWS-UpdateSSMAgent
ターゲット タグを指定 → キー: タグを入力
スケジュール CRON/Rate 式(14:00 UTC): cron(0 14 * * ? *)

作成したジョブの実行履歴を確認します。

ステータスが「成功」になって、意図した EC2 インスタンスに適用されていることを確認します。

7. セッション時間・ログイン方法・スコープの注意点

セッション時間はいつから始まるか

JIT では、承認されてからセッション時間のカウントが始まります。ユーザーが実際に接続した時点ではないため、承認後にアクセスしなかった場合でもセッション時間は消費されますので、設計時にご注意ください。

承認期限が切れても、確立済みのセッションは切断されない

承認ポリシーで設定した「アクセス許可時間」は、その時間内にセッションを開始できる期限であり、既に確立済みのセッションを強制的に切断するタイマーではありません。

※本記事執筆時点の検証結果ですが、最新の挙動をあらためてご確認ください。

検証したところ、以下のような挙動になります。

タイミング 挙動
承認期限内にセッション開始 → 期限を過ぎても接続を継続 ✅ セッションは切断されない（そのまま継続可能）
承認期限が切れた後、同じリクエストで新規セッションを開始しようとする ❌ 新規セッションは開始できず、新しいアクセスリクエストの申請画面が表示される

つまり「アクセス許可時間」は 新規セッション開始の締切であり、セッションの最大持続時間ではありません。

承認期限とは別に、セッション自体の接続時間を制限したい場合は、Session Manager Preferences 側の以下の機能で制御してください。

設定項目 役割 デフォルト設定値
アイドルセッションタイムアウト 非アクティブ（無操作）が一定時間続いた場合にセッションを自動切断する（1〜60分） 20分
最大セッション時間 セッション開始から接続を強制終了するまでの最大持続時間を設定する（有効にする場合は1〜1,440分） デフォルト設定なし（無効）

設計上の注意

「承認ポリシーのアクセス許可時間を短く設定すれば、セッションもその時間で自動的に終了する」という誤解をしないようご注意ください。セッションそのものの接続時間を制限したい場合は、承認ポリシーの時間設定ではなく、Session Manager Preferences のアイドルセッションタイムアウトまたは最大セッション時間を別途有効化・設定する必要があります。

Windows ログイン時の認証情報

Linux の場合、JIT 承認後にそのままセッションが開始されます。一方 Windows の RDP 接続では、JIT 承認後も別途ログイン認証が必要ですので、ご注意ください。

認証タイプ 説明 パスワード必要？
ユーザー認証情報 Windows のユーザー名＋パスワード ✅ 必要
キーペア EC2 キーペアで管理者として接続 ❌ 不要（キーペアが必要）

SSO 認証タイプは JIT の Windows RDP 接続では非対応です。

ジャストインタイムノードアクセスでは、リモートデスクトップで Windows Server インスタンスに接続する場合、シングルサインオン認証タイプはサポートされません。

参照：Systems Manager でジャストインタイムアクセスをセットアップする

JITログインの実装方式によっては、AWSドキュメントのJIT申請者ポリシーに含まれている ec2:GetPasswordData（WindowsインスタンスへRDP接続する際に初期Administratorパスワードを取得するための権限）が不要な場合があります。その場合は、本権限をポリシーから削除することを検討してください。

クロスアカウント・クロスリージョンは非対応

スコープの制限

JIT ノードアクセスは、リクエスト者と同一アカウント・同一リージョンのノードへのアクセスのみをサポートします。別アカウントや別リージョンのノードへのアクセスには対応していません。

ハイブリッドアクティベーションで登録したオンプレミス・他クラウドのノードも JIT に対応していますが、同様にリクエスト者と同一アカウント・同一リージョンへの登録が必要です。

docs.aws.amazon.com

8. その他の注意点

RDPセッション開始のための追加権限が必要

「ジャストインタイムノードアクセスユーザー用の IAM ポリシー」の参考ポリシーには、ssm-guiconnect:GetConnection が含まれていません。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-just-in-time-node-access-setting-up.html

ssm-guiconnect:GetConnection を追加しない場合、JIT上で承認されていても Fleet Manager 経由で Windows Server への RDP セッションを開始できず、以下のエラーが発生します。

ブラウザの開発者ツールで、以下のエラーが出力されていることを確認できます。

GET https://ssm-guiconnect.ap-northeast-1.amazonaws.com/GetConnection/... 403 (Forbidden)

このエラーが表示される場合、IAMポリシーにssm-guiconnect:GetConnectionの権限が不足している可能性があります。

9. コスト

JIT ノードアクセスは 30 日間の無料トライアルが提供されます。トライアル終了後は有料となります。

JIT ノードアクセスはノード × 時間単位の従量課金です。無料トライアルは「有効化した請求サイクルの残り期間 + もう 1 請求サイクル分」が対象です。また、Advanced オンプレミスインスタンス tier を使用しているノードは、JIT 有効化アカウントでは追加料金が発生しません。

料金テーブル（ノード時間の累計・月次）

ボリューム 単価（ノード/時間）
最初の 72,000 時間 $0.0137
次の 647,999 時間（72,001〜720,000） $0.0103
次の 6,479,999 時間（720,001〜7,200,000） $0.0034
7,200,001 時間以上 $0.0014

AWS Organizations の Consolidated Billing を使っている場合、組織全体のアカウント・リージョンをまたいだノード時間が集計されます（計算例2はこのケース）。

計算例 1：小規模（200 ノード）

200 台 × 100 時間 = 20,000 ノード時間（すべて第 1 ティア）

20,000 時間 × $0.0137 = $274.00/月

計算例 2：大規模（1,000,000 ノード時間）

最初の 72,000 時間     × $0.0137 =   $986.40
次の 648,000 時間      × $0.0103 = $6,674.39
残り 280,000 時間      × $0.0034 =   $952.00
─────────────────────────────────────────────
合計                             = $8,612.79
平均単価                         ≒ $0.0086/ノード時間

最新の料金は AWS Systems Manager Pricing で確認してください。

参照：Is there cost associated with just-in-time node access?

チェックリスト

  • Unified Console の Regions セクションで必要なリージョンを選択した（リージョンの追加・削除はいつでも可能だが、JIT で使えるリージョンは Unified Console で選択済みのリージョンのみ）
  • 委任管理者アカウントを管理アカウントとは別に指定した
  • 依存サービスの委任管理者クォータを事前に確認した
  • 4 種類の IAM ポリシーを適切なエンティティに付与した
  • 移行後に ssm:StartSession 権限を既存ポリシーから削除した
  • 承認ポリシーのターゲットタグは EC2 タグと大文字小文字を含めて完全一致している
  • 1 つのノードにマッチする手動承認ポリシーが必ず 1 つだけになるようタグ設計した
  • すべてのノードをカバーする承認ポリシーが存在する（カバーされないノードはアクセス不可）
  • プライベートサブネット用に ssm / ssmmessages / ec2messages VPC エンドポイントを作成した（必要な場合のみ）
  • S3 エンドポイントは要件に応じて Gateway 型か Interface 型を選択した（必要な場合のみ）
  • SSM Agent バージョンを使用機能の要件バージョン以上に更新した
  • JIT のスコープは同一アカウント・同一リージョンのみであることをチームに周知した
  • 30 日の無料トライアル後のコストを試算・承認した

以上、御一読ありがとうございました。

本田 イーゴリ (記事一覧)

クロスインダストリー第2本部 インフラ技術課

・2026 AWS Ambassadors
・2026 Japan AWS Top Engineers (Services)
・2026 Japan All AWS Certifications Engineers
・2024 Japan AWS Top Engineers (Security)
・EC-Council CCSE
・Azure AZ-900

趣味：日本国内旅行(47都道府県制覇)・ドライブ・音楽