AWS CloudShell が実装されて個人的に嬉しかったこと
本日、AWS は AWS CloudShell をローンチしました。これは、AWS 対応のシェルプロンプトの作業を簡単かつセキュアにし、できるだけ手間を少なくすることを目的としたものです。CloudShell で実行するすべてのシェル環境には、AWS コマンドラインインターフェイス (CLI) (v2) がインストールおよび設定されており、AWS のコマンドを即座に実行できます。環境には Python と Node のランタイムも含まれ、今後さらに多くのランタイムを追加する予定です。 コンソール画面上からターミナル画面を起動出来て CLI の実行が出来る機能です。Google Cloud にもあったやつですね。 AWS re:Invent 2020 で発表され、今のところ（2021年3月現在）、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、およびアジアパシフィック (東京) リージョンで利用できます。 個人的に AWS CloudShell が実装されて嬉しい点は下記の2つです。 1. 認証情報を設定する必要がない 2. AWS CLI 等のツールをインストールしておく必要が無い 管理しているアカウントの数が少なければ大したことないのですが、監視業務を行なっている現場では多数の AWS アカウントにログインする必要があり、AWS CLI を使用する場合は都度認証情報を切り替える必要がありました。 もちろん direnv 等便利なツールは存在しますが、1日で多くの AWS アカウントを行った来たりしていると対象アカウントを間違えてコマンドを実行してしまう…等といった危険がありました。 CloudShell を用いれば認証情報を端末に設定する必要が無く、コンソール画面にログインをすれば AWS CLI 等を実行できる環境が手に入ります。 もちろんログインする AWS アカウントを間違えてしまうと元も子もないですが… AWS アカウントへのログイン方法は各社工夫がされていると思いますので、認証情報の切り替え間違えよりはリスクが低いのかなと個人的には考えています。 AWS CLI には現状バージョン1と2が存在しており、当たり前ですがバージョン1がインストールされている環境ではバージョン2で記述されたコマンドは実行されません。 つまり夜間対応等をMSP部隊にお願いする際は、対応者の端末にインストールされている AWS CLI のバージョンをあらかじめ調べておく必要があったり、チーム内でバージョンを統一しておく必要がありました。 AWS CloudShell を用いれば AWS CLI は既にインストールされているので、上記のような懸念を無くすことができ、また常に事前に想定された環境で CLI を実行することが可能になります。 さらに使用するスクリプトによっては jq コマンドを使ったりするケースもあると思うのですが、こういったものも既にインストールされているのでとても頼もしいです。 ランタイム – Python およびノードランタイムに加えて、Bash、PowerShell、jq、git、ECS CLI、SAM CLI、npm、pip は既にインストールされており 、ご利用いただけます。 AWS CloudShell はデフォルトでは AdministratorAccess や PowerUerAccess のポリシー、もしくは AWSCloudShellFullAccess ポリシーを割り当てても利用できます。 反対に、明示的に AWS CloudShell を使えないようにするには以下のポリシーを割り当てる必要があります。 また、現状だと実行ログを CloudWatch Logs に転送する機能は無いため、監査が厳しい案件では使用は出来なさそうです。（むしろ使用出来ないようにしておいた方が良いかもですね。）
AWS CloudShell とは
1. 認証情報を設定する必要がない
2. AWS CLI 等のツールを事前にインストールしておく必要がない
注意点
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyCloudShell",
"Effect": "Deny",
"Action": [
"cloudshell:*"
],
"Resource": "*"
}]
}
