ある医療系企業は、複数の病院グループが参加するデータレイクを Amazon S3 と AWS Glue Data Catalog で構築しています。患者レコードを格納する単一の Glue テーブルがあり、各病院の分析担当者は自病院の患者データのみ参照できる必要があります。以下の制約があります。 ・S3 のバケットやプレフィックスを病院ごとに分割することは禁止（データレイクの構造を変更しない） ・Glue テーブルは1つのまま維持する ・分析担当者は Amazon Athena でクエリを実行する この要件を最小の運用オーバーヘッドで実現するにはどのアプローチが最適ですか？
AWS Lake Formation のデータフィルター（行レベルセキュリティ）機能を使用すると、単一の Glue テーブルに対してフィルター条件を定義し、特定の IAM プリンシパルやグループが参照できる行を制限できます。 データフィルターの仕組みは以下の通りです。 ①AWS Glue Data Catalog のテーブルに対してデータフィルターを作成（例：hospital_id = 'A'） ②各病院グループの IAM ロールまたは Lake Formation タグにフィルターを付与 ③Athena でクエリを実行すると、Lake Formation が自動的にフィルター条件を適用して対象行のみ返す これにより S3 の構造を変更せず、単一テーブルを維持したまま細粒度のアクセス制御が実現でき、運用負荷も最小化されます。 選択肢Bの IAM ポリシーと Athena ワークグループのアプローチは、WHERE 句の自動強制はワークグループ設定ではサポートされておらず、ユーザーが WHERE 句を省略した場合にデータ全体にアクセスできてしまう恐れがある。 選択肢Cの AWS Glue ETL ジョブによる別テーブル生成は、テーブルを1つに維持するという要件に反し、かつ日次バッチ完了まで最新データを参照できない。 選択肢Dの Amazon Macie は PII データの検出・分類ツールであり、行レベルのアクセス制御機能は持たない。S3 Select はオブジェクト単位のクエリ最適化であり、アクセス制御の仕組みではない。