データの関係と、 読み書きの設計

リレーショナルデータベースは、行と列からなるテーブルでデータを管理します。主キーで行を識別し、外部キーで別テーブルの行を参照します。注文に利用者の名前を毎回コピーせず、IDで関連付けられます。

SQLでは、条件で絞り、テーブルを結合し、集計できます。例の注文を利用者名・商品名と合わせて取り出すなら、OrdersのUserID・ProductIDを使ってUsers・ProductsとJOINします。正しく関連付けたモデルが、取り出したい情報を支えます。

Amazon RDSは、複数のリレーショナルDBエンジンを選べるマネージドサービスです。AuroraはMySQL／PostgreSQL互換で、計算とストレージを分離したAWSのDB基盤です。標準的なAuroraクラスターでは、複数AZにデータを保ち、読み取りレプリカを配置できます。

RDSやAuroraでも、データへの権限やバックアップの保持期間を利用者が設定します。マネージドであることは、アプリケーション設計や復旧確認が不要になるという意味ではありません。

Amazon DynamoDBは、キー・バリューとドキュメントを扱うマネージドNoSQLデータベースです。テーブルの中に項目（Item）を保存し、属性（Attribute）を持たせます。主キーに必要な属性以外は、項目ごとに異なる属性を持てます。

コンソール・CLI・SDKなどからAPIを使って操作できます。SQL互換のPartiQLも利用できますが、リレーショナルDBと同じ機能がすべて使えるわけではありません。

1. 配置と通信を用意する

   DBサブネットやSGを設定します。MySQLの標準ポートは3306。アプリのSGから必要なDBポートへの接続だけを許可する、などの範囲を決めます。

2. 接続と認証を設定する

   RDSのエンドポイント、ポート、DB名、認証情報をアプリに渡します。ネットワークの許可と、DBのユーザー権限は別です。認証情報はソースコードへ直接埋め込まないようにします。

3. テーブルと操作を用意する

   リレーショナルDBでは主キー・外部キー・型を定義し、SQLを実行します。DynamoDBではテーブルのキーを定義し、項目を保存して取得します。操作方法の違いを確認します。

Amazon ElastiCacheは、Valkey・Redis OSS・Memcachedなどのインメモリ基盤を提供します。データをメモリから素早く読み、DBの繰り返し読み取りを減らす用途などに使います。

DynamoDB Accelerator（DAX）は、DynamoDBの読み取りを高速化するためのキャッシュです。ElastiCacheの汎用的な利用とは対象が異なります。キャッシュできる読み取りや整合性の条件も確認します。

専用DBは、名前の暗記より「何を検索・更新するか」を先に考えます。DocumentDBはMongoDB互換ですが、使用するバージョンや機能の互換性を確認します。DynamoDBもドキュメント型の属性を扱うため、保存形式だけでサービスが1つに決まるわけではありません。

AWS Backupでは、対応するAWSリソースや一部のオンプレミス環境の保存をまとめて管理できます。対象・スケジュール・保持期間・保存先を設定します。対象外のリソースまで自動保護されるとは考えません。

• リレーショナルDBは、テーブルとキーで関係を管理しSQLで検索する。
• RDS・Auroraは運用をAWSに任せる範囲を増やす。データ・権限・設定の責任は残る。
• DynamoDBはキーとアクセスパターンから設計する。ScanとQueryは異なる。
• キャッシュは高速化、バックアップは復旧。原本・複製・保存時点を分けて考える。

元データ：scripts/module7.txt。提供されたトランスクリプトを意味のまとまりで再構成し、誤解しやすい箇所を以下のAWS公式資料で確認しました（2026年10月6日）。実際の操作・仕様・料金は最新版を確認してください。

• RDSの基本
• Auroraの概要
• Aurora DSQL
• DynamoDB Query
• PartiQL
• ElastiCache
• DAX
• DMSによる移行
• DocumentDBの互換性
• AWS Backup