はじめに

Terraform学習でEC2を作成する際、以下のような構成をよく見かけます。

EC2を作成
Security GroupでSSH（22番）を許可
キーペアを作成してSSH接続

しかしこの構成には、学習段階でも無視できない課題があります。

SSHポートをインターネットに公開する必要がある
鍵ファイルは誰が・どこで・どう管理するのか
接続経路や操作履歴がAWS側に残らない
「踏み台サーバ」としてはセキュリティ的に不安が残る

そこで本記事では、SHを前提としない踏み台EC2をどう設計するかにフォーカスし、 AWS公式の仕組み（SSM Session Manager）を用いた構成をTerraformで表現します。

SSM Session Managerを採用する理由

AWS Systems Manager Session Manager は、EC2へのリモートアクセスを以下の特徴で提供します。

SSH・鍵ファイル不要
インバウンドポート不要
IAMによるアクセス制御
操作履歴をCloudTrailに記録可能

ここで重要なのは、「便利だから使う」のではなく「設計上の責務分離が明確になる」点です。

認証・認可：IAM
通信制御：Security Group
操作記録：CloudTrail

Session Managerは、これらをAWS側に寄せる設計を可能にします。

設計方針（なぜこの構成にしたか）

今回の踏み台EC2は、以下3つの設計方針を軸に構成しています。

① SSHを「使わない」のではなく「設計に含めない」

SSHは便利ですが、

ポート開放が必要
鍵管理が必要
認可・監査がOSレイヤに閉じる

という特徴があります。

本構成では、「EC2に接続する責務はAWSが提供するマネージド機能に委ねる」という設計判断を取りました。

その結果、

接続経路はAWS内部
認可はIAM
ログはCloudTrail

という一貫した責務分離が成立します。

② ネットワークと認可を意図的に分離する

本構成のSecurity Groupには、インバウンドルールを一切定義していません。
これは「より厳しくするため」ではなく、

ネットワーク制御はSecurity Groupの責務
接続可否はIAMの責務

という分離を明確に体験するためです。

重要なのは、EC2内部でsshdが起動しているかどうかは本質ではないという点です。

プロセスが起動していても
ネットワーク的に到達できなければ

それは「接続不可なサーバ」です。
この考え方は、実務でのゼロトラスト設計にも直結します。

③ Terraformは「作成ツール」ではなく「状態管理ツール」として使う

Terraform学習では、

applyできた
EC2が立ち上がった

で満足してしまいがちです。
しかし設計の観点では、

何を作ったのか
何が管理対象なのか
どう消えるのか

が説明できて初めて意味を持ちます。
そのため本記事では、 terraform destroyで完全に消えることを構成のゴールとして明示的に設定しています。

構成概要（設計比較）

観点	SSH前提構成	本構成(SSM)
接続経路	インターネット	AWS内部
認可	鍵ファイル	IAM
ネットワーク	22番解放必須	インバウンド不要
操作監査	困難	CloudTrail
設計責務	EC2寄り	AWSサービス寄り

本記事では右側の設計をTerraformでコード化します。

Terraform構成（ファイル分割の意図）

provider.tf：実行環境の前提定義
main.tf：リソースの関係性を表現
variables.tf：変更可能な設計パラメータ
outputs.tf：外部操作に必要な最小限情報

動作確認から読み取れる設計の妥当性

SSM接続が成立する理由

IAM RoleにAmazonSSMManagedInstanceCoreを付与
Instance ProfileとしてEC2に関連付け
SSM Agentが入ったAMIを使用

ここで重要なのは、Security Groupの設定は一切関与していない点です。

SSHが「使えない」のではなく「設計上不要」な状態

EC2内部ではsshdが起動していますが、

インバウンド通信は全遮断
到達経路が存在しない

ため、SSHは設計上意味を持ちません。
これは「SSHを止めた」のではなく、設計のレイヤで無効化している状態です。

Terraform stateから見る設計の完結性

stateに存在するリソースは、

EC2
IAM Role / Instance Profile
Security Group

のみです。

暗黙的に作られらリソースがない
destroyで完全に消える

この状態を作れていること自体が、設計としての完成度を示しています。

まとめ

本記事の構成を通して、以下を実体験できます。

「EC2に入る＝SSH」という思い込みからの脱却
IAM・Security Group・SSMの責務分離
Terraformを状態管理ツールとして使う感覚

次のステップとしては、

踏み台＋RDS接続設計
Session Managerのログ永続化
環境分離（dev / prod）設計

などに進むことで、より実務に近い設計力を鍛えられると考えています。