廃止候補ワークロードの特定
通信事業者が 1,100 台のオンプレミスサーバーの移行を計画しています。過去のプロジェクトで構築されたまま放置されているサーバーが相当数含まれていると推測されており、移行を開始する前にそれらを廃止 (リタイア) して移行対象そのものを減らしたいと考えています。すべてのサーバーには AWS Application Discovery Agent が導入済みで、90 日分の性能データとネットワーク接続データが収集されています。移行チームは、CPU とメモリの使用率が継続的に極めて低く、かつ他システムからの受信 TCP 接続が一切観測されていないサーバーを廃止候補として抽出したいと考えています。追加の開発と運用の手間を最小限に抑えてこれを実現する方法はどれですか。
解説を読む（正解: A）
AWS Application Discovery Service のエージェントは、システム構成と時系列の性能データに加えて、実行中のプロセスと TCP および UDP のネットワーク接続を収集します。さらにデータ探索機能を有効にすると、収集されたこれらの詳細データが Amazon S3 バケットに継続的にエクスポートされ、AWS Glue のデータカタログが自動で作成されて Amazon Athena から SQL でクエリできるようになります。A はこの仕組みをそのまま利用し、性能データと接続データを結合して「使用率が低く、かつ受信接続が観測されないサーバー」という廃止候補の条件をクエリ 1 本で表現できるため、追加のエージェント導入も独自開発も不要で要件に最も適合します。B は既にエージェントが入っている環境にもう 1 種類のエージェントを追加する二重投資であるうえ、CloudWatch エージェントはサーバー間の受信 TCP 接続の有無というトポロジー情報を収集しないため、廃止判定の中核となる条件を満たせません。C は使われていない可能性のあるサーバーまで先に移行してしまう方式で、移行工数とライセンス、EC2 の稼働コストを無駄に消費するため、移行対象を事前に減らすという目的に反します。D の Migration Evaluator は総保有コストの比較を目的としたサービスで、想定コストの低さは単にスペックが小さいことを意味するに過ぎず、実際に利用されているかどうかの判断材料にはなりません。
IoT センサーデータ基盤のサーバーレス化
農業 IoT を推進する団体が、25,000 台以上の土壌水分センサーを圃場に設置しています。各センサーは継続的に更新データを送信しており、1 回の更新のサイズは 500 KB 未満です。現在はオンプレミスのアプリケーションサーバー群がこれらの更新を受信し、生データを人が読める形式に変換して、オンプレミスのリレーショナルデータベースサーバーに書き込んでいます。データアナリストは単純な SQL クエリでこのデータを参照しています。
団体はアプリケーション全体の可用性を高め、メンテナンス作業にかかる労力を削減したいと考えています。アプリケーションサーバーの更新やパッチ適用といったメンテナンスはダウンタイムの原因となっており、その間は残りのサーバーだけでは負荷を捌ききれずセンサーデータが失われています。
ソリューションアーキテクトはどの構成を推奨すべきですか。
解説を読む（正解: B）
Amazon Data Firehose (旧 Kinesis Data Firehose) は、ストリーミングデータを受け取ってバッファリングし、S3 などの宛先へ配信するフルマネージドなサービスです。取り込み量に応じて自動的にスケールし、配信の再試行やバックアップも組み込みで備えているため、サーバーの台数管理やパッチ適用が不要です。配信の途中で AWS Lambda を呼び出してレコードを変換でき、レコード形式変換によって Apache Parquet のような列指向形式で S3 に保存することもできます。Amazon Athena は S3 上のデータに対して標準 SQL を実行できるサーバーレスのクエリサービスで、Parquet 形式であればスキャン量が減り、クエリの速度とコストの両面で有利になります。
正解の構成では、受信から変換、保存、分析までがすべてマネージドサービスで構成されるため、パッチ適用によるダウンタイムもデータ損失も発生せず、アナリストは従来どおり単純な SQL で分析を継続できます。
他の選択肢は要件を十分に満たしません。A と C はデータの最終的な保存先を Aurora MySQL としています。Aurora はマネージドですが、2 万台を超えるセンサーからの継続的な書き込みを受け止めるにはインスタンスサイズやストレージの見積もりとスケーリングの管理が必要で、時系列データを行指向のリレーショナルデータベースに蓄積し続けるのはコスト面でも不利です。加えて C は S3 への保存後に改めてインポートする二重処理が発生します。D は保存形式と分析方法は適切ですが、単純な形式変換のために Managed Service for Apache Flink のアプリケーションを開発し、処理能力 (KPU) やアプリケーションのバージョンを管理し続ける必要があり、Firehose と Lambda の組み合わせに比べて運用の労力が大きくなります。Flink はウィンドウ集計やストリーム結合といった複雑なリアルタイム処理が必要な場合に選ぶべき選択肢です。
個人別 S3 プレフィックス制御とアクセス監査レポート
メルボルンの気象研究機関が、研究者が業務関連のドキュメントを保存するための Amazon S3 バケットを 1 つだけ作成する方針を決めました。同機関は AWS IAM Identity Center ですべての利用者を認証しており、研究者用のグループもすでに作成済みです。同機関は、各研究者が自分自身の作業成果にのみアクセスできるようにしたいと考えています。あわせて、どの利用者がどのドキュメントにアクセスしたかを示す月次レポートも作成する必要があります。これらの要件を満たす手順の組み合わせはどれですか。2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: B、C）
本問の要件は「各利用者が自分の領域だけにアクセスできること」と「オブジェクト単位のアクセス履歴を月次で集計できること」の 2 点に分解でき、それぞれ属性ベースのアクセス制御 (ABAC) と CloudTrail のデータイベントで実現します。AWS IAM Identity Center はフェデレーション時に利用者属性をセッションタグとして引き渡すことができ、許可セットに設定したポリシーの中で aws:PrincipalTag 条件キーとして参照できます。ポリシーのリソースを arn:aws:s3:::bucket/${aws:PrincipalTag/userName}/* のように動的に指定すれば、利用者ごとに個別のポリシーを作らなくても、各研究者は自分のユーザー名と一致するプレフィックス配下のオブジェクトだけを読み書きできます。1 つの許可セットで全員をカバーできるためスケールし、最小権限の原則も守られます (B)。アクセス履歴については、CloudTrail が既定で記録する管理イベントに GetObject や PutObject といったオブジェクトレベルの操作は含まれないため、対象バケットに対して S3 データイベントを明示的に有効化する必要があります。データイベントを S3 バケットへ配信し、Amazon Athena でクエリすれば、誰がいつどのオブジェクトにアクセスしたかを月次で集計できます (C)。A は研究者グループ全体に同じ S3 の読み書き権限を与えるだけであり、研究者が互いのドキュメントを閲覧できてしまうため分離要件を満たしません。D は管理イベントしか記録しないためオブジェクトレベルのアクセスを追跡できず、目的を達成できません。E の EMRFS は Amazon EMR が S3 を Hadoop のファイルシステムとして扱うための実装であり、S3 のアクセスログを有効化する機能ではありません。また Amazon S3 Select は単一オブジェクト内のレコードを絞り込む機能であり、多数のログファイルを横断して集計するレポート生成には適していません。