大手金融サービス企業のセキュリティオペレーションセンター（SOC：Security Operations Center、セキュリティ監視・対応を専門とする組織）が、500以上のアプリケーションと15,000台のエンドポイントからのセキュリティログを集中管理するプラットフォームをAWSで運用しています。 【現在の構成】 ・ログ取り込み量：1日あたり800GB ・配信パイプライン：各サーバーのCloudWatch Logs Agent → CloudWatch Logs → AWS Lambda（ログの変換・フィールド追加などのエンリッチメント処理） → 自己管理型Elasticsearch 7.xクラスター（r5.4xlarge × 8台、us-east-1） ・ストレージ：gp2 EBSボリューム50TB（ホットデータ90日分） ・月次インフラコスト：EC2 + EBS $28,000 ＋ CloudWatch / Lambda $6,000 ＝ 計$34,000 【課題】 ・Elasticsearchクラスターのバージョンアップ・スナップショット管理・キャパシティ計画等の維持管理に、3名のSOCエンジニアの作業時間の35%が費やされている ・30日間を対象とした複雑なセキュリティ調査クエリの実行に45〜90秒かかっている（要件：10秒未満） ・90日を超えるデータの検索可能なアーカイブが存在せず、コンプライアンス上3年間のログへの検索アクセスが必要 【要件】 ・R1：自己管理型Elasticsearchの運用負荷を完全に排除する ・R2：30日間レンジのクエリ時間を10秒未満に改善する ・R3：過去3年分のログをOpenSearch上で検索可能な状態で保持する（S3エクスポートのみの非検索アーカイブは不可） ・R4：月次インフラコストを35%以上削減する ・R5：配信パイプラインの変更を最小限にとどめる（Lambdaによるエンリッチメント処理は維持すること） 最適なソリューションはどれですか？
Amazon OpenSearch Serviceへの移行でクラスター管理が不要になりR1を達成します。マネージドサービスのインデックス最適化により30日レンジクエリが10秒未満になりR2を達成します。OpenSearch Serviceのストレージ階層はホット（EBS）→ UltraWarm（S3バックエンド＋ローカルSSDキャッシュ、ホットより大幅安価）→ Cold Storage（S3デタッチ保管、UltraWarmより更に安価、アタッチ操作で検索可能）の3層構造です。Cold Storageはデータをドメイン内に保持したまま低コストで格納し、5〜30分のアタッチ操作で検索可能になるため、R3（3年間の検索可能な保持）を実現します。リザーブドインスタンス＋UltraWarm＋Cold Storageの組み合わせで35%以上のコスト削減（R4）が可能です。Lambdaパイプラインを変更しないためR5も達成します。 選択肢Bの Firehose直接配信案は Firehoseを使用するとLambdaエンリッチメント処理がバイパスされ、R5に直接違反します。また90日以降のデータをS3 Glacierに移動するとOpenSearch上での直接検索ができなくなりR3にも違反します。コンプライアンス調査でGlacierからデータを取り出すには別途復元処理が必要です。 選択肢Cの Snapshotリストア案は スナップショット取得後にインデックスを削除するとOpenSearch上での検索が不可能になります。オンデマンドの別クラスターへのリストアには数時間かかるケースがあり、コンプライアンス監査での迅速な検索要件（R3）を満たしません。Cold Storageを使えばアタッチのみで検索可能であり、別クラスターへのリストアは不要です。 選択肢Dの 別ドメインレプリケーション案は アーカイブ専用の別OpenSearch Serviceドメインの維持は運用負荷（R1）とコスト（R4）の両方を悪化させます。クロスリージョンへのインデックスレプリケーションはデータ転送費用と管理複雑性を増大させます。Cold Storageを使えば1ドメインで全要件を満たせるため、別ドメインの構成は過剰かつ非効率な解法です。