踏み台サーバーは「負債」である。Ansible × SSM Session Manager で構築する境界防御ゼロの自動化環境
インフラエンジニア諸君。まだ「踏み台サーバー（Bastion Host）」を維持管理しているのか？
SSH鍵のローテーション、パッチ当て、そして何より「踏み台経由のAnsible実行」という、遅延と不安定さを招くアーキテクチャに甘んじているなら、今すぐそのレガシーを捨てろ。
AWS環境において、SSM Session Manager（以下SSM）を介してAnsibleを実行することは、単なる「セキュリティ強化」ではない。「SSHのポート開放という地雷を埋めずに、プライベートな世界へ直接リーチする」という、運用のパラダイムシフトだ。
本稿では、プロの現場で即座に採用すべき、SSM経由の疎通設計と、Ansible運用を劇的に加速させる極意を伝授する。
—
1. 接続の深淵：SSH over SSM の仕組みを理解する
SSHポート（22）をSecurity Groupで全閉鎖したままAnsibleを動かす。その正体は、`ProxyCommand`を利用したトンネル構築だ。
設定すべき `~/.ssh/config` のベストプラクティス
SSHの設定ファイルに以下の設定を書き込むことで、AWS CLIがSSMを通じて通信をラップしてくれる。
AWS SSM経由の接続設定
host i- mi-
ProxyCommand sh -c “aws ssm start-session –target %h –document-name AWS-StartSSHSession –parameters ‘portNumber=%p'”
IdentityFile ~/.ssh/your-key.pem # 必要に応じて。SSM使用時は公開鍵認証不要な場合も多い
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
この設定により、`ansible-playbook` は「普通のSSH」として通信を行い、バックグラウンドではSSMの暗号化されたトンネルを流れる。踏み台サーバーの管理コストはこれでゼロになる。
—
2. チーム開発の生産性を底上げする「神」構成
Ansibleのディレクトリ構造が汚いチームは、例外なく崩壊する。IaCのコードは「誰が読んでも即座に意図が伝わる」ドキュメントでなければならない。
推奨ディレクトリ構造
.
├── ansible.cfg # プロジェクト単位の最適化
├── inventory/
│ ├── aws_ec2.yml # AWS Dynamic Inventory（必須）
│ └── group_vars/
├── roles/ # 再利用可能なモジュール群
└── site.yml # エントリーポイント
チーム開発のための `ansible.cfg` 設定
[defaults]
実行速度を極限まで引き上げる
pipelining = True
forks = 20
冪等性を担保するために、無駄なログを抑止
stdout_callback = yaml
[ssh_connection]
SSM経由の接続を最適化
ssh_args = -o ControlMaster=auto -o ControlPersist=60s
- `pipelining = True`: SSHの回数を減らし、モジュール実行速度を劇的に向上させる。これだけで実行時間が半分になることも珍しくない。
—
3. 実践：AWS Dynamic Inventory の完全自動化
IPアドレスをハードコードするような前時代的な運用は今すぐ廃止せよ。AWSのタグで動的に管理するのだ。
`inventory/aws_ec2.yml`
plugin: aws_ec2
regions:
- ap-northeast-1
filters:
tag:Environment: production
SSMを使うための重要な設定
compose:
ansible_host: instance_id
この設定により、`ansible-playbook -i inventory/aws_ec2.yml` を叩くだけで、タグ付けされた全てのインスタンスが自動的にターゲットとなる。EC2が増減しても、 inventory を書き換える必要は一切ない。
—
4. 現場で震えるほど役立つ「小技」と「プラグイン」
1. ターミナル操作の劇的短縮：`fzf` + `ansible-inventory`
対象ホストを選択する際、毎回リストを眺めるのは非効率だ。以下のコマンドをエイリアスにしておけ。
fzfで動的にホストを選択して実行
ansible-playbook site.yml -l $(ansible all –list-hosts | fzf)
これだけで、目的のノードまで0.5秒で到達できる。
2. 必須プラグイン：`ansible-lint`
CI/CDパイプラインに必ず組み込め。YAMLの構文ミスだけでなく、「非効率なループの使用」や「セキュリティリスクのある書き方」を自動で指摘してくれる。 チームメンバーのコード品質を一定に保つための最強の門番だ。
3. デバッグの救世主：`mitogen`
Ansibleの実行速度に限界を感じたら、迷わず `mitogen for Ansible` を導入せよ。SSHのオーバーヘッドを極限まで排除し、Pythonの実行を最適化する。大規模環境でのプロビジョニング時間が劇的に短縮される。
—
結論：IaCは「美学」である
踏み台サーバーを排除し、SSMで閉域網をコントロールする。これは単なる技術選択ではなく、「インフラをコードという純粋な論理体系に落とし込む」というエンジニアリングの美学だ。
自動化の先には、常に「次なる課題」がある。しかし、まずはここから始めよう。無駄なコネクションを排除し、冪等性の高いコードを書き、チーム全体の生産性を最大化する。それが、我々SREに課せられた責務だ。
さあ、今すぐ `ansible.cfg` を開き、あなたのインフラを「真のコード」へ進化させろ。