アクセスパターンが不明な S3 データのコスト最適化
オンライン学習プラットフォームを運営する教育系企業が、数十の AWS アカウントにまたがる多数の S3 バケットに講義動画・教材 PDF・提出課題を保存しています。データ量は急増していますが、どのオブジェクトがいつアクセスされるかの傾向は把握できておらず、アクセス頻度は講義の開講時期によって大きく変動します。取り出しの遅延やアクセス失敗は許容できません。ストレージコストを削減しつつ、組織全体の使用状況を可視化するために推奨すべき対応はどれですか。
解説を読む（正解: B）
S3 のコスト最適化では、アクセスパターンが予測できるかどうかで打ち手が変わります。予測できる場合はライフサイクルポリシーによる決め打ちの階層移行が有効ですが、本シナリオのようにアクセス傾向が不明で季節変動もある場合に適しているのが S3 Intelligent-Tiering です。Intelligent-Tiering はオブジェクトごとのアクセスを監視し、一定期間アクセスがなければ低頻度アクセス階層やアーカイブインスタントアクセス階層へ自動的に移動し、再びアクセスされれば高頻度アクセス階層へ戻します。取り出し料金が発生せず、ミリ秒単位のアクセスを維持できるため、遅延を許容できない要件にも合致します。組織全体の可視化には S3 Storage Lens が適しており、AWS Organizations と統合して全アカウント・全バケットのストレージ使用量、ストレージクラス分布、最適化の推奨を単一のダッシュボードで確認できます。よって B が正解です。A は Deep Archive からの復元に数時間かかり、取り出し遅延を許容できないという要件に反します。C は One Zone-IA が単一アベイラビリティーゾーンにしかデータを保持せず、ゾーン障害時にデータを失うリスクがあり、頻繁にアクセスされるオブジェクトでは取り出し料金がかさむ可能性もあります。D は手作業に依存し、数十アカウント規模では継続不可能なうえ、季節変動する需要への追随も遅れます。
持株会社のマルチアカウント請求とガバナンス
ある持株会社が、5 つの子会社をグループとして統合しました。各子会社はそれぞれ独自の AWS アカウントを保有しています。ソリューションアーキテクトは、次の要件を満たす仕組みを設計するよう依頼されました。
・グループ全体の AWS 利用料を 1 通の請求書にまとめること。
・請求書では子会社アカウントごとの利用額の内訳が確認できること。
・グループのガバナンス規程で認可されたサービスと機能のみを子会社アカウントで利用できるよう制限できること。
・ガバナンス規程の範囲内では、各子会社アカウントに完全な管理者権限を委譲すること。
これらの要件を満たすためにソリューションアーキテクトが実施すべき手順の組み合わせはどれですか。2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: B、D）
AWS Organizations は複数の AWS アカウントを一元的に管理するためのサービスです。組織を作成すると一括請求が自動的に有効になり、管理アカウントに対してグループ全体の請求書が 1 通発行されます。同時に Cost Explorer や Cost and Usage Report ではメンバーアカウント単位の内訳を確認できるため、請求の統合と内訳表示の要件を同時に満たせます。もう一方の柱がサービスコントロールポリシー (SCP) で、これは組織、OU、アカウントに適用される権限の上限 (ガードレール) を定義するものです。SCP 自体は権限を付与せず、アカウント内のすべての IAM プリンシパル (管理者を含む) が実行できる操作の最大範囲を制限します。
したがって B で単一の組織にすべての子会社アカウントを参加させ、D で認可済みサービスのみを許可する SCP をアタッチすれば、4 つの要件をすべて満たせます。SCP で許可された範囲の中であれば、各子会社の担当者に完全な管理者権限を与えても差し支えありません。
他の選択肢は誤りです。A は子会社ごとに別々の組織を作るため、請求書も組織の数だけ発行され、単一請求書の要件を満たせません。C の Service Quotas は VPC 数や実行中インスタンス数といったリソースの上限値を管理する機能であり、特定のサービスや API 呼び出しを禁止するガバナンス制御には使えません。E の一括請求は現在 AWS Organizations の機能として提供されており、組織を作らずに請求コンソールだけでアカウントをリンクする独立した仕組みではありません。仮に請求を束ねられたとしても、サービスの利用制限は実現できず要件の一部しか満たせません。
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 はソフトウェアの脆弱性と意図しないネットワーク露出をスキャンするサービスであり、ハードウェア劣化の検出とは無関係です。