概要
AWS CLIについて、使うべきだと思う理由や注意点について簡単に紹介してみる。
前置き
AWSでリソースを操作する場合、最も基本となるのがマネジメントコンソールである。
GUIで直感的に操作できたり、必要なIAMロールを自動で作成してくれたりするため、すぐに簡単にAWSリソースを構築することができる。
その一方で、AWS CLIではCUIでAWSリソースの参照・操作が可能である。
AWS CLIを使用することで、非常に効率的にAWSリソースを操作することができるようになる。
マネジメントコンソールでの操作は分かりやすいのだが、操作時にいくつもの画面遷移が必要だったり、作業の再現性を保つのが難しかったりする。
個人的にはAWS CLIを積極的に使うべきだと思っているので、その理由や注意点について紹介したいと思う。
内容
インストールと初期設定
生まれてこの方ずっとWindowsを使っているので、WSL上のUbuntuにAWS CLIをインストールして利用している。
$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ sudo apt install -y unzip
$ unzip awscliv2.zip
$ sudo ./aws/install
$ aws configure # AWS CLIの設定
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]:
Default output format [None]:インストールの詳細については下記を参照。
AWS CLIを使うべき理由
AWS CLIを使うべき理由は下記2点。
- マネジメントコンソールから見えない情報の確認
- AWSリソース参照・操作の効率化
1点目は、マネジメントコンソールから見えない情報の確認のためである。
実は、マネジメントコンソール上からだと見えない情報がまあまあある。
例えば、CloudTrail証跡の「Include global resource events（グローバルリソースを含める）」という項目はコンソールからは確認・設定ができない。これを設定するためには、AWS CLIやCloudFormationを使用する必要がある。
$ aws cloudtrail get-trail --name trail
Trail:
HasCustomEventSelectors: true
HasInsightSelectors: false
HomeRegion: ap-northeast-1
IncludeGlobalServiceEvents: true # グローバルサービスの証跡記録が有効になっている
IsMultiRegionTrail: true
IsOrganizationTrail: false
LogFileValidationEnabled: true
Name: trail
S3BucketName: aws-cloudtrail-logs-123456789012-01234567
TrailARN: arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/trail2点目は、AWSリソースの参照・操作の効率化のためである。
個人的には、このメリットが非常に大きい。
作成したAWSリソースは、AWS CLIを使用して参照することでJSONやYAMLの形式で設定値を取得できる。取得した設定値を使用してAWS CLIからリソースを構築することが可能である。
また、コマンドなら操作履歴を簡単に残せるので、同じ操作を何度も行う際に、作業スピードが格段に向上する。
個人的には、CloudFormationテンプレートを展開する際によく使用する。
マネジメントコンソールから操作する場合、テンプレートファイルのアップロードや、項目設定のための画面遷移がいくつか必要になる。
しかし、AWS CLIから操作する場合、下記のようなコマンドを実行するだけで展開可能である。
$ aws cloudformation deploy \
--template-file [CloudFormationテンプレートファイルのパス] \
--stack-name [スタック名]展開に失敗した場合には、手元にあるテンプレートファイルを修正し、再度上記コマンドを実行することにより、簡単に展開できる。
コマンドの詳細については下記を参照。
AWS CLIの注意点
AWS CLIを使用する上での注意点は、必要な認証情報の取り扱いである。
IAMユーザの認証情報でAWS CLIを使用する場合には、アクセスキーとシークレットアクセスキーを設定することになるが、これらは永続的な認証情報である。
IAMユーザでAWS CLIを使用する必要がある場合には、MFAを使用することでセキュリティリスクを低減することができる。
マネジメントコンソールを利用する場合は、設定でMFAを有効にすると、ログイン時にユーザ名とパスワードの他に、MFAコードの入力が求められるようになる。
しかし、AWS CLIでは、デフォルトではアクセスキーとシークレットアクセスキーのみで操作することができてしまう。
そこで、MFAを有効化していない場合には、リソースアクセスを禁止するポリシーを適用することでこの問題を回避する。
MFA強制のポリシーは公式ドキュメントで紹介されている。
具体的には、下記ブログにある「公式ドキュメントに載っているIAMポリシーでの対応方法」に掲載の方法と同様にすることで、適切に権限を制限することができる。
※ AWS公式の推奨は、AWS Identity Center等を使用したSSOによる一時認証情報の使用である。
AWS CLIをより便利に
AWS CLIをより便利に使う方法を紹介する。
- WSL上で使用する（Windowsの場合）
- ページャを無効化する
jqを活用する
1点目。Windowsの場合、WSL上で実行することをおすすめする。
Linuxコマンドを組み合わせたり、シェルスクリプトを作成できたりするので使いやすい。
2点目。意外とおすすめなのが設定でページャを無効化しておくこと。
コマンドによってはページャで出力されるが、それを毎回エスケープで抜けるのが面倒なので、設定で無効化しておく。
設定ファイル「.aws/config」に「cli_pager=」という行を追加することで無効化できる。
[default]
cli_pager=ページャが必要な場合は少ないと思うので、その都度パイプでlessに渡してしまえば良い。
$ aws sts get-caller-identity | less3点目。jqを組み合わせてAWS CLIの出力を絞り込む。
AWS CLIの出力では多くの情報が表示されるが、jqを使用してJSON形式の出力から必要な情報を取得することができる。
$ aws cloudtrail get-trail --name trail | jq ".Trail.IncludeGlobalServiceEvents"
truejqは正直まだあまり使いこなせていないので、もう少し勉強したい。
まとめ
AWS CLIを活用すれば、AWSリソースの操作をもっと効率化できる、かも！
認証情報の管理にはお気を付けて。
感想
触ったことがないリソースでいきなりAWS CLIを使うのは難しいと思うが、慣れているリソースに対してはAWS CLIの使用による効率化の余地があると思う。
業務でも個人でもよくCloudFormationを使うのだが、特にテンプレートを展開する場面では、AWS CLIでの操作は、マネジメントコンソールでの操作と比較してかなり楽であることが実感できると思う。
CloudFormationを使っている人は、ぜひAWS CLIの「aws cloudformation deploy」からテンプレートを展開してほしい。
参考
