EC2 に入るなら SSH か Session Manager か？運用と監査で整理する

EC2 を運用するとき、最初の接続手段として SSH を思い浮かべることは多いです。

ただし、AWS の設計として「安全に管理したい」「公開ポートを減らしたい」「鍵配布を避けたい」という要件があるなら、まず検討したいのは AWS Systems Manager Session Manager です。

この記事では、SSH と Session Manager を宗教論ではなく、運用・監査・障害対応の観点から整理します。

結論：安全性と運用性を両立したいなら Session Manager を優先したい

先に結論を書くと、次のような要件があるなら Session Manager がかなり有力です。

つまり、管理のために SSH を公開する前に、そもそも公開不要で入れないかを考えるべきです。

SSH 自体は一般的な手段ですが、運用の現場では次のような論点が増えがちです。

たとえば一時対応のつもりで 22 番を広く開け、そのまま残る事故は珍しくありません。接続のための仕組みが、そのままリスク要因になりやすいわけです。

Session Manager は、Systems Manager の機能の一つで、EC2 などへ安全にシェル接続するための仕組みです。

主な利点は次の通りです。

このため、運用の安全性と管理性を同時に上げやすいのが強みです。

特に Session Manager を選びやすいのは、次のような場面です。

この表で見ると、Session Manager が単なる代替手段ではなく、運用設計そのものを軽くする選択肢だと分かります。

実務で特に効くのは、この 2 つです。

踏み台サーバーを置くと、そのサーバー自体のパッチ、監視、アクセス管理が必要になります。つまり、管理用のサーバーをさらに管理する仕事が増えます。

SSH 鍵の配布は、人の増減がある組織ほど重くなります。

このあたりを曖昧にすると、後から非常に面倒です。

AWS 認定試験では、次のようなキーワードがあれば Session Manager を先に疑うべきです。

たとえば「管理アクセスを安全に提供しつつ、インターネット公開を避けたい」と書かれていれば、かなり本命です。

もちろん、Session Manager を使うには前提もあります。

ただし、これらを踏まえても、22 番を開けて鍵を回すより整理しやすいケースは多いです。

EC2 の管理手段として SSH は一般的ですが、AWS では常に最初の正解とは限りません。

こうした要件があるなら、Session Manager を先に考える方が自然です。

22 番を開ける前に、公開せずに安全に管理できる方法がないかを見る。この順番を持っておくと、設計判断がかなり安定します。