 本記事は 夏休みクラウド自由研究 8/16付の記事です。 |
どうも、相変わらずCloudShellの話題の寺内です。
時期を逸してしまいましたが、2024年6月26日に、AWS CloudShell が指定のVPC内で起動できるようになりました。
作成数の制約
ひとつのIAMユーザで作成できるVPC環境のCloudShell は2つまでです。
VPC環境のCloudShell を削除するには、削除したいCloudShellのコンソールを選択した後、アクションから「削除」を選択します。意外とわかりにくいですね。
作成
VPC環境のCloudShell を作成するには、CloudShell の「アクション」メニューから「Create a VPC environment (max 2)」 を選択します。
すると以下のようなVPCとサブネット、セキュリティグループを選択する画面がでますので、ここを指定するだけです。
ネットワークインターフェースの確認
このようにして作成したVPC環境のCloudShell のIPアドレスを確認してみましょう。
CloudShellを作成する以下の種類のVPCを指定します。
- VPC環境ではない標準のCloudShell
- インタネットゲートウェイを持つパブリックサブネットのCloudShell
- インターネットゲートウェイを持たず外部接続できないCloudShell
IPアドレスの値は、それぞれ指定したVPCとサブネットの設定に依存します。ここでは、その値そのものより、ネットワークインターフェースに注目します。
a. 標準のCloudShell
[cloudshell-user@ip-10-132-71-142 ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 0e:cb:3f:8e:55:d7 brd ff:ff:ff:ff:ff:ff
altname enp0s5
altname eni-079c3fba4bc3a932d
altname device-number-0
inet 10.132.71.142/19 metric 512 brd 10.132.95.255 scope global dynamic ens5
valid_lft 3445sec preferred_lft 3445sec
inet6 fe80::ccb:3fff:fe8e:55d7/64 scope link
valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:f8:e3:ca:72 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
b. インターネット接続可能なVPC
[cloudshell-user@ip-10-1-1-46 ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:4c:44:c6:9f brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
4: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 06:78:c6:7c:d0:c1 brd ff:ff:ff:ff:ff:ff
altname enp0s6
altname eni-03e1af8560b73e6fe
altname device-number-1
inet 10.1.1.46/24 scope global ens6
valid_lft forever preferred_lft forever
5: devfile-veth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether da:70:b4:10:58:d7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.0.2/32 scope global devfile-veth0
valid_lft forever preferred_lft forever
c. クローズドVPC
[cloudshell-user@ip-10-10-1-223 ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:b8:b6:77:c8 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
4: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 06:9e:3b:36:ff:bf brd ff:ff:ff:ff:ff:ff
altname enp0s6
altname eni-0a72fb1c1bcc4d6c6
altname device-number-1
inet 10.10.1.223/24 scope global ens6
valid_lft forever preferred_lft forever
5: devfile-veth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether e2:d3:11:74:63:1f brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.0.2/32 scope global devfile-veth0
valid_lft forever preferred_lft forever
いずれも以下の3つのネットワークインターフェースは持っていることがわかります。
- lo
- docker
- ens
ensのインターフェースを見ると、altname(別名)としてeni IDが記載されています。
CloudShell コンテナがAWSの基盤内で作られると、そのコンテナに対して利用者のAWSアカウント内の指定VPCにENIが作成され、そこと関連付けられる仕組みのようです。
確認のために、EC2のコンソールからネットワークインターフェース一覧を見てみてください。そこで、ManagedByCloudShell というタグキーを持つENIを検索すると、上記の altname に記載されたENIがリストアップされます。
またVPC環境の CloudShell には上記に加えて、 devfile-veth0 というものを持っています。devfile というのは、CodeCatalyst などで使われる構成情報自動化のファイルなので、内部の自動構築を行うための専用の制御ネットワークがあるのかもしれません。これは推測です。
使いどころ
このような仕組みで提供されるVPC環境のCloudShell ですので、使いどころを考えてみましょう。
いままで構築したEC2やRDSなどのVPC内リソースの動作確認に、テスト用EC2を立て、そこからping やtelnet、curl やmysql コマンドでテストをしていたのではないかと思います。
そうした一時的なテストでは、VPC環境のCloudShell が活用できます。
その他、ちょっとしたデータ加工の後のテストデータの作成とテストの実施などにも便利ですね。
注意すべきは、インターネット接続できないクローズドなVPCに作った場合です。インターネットのリポジトリへアクセスできませんので、追加のツールインストールができません。AWS APIへのアクセスもVPCエンドポイントがない限りはできません。
当然といえば当然ですが、VPC内のEC2やコンテナなどと同じネットワーク条件になるわけなので注意が必要です。
その他、従来のCloudShell の注意点である、以下も同じですのでお忘れなく。
- 1GBしか保存できない
- 120日間アクセスないとデータが消える
- 12時間でセッションが切れる
ますます便利になったAWS CloudShell。これからも愛用していきたいと思います。なんせ無料なのがいい。ですが、VPC環境の場合データ通信量はかかります。