AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

A. プレミアム層のテナントについては、検索性能の可視化を優先し、共有インデックスのまま OpenSearch の異常検知(Anomaly Detection)ジョブをテナントごとに個別設定してクエリレイテンシを監視する。性能劣化を検知した時点でアラートを出す運用によりノイジーネイバー対策とする

OpenSearch の異常検知でクエリレイテンシを監視するのは「劣化が起きたことを知る」ための可観測性の施策であって、分離の実装ではありません。
共有インデックスのままではプレミアム層のクエリが他テナントの負荷に引きずられる構造が残り、アラートが鳴ってもその場で性能を取り戻す手段がありません。
「他テナントの負荷に検索性能が左右されない」という必須要件に対する回答になっていません。

正解

B. スタンダード層のテナントには Pool(プール)モデルを採用する。全テナントのデータを共有インデックス(または時系列の複数インデックス)に格納し、すべてのドキュメントに tenant_id フィールドを付与したうえで OpenSearch の Document Level Security(DLS)を設定し、認証済みユーザーのテナントコンテキストに応じて検索結果を動的にフィルタする

スタンダード層は 6,000 社以上・利用が散発的で、目標はコストの最小化です。テナントごとにリソースを分けるとインデックス数・シャード数が爆発してクラスターのオーバーヘッドだけで費用が膨らむため、共有インデックスに全テナントのデータを収める Pool モデルが最適です。
全ドキュメントに tenant_id を付与し、ファイングレインアクセスコントロールの Document Level Security (DLS) を設定すれば、認証済みユーザーのテナントコンテキストに応じて検索結果が自動的に絞り込まれ、分離をアプリケーションコードに依存せず担保できます。
コスト効率とデータ分離を両立する、スタンダード層の正解です。

C. 全テナント共通で1つの共有インデックスを使う。分離ロジックは AWS Lambda のクエリ関数内に実装し、条件に一致する全件を取得したうえで tenant_id が一致しないレコードをアプリケーションコード側でフィルタしてから応答する

共有インデックスから条件に一致する全件を取得し、アプリケーションコード側で tenant_id をフィルタするのは典型的なアンチパターンです。
フィルタ処理を書き漏らした 1 か所がそのままクロステナントのデータ漏洩につながるうえ、他テナント分まで取得するため転送量とレイテンシも悪化します。
DLS のようにデータストア側で強制できる仕組みがある以上、この設計を選ぶ理由はありません。

正解

D. プレミアム層のテナントには Silo(サイロ)モデルを採用する。テナントごとに専用インデックス(例: kb-tenant-premium-001)をプロビジョニングし、Lambda のルーティングロジックで読み書きの対象インデックスを切り替え、シャードリソースを物理的に分離する

プレミアム層は 18 社と少数で、ノイジーネイバー対策とデータ分離が必須要件です。テナントごとに専用インデックスをプロビジョニングする Silo モデルなら、シャードがテナント単位に分かれるため、他テナントの重いクエリやインデックス更新の影響を受けにくくなります。
データが物理的に別インデックスへ分かれるため誤って他テナントのドキュメントを返す余地がなく、テナント単位のスナップショット・削除・チューニングも容易です。
テナント数が少なくインデックス数の増加が問題にならない層に限定して適用する点も、この設計の要です。

E. スタンダード層のテナントにも Silo モデルを採用する。6,000社超のテナントそれぞれに専用の OpenSearch ドメインを作成し、AWS CloudFormation StackSets でライフサイクルを管理して絶対的な分離を担保する

6,000 社超のテナントそれぞれに専用の OpenSearch ドメインを作るのは、ドメイン単位の最低ノード費用が全テナント分積み上がるため、散発利用でコスト最小化が目標のスタンダード層には最悪の選択です。
CloudFormation StackSets でライフサイクルを管理しても、6,000 個のドメインの監視・パッチ・バージョンアップという運用負荷は消えません。
分離レベルは最高でも、要件（コストの最小化）に真っ向から反します。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
スタンダード層は 6,000 社以上・散発的な利用でコスト最小化が目標	テナントごとにリソースを分けると固定費が積み上がる。共有インデックスの Pool モデルが前提 →選択肢（E）を消す
共有しつつテナント間のデータ分離も守る	tenant_id ＋ DLS でデータストア側にフィルタを強制させる。アプリコードでの後フィルタは漏洩リスク →選択肢（B）が正解／選択肢（C）を消す
プレミアム層は他テナントの負荷に性能が左右されない厳格な分離が必須	テナント専用インデックス（Silo モデル）でシャードを分け、影響範囲を切り離す。監視だけでは分離にならない →選択肢（D）が正解／選択肢（A）を消す
プレミアム層は 18 社と少数	テナント数が少ないためインデックス数の増加が現実的な負担にならない。同じ設計をスタンダード層へ広げると破綻する →選択肢（D）が正解／選択肢（E）を消す
2 つ選ぶ（層ごとに 1 つずつ）	「スタンダード層＝コスト重視の Pool」「プレミアム層＝分離重視の Silo」と層と対策の対応が正しい組み合わせを選ぶ →選択肢（B・D）が正解

ひっかけポイント

• 選択肢 A の異常検知は「ノイジーネイバー対策」と書かれているが、実際は検知して知らせるだけ。共有インデックスのままなので分離要件は未達
• 選択肢 C はデータ分離を実装しているように読めるが、全件取得してからアプリ側でフィルタする構造。実装漏れが即クロステナント漏洩になるアンチパターン
• 選択肢 E は分離レベルだけ見れば最強だが、6,000 ドメイン分の固定費と運用が発生する。「コストの最小化」という層の目標を読み飛ばすと選んでしまう
• Pool と Silo はどちらが優れているかではなく、層ごとの要件で使い分けるもの。全テナントを一律に扱う選択肢が出てきたら、まず要件との対応を疑う

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「プレミアム層に暗号化鍵もテナント専用にしたい／規制上ハードウェア分離が必要」	インデックス単位ではなくテナント専用ドメイン（フル Silo）が正解軸に。
「スタンダード層でテナントごとの利用量を課金に反映したい」	リクエストへのテナント属性付与と使用状況メトリクスの集計が論点に。
「ベクトルストアを Amazon Bedrock ナレッジベースで構成する」	メタデータフィルタによるテナント絞り込みと、ナレッジベース分割の判断が正解軸に。
「テナント数がさらに増え、シャード数の上限やヒープ使用量が問題になってきた」	インデックスの統合や 時系列インデックス＋ロールオーバーの設計が論点に。
「特定テナントのデータだけを即座に完全削除したい（忘れられる権利）」	専用インデックスならインデックスごと削除で完結する点が Silo の利点として問われる。

関連サービスの解説

Amazon Bedrock
Amazon OpenSearch Service
AWS Lambda