SAA向けにRDSとDynamoDBの選び方を整理する

SAAでは、要件に合ったデータベースを選ぶ問題が出題されます。AWS公式の試験ガイドでも「高性能なアーキテクチャの設計」の中にデータストアの選定が含まれており、RDSとDynamoDBの対比は基礎になります。

結論

リレーショナルデータ、SQL、複雑な結合、既存DB移行が重要ならRDS。スケーラブルなKey-Valueアクセス、サーバーレス、低運用負荷が重要ならDynamoDBを検討します。

判断の順序は「アクセスパターンが事前に決まっているか」です。決まっているならDynamoDBで設計でき、決まっていない・後から自由に問い合わせたいならRDSが安全です。

アクセスパターン別の選定基準

要件の書かれ方から選択肢を絞る対応表です。

RDSが向いているケース

RDSはリレーショナルデータベースのマネージドサービスです。MySQL、PostgreSQL、MariaDB、Oracle、SQL Server などのエンジンを選べます。

注文、顧客、商品、請求のようにテーブル間の関係が重要な業務システムではRDSが向きます。SQLで集計や結合を行いたい場合もRDSが自然です。

Multi-AZ と リードレプリカの違い

SAAで頻繁に対比されるのがこの2つです。目的が違うため、置き換え可能ではありません。

「読み取り負荷が高い」ならリードレプリカ、「AZ障害でも止めたくない」なら Multi-AZ、「災害対策で別リージョンに複製したい」ならクロスリージョンのリードレプリカ、という対応です。両方必要なら両方を構成します。

Lambda から RDS に繋ぐときの注意

Lambda は実行のたびに新しい実行環境が作られることがあり、同時実行数がそのまま接続数として押し寄せる可能性があります。RDS は接続数に上限があるため、この組み合わせは接続枯渇を招きやすい構成です。

対策として Amazon RDS Proxy を挟み、接続をプールして再利用する構成が取られます。「Lambda + RDS で接続エラーが多発する」という問題文が出たら、RDS Proxy が選択肢になります。

DynamoDBが向いているケース

DynamoDBはNoSQLのマネージドデータベースです。キーを使った高速な読み書き、大量アクセス、サーバーレス構成と相性が良いサービスです。

このサイトでは、問い合わせデータをContactsTableに保存します。複雑な結合は不要で、LambdaからPutItemできればよいため、DynamoDBが合っています。

押さえておくべき制限値

400 KB の上限があるため、画像やPDFのような大きなデータは DynamoDB に直接入れません。実体を S3 に置き、そのオブジェクトキーを DynamoDB に保存する構成が定石です。

GSI と LSI の違い

「後から新しい検索軸が必要になった」場合、LSI は作れません。この非対称性が、DynamoDB で「先にアクセスパターンを決める」必要がある理由の1つです。

Query と Scan

Query はパーティションキーを指定して該当範囲だけを読みます。Scan はテーブル全体を読みます。

重要なのは、Scan にフィルター式を付けても、読み取ったアイテム分のキャパシティは消費されるという点です。フィルターは読んだ後に絞り込むだけで、読む量は減りません。「Scan を使ったらコストが跳ね上がった」という事象はこの仕様から説明できます。

キャパシティモードと料金

DynamoDB には2つのキャパシティモードがあります。

キャパシティユニットの定義は次の通りです。

• 1 WCU: 最大 1 KB のアイテムを 1 秒あたり 1 回書き込む
• 1 RCU: 最大 4 KB のアイテムを 1 秒あたり 1 回、強い整合性で読み取る
• 結果整合性のある読み取りは、同じ 4 KB あたり 0.5 RCU で済む

料金の計算例

前提: 東京リージョン（ap-northeast-1）、オンデマンドモード、2026年8月時点の公開単価。1アイテムは 1 KB 未満。月間の書き込み 100,000 件、結果整合性のある読み取り 500,000 件。

読み取りが 250,000 RRU なのは、結果整合性の読み取りが 1 件あたり 0.5 RRU で済むためです。ここを強い整合性にすると倍の 500,000 RRU になります。整合性のレベルが、そのままコストの倍率になります。

ストレージは別途、25 GB を超えた分に対して 1 GB あたり月 0.285 USD が発生します。単価は改定されるため、実際の見積もりではAWS公式の料金ページで確認してください。

コスト観点でのRDSとの違い

個人開発MVPでは、RDSは固定費になりやすいため慎重に扱います。RDS の課金はインスタンスの稼働時間、割り当てたストレージ容量、バックアップ保存量の組み合わせで、アクセスがゼロでもインスタンスが起動している限り課金が続きます。

DynamoDB はオンデマンドキャパシティを使うと、リクエストが無ければ課金対象もほぼストレージだけになります。小規模・低頻度アクセスでは始めやすい構成です。

ただし、DynamoDBでもScan多用や大量書き込みはコスト増につながります。アクセスパターンを決めてからキー設計をします。

SAAで問われるポイント

• SQLや複雑なリレーションが必要ならRDS
• サーバーレスでスケールするNoSQLならDynamoDB
• RDS Multi-AZは高可用性、リードレプリカは読み取り分散
• Lambda から RDS への大量接続には RDS Proxy
• DynamoDB はパーティションキー設計が重要で、Scan の多用はコストと性能の両方に影響する
• 400 KB を超えるデータは S3 に置き、キーだけを DynamoDB に持つ

実務での注意点

DynamoDBは「とりあえず入れるDB」ではありません。検索条件や取得パターンが曖昧なまま作ると、後でScanだらけになります。

RDSは柔軟ですが、バックアップ、パッチ、スケール、コストを考える必要があります。個人ポートフォリオでは、要件に対して過剰構成になっていないか確認します。

どちらを選んだ場合も、選んだ理由を「このアクセスパターンだから」と説明できる状態にしておくことが、設計として一番重要です。

関連用語

• Amazon RDS
• Amazon DynamoDB
• AWS Lambda

次に読む記事

• RDS・DynamoDBの違い
• API Gateway + Lambda + DynamoDB サーバーレスAPI構成