大手EC企業が、100以上のマイクロサービスが稼働する全社的なログ管理・検索基盤を新規構築しています。サービスは開発・ステージング・本番の3つのAWSアカウントに分散しており、各アカウントのCloudWatch Logsにログが保存されています。 【要件】 1. 複数AWSアカウントのログを1つの中央ログ基盤に5分以内に集約（準リアルタイム） 2. セキュリティチームは全アカウントの全ログ（アプリケーションログ・CloudTrailログ）を横断検索可能にする 3. 各開発チームは自チームのサービスログのみ参照可能にする（インデックスレベルのアクセス制御） 4. コンプライアンス要件：ログは最低1年間保持、ただし古いデータへのアクセス頻度は低い 5. OpenSearch Dashboards（旧Kibana）を使用した可視化が必須 6. ストレージコストを最小化 この要件を満たすアーキテクチャとして正しいものを2つ選択してください。
選択肢AはCloudWatch Logsサブスクリプションフィルター → Amazon Data Firehose → OpenSearchの中央集権的ログ集約のベストプラクティスで、FGAC（きめ細かいアクセス制御）によりインデックスレベルでチームごとのアクセス制御が可能（要件1〜3・5を充足）。 選択肢CはUltraWarm（S3ベースの低コストウォームストレージ）とCold Storage（S3バックアップ、さらに低コスト）への段階的移行で、1年保持要件をコスト効率的に満たす（要件4・6を充足）。 選択肢Bはアカウント数が増えるほど管理コストが増大し、中央アクセス制御が困難。 選択肢DはKinesis StreamsとAmazon Data Firehoseの二重構成は不要でCloudWatch Logs → Amazon Data Firehose直接転送で十分（複雑性のみ増加）。 選択肢EはAthenaはフルテキスト検索・リアルタイム検索が不可能でOpenSearchの代替にはならない。