手法

いくつかあると思うが、今回の選択肢としては次が挙がった

1. Public SubnetにEC2を構築し、そのEC2を経由してPrivate RDS（など）にアクセスする手法と、
2. ECS Fargate × SSMで構築し、ECSに対してSSM接続することでProxyとする手法。

Pros and Cons

1. EC2
   • Pros（長所）
     • 馴染みのEC2なので何かと情報が出回っており、直感で操作できる
     • 構築難易度がECSに比べ低い。
   • Cons（短所）
     • EC2 Fargateパターンに比べ、イケイケ感の低さや運用コスト（後述）の違いがある
     • 運用担当者がEC2内にSSHユーザーの設定をユーザー毎に行わなくてはいけない
     • sshのkey pairをどう管理するのか問題が控えている
2. ECS(Fargate)
   • Pros（長所）
     • まず、イケている。
     • 運用担当者はSSHユーザーの作成不要で、IAMユーザーさえ作成すればよい
       • SSMはIAMユーザーがあれば（credencials設定さえできれば）接続できるため
     • sshのkey pair問題がなくなる
   • Cons
     • SSMの接続制限として接続時間20分の上限があるため、RDSへの接続上限も20分となる
       • ユースケースとして耐えられなければ採用が厳しい。
     • SSMの接続情報となるActivationCode/ActivationIDの有効期限が30日（MAX）なため、洗い替えが必要になる。
     • Activationの生成とパラメータストア更新を自動化できれば解消できるが、その実装コストが発生する^[1][2]
     • 単純なSSMのみではRDSのProxyとして機能せず、ひと手間必要な可能性がある（※調査不足）^[3]
     • 情報が少ない。
       • コピペすればOK！のように丁寧に解説されている記事がなく、ある程度具体的な方法論を取り込んで実装に落とし込む必要がある

EC2 Proxyを実装するときのPOINT

1. EC2インスタンスにセキュリティグループを作らない（デフォルトのまま）
   • SSHできない。セキュリティグループはちゃんと作って付与しましょう。
2. Elastic IPを作りましょう（VPNを構築しない場合）

EC2 Proxyを構築する方法

1. キーペアを作成する

2. セキュリティグループAを作成する

   • インバウンド：SSHポートを開放する

3. EC2 Instanceを作成する

   • セキュリティグループAを付与する
   • 1のキーペアを付与する
     • ※GUIだとキーペアが必須だが、Terraformだとキーペアなしで作れちゃうので注意

4. この状態でGUIの「接続」からssh情報を参照し、SSH接続できることを確認する

5. 作成したEC2 Instanceに接続する

   • SSMで接続したいなら 3. でSSM Roleを付与して作成する

6. ユーザーHを作成し、ユーザーHのpub.pemを配置する

7. ユーザーHでSSHログインできることを確認する

8. ここまで揃ったら、RDSに対してSSHを設定し、ログインできることを確認。