AWS Systems Managerの
aws ssm start-session コマンドを使えば、踏み台EC2もSSHポート解放も不要で、プライベートサブネットのEC2に安全に接続できます。接続経路がAWSのSSMサービスエンドポイントを経由するため、特定のAZに依存しない設計が実現できます。この記事では、マルチAZ冗長構成へのSSM Session Manager組み込み方法、IAMインスタンスプロファイルの設計方針、クロスアカウント接続のSTSロール引き受け手順を、Amazon Linux 2023で動作確認した実行例付きで解説します。この記事のポイント
・aws ssm start-session は踏み台なしでプライベートサブネットのEC2に接続できる
・マルチAZ構成では全AZのEC2に同じIAMインスタンスプロファイルを付けるのが基本設計
・クロスアカウント接続はExternalId付き信頼ポリシーとSTSロール引き受けで実現する
・プライベートサブネットにはssm・ssmmessages・ec2messagesの3エンドポイントが必要
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜSSM Session ManagerがマルチAZ冗長設計と相性がいいのか
従来の踏み台EC2方式には構造的な弱点があります。「AZ-aの踏み台経由でAZ-cのEC2に入る」設計では、AZ-aに障害が発生した瞬間に、AZ-cの正常なEC2への入り口も消えます。冗長化しているはずのAZ-cインスタンスに接続できず、障害対応が遅れる——これはマルチAZ設計の目的を半ば損なう結果です。SSM Session Managerでは、接続経路がEC2内のSSM AgentとAWSのSSMサービスエンドポイント間のアウトバウンド通信で完結します。特定のAZを経由するネットワーク経路ではないため、AZ-aが落ちても、AZ-c・AZ-dのEC2へは独立して接続を維持できます。
・踏み台EC2が不要:EC2台数と管理コストを削減できる
・SSHポート22のインバウンド解放が不要:セキュリティグループの規則をシンプルに保てる
・IAMによるアクセス制御:接続先EC2・実行可能操作をポリシーで細かく制御できる
・セッションログ:CloudWatch Logs / S3への自動記録で監査証跡を残せる
aws ssm start-sessionの前提条件を確認する
接続が成立するまでに必要な要素を整理します。1. 接続元PC・サーバーへのSession Manager Pluginインストール
aws ssm start-session を実行するPCまたは作業用サーバーにAWS CLI v2とSession Manager Pluginが必要です。Amazon Linux 2023 / RHEL 9.4での確認例を示します。# Session Manager PluginをRPMでインストール(Amazon Linux 2023 / RHEL9) $ curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm" -o "/tmp/session-manager-plugin.rpm" $ sudo dnf install -y /tmp/session-manager-plugin.rpm # インストール確認 $ session-manager-plugin --version 1.2.677.0
2. EC2インスタンスのSSM Agent稼働確認
接続先EC2でSSM Agentが動いているかを確認します。Amazon Linux 2023はデフォルトでインストール・有効化されています。# EC2インスタンス内でSSM Agentの状態を確認 $ sudo systemctl status amazon-ssm-agent * amazon-ssm-agent.service - amazon-ssm-agent Loaded: loaded (/usr/lib/systemd/system/amazon-ssm-agent.service; enabled) Active: active (running) since Mon 2026-09-14 09:00:00 UTC; 3 weeks ago Main PID: 1105 (amazon-ssm-agent) Tasks: 10 (limit: 4600) Memory: 42.3M
Active: active (running) であれば正常です。停止している場合は以下で起動・自動起動設定を行います。$ sudo systemctl start amazon-ssm-agent $ sudo systemctl enable amazon-ssm-agent
3. IAMインスタンスプロファイルの設定
EC2インスタンスがSSM経由で操作されるには、IAMロールにAmazonSSMManagedInstanceCore ポリシーが必要です。IAMコンソールでロールを作成する際の設定は以下のとおりです。・信頼エンティティ:EC2(
ec2.amazonaws.com)・アタッチするポリシー:
AmazonSSMManagedInstanceCore(AWS管理ポリシー)このポリシーには
ssm:UpdateInstanceInformation・ssmmessages:*・ec2messages:* など、SSM AgentがAWSサービスと通信するための権限が含まれています。IAMロールを作成後、EC2コンソールで対象インスタンスを選択し「アクション」→「セキュリティ」→「IAMロールを変更」からアタッチします。4. VPCエンドポイントの設計(プライベートサブネット)
インターネットに出られないプライベートサブネットに置いたEC2からSSMを使うには、NATゲートウェイかVPCエンドポイントが必要です。VPCエンドポイントを選ぶとNATゲートウェイのデータ処理コストを回避できます。必要なエンドポイントは3つです。| サービス名 | 役割 |
|---|---|
com.amazonaws.ap-northeast-1.ssm |
SSM APIエンドポイント(AgentがSSMサービスと通信) |
com.amazonaws.ap-northeast-1.ssmmessages |
Session Managerのセッション確立に使うメッセージチャネル |
com.amazonaws.ap-northeast-1.ec2messages |
Run Commandなどの操作コマンドの転送 |
マルチAZ環境でのIAMインスタンスプロファイル設計
マルチAZ構成でSSMを正しく機能させるIAM設計の考え方を整理します。1. 全AZのEC2に同一インスタンスプロファイルを付ける
AZ-a・AZ-c・AZ-d など複数AZにEC2を分散させる場合、全インスタンスに同じIAMインスタンスプロファイルをアタッチします。IAMロールは1つ作成して全EC2に付与する設計が基本です。Auto Scalingグループを使う場合は、起動テンプレート(Launch Template)のIAMインスタンスプロファイルに設定しておくと、新規起動されるEC2にも自動的に適用されます。Systems Manager → フリートマネージャーに「マネージドインスタンス」として表示されるかどうかで、全AZのEC2が正しくSSM管理下に入っているかを確認できます。
2. 接続元IAMユーザー・ロールに必要な権限
接続元のIAMユーザーまたはロールには以下の権限が必要です。最小権限の原則に従い、接続先EC2のARNをリソースで絞るのが望ましいです。{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:StartSession", "ssm:TerminateSession", "ssm:DescribeSessions", "ssm:GetConnectionStatus" ], "Resource": [ "arn:aws:ec2:ap-northeast-1:111122223333:instance/*", "arn:aws:ssm:ap-northeast-1:111122223333:session/${aws:username}-*" ] }, { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ssm:DescribeInstanceInformation" ], "Resource": "*" } ] }
${aws:username} を使って自分のセッションにしかアクセスできないよう制限することで、他のユーザーのアクティブセッションへの誤介入を防げます。3. aws ssm start-sessionの実行例
# インスタンスIDを指定してセッションを開始(ap-northeast-1・AZ-aのインスタンス) $ aws ssm start-session --target i-0a1b2c3d4e5f67890 --region ap-northeast-1 Starting session with SessionId: operator01-0123456789abcdef0 $ whoami ssm-user $ hostname ip-10-0-1-101.ap-northeast-1.compute.internal $ exit Exiting session with sessionId: operator01-0123456789abcdef0.
# AZ-cのインスタンスにも同じコマンドで接続可能(踏み台経由不要) $ aws ssm start-session --target i-0f9e8d7c6b5a43210 --region ap-northeast-1 Starting session with SessionId: operator01-abcdef0123456789 $ hostname ip-10-0-3-202.ap-northeast-1.compute.internal
ssm-user です。sudo -i でrootに切り替えられます。AZ-aが障害を起こしていても、AZ-cのインスタンスIDを指定すればそのまま接続できます。これがSSMをマルチAZ設計に組み込む最大のメリットです。クロスアカウント権限設計の実装
本番環境(アカウントB)と管理・監視環境(アカウントA)を分けたマルチアカウント構成では、アカウントAのオペレーターがアカウントBのEC2にSSMでアクセスするケースがあります。STSのロール引き受け(AssumeRole)を経由することで、クロスアカウントのSSM接続を実現します。1. アカウントB側のIAMロールに信頼ポリシーを設定する
アカウントBに「アカウントAからの引き受けを許可するロール」を作成します。信頼ポリシーにアカウントAのARNを指定します。ExternalId(外部ID)を設定することで「混乱した代理人問題」を防ぎます。# アカウントBのIAMロール「SSMCrossAccountRole」の信頼ポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "ssm-crossaccount-prod-2026" } } } ] }
2. アカウントB側のロールにSSM接続権限を付与する
SSMCrossAccountRole に ssm:StartSession 等を含むアクセス許可ポリシーをアタッチします。{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:StartSession", "ssm:TerminateSession", "ssm:DescribeSessions", "ssm:GetConnectionStatus", "ssm:DescribeInstanceInformation", "ec2:DescribeInstances" ], "Resource": "*" } ] }
3. アカウントA側のIAMユーザー・ロールにsts:AssumeRole権限を付与する
# アカウントAのIAMポリシー(アカウントBのSSMCrossAccountRoleを引き受ける権限) { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::444455556666:role/SSMCrossAccountRole" } ] }
4. クロスアカウントSSM接続の実行
AWS CLIのプロファイル機能を使うと、STSのロール引き受けを自動化できます。# ~/.aws/config にクロスアカウントプロファイルを登録 [profile account-b-prod] role_arn = arn:aws:iam::444455556666:role/SSMCrossAccountRole source_profile = default external_id = ssm-crossaccount-prod-2026 region = ap-northeast-1 # プロファイルを指定してSSMセッションを開始 $ aws ssm start-session --target i-0a1b2c3d4e5f67890 --profile account-b-prod Starting session with SessionId: operator01-cafebabe12345678 $ hostname ip-10-1-2-150.ap-northeast-1.compute.internal $ exit Exiting session with sessionId: operator01-cafebabe12345678.
--profile account-b-prod を付けるだけで、STS AssumeRoleの一時クレデンシャル取得が自動的に行われます。AWSマルチアカウント構成全体の設計(Organizations・SCPの設計)については、AWSマスターセミナーでVPCからIAMまでの設計をハンズオンで学べます。「TargetNotConnected」「AccessDeniedException」が出た時の対処法
1. An error occurred (TargetNotConnected)
EC2インスタンスがSSMのマネージドインスタンスとして認識されていない状態です。以下を順に確認します。・SSM Agentが起動しているか:EC2にコンソール接続し
sudo systemctl status amazon-ssm-agent で確認・IAMインスタンスプロファイルが付いているか:EC2コンソール → セキュリティ → IAMロールに
AmazonSSMManagedInstanceCore が含まれているか確認・VPCエンドポイントまたはNATゲートウェイが存在するか:プライベートサブネットの場合、SSMの3エンドポイントが揃っていないと通信できない
・エンドポイントのSGがHTTPS 443を許可しているか:VPCエンドポイントのSGに、EC2のSGからのインバウンド443を許可する規則があるか確認
IAMロールを変更した後でも、Systems Manager → フリートマネージャーに表示されるまで数分かかる場合があります。
2. AccessDeniedException: User is not authorized to perform ssm:StartSession
接続元のIAMユーザー・ロールにssm:StartSession 権限が不足しています。以下で接続元のIAMポリシーをシミュレーションできます。# IAMポリシーシミュレーターで権限を確認 $ aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::111122223333:user/operator01 --action-names ssm:StartSession --resource-arns arn:aws:ec2:ap-northeast-1:111122223333:instance/i-0a1b2c3d4e5f67890 { "EvaluationResults": [ { "EvalActionName": "ssm:StartSession", "EvalDecision": "explicitDeny", ... } ] }
EvalDecision: "allowed" にならない場合は、IAMポリシーに ssm:StartSession と対象EC2インスタンスのARNを追加してください。3. Session Manager Pluginが見つからない
SessionManagerPlugin is not found. Please refer to SessionManager Documentation here: http://docs.aws.amazon.com/console/systems-manager/session-manager-plugin-not-found
本記事のまとめ
| やりたいこと | コマンド・設定 |
|---|---|
| EC2にSSMで接続する | aws ssm start-session --target i-xxxxxxxx --region ap-northeast-1 |
| クロスアカウント接続(プロファイル指定) | aws ssm start-session --target i-xxxxxxxx --profile account-b-prod |
| STSロール引き受け確認 | aws sts assume-role --role-arn arn:aws:iam::ACCT_B:role/SSMCrossAccountRole --role-session-name test --external-id EXTERNAL_ID |
| SSM Agentの状態確認 | sudo systemctl status amazon-ssm-agent |
| IAMポリシーのシミュレーション | aws iam simulate-principal-policy --policy-source-arn ... --action-names ssm:StartSession |
aws ssm start-session は、踏み台EC2に依存しないマルチAZ接続設計の中核となるコマンドです。IAMインスタンスプロファイルと3つのVPCエンドポイントを正しく設計することで、特定のAZが落ちても接続経路が残る構成を実現できます。クロスアカウント設計では ExternalId を必ず設定した信頼ポリシーがセキュリティ設計の鍵になります。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AWS FISで本番環境の耐障害性を検証する冗長設計テスト手順|マルチAZ構成への応用
- この記事の属するカテゴリ:AWS(Amazon Linux)へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます