AWS Health イベントを組織横断で自動処理する
製造業の企業が AWS Organizations 配下の 40 アカウントで生産管理システムを運用しています。これまで EC2 インスタンスの予定メンテナンス (リタイア通知) や EBS ボリュームの劣化通知を各アカウントの担当者が個別に確認していましたが、見落としによって計画外の再起動が発生し、工場のラインが停止する事故が起きました。今後は組織全体のイベントを一元的に受け取り、対象インスタンスへの対処 (停止と起動による基盤移行) を自動化し、対応状況を運用チームに通知したいと考えています。最も適切な設計はどれですか。
解説を読む（正解: A）
AWS Health は、利用中のリソースに影響する AWS 側のイベント (スケジュールされた EC2 のリタイア、基盤ハードウェアの劣化、サービスの障害など) をアカウント単位で通知するサービスです。Organizations と統合して組織ビューを有効化すると、管理アカウントまたは委任管理者アカウントから全メンバーアカウントのイベントを一元的に参照でき、見落としの構造的な原因を取り除けます。さらに Health のイベントは aws.health を送信元として Amazon EventBridge に配信されるため、イベントタイプやアカウント、影響を受けるリソースでフィルタするルールを作り、SNS 通知と Systems Manager Automation ランブック (インスタンスの停止・起動によって新しい基盤ホストへ移動させる処理) を同時に起動できます。よって A が正解です。B は人手の確認に依存する運用で、40 アカウント規模では同じ見落としが再発します。C は誤りで、AWS Health のイベントは CloudTrail の API 呼び出し履歴として記録されるものではないため、証跡を検索しても取得できません。D も誤りで、AWS Config はリソースの設定変更を評価するサービスであり、AWS 側の基盤ハードウェア劣化を検出するデータソースを持ちません。E も誤りで、Amazon Inspector はソフトウェアの脆弱性と意図しないネットワーク露出をスキャンするサービスであり、ハードウェア劣化の検出とは無関係です。
組織全体の AWS Health イベント通知の一元化
産業機械メーカーが AWS Organizations 配下の 25 個のアカウントでワークロードを運用しています。運用チームは、Amazon EC2 インスタンスのリタイア予定、Amazon EBS ボリュームの劣化、Amazon RDS のメンテナンス予定といった AWS 側で発生する計画・非計画イベントを、アカウントを問わず 1 つの通知チャネルにまとめて受け取りたいと考えています。エージェントの追加導入や新しいサーバーの構築は避けたいという方針です。最小の労力でこれを実現する方法はどれですか。
解説を読む（正解: A）
AWS Health は、AWS 側で発生したリソースへの影響やスケジュールされた変更を利用者に伝えるサービスで、EC2 のリタイア予定、EBS ボリュームの劣化、RDS のメンテナンス予定などがイベントとして配信されます。AWS Organizations と統合した組織ビューを有効にすると、メンバーアカウントで発生した Health イベントを管理アカウントから一元的に参照でき、管理アカウントの Amazon EventBridge では aws.health をソースとするイベントを受け取れます。EventBridge のルールで対象のイベントタイプを絞り込み、ターゲットに Amazon SNS トピックを指定すれば、追加のサーバーもエージェントもなくアカウント横断の単一通知チャネルが完成します。したがって A が要件を最小の労力で満たします。B は誤りで、AWS CloudTrail が記録するのは API 呼び出しの監査ログであり、AWS 基盤側で発生する Health イベントはそこには現れないため、文字列一致で検出することはできません。C も誤りで、AWS Config はリソース構成が定めたルールに準拠しているかを評価する仕組みであり、AWS 側の計画メンテナンスやハードウェア劣化を通知する機能は備えていません。D はゲスト OS 上のログを集めるだけであり、リタイア予定のような AWS 基盤のイベントは記録されないうえ、全インスタンスへのエージェント導入と OpenSearch クラスターの運用は「エージェントもサーバーも増やさない」という方針に反します。
画像リサイズ基盤のイベント駆動設計とコスト最適化
不動産ポータルを運営する企業は、物件写真の保管と配信を担う新しいサービスを AWS に構築しようとしています。数百万人の利用者が対象で、不動産会社から一度に数百枚単位の高解像度画像がまとめて送られてきます。サービスはそれらの画像を配信用サイズへ変換し、Amazon S3 に最大 6 か月間保管したうえで自動的に削除する必要があります。アップロード量は時期によって大きく変動し、大規模でも安定して動作すること、および処理が失敗したジョブを後から再実行できることが求められます。これらの要件を最も費用対効果の高い方法で満たすソリューションはどれですか。
解説を読む（正解: B）
正解は B です。Amazon EventBridge は、S3 のオブジェクト作成イベントをルールで受け取り、AWS Lambda などのターゲットへ配信するサーバーレスのイベントバスです。イベント数に応じた従量課金でスケーリングの管理が不要なため、アップロード量が大きく変動しても追加のキャパシティ設計をせずに追随できます。さらに EventBridge のターゲットにはリトライポリシーとデッドレターキュー (DLQ) を設定でき、配信に失敗したイベントを標準 SQS キューへ退避して原因解消後にまとめて再処理できるため、「障害時にジョブを再実行できる」という要件も満たします。保管については、6 か月で失効させる S3 ライフサイクルルールにより不要なオブジェクトが自動削除され、保管コストが際限なく増えることを防げます。以上から B が最も費用対効果に優れます。A の Step Functions でも同じ処理は可能ですが、そもそも S3 イベント通知が直接配信できる宛先は SNS・SQS・Lambda・EventBridge のみで、ステートマシンを起動するには結局 EventBridge を挟む必要があります。さらに Standard ワークフローは状態遷移ごとの課金 (1,000 遷移あたり 0.025 USD) が上乗せされ、リサイズという単一ステップのためだけにオーケストレーション料金を払うことになるため割高です。C は S3 イベント通知から Lambda を直接呼び出す構成で、非同期呼び出しの再試行回数が限られ失敗イベントの再実行が難しいうえ、ライフサイクルが 6 か月後に S3 標準 - IA へ移行するだけでオブジェクトを削除しないため、削除要件を満たさず保管コストも積み上がり続けます。D は新規に作成した変換済み画像を最初から S3 標準 - IA に置く点が問題で、公開直後の物件写真は頻繁に参照されるためリクエストごとの取り出し料金が発生し、最低保管期間 30 日の制約も受けます。さらに Deep Archive への移行も削除ではないため、やはり 6 か月後に削除するという要件を満たしません。