マルチAZ冗長設計にAWS SSM Start Sessionを組み込むIAM設計|クロスアカウント権限設計

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > AWS(Amazon Linux) > マルチAZ冗長設計にAWS SSM Start Sessionを組み込むIAM設計|クロスアカウント権限設計
「本番EC2への接続経路を踏み台EC2に頼っていたら、その踏み台が置いてあるAZが落ちて、正常なAZのインスタンスにも入れなくなった」——マルチAZ冗長設計を組んでいる現場でも、こういった事故は起きます。

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エンドポイントが必要


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は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などの操作コマンドの転送
エンドポイントのセキュリティグループには、EC2のセキュリティグループからのHTTPS(443番ポート)インバウンドを許可します。マルチAZ構成では、各AZのサブネットを全てエンドポイントに関連付けておくと、どのAZのEC2からも通信できます。

マルチ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

接続元PCまたはサーバーにSession Manager Pluginがインストールされていません。AWS公式からOSに合ったパッケージをダウンロードしてインストールしてください。

本記事のまとめ

やりたいこと コマンド・設定
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 を必ず設定した信頼ポリシーがセキュリティ設計の鍵になります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AWSのVPC設計・IAM設計・EC2構築をハンズオン形式で体系的に習得できる「AWSマスターセミナー」を開催しています。AWS上でのマルチAZ冗長設計やSSM Session Managerの接続設計も実習で扱います。AWSマスターセミナーの詳細はこちら>>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。