はじめに
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）設計
などに進むことで、 より実務に近い設計力を鍛えられると考えています。