Fargate タスク数のサービスクォータ使用率の監視
フードデリバリー企業は、およそ 100 のマイクロサービスから成る大規模なコンテナワークロードを Amazon Elastic Container Service (Amazon ECS) で運用しています。開発チームは最近、ECS クラスターの起動タイプを Amazon EC2 インスタンスから AWS Fargate に切り替えました。EC2 で運用していた頃は、アカウントのインスタンス数の上限に達しかけてスケールできなくなる事態が何度も起きていました。同社は、今度は Fargate タスク数のサービスクォータに近づいてしまうことを懸念しています。ソリューションアーキテクトは、Fargate のタスク数がクォータの 80% を超えた時点で開発チームに通知する仕組みを、できるだけ運用負荷をかけずに構築する必要があります。この要件を満たす最適な方法はどれですか。
解説を読む（正解: B）
AWS の多くのサービスクォータは、現在の使用量を Amazon CloudWatch の AWS/Usage 名前空間にメトリクスとして自動的に発行しています。ECS の Fargate オンデマンドタスク数のように引き上げ可能なクォータでは、この使用量メトリクスと、Service Quotas が提供するメトリクス数式関数 SERVICE_QUOTA() を組み合わせることで、m1 / SERVICE_QUOTA(m1) * 100 という数式によって使用率をパーセントで算出できます。この数式メトリクスに対して 80 を超えたらアラーム状態になる CloudWatch アラームを作成し、アクションとして Amazon SNS のトピックへ通知すれば、上限に達する前に開発チームへ知らせるという要件を、独自のコードを書かずに満たせます。よって選択肢 B が正解です。選択肢 A のサンプルカウント統計は、その期間にメトリクスへ送信されたデータポイントの個数を表すだけで、実行中のタスク数やクォータの使用量を意味しないため、算出される値に意味がありません。選択肢 C は Lambda によるポーリング処理を自作して保守する運用負荷が生じるうえ、80 タスクという固定のしきい値はクォータの 80% とは一致せず、クォータが引き上げられた時点で意味を失います。選択肢 D の AWS Config はリソースの構成変更を評価して準拠状況を記録するサービスであり、サービスクォータの使用率をリアルタイムに評価する用途には対応していません。
インライン検査アプライアンスの障害検知とルート自動修復
ある証券会社が、VPC を出入りするトラフィックを独自のパケット検査ソフトウェアで解析しています。このソフトウェアは AWS CloudFormation でデプロイされた Auto Scaling グループ内の 3 台の Amazon EC2 インスタンス上で動作し、サブネットのルートテーブルはトラフィックがこれらのインスタンスを直接経由するように構成されています。運用チームは 2 つの問題に直面しています。検査ソフトウェアのプロセスが異常終了してもインスタンス自体は稼働し続けるため置き換えが起こらず、また Auto Scaling グループがインスタンスを置き換えたときにもルートテーブルが新しいインスタンスを指すように更新されません。この問題を解決する手順の組み合わせはどれですか。3 つ選択してください。
複数選択問題です (正解 3 つ)。選んでから判定してください。
解説を読む（正解: B、D、E）
EC2 のステータスチェックは基盤ハードウェアの健全性とインスタンスの OS 到達性しか判定しないため、OS が正常なままアプリケーションプロセスだけが停止する「サイレント障害」を検知できません。そこで選択肢 B のように CloudWatch エージェントを導入し、プロセスの稼働状況をカスタムメトリクスとして Amazon CloudWatch へ送信すると、アプリケーション観点の健全性を可視化できます。次に選択肢 D で、そのカスタムメトリクスに対する CloudWatch アラームを作成し、しきい値を超えたときに Amazon SNS トピックへ通知を発行させます。最後に、ルートテーブルの書き換えは Auto Scaling が自動では行わないため、選択肢 E の AWS Lambda 関数を SNS にサブスクライブさせ、異常インスタンスの隔離と、代替インスタンスの ENI を指すルートの更新を自動実行させる必要があります。この 3 つで「検知 → 通知 → 修復」という自己修復のループが完成します。選択肢 A は前述のとおり EC2 ステータスチェックがプロセス障害を捉えないため機能しません。選択肢 C の Systems Manager エージェントはコマンド実行、パッチ適用、インベントリ収集を担うものであり、OS やプロセスのメトリクスを CloudWatch に発行する役割は CloudWatch エージェントが担います。選択肢 F の CloudFormation の Conditions は、スタックの作成・更新時にリソースを作成するかどうかを評価するテンプレート機能にすぎず、実行時のインスタンス置換に反応してルートを書き換えることはできません。
リポジトリへのアクセスキー混入の自動検知と封じ込め
クラウド会計 SaaS を提供する企業のセキュリティ監査で、モバイルアプリ開発チームが IAM ユーザーのシークレットアクセスキーをソースコードに直接埋め込み、AWS CodeCommit リポジトリにコミットしていたことが判明しました。同社のサイバーセキュリティチームは、同種の混入をコミットされた時点で自動的に検知し、漏えいした認証情報を即座に無効化したうえで関係者へ通知する仕組みを求めています。機密情報を自動的に保護し、同様の問題が再発した場合にも確実に対処できるソリューションはどれですか。
解説を読む（正解: B）
認証情報がリポジトリに混入した場合、漏えいから悪用までの時間が非常に短いため、検知は「コミットという事象そのもの」を起点にし、対応は「該当キーの無効化」まで自動化する必要があります。CodeCommit はリポジトリに対するトリガー（通知）を設定でき、指定したブランチへのプッシュを契機に AWS Lambda 関数を同期的に呼び出せます。この関数がコミットの差分をスキャンし、アクセスキーのパターンを検出したら IAM の UpdateAccessKey や DeleteAccessKey を呼んで即座に無効化し、Amazon SNS で開発者とセキュリティチームに通知すれば、検知から封じ込めまでが数秒で完結し、将来のコミットにも同じ仕組みが自動的に適用されます。A は開発者のワークステーションを対象にしており、リポジトリにコミットされた認証情報は見つけられません。また夜間バッチのため即時性がなく、Secrets Manager のローテーションは Secrets Manager が管理するシークレットにしか適用できないため、ハードコードされたキーには効きません。D はスケジュール実行であるためコミットから検知までに最大でスケジュール間隔分の遅延が生じ、しかも新しいキーを発行するだけで漏えいしたキーを無効化していないため、攻撃者は元のキーを使い続けられます。C は Amazon Macie が Amazon S3 に保存されたオブジェクトの機密データ検出に特化したサービスであり、CodeCommit リポジトリをスキャン対象にできないという前提の誤りがあります。