1. はじめに
1. 踏み台EC2の課題
2. セッションマネージャーを使用した構成
3. セッションマネージャーの利点
4. まとめ

はじめに

アプリケーションEC2への接続手段として、従来は「踏み台EC2（Bastion Host）」を構築してSSH接続する方法が一般的でした。
しかし、現在はその手法は必ずしも効率的とは言えなくなっています。

現在はAWS Systems Manager Session Manager（SSM セッションマネージャー）を利用することで、踏み台EC2を置かずに、安全かつ低コストでアプリケーションEC2を操作できます。

本記事では、「コスト」「セキュリティ」「運用負荷」の3つの観点から、なぜ踏み台EC2からセッションマネージャーへ移行すべきなのか、その具体的な理由を解説します。

1. 踏み台EC2の課題

図1のように、踏み台EC2を経由して目的のアプリケーションEC2へアクセスする構成はよく見られます。しかし、この方式を維持し続けるには、「コスト」「セキュリティ」「運用負荷」の3つの観点でデメリットがあります。

図1

コスト面の課題

踏み台EC2を維持・管理するために、年間およそ$102（約16,000円）の固定費がかかります。

踏み台EC2の稼働コスト

• 常時稼働する必要があり、年間およそ$58.75（約9,000円）のコストがかかります。
• ※ 30日 × 24時間 × 1時間あたりの料金 0.0068 USD × 12ヶ月 = 58.75 USD（年間）1ドル154円で換算。参考：Amazon EC2 オンデマンド料金（東京リージョン）

• 固定IPを利用する場合、年間およそ$43.2（約6,600円）の追加コストがかかります。
• ※ 30日 x 24時間 x 1時間あたりの料金 0.005 USD x 12ヶ月 = 43.2 USD（年間）1ドル154円で換算。参考：Amazon VPC の料金

• OSの更新や、セキュリティパッチの適用などのサーバ保守に人件費が発生します。

セキュリティ面の課題

踏み台EC2自体が、攻撃対象となるリスクを抱えることになります。

ポートの常時開放

• 踏み台EC2のセキュリティグループでSSHポート（通常は22）を開放する必要があります。
• ブルートフォース攻撃やポートスキャンの標的になり得ます。

• SSH鍵の紛失や不適切な共有がセキュリティホールになる恐れがあります。
• SSH鍵のローテーションを設定・管理する必要があります。

• 踏み台EC2にログインした後のコマンド履歴は、OS側にしか残りません。
• 権限を持つ利用者であれば、ログの改ざんや消去が可能です。

運用面の課題

管理すべきリソースが増えることで、運用担当者の負担が増加します。

管理対象の増加

• 踏み台EC2のメンテナンス負荷がかかります。

• 操作ログをS3やCloudWatch Logsへ転送するためには、追加の設定や実装コストがかかります。

• プロジェクトメンバーの増減に伴い、「鍵の回収」やOS内にて「アクセス権の剥奪」を手動で行う必要があり、作業ミスのリスクが考えられます。

2. セッションマネージャーを使用した構成

図2は、踏み台EC2を使用せずに、セッションマネージャーを使用した構成例です。決済処理などの外部システム連携が必要な一般的なWebサービスを想定しています。

図2

セッションマネージャーは、AWS Systems Managerの機能の一つで、SSHを使わずにEC2やECSへ安全に接続できるマネージドサービスです。

最大の特徴は、アプリケーションEC2側のインバウンドポートを完全に閉じられる点にあります。
これは、EC2内のSSMエージェントがセッションマネージャー側へリクエストを取りに行く「プル型」の通信モデルであるためです。

エージェントはセッションマネージャーに接続要求が来ていないか、アウトバウンド通信で定期的にポーリングしています。一度セッションが確立されると、双方向の通信により、コマンドリクエストを処理します。

またアクセス権限はIAMで一元管理されるため、従来の踏み台EC2が抱えていた「鍵管理」の問題を解消します。

操作ログについても、図3のようにセッションマネージャーの設定画面からログ出力を有効にするチェックボックスにチェックを入れるだけで、簡単にCloudWatch LogsやS3へ統合できます。

図3

3. セッションマネージャーの利点

コスト面の利点

踏み台EC2のコスト面の課題で紹介した、年間およそ$102（約16,000円）の固定費を削減できます。

• EC2の常時稼働コストとElastic IPのコストが不要になります。
• メンテナンスにかかる人件費が削減されます。

セキュリティ面の利点

不要な攻撃対象が減り、監査対応もしやすくなります。

インバウンドポートの完全閉鎖

• ポートスキャン・ブルートフォース攻撃などのリスクを排除します。

信頼性を担保するAWSのログ管理

• IAMによるアクセス制御に加え、CloudTrailでユーザごとのアクセス履歴を記録できます。
• ログがOSから切り離されAWS側で保管されるため、アプリケーションEC2へのアクセス権を持つユーザであっても操作ログの改ざんが不可能になります。
• CloudWatch Logsとの連携も容易です。OS上の実行コマンドだけでなく、あらゆる操作ログを集約できるため、一元管理に非常に役立ちます。

鍵管理の撤廃

• 鍵の配布、紛失、ローテーション、プロジェクト離脱者の鍵回収といった「鍵のライフサイクル管理」に伴うセキュリティリスクが消失します。

運用面の利点

接続体験の向上

• マネジメントコンソール上でのクリック、あるいはAWS CLIによるワンコマンドで即座に接続が完了します。

アカウント管理の統合

まとめ

これまで一般的だった踏み台EC2による運用は、「コスト」「セキュリティ」「運用負荷」のすべてにおいて負担が大きいものでした。セッションマネージャーへ移行することで、これらの課題を解消し、より安全で効率的なインフラ運用が可能になります。

一方で、OSの制約でエージェントをインストールできない場合や、大容量のデータ転送で高いスループットが要求されるなど、特殊な要件がある場合には、踏み台構成を採用することもあります。

しかしその場合でも、踏み台EC2自体へのアクセスにはセッションマネージャーを利用したり、Fargateを踏み台として利用したりすることで、セキュアな構成を維持できます。
（Fargateを踏み台にした場合は、同様な仕組みであるECS Execを使用することで、安全な接続が可能です）

従来の「踏み台EC2＋SSH鍵管理」を利用している場合は、セッションマネージャーへの移行を検討してみてはいかがでしょうか。まずは開発環境などの、影響の少ない環境から試してみるのがおすすめです。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse