WEB問題集
ある企業は、Amazon RDS for PostgreSQL マルチ AZ DB クラスターを実行しています。企業は AWS CloudFormation テンプレートを使用して、データベースを個別に作成しており、デフォルトのサイズは 100 GB です。企業は毎週月曜日にデータベースを作成し、金曜日にデータベースを削除します。
時折、データベースのディスク容量が不足し、Amazon CloudWatch アラームが発報します。SysOps 管理者は、今後データベースがディスク容量不足になることを防がなければなりません。 アプリケーションに対する変更を最小限に抑えつつ要件を満たすソリューションはどれですか？正解：C
RDS for PostgreSQL には「ストレージ自動スケーリング」機能があり、ディスク使用量が閾値に近づくと自動的にストレージを拡張してくれます。CloudFormation テンプレートでパラメータを追加するだけで実装可能なため、アプリケーション側に変更は不要です。これが最適解です。
このシナリオでは、すでに Amazon RDS for PostgreSQL を使用しており、アプリケーションはその前提で設計されています。課題は「ディスク容量不足」であり、アプリケーションコードの修正を極力避けたいという要件があります。そのため、**RDS のストレージ自動スケーリング機能（Storage Auto Scaling）**を有効化するのが最小限の変更で解決できる正しい方法です。
SysOps 管理者は、本番データベースのコピーを マイグレーション用アカウントと共有したいと考えています。本番データベースは Amazon RDS DB インスタンス上にホストされており、保存時の暗号化にはエイリアス production-rds-key を持つ AWS Key Management Service (AWS KMS) キーが使用されています。
最小限の管理作業で要件を満たすには、SysOps 管理者は何をすべきですか？正解：A
スナップショットを作成し、KMS キーのポリシーにマイグレーションアカウントを追加して共有するのが、AWS公式に推奨される手順です。これでマイグレーションアカウントがスナップショットから新しい DB インスタンスを復元できます。
Amazon RDS の 暗号化スナップショットを別アカウントと共有する場合、スナップショットに使用されている KMS カスタマー管理キー (CMK) のポリシーに、共有先アカウントを明示的に追加する必要があります。これにより共有先アカウントがスナップショットにアクセスできるようになります。
この方法は 最小限の変更で要件を満たす方法であり、管理作業も最小限です。ある企業は、AWS 上で 継続的インテグレーションと継続的デリバリー (CI/CD) の環境をホストしています。CI/CD 環境には Amazon EC2 インスタンス上でホストされている Jenkins サーバーが含まれています。この EC2 インスタンスには 500 GB の汎用 SSD (gp2) の Amazon Elastic Block Store (Amazon EBS) ボリュームがアタッチされています。
ディスクのスループット制限が原因で、Jenkins サーバーにパフォーマンス問題が発生し、ビルドが遅くなっています。EBS ボリュームは、毎晩のビルド処理中に 3,000 IOPS を持続する必要があります。 Amazon CloudWatch でサーバーの履歴を確認したところ、毎晩のビルド時に BurstBalance メトリクスが 0 になっていました。SysOps 管理者は、パフォーマンスを改善し、持続的なスループット要件を満たす必要があります。 最もコスト効率よく要件を満たすソリューションはどれですか？正解：B
本件のボトルネックは、gp2 の バーストクレジットが尽きて BurstBalance=0 となり、必要な IOPS を 持続できない点にあります。gp2 は「3 IOPS/GB」のベースラインで、500 GB なら 1,500 IOPS が上限（バースト時は一時的に上げられるが、クレジットが枯渇すると低下）です。よって 3,000 IOPS を継続したい場合、gp2 のままでは不適です。
gp3 は gp2 と同等/それ以上の料金効率で、ボリュームサイズと性能 (IOPS/スループット) を独立してプロビジョニングでき、デフォルトで 3,000 IOPS / 125 MB/s を提供します（必要に応じて IOPS を追加購入可能）。バーストクレジットに依存せず、持続性能を確保できるため、要件を最もコスト効率よく満たします。既存ボリュームを無停止で gp3 に変換できる点（オンライン変更可）も運用上の変更が最小です。ある企業は、Amazon EC2 インスタンスのグループ上でアプリケーションを実行しており、それらは Application Load Balancer (ALB) の背後に配置されています。EC2 インスタンスは 3つのアベイラビリティーゾーンに分散して稼働しています。企業は、顧客に対して 最大 2 つの固定 IP アドレスを提供する必要があります。
SysOps 管理者は、どのようにしてこの要件を満たすべきでしょうか？正解：A
Global Accelerator は「静的 IP を提供しつつ ALB へルーティング」できる唯一の正解。最大 2 つの IP を持ち、AWS グローバルネットワークを経由するため低レイテンシの利点もあります。
Application Load Balancer (ALB) は 静的 IP アドレスを直接提供できません。ALB は DNS 名（例: xxx.elb.amazonaws.com）を持ちますが、背後では複数の可用性ゾーンにわたる動的 IP を使います。そのため、ALB に Elastic IP を直接割り当てることはできません。
SysOps 管理者は、本番環境の Auto Scaling グループが 2 台の Amazon EC2 インスタンスにスケールダウンしたというアラートを受け取りました。Auto Scaling グループは元々、最小キャパシティを 3 インスタンスに設定していました。しかし SysOps 管理者が確認すると、現在の設定では 最小キャパシティが 2 インスタンスに変更されていました。
誰がこの変更を行ったのかを特定するのに役立つ AWS サービスはどれですか？正解：A
リソースの設定変更履歴を追跡し、誰が変更を加えたのかを特定可能。Auto Scaling グループの「最小キャパシティ」の変更記録も保持されます。
今回のシナリオは「Auto Scaling グループの設定が意図せず変更され、誰が変更したのかを特定したい」というものです。
AWS Config は、AWS リソースの設定変更を継続的に記録し、いつ・誰が・どのように設定を変更したかを確認できるサービスです。さらに、AWS Config と CloudTrail を組み合わせることで「変更を行った IAM ユーザーやロール」まで追跡できます。したがって、今回のケースで最適な選択肢は AWS Config です。