EC2への接続方法の整理と比較（「EC2 Instance Connect」or「Session Manager」

従来のSSH接続（ローカル端末からEC2インスタンスにキーペアを使ってSSH接続）はあまり推奨されてなさそうなので、AWSが推奨している接続方法でEC2に接続してみました。

AWSは「EC2 Instance Connect」や「Session Manager」での接続を推奨しているようですが、どちらも、一筋縄にはいかなかったので、次からはスムーズに設定するために必要な手順をメモしておきたいと思います。

## 「EC2 Instance Connect」で接続する場合

###  「EC2 Instance Connect」の画面イメージ
![スクリーンショット 2024-03-23 13.51.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/0873414f-44bc-b5f3-2824-563a3f75b8ac.png)
![スクリーンショット 2024-03-23 14.31.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/1f99191f-8456-26bd-7ae8-29e5b423f48e.png)

### 必要な設定

* EC2にパブリックIPが振られている必要がある（EC2 Instance Connectはパブリック通信を用いる模様）

* EC2にアタッチするセキュリティグループにて、以下の設定を行う必要がある
　タイプ：SSH
　ソース：3.112.23.0/29（※1）
 ![スクリーンショット 2024-03-23 14.11.27のコピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/da0fc066-342d-309a-d608-3211e54f51d9.png)


※1 [AWSの サービスに発行された推奨される IP ブロック](https://ip-ranges.amazonaws.com/ip-ranges.json)
2024/3/22時点では、EC2を東京リージョンに設置している場合、以下の情報が「EC2 Instance Connect」の接続元として可能性があるとのことだった。（時期によって変わる可能性があるので、その度に要チェック）
```
    {
      "ip_prefix": "3.112.23.0/29",
      "region": "ap-northeast-1",
      "service": "EC2_INSTANCE_CONNECT",
      "network_border_group": "ap-northeast-1"
    },
```


必要な設定はこれだけだったと思います。特に追加費用等も不要ですね。（パブリックIP代くらいでしょうか）


### 参考にさせてもらった記事
https://dev.classmethod.jp/articles/tsnote-ec2connect-connecterror/


## 「Session Manager」で接続する場合
###  「EC2 Instance Connect」の画面イメージ
![スクリーンショット 2024-03-23 13.54.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/225e6069-6ad1-4e28-8907-10e8291b3741.png)
![スクリーンショット 2024-03-23 14.30.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/a26d9b84-7d25-6d1d-0319-3019747b7bc7.png)

### 必要な設定

* 以下のVPCエンドポイントを作成する必要がある
```
com.amazonaws.region.ssm
com.amazonaws.region.ec2messages
com.amazonaws.region.ssmmessages
```
![スクリーンショット 2024-03-23 14.18.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/6929506e-3074-c237-542d-b680de2ed986.png)



* 上記のVPCエンドポイントそれぞれにアタッチされたセキュリティグループにて、以下の設定を行う必要がある
　タイプ：HTTPS
　ソース：VPC IP（※2）
![スクリーンショット 2024-03-23 14.11.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/4afbd3d9-a09d-4bed-7b82-dcdf9dbcc2e9.png)


※2 デフォルト設定の場合、172.31.0.0/16になると思われる。
![スクリーンショット 2024-03-23 14.05.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/33b6bda6-19c0-5f70-b48f-03e89718a05b.png)

ちなみに、上記のいずれかの設定ができていない状態で、Session Managerでの接続画面を開くと、以下のようなエラーが出るようです。
![スクリーンショット 2024-03-23 13.17.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/8300687e-3798-e3b3-14fc-af7696a6c05c.png)



* マネージドポリシー「AmazonSSMManagedInstanceCore」をアタッチしたIAMロールをEC2インスタンスにアタッチする必要がある
![スクリーンショット 2024-03-23 14.08.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/b130b22f-3ff4-32cf-f6e5-61bb1aed874e.png)



3つのVPCエンドポイントを作成すると1日あたり2$くらい費用がかかるようです。Session Managerで接続したいEC2が1台であろうが、100台であろうが同じVPCエンドポイントの費用がかかるので、小規模の環境の場合は割高になりますね。

![スクリーンショット 2024-03-23 14.02.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/65ce4db0-8422-6318-70b8-b7885e5f8c99.png)

### 参考にさせてもらった記事
https://dev.classmethod.jp/articles/tsnote-private-ec2-ssm-vpc-endpoint/

## まとめ

小規模な環境では、「EC2 Instance Connect」を使用するのが良いと思いました。（VPCエンドポイントの設定やVPCエンドポイントの費用を支払う必要がないという理由で）

中規模以上の場合は、「Session Manager」を使用するのが良いと思いました。（Systems Managerのフリートマネージャーで管理する等、管理面が強そう、「EC2 Instance Connect」での接続のために3.112.23.0/29などからのSSH接続を許可するのがスマートではなさそうという理由で）


## 追記

Session Managerを使用するための「VPCエンドポイント」を削除した後も、Session Managerを用いてEC2インスタンスに接続できてしまいました。EC2インスタンスを再起動すると、接続できなくなりましたが、Systems Managerのフリートマネージャーからは依然として接続できてしまいました。

その後、フリートマネージャーから接続できていたEC2インスタンスを終了させ（※3）、新しくEC2インスタンスを起動する（※4）と、フリートマネージャーに※3のインスタンスが表示されなくなり、※4のインスタンスも表示されなくなりました。
![スクリーンショット 2024-03-23 15.23.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/2653d632-45c8-56bf-d23f-06ba8dd93ab7.png)
![スクリーンショット 2024-03-23 15.21.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/a63111e7-16dc-9c9d-d37a-f0b4b52463ef.png)







この動きから、一度フリートマネージャーに登録されたEC2インスタンスは、Session Managerの接続条件が揃っていなくても、該当のEC2インスタンスを終了するまでの間は、フリートマネージャー経由で接続が可能となってしまうと理解しました。

特に問題は発生しなさそうですが、AWS側の仕組みがどうなっているか気になります。

と、思いきやしばらくすると（5分ほど？）、フリートマネージャーに新しいインスタンスが表示されており、接続もできてしまいました。
![スクリーンショット 2024-03-23 15.37.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/7aab80e7-dbb2-79f2-ec9c-be397ebb37e3.png)
![スクリーンショット 2024-03-23 15.37.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/7b6c843c-abc4-ae9d-c8df-3893c22883d8.png)



VPCエンドポイントは削除しているのに、接続できる理由が謎です。EC2インスタンスの「接続」画面のセッションマネージャー画面からも接続できるようになっていました。
![スクリーンショット 2024-03-23 15.45.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/438423/3c00c92e-ae20-9240-69e6-12780efeabaa.png)


ということは、VPCエンドポイントの設定は不要と理解できます。（VPCエンドポイントを設定していない時は、フリートマネージャー経由でもEC2インスタンスの「接続」画面のセッションマネージャー画面からも接続できなかったのですが）

VPCエンドポイントの必要性が不明確になってしまいました。

歯切れの悪い結果となっていますが、VPCエンドポイントなしでSession Mangerが使用できるのは嬉しいので、様子を見ながら使用して、何か分かったら記事に残そうと思います。