今回はAWS CloudShellを使った小ネタを書きます。
こんなとき、ありませんか？
- 対向システムがセキュリティグループ（ファイアウォール）やWAFなどで送信元IPアクセス制限している
こんな時は対向のシステム担当者に自システムで使うIPアドレスを許可してもらいます。
ここで許可してもらうIPアドレスは固定化する必要があるので、NAT GatewayとElastic IPを使って固定化をする方法があります。こんな感じの構成であれば、自システムはプライベートサブネットに置きつつ、固定IPアドレスで通信することができます。
この時、自システムが常設のEC2上で構築されたものであればEC2 Instance ConnectやSession Managerを利用することでいつでも接続できる状態にすることもあると思います。
しかし、CodeBuildでビルド中だけEC2が立ち上がる環境やVPC Lambdaを使っているなど、常設ではないEC2やサービスを取り扱う際、対向システムとの疎通確認はどのようにするのが良いでしょうか。もちろん、実際に動かして確かめるのも手ですが、万が一うまくいかなかった際の切り分けの手間が出てしまいます。可能な限り対向システムで接続が許可された後に確認したいところです。
とはいえ、疎通確認のためだけにEC2やらVPCエンドポイントを作成するのは少々面倒です。
そこで登場するのがAWS CloudShellです。
CloudShellとは？
AWSマネジメントコンソールから起動できるブラウザベースのシェルです。コンソール上からは画面上部または左下のアイコンから起動できます。
使ったことがなくてもデフォルトVPCがあればこのアイコンを押すだけで起動されます。
ちなみに現在（2025/4/25）はAmazon Linux 2023が入ってます。
~ $ cat /etc/system-release
Amazon Linux release 2023.6.20250218 (Amazon Linux)
というわけでやってみる
こんな感じの構成です。（EC2は既に削除済み）
まずは右側のVPCを作成します。作成時にNAT Gatewayも同時に作っておきます。
同じように対向システムを模擬したVPCとEC2を作成します。このEC2はパブリックサブネットに配置し、パブリックIPアドレスを付与しておきます。また、この時点ではEC2のセキュリティグループは何も設定していません。
CloudShellを起動
マネジメントコンソールの検索窓から「Cloudshell」を検索して選択します。
画面上の「+」もしくは右上のアクションから「Create VPC environment」を選択します。
すると、CloudShellの作成画面が出ますので任意の名前、NATゲートウェイがあるVPC、プライベートサブネット、デフォルトセキュリティグループを選択します。
これでCloudShellの準備は完了です。
動作確認
まずは対向システムで何も許可していない状態でpingコマンドを実行してみます。何も許可していないので当然ながら疎通はできません。
次に対向システムのセキュリティグループを変更し、NAT GatewayについているIPアドレスからのICMP通信を許可します。
今度は疎通確認ができました！
対向システムがWebサーバであればcurlで確認可能
対向システム側がWebサーバで、80番もしくは443番ポートを開けていればcurlコマンドでも確認が可能です。
まとめ
今回はCloudShellを使ったお手軽動作確認をやってみました。あまり注目されないCloudShellですが、以前の記事でも紹介したように地味に嬉しいアップデートもあります。疎通確認をするときはCloudShellのことを思い出して活用してみてください。