会社経営で理解する一斉指示システム
AWS Run Commandを、身近な会社の支店管理システムで例えて分かりやすく説明します！
会社の本社 から 複数の支店 に、 同じ作業指示 を一斉に送って実行させる仕組みです
本社の社長
が
全支店
に
「新しいセキュリティソフトを
全PCにインストールして」
📞 電話で一つずつ連絡は大変...
📧
一斉メール
で指示を送ろう！
管理者
が
複数のEC2
に
「新しいソフトウェアを
全サーバーにインストールして」
💻 一台ずつSSH接続は大変...
🚀
Run Command
で一斉実行！
指示を出す人
です。
会社の社長や管理者のように、
複数の支店に
同じ作業指示
を一斉に送ります。
指示を受ける側
です。
東京支店、大阪支店、名古屋支店のように、
それぞれが
独立した作業場所
を持っています。
連絡を受ける専門スタッフ
です。
本社からの指示を受け取って、
支店内で
実際の作業を実行
します。
具体的な作業手順書
です。
「ソフトウェアインストール手順」や
「システム再起動手順」など、
標準化された作業内容
が記載されています。
Run Command実行
「全支店で同じ作業をして！」EC2-Tokyo
📱 SSMエージェント待機中EC2-Osaka
📱 SSMエージェント待機中EC2-Nagoya
📱 SSMエージェント待機中
✅ 東京支店: 作業完了 (成功)
✅ 大阪支店: 作業完了 (成功)
❌ 名古屋支店: エラー発生 (要確認)
会社の例: 「全支店のPCを明日朝に再起動して」
結果: 指定したサーバーが安全に再起動されます
会社の例: 「新しいセキュリティソフトを全支店に導入して」
結果: 全サーバーに同じソフトウェアがインストールされます
会社の例: 「各支店の業務状況を報告して」
結果: 各サーバーのディスク使用量、メモリ使用量、稼働プロセスが分かります
会社の例: 「新しい業務マニュアルを全支店に配布して」
結果: 統一された設定ファイルが全サーバーに適用されます
全支店ではなく、条件に合った特定の支店だけに指示を出すことも可能です
会社の例:
「営業部」タグが付いた支店のみ
「関東地方」タグが付いた支店のみ
会社の例:
東京支店（支店番号：001）
大阪支店（支店番号：002）
のみに指示
会社の例:
「新規開店した支店」グループ
「大型店舗」グループ
事前に分類したグループ単位で指示
SSMエージェントの確認
→ 各支店（EC2）に連絡担当者（SSMエージェント）が配置されているか確認
→ 最新のAmazon LinuxやWindows Serverには標準で含まれています
→ 古いOSの場合は手動インストールが必要
IAMロールの設定
→ EC2に「AmazonSSMManagedInstanceCore」ポリシーを付与
→ 各支店が本社からの指示を受け取れるように権限設定
→ これがないと支店は指示を受け取れません
管理画面へアクセス
→ AWSコンソールでSystems Managerを選択
→ 左メニューから「Run Command」をクリック
→ 本社の管理者用の操作画面です
Document（作業マニュアル）の選択
→ AWS-RunShellScript（Linux用の基本的な作業）
→ AWS-RunPowerShellScript（Windows用）
→ または自作のカスタムドキュメント
ターゲットの指定
→ すべての支店、または特定の支店を選択
→ タグやインスタンスIDで細かく指定可能
→ 「営業部の支店のみ」「関東地方のみ」など
コマンドの入力
→ 実行したいコマンドを入力欄に記載
→ 例：「sudo yum update -y」（システム更新）
→ 複数のコマンドを順番に実行することも可能
一斉指示の送信
→ 「Run」ボタンをクリックで指示を一斉送信
→ 各支店で同時に作業が開始されます
→ 実行状況はリアルタイムで確認可能
各支店からの作業報告を確認
→ 成功・失敗の状況を一覧で確認
→ 失敗した支店は詳細なエラーログも確認可能
→ 必要に応じて個別対応を実施
効率性とスケーラビリティ のためです！
従来の方法（SSH）:
Run Command:
基本的には無料 です！
無料枠:
有料になる場合:
一般的な企業なら、ほぼ無料で使えます！
非常に安全 です！
セキュリティ機能:
ベストプラクティス:
詳細な診断情報 が提供されます！
失敗の確認方法:
よくある失敗原因:
対処法: 失敗したインスタンスのみを対象に再実行可能
はい！ 時間指定実行も可能です。
方法1: EventBridge（CloudWatch Events）連携
方法2: Maintenance Windows
例: 「毎月第2土曜日の午前2時に全サーバーでパッチ適用」
100台のサーバーでも1回の操作で一斉実行。SSH接続の手間が不要
手動作業のミスを防止。全サーバーで同じ作業が確実に実行される
作業の実行状況と結果をリアルタイムで確認。履歴も残る
SSHキーの管理不要。IAM権限で安全にアクセス制御
タグやグループで細かく対象を指定。必要な支店のみに実行
月10万リクエストまで無料。専用ツール導入より圧倒的に安い
企業が新しいウェブサービスを立ち上げる際の、セキュリティを重視したサーバー管理の実例です
Amazon ECS クラスター
100台のEC2インスタンス = 100階のオフィス
100階建てオフィスビルの建設
→ 100台のEC2インスタンスでECSクラスターを構築
→ 各インスタンスに「SSMエージェント」を配置（連絡担当者）
→ 新しいウェブサービス専用の環境を準備
ビルの入口を最小限に制限
→
インバウンド：
HTTPS（443）のみ許可
→
ブロック：
SSH（22）、HTTP（80）、その他全て
→ 会社のセキュリティポリシーに完全準拠
物理的な鍵を一切使わない方針
→ EC2起動時にSSHキーペアを指定しない
→ 従来の「鍵管理」リスクを完全排除
→ 紛失・悪用・不正アクセスの心配なし
統合管理システムの稼働開始
→ 管理者は中央制御室（AWSコンソール）から操作
→ 100台すべてに同時指示が可能
→ セキュアで効率的なリモート管理を実現
ビル全体でのシステム更新作業
効果: 100台のサーバーで同時にコンテナ環境を更新
全階の業務状況を一斉チェック
効果: 全サーバーの稼働状況を瞬時に把握
ビル全体のセキュリティ強化作業
効果: 全サーバーを同じセキュリティレベルに統一
攻撃経路を最小限に制限。SSH鍵管理リスクを完全排除
100台のサーバーを1回の操作で管理。作業時間99%削減
全サーバーで同一の設定・操作。環境差異によるトラブル防止
管理工数大幅削減。障害対応時間短縮。予防保守効率化
✅ セキュリティ面:
⚡ 運用面:
🔄 継続改善:
Run Commandは「外から中」ではなく、「中から外」への通信だけで完璧に動作します
固定電話への着信
🏢 ← 👨💼
サーバーが「電話を受ける」
携帯電話からの発信
🏢 → ☁️
サーバーが「電話をかける」
連絡担当者が待機開始
→ EC2起動時にSSMエージェントが自動起動
→ 「仕事がないか」定期的にAWSに確認する準備完了
→
インバウンドポートは一切不要
「何かお仕事ありますか？」の定期確認
→ アウトバウンドHTTPS(443)でAWS Systems Managerに問い合わせ
→ 通常は「特に仕事なし」の応答
→
デフォルトのセキュリティグループ設定で動作
本社からの作業指示
→ 管理者がAWSコンソールでRun Command実行
→ AWS Systems Managerが指示を保管
→
管理者とEC2は直接通信しない
次回のポーリングで指示を発見
→ SSMエージェントが「今度は仕事がある！」を確認
→ 指示内容をダウンロードして実行開始
→
全てアウトバウンド通信で完結
作業完了報告
→ 実行結果をアウトバウンドHTTPS(443)でAWSに送信
→ AWS Systems Managerが結果を保存
→ 管理者はコンソールで結果確認可能
最小権限の原則を適用
Run Command が動作するための最小要件
どの構成でもインバウンドポート開放は不要！
外部からアクセス可能なポートを開く必要なし。攻撃面を最小化
複雑なファイアウォール設定不要。標準設定で即座に利用開始
サーバー側から定期確認。リアルタイム性と安全性を両立
インターネット、NAT、VPCエンドポイント。どの構成でも対応
🔑 セキュリティ革命:
⚡ 運用効率:
🎛️ 技術的優位性:
👨💼 Run Command = 本社の管理者（一斉指示を出す人）
🏢 EC2インスタンス = 各支店（指示を受けて作業する場所）
📱 SSMエージェント = 連絡担当者（指示を受け取って実行する人）
📋 Document = 作業マニュアル（具体的な手順書）
この仕組みを使うことで、 複数のサーバーを効率的に一元管理 できます！
🎯 初心者へのアドバイス：
💡 実際の活用例：
Created by SSuzuki1063
AWS SAP Learning Resources