[アップデート] CloudShell を任意の VPC 上で起動できる CloudShell VPC environment が提供されました！

こんにちは、AWS 事業本部の平木です！

皆さんは CloudShell を活用していますか？

普段使用したことがある方ならご存じかと思いますが、今まで CloudShell はパブリックな環境のためインターネット経由で様々な通信を行っていました。

今回のアップデートで、ユーザーが作成した VPC 上に CloudShell を起動できる CloudShell VPC environment が提供されたため仕様を確認してみます。

何ができるようになったか

何ができるようになって、何ができないようになったのかを確認してみます。

任意の VPC 上に CloudShell を起動

まずメインの部分はこちらです。

今までは CloudShell ではインターネットに自由に出ることができましたが、今回のアップデートによりユーザーが作成した VPC 上に CloudShell を起動することでプライベートに CloudShell を活用できるようになりました。

VPC 上（厳密には指定したサブネット上）で起動するため、通信の制御はルートテーブルにて行われます。

そのため NAT Gateway へのルートの無いルートテーブルが紐づくサブネットで CloudShell を起動した場合は、インターネットへ出ることができません。

また、仕様上パブリックサブネットで起動した場合は、CloudShell にパブリック IP アドレスが割り当てられないためこの場合もインターネットへ出ることは出来ません。

インターネットへ出れるようにするためには、NAT Gateway へのルートのあるプライベートサブネット上で起動する必要があります。

イメージ的には、通常の EC2 などのコンピューティングサービスを想像すると理解しやすいかと思います。

セキュリティグループによるアクセス制限

CloudShell VPC environment では構築した段階で起動した VPC 内にマネージドな ENI が払い出されます。

ENI ではセキュリティグループをアタッチすることが可能なため CloudShell VPC environment でもセキュリティグループを関連付けできます。

そのため例えば同一 VPC 内リソースと通信したい場合に割り当てたセキュリティグループを活用してアクセス制御を行うことも可能です。

制約事項

CloudShell VPC environment ではいくつか制約事項もあるため見ていきます。

• IAM プリンシパル毎に最大 2 つの環境が作成可能
• 1 つの環境につき最大 5 つのセキュリティグループを割りあて可能
• 「アクション」メニューからのデータのアップロード・ダウンロードは不可
  • インターネットへ出れる環境であれば別のツールで実現可能
• 永続的なストレージは使用不可
  • セッション終了時にホームディレクトリが削除されるため S3 へ保存などの仕組みが必要

また、マネージド CloudShell 環境として利用するために下記 VPC エンドポイントが必要です。

• com.amazonaws.<リージョン>.ssmmessages
• com.amazonaws.<リージョン>.logs
• com.amazonaws.<リージョン>.kms
• com.amazonaws.<リージョン>.execute-api
• com.amazonaws.<リージョン>.ecs-telemetry
• com.amazonaws.<リージョン>.ecs-agent
• com.amazonaws.<リージョン>.ecs
• com.amazonaws.<リージョン>.ecr.dkr
• com.amazonaws.<リージョン>.ecr.api
• com.amazonaws.<リージョン>.codecatalyst.packages
• com.amazonaws.<リージョン>.codecatalyst.git
• aws.api.global.codecatalyst

VPC エンドポイントが無くても起動自体は可能ですが、メンテナンスなどが実施されないなどが懸念されるため対象リージョン毎に作成しておくほうが良いです。

また、インターネットへ出れない CloudShell VPC environment から AWS サービスへの API を使用する場合には、別途 VPC エンドポイントが対象サービス毎に対象リージョン毎に必要なためそちらもご注意ください。

サポートされているリージョン

執筆時点（2024/06/17）では以下のリージョンがサポートされています。

• US East (Ohio)
• US East (N. Virginia)
• US West (Oregon)
• Asia Pacific (Mumbai)
• Asia Pacific (Sydney)
• Asia Pacific (Singapore)
• Asia Pacific (Tokyo)
• Canada (Central)
• Europe (Frankfurt)
• Europe (Ireland)
• Europe (London)
• Europe (Paris)
• South America (São Paulo)

最新情報はこちらを参照ください。

Supported Regions for AWS CloudShell VPC - AWS CloudShell

権限

CloudShell VPC environment を起動するには以下の権限を含める必要があります。

• ec2:DescribeVpcs
• ec2:DescribeSubnets
• ec2:DescribeSecurityGroups
• ec2:DescribeDhcpOptions
• ec2:DescribeNetworkInterfaces
• ec2:CreateTags
• ec2:CreateNetworkInterface
• ec2:CreateNetworkInterfacePermission
• ec2:DeleteNetworkInterface ※

※DeleteNetworkInterfaceは、必須ではないですが Cloudshell 環境を削除する際に ENI が残ってしまうため付与しておくと良いです。

細かく権限制御したい場合は、CloudShell VPC environment が払い出す ENI にはタグにManagedByCloudShellの Key が含まれるため Condition などで条件付けすると良いです。

IAM ポリシーの例は下記公式ドキュメントを参照してください。

Required IAM permissions for creating and using CloudShell VPC environments - AWS CloudShell

やってみた

起動してみる

実際に使用してみました。

起動の仕方は、まず Create VPC environment (max 2) の箇所を押下します。

2 箇所あり、タブを追加＋または「アクション」メニューから選べます。

続いて必要な設定を入力します。

① 任意の環境名 ② 起動したい VPC ③ 起動したいサブネット ④ 割りあてたいセキュリティグループ

以上が入力できたら「Create」を押下して作成完了です。

Invalid VPC configuration provided. Environment with provided VpcConfig already exists for user （IAM プリンシパル名）

というエラーが出た場合は既に同一のサブネットに起動している可能性があるため異なるサブネットを選択するとエラーは解消します。

パブリック環境と比較

パブリック環境と NAT Gateway の無いインターネットへ出れないプライベートサブネットに起動した CloudShell VPC environment とを比較してみようと思います。

下記 AWS CLI のパッケージをインストールするコマンドをたたいてみると

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

パブリック環境では当然インターネットへ出れるため問題なくダウンロードできました。

しかし、CloudShell VPC environment はインターネットへ出れないためタイムアウトとなりました。
デフォルトのタイムアウトは長いため 20 秒で指定しました。

参考

• Using AWS CloudShell in Amazon VPC - AWS CloudShell

おわりに

今回はしれっとアップデートされていたユーザーが作成した VPC に CLoudShell を起動し、プライベートに CloudShell を活用できるアップデートをご紹介しました。

取り急ぎ執筆したためもっと深堀できそうなアップデートかなと思ったため様々な検証をこれから実施したいと思います。

この記事がどなたかの役に立つと嬉しいです。