モダナイゼーションの重要な柱の一つが、高額なライセンス費用がかかる商用データベース（Oracle、SQL Server等）からの移行です。本記事ではその戦略的な判断を解説します。

SAA レベル：基礎概念

商用DBからの移行における基本選択肢

移行先	特徴
Aurora（MySQL/PostgreSQL互換）	リレーショナルなデータモデルを維持したまま、ライセンスコストを削減
DynamoDB	データモデル自体をNoSQLへ再設計（大きな変更を伴う）

SAA 試験のポイント

「ライセンスコストを削減したいが、既存のSQLベースのアプリケーションロジックは大きく変えたくない」という要件では、**Auroraへの移行（Replatform）**が現実的な第一の選択肢になる、という基本判断がSAAで問われます。

SAP レベル：高度な設計シナリオ

ライセンスコスト削減移行の経済的インパクト

SAP 試験のポイント

Oracle/SQL Serverのライセンス費用は、コア数やエディションに応じて高額になることが多く、AWSへの移行と同時にAuroraのようなオープンソース互換エンジンへ切り替えることで、インフラコストとライセンスコストの両方を削減する大きな経済的インパクトが得られます。SAPでは、この移行のビジネスケース（TCO削減効果）を説明できることが問われます。ただし、Oracle固有の機能（PL/SQLの複雑なストアドプロシージャ等）に強く依存している場合、SCT（2-3で解説）での変換に相応の工数がかかる点も踏まえた判断が必要です。

データモデル変換（RDBからNoSQLへ）の設計判断

SAP 試験のポイント

DynamoDBへの移行は、単なるエンジンの入れ替えではなく、アクセスパターン起点でのデータモデル再設計が必要です。リレーショナルモデルの正規化されたテーブル設計とは異なり、DynamoDBでは「どのようなクエリが必要か」を先に定義し、それに最適化された非正規化テーブル設計（単一テーブル設計等）を行います。SAPレベルでは、JOINを多用する複雑なレポーティング用途にはDynamoDBは不向きであり、Auroraに残すか、別途Redshift/Athenaでの分析基盤を用意する、という使い分けの判断が問われます。

観点	RDB（Aurora等）に適する	DynamoDBに適する
クエリパターン	複雑なJOIN、アドホックな分析クエリ	事前定義されたキーによる高速アクセス
スキーマの柔軟性	スキーマ変更にコストがかかる	スキーマレス、柔軟な項目追加
スケール要件	垂直スケールが基本（Auroraは自動拡張あり）	ほぼ無制限の水平スケール

設計上の落とし穴

「NoSQLの方が新しくスケーラブルだから、すべてDynamoDBに移行すべき」という技術トレンド優先の判断は、SAP試験では誤りになりがちです。既存のアプリケーションが複雑なリレーショナルクエリに強く依存している場合、DynamoDBへの移行はアプリケーション全体の大規模な書き換えを要求し、移行リスクと工数が著しく増大します。データアクセスパターンの実態に基づいた判断が常に優先されるべきという点が問われます。

段階的な移行アプローチ

まずAuroraへ移行してライセンスコストを削減し（低リスク）、その後アクセスパターンを分析した上で、真にDynamoDBのメリットが活きる特定の機能（セッション管理、リアルタイムランキング等）だけを個別にDynamoDBへ移行する、というハイブリッドかつ段階的なアプローチが実務的である

まとめ

SAA: 商用DBからの移行における基本的な選択肢（Aurora vs DynamoDB）を理解する。
SAP: ライセンスコスト削減の経済的インパクト評価、アクセスパターンに基づくデータモデル変換の判断、段階的なハイブリッド移行アプローチができる。

ここまでで 4-3 モダナイゼーション戦略 の全4記事が完了しました。次は 4-4 移行時のネットワーク・セキュリティ考慮 に進みます。