AWS CLF-C02 で AWS CLI はどう問われるか

AWS を操作する手段には、ブラウザから使う AWS マネジメントコンソール、アプリケーションから呼び出す AWS SDK、そしてコマンドラインから使う AWS CLI があります。AWS CLI は単一のツールであらゆる AWS サービスの API を呼び出せる統合コマンドラインインターフェイスで、シェルスクリプトやバッチファイルに組み込めるため、繰り返し実行する運用作業の自動化に適しています。本シナリオのように、EC2 の停止、S3 へのファイル同期、古いスナップショットの削除という複数サービスをまたぐ処理を夜間バッチとして無人実行したい場合、CLI コマンドを並べたスクリプトを cron から呼び出すのが最も素直で標準的な実装になります。AWS マネジメントコンソールは GUI であり、人がブラウザで操作することを前提としているためスクリプト化できず、無人実行の要件を満たせません。AWS Systems Manager は EC2 インスタンスやオンプレミスサーバーの構成管理、パッチ適用、リモートコマンド実行を行う運用管理サービスで、Run Command や Automation で自動化はできますが、管理対象のサーバー群に対する運用が主眼であり、AWS サービス全体を横断的に呼び出す汎用のスクリプト用ツールという位置づけではありません。AWS IAM は誰がどのリソースに対して何をできるかを制御する認証・認可のサービスで、スクリプトが使う権限を定義するものではあっても、リソースを操作するツールそのものではありません。

長期のアクセスキーは有効期限を持たないため、一度漏えいすると気付くまで悪用され続ける可能性があります。そのため AWS は、まず不要な長期キーを持たないこと、次に残るキーを定期的にローテーションし、使われていないキーを削除することを推奨しています。B は、IAM の認証情報レポートやコンソールの最終使用日を使って未使用キーを洗い出し削除する運用そのもので、攻撃対象領域を継続的に縮小できるため適切です。D は、EC2 のインスタンスプロファイル、IAM Identity Center、AssumeRole などを通じて AWS STS の一時的な認証情報を使う方針であり、有効期限付きで自動ローテーションされるため長期キーそのものを不要にできる、最も推奨される考え方です。よって B と D が正解です。A は、ルートユーザーはアカウント内のすべての操作が可能で権限を絞れないため、アクセスキーを作らないことが公式に推奨されており、日常運用に使うのは最も避けるべき行為です。C は、ソースコードに直接キーを書くと、リポジトリの公開やコピーによって容易に流出し、ローテーションのたびにコード変更とデプロイが必要になるため、明確なアンチパターンです。

AWS CLI (AWS Command Line Interface) は、AWS サービスの API をコマンドラインから呼び出すための統合ツールで、Linux や macOS、Windows の端末やスクリプトから実行できます。コマンドをシェルスクリプトに記述してループ処理すれば、数百個のバケットに対する同一操作を人手を介さず繰り返し実行でき、実行内容そのものがスクリプトとして残るため再現性と監査性も確保できます。したがって C が最も適しています。B のマネジメントコンソールでの個別変更は、GUI で分かりやすい反面、対象が数百個になると膨大な工数がかかり、設定漏れや誤操作のリスクも高まるため、反復的な作業には向きません。A の AWS Trusted Advisor は、コスト最適化やセキュリティ、耐障害性などの観点からアカウントを分析して改善を推奨するサービスであり、推奨事項を提示することはできても、その画面から S3 バケットの設定を一括変更する機能は持ちません。D の Amazon S3 バッチオペレーションは、バケット内の大量の「オブジェクト」に対してコピーやタグ付けなどの処理をまとめて実行する機能であり、バケット単位の設定を横断的に変更する用途のものではありません。プログラムによるアクセス手段としては、ほかにアプリケーションのコードに組み込む AWS SDK もあり、目的に応じて使い分けます。