雑に疎通確認だけしたい…せや！CloudShell使ったろ！

今回はAWS CloudShellを使った小ネタを書きます。

# こんなとき、ありませんか？
- 対向システムがセキュリティグループ（ファイアウォール）やWAFなどで送信元IPアクセス制限している
![スクリーンショット 2025-04-22 22.16.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/5c30c4ce-3e8a-4dd2-ad44-f158781276f8.png)

こんな時は対向のシステム担当者に自システムで使うIPアドレスを許可してもらいます。
![スクリーンショット 2025-04-22 22.18.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/2d405a6e-bfef-4d53-846d-217def3f9296.png)


ここで許可してもらうIPアドレスは固定化する必要があるので、NAT GatewayとElastic IPを使って固定化をする方法があります。こんな感じの構成であれば、自システムはプライベートサブネットに置きつつ、固定IPアドレスで通信することができます。

![スクリーンショット 2025-04-22 22.21.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/768b8c6d-42d0-46f4-80ac-6196ebc4b2c7.png)

この時、自システムが常設のEC2上で構築されたものであれば[EC2 Instance Connect](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/connect-linux-inst-eic.html)や[Session Manager](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/connect-with-systems-manager-session-manager.html)を利用することでいつでも接続できる状態にすることもあると思います。

しかし、CodeBuildでビルド中だけEC2が立ち上がる環境やVPC Lambdaを使っているなど、常設ではないEC2やサービスを取り扱う際、対向システムとの疎通確認はどのようにするのが良いでしょうか。もちろん、実際に動かして確かめるのも手ですが、万が一うまくいかなかった際の切り分けの手間が出てしまいます。可能な限り対向システムで接続が許可された後に確認したいところです。

とはいえ、疎通確認のためだけにEC2やらVPCエンドポイントを作成するのは少々面倒です。
そこで登場するのが[AWS CloudShell](https://aws.amazon.com/jp/cloudshell/)です。

# CloudShellとは？
AWSマネジメントコンソールから起動できるブラウザベースのシェルです。コンソール上からは画面上部または左下のアイコンから起動できます。

![スクリーンショット 2025-04-23 22.51.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/864d7e53-5cd1-4b93-b460-ef7713bae3d2.png)

使ったことがなくてもデフォルトVPCがあればこのアイコンを押すだけで起動されます。
ちなみに現在（2025/4/25）はAmazon Linux 2023が入ってます。

```bash
~ $ cat /etc/system-release
Amazon Linux release 2023.6.20250218 (Amazon Linux)
```

# というわけでやってみる
こんな感じの構成です。（EC2は既に削除済み）
![スクリーンショット 2025-04-23 23.00.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/9bd6cb99-7dba-4456-bed3-d90e4a833579.png)

まずは右側のVPCを作成します。作成時にNAT Gatewayも同時に作っておきます。
![スクリーンショット 2025-04-15 17.23.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/823036c8-cb1a-48a0-940b-9a73b8d19ee9.png)

同じように対向システムを模擬したVPCとEC2を作成します。このEC2はパブリックサブネットに配置し、パブリックIPアドレスを付与しておきます。また、この時点ではEC2のセキュリティグループは何も設定していません。
![スクリーンショット 2025-04-23 23.04.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/3cbff48d-07ae-4c6b-a9e9-f6a93858f855.png)

## CloudShellを起動
マネジメントコンソールの検索窓から「Cloudshell」を検索して選択します。
![スクリーンショット 2025-04-23 23.07.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/102c7e75-b533-45df-bdcf-bf58fc96dd02.png)

画面上の「+」もしくは右上のアクションから「Create VPC environment」を選択します。
すると、CloudShellの作成画面が出ますので任意の名前、NATゲートウェイがあるVPC、**プライベートサブネット**、デフォルトセキュリティグループを選択します。
![スクリーンショット 2025-04-23 23.06.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/906a6a66-08bc-4457-a637-f3a9aa835424.png)

これでCloudShellの準備は完了です。

## 動作確認
まずは対向システムで何も許可していない状態でpingコマンドを実行してみます。何も許可していないので当然ながら疎通はできません。
![スクリーンショット 2025-04-15 17.44.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/f69ed5d3-ae1a-4831-a05e-145b94f84d53.png)

次に対向システムのセキュリティグループを変更し、NAT GatewayについているIPアドレスからのICMP通信を許可します。
![スクリーンショット 2025-04-15 17.47.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/46fd2990-6dcf-43bf-a3dd-d096c2a41eb6.png)

今度は疎通確認ができました！
![スクリーンショット 2025-04-15 17.49.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/202d71a8-ca6a-450c-88e8-fa7ecae98290.png)

# 対向システムがWebサーバであればcurlで確認可能
対向システム側がWebサーバで、80番もしくは443番ポートを開けていればcurlコマンドでも確認が可能です。
![スクリーンショット 2025-04-15 18.03.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2448259/bf7371be-581c-4876-998a-8cf27495dc00.png)

# まとめ
今回はCloudShellを使ったお手軽動作確認をやってみました。あまり注目されないCloudShellですが、[以前の記事](https://qiita.com/ry-harada/items/f0ff3f1b7d839929afb5)でも紹介したように地味に嬉しいアップデートもあります。疎通確認をするときはCloudShellのことを思い出して活用してみてください。