変更要約: in-scopeサービス網羅(軸B): s1にEKS/EFS、s2にAppSync/ELB/Route 53/WAF、s3にAuroraの定義・役割・選択基準を追記。
1.3Amazon DynamoDB でデータを扱う
DynamoDB のテーブルとキー（パーティションキー/ソートキー）、Query と Scan の違い、グローバルセカンダリインデックス（GSI）といった、サーバーレスアプリのデータ層の基礎を理解します。
サーバーレスアプリの定番データストアが Amazon DynamoDB です。キーバリュー型の NoSQL で、スケールしても1桁ミリ秒の低遅延を提供します。
1.3.1テーブルとキー
- パーティションキー：項目を物理的に分散させる主キー。値が偏るとホットパーティションになり性能が落ちる。
- ソートキー（任意）：同一パーティション内で項目を並べ替え、範囲クエリ（begins_with・between 等）を可能にする。
- Query：パーティションキー（＋ソートキー条件）で高速に取得。Scanはテーブル全体を読むため低速・高コスト。
- GSI（グローバルセカンダリインデックス）：主キー以外の属性で検索したいときに追加（別のキースキーマを持つ）。LSI は同一パーティションキーで別ソートキー。
DynamoDB は「アクセスパターンを先に決めてからテーブル設計する」のがリレーショナル DB との最大の違いです。検索は基本 Query（キー指定で高速・低コスト）で行い、Scan（全件走査）は遅く高コストなので多用を避けます。主キー以外で検索したくなったら GSI を追加します（後付け可能）。性能を左右するのがパーティションキーの分散——特定の値に偏るとホットパーティションになり、スループットを使い切ってスロットリングされます。キャパシティは オンデマンド（自動・予測不要）か プロビジョンド（固定＋Auto Scaling・安定負荷で安価）を選択。読み取りは既定の結果整合性（安価・わずかな遅延あり）か強整合性を選べます。さらに DynamoDB Streams で項目変更をイベント化し、Lambda と連携できます。
| やりたいこと | 手段 |
|---|---|
| キーで高速取得 | Query（Scan は避ける） |
| 主キー以外で検索 | GSI |
| 範囲検索・並べ替え | ソートキー |
| 予測しにくい負荷 | オンデマンドキャパシティ |
| 変更をイベント連携 | DynamoDB Streams（→Lambda） |
シナリオ：注文管理。 パーティションキーを customerId、ソートキーを orderDate にして「顧客の注文を新しい順に」を Query で高速取得。status で検索したい要件が出たら GSI（status をキー）を追加。Scan は避ける。アクセスが読めないので オンデマンドを選択。注文確定時の後続処理は DynamoDB Streams → Lambda で連携。customerId が一部に偏らないよう設計しホットパーティションを回避。
混同に注意：
①Query（キーで高速）と Scan（全件・低速高コスト）——Scan を多用しない。
②GSI（主キー以外で検索・別キースキーマ）と LSI（同一パーティションキー・別ソートキー）。
③パーティションキーの偏り＝ホットパーティション（スロットリングの原因）。
④読み取り整合性は結果整合性（既定・安）／強整合性。
Q. Query と Scan はどちらを使う？ 基本は Query（キー指定で高速・低コスト）。Scan はテーブル全件で遅く高コストなので極力避ける。Q. 主キー以外で検索したいときは？ GSI を追加（後付け可）。Q. ホットパーティションとは？ パーティションキーの値が偏り、特定パーティションにアクセスが集中してスロットリングされる状態。Q. 変更をトリガーにしたい？ DynamoDB Streams で Lambda を起動。
「キーで高速取得＝Query／全体走査で低速＝Scan」「主キー以外で検索＝GSI」「分散の鍵＝パーティションキー（偏るとホットパーティション）」「変更イベント＝DynamoDB Streams」 は DVA で頻出です。Scan の多用を避け、アクセスパターン起点で設計します。
（参考）Amazon Q Developer： 2024 年末の DVA-C02 改訂で、開発を支援する 生成AIアシスタント として Amazon Q Developer が範囲に加わりました。IDE 上でのコード補完・生成・説明・修正提案や、AWS リソースに関する質問への回答を行います。開発者の生産性ツールとして「AWS の AI コーディング支援＝Amazon Q Developer」を押さえましょう。
1.3.2リレーショナルが要るとき：Amazon Aurora
すべてのデータが NoSQL 向きとは限りません。結合や複雑なトランザクション、固定スキーマが必要なら、リレーショナルの Amazon Aurora を選びます。Aurora は MySQL/PostgreSQL 互換のマネージドリレーショナルデータベースで、ストレージは自動で伸縮し、最大 15 台のリードレプリカで読み取りをスケール、複数 AZ にまたがるクラスターで高可用性を確保します。可変・断続的なワークロードには需要に応じて自動で増減する Aurora Serverless も選べます。判断の勘所は「キーバリューで超低遅延・水平スケール＝DynamoDB／結合や強い整合・既存 SQL 資産＝Aurora（RDS）」という住み分けです。アプリからの接続が増減するサーバーレス構成では、接続を集約する RDS Proxy を併用してコネクション枯渇を防ぎます。
| 要件 | 選択 |
|---|---|
| 結合・複雑なトランザクション・固定スキーマ | Amazon Aurora（RDS） |
| キーバリューで超低遅延・水平スケール | Amazon DynamoDB |
| サーバーレスの接続集約 | RDS Proxy |
1.3.3この節のまとめ
- キー＝パーティションキー（分散・偏りはホットパーティション）＋ソートキー（並べ替え/範囲）
- Query は高速／Scan は低速、非キー検索はGSI、変更連携はStreams→Lambda、容量はオンデマンド/プロビジョンド
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. DynamoDB で項目を物理的に分散させる主キーはどれですか？
Q2. DynamoDB でキーを使って効率よく項目を取得する操作はどれですか？
Q3. 主キー以外の属性で DynamoDB を検索したい。何を追加しますか？