ある大手製造業企業（年商1兆円超、全世界に生産拠点50か所を展開）が、オンプレミスのTeradata Vantage（25TB、10,000テーブル）をAWSのデータレイクアーキテクチャに移行します。 現在の構成： ・Teradata Vantage：25TB（圧縮後）、データ保持期間7年 ・ETLツール：IBM DataStage（200以上のジョブ） ・BIツール：SAP BusinessObjects（500ユーザー、2,000以上のレポート） ・データソース：SAP ERP、製造MES（Manufacturing Execution System：製造実行システム）、IoTセンサー（1日50GBの新規データが追加） ・BTEQスクリプト（Basic Teradata Query：Teradata固有のバッチクエリツール）・FastExport・FastLoadスクリプト4,000以上 移行後の要件： ・SAP BusinessObjectsの接続先変更は許容するが、クエリの大幅な書き換えは避けたい ・ETLジョブの自動変換ツールを活用し移行コストを削減 ・IoTセンサーデータのリアルタイム取り込みとバッチデータの統合 ・工場ごとの列・行レベルのアクセス制御（GDPR・各国プライバシー規制準拠が必須） ・直近1年分は高速クエリ対応、2〜7年分はコストを抑えたアドホッククエリ ・データカタログおよびデータ系譜（lineage）追跡が必須 制約： ・Direct Connect帯域：1Gbps（月間転送量に制限あり） ・移行期間：18ヶ月（移行中はTeradataと並行稼働） ・GDPR・個人情報保護法等への対応が必要 最もコスト効率よく要件を満たす移行戦略を2つ選択してください。
AWS Snowball Edge（選択肢B）は25TBの大容量データをネットワーク転送なしにS3へ初期ロードできるため、1Gbpsの帯域制約を回避できます。その後DMS CDCで差分を継続同期し、Redshift Spectrumでアーカイブデータ（2〜7年分）をS3から直接クエリすることでストレージコストを最適化します。Lake FormationはGDPR準拠に必要な列・行レベルのセキュリティ、データカタログ、系譜管理を一元的に提供し、Glue DataBrewがDataStageジョブの変換を支援します。 AWS Glue ETL + EMR（選択肢C）の組み合わせは、DataStageの複雑なETLジョブをSpark処理として再実装するのに適しており、S3をデータレイクとしたモダンなアーキテクチャの構築を支援します。Kinesis Data FirehoseでIoTデータをリアルタイムにS3へ収集してバッチパイプラインと統合でき、Lake FormationとGlueデータカタログがコンプライアンス要件を満たすデータガバナンスを実現します。 選択肢AのDMS直接転送は1Gbps帯域で25TBを送ると帯域制約に抵触するリスクがあります。また全データをRedshiftマネージドストレージに保持するとアクセス頻度の低いアーカイブデータにも高コストのRedshiftストレージ料金が発生し、コスト最適化要件を満たしません。 選択肢DのAthenaをSAP BusinessObjectsのバックエンドとして使用する場合、スキャンデータ量に応じた課金モデルにより500ユーザーの同時クエリ環境ではコストが予測困難になります。また、BTEQスクリプトをHiveQLに変換するよりSpark SQLへの変換が現実的です。 選択肢EのAurora PostgreSQLはOLTPデータベースであり、25TBのデータウェアハウスワークロードに対して分析クエリのパフォーマンスとスケーラビリティが不十分です。大規模なスター/スノーフレークスキーマの集計クエリでは、列指向アーキテクチャのRedshiftと比較して著しく性能が劣ります。