▪️はじめに
AWSでシステムを構築すると、ユーザー情報や注文情報、アプリケーションの状態など、さまざまなデータを保存する必要があります。
AWSのデータベースサービスとして有名なのがAmazon RDSですが、AWSにはほかにもデータを保存するためのサービスがあります。
そのひとつが、Amazon DynamoDBです。
DynamoDBは、AWSが提供するフルマネージド型のNoSQLデータベースサービスです。サーバーの管理をAWSに任せながら、データの読み書きを行えます。
この記事では、AWS初心者向けに以下の内容を解説します。
- DynamoDBとは何か
- RDSとDynamoDBの違い
- NoSQLデータベースの仕組み
- テーブル・項目・属性とは何か
- パーティションキーとソートキー
- DynamoDBの読み書き
- LambdaなどのAWSサービスとの連携
- DynamoDBを利用するときの注意点
それでは、順番に見ていきましょう。
目次
- DynamoDBとは？
- NoSQLデータベースとは？
- RDSとDynamoDBの違い
- DynamoDBの基本構造
- パーティションキーとソートキー
- DynamoDBのデータ操作
- DynamoDBとLambdaの連携
- DynamoDBのキャパシティモード
- DynamoDBのセキュリティとバックアップ
- DynamoDBを利用するときの注意点
- まとめ
▪️DynamoDBとは？
DynamoDBは、AWSが提供するNoSQLデータベースサービスです。
データの保存や読み書きに必要なデータベース基盤をAWSが管理するため、利用者がデータベースサーバーの構築やOSのパッチ適用などを行う必要はありません。
例えば、Webアプリケーションでユーザー情報を管理する場合、DynamoDBにユーザーIDやユーザー名などの情報を保存できます。
アプリケーション
|
| データの読み書き
v
DynamoDB
|
v
ユーザー情報・注文情報など
DynamoDBの主な特徴は、以下のとおりです。
- フルマネージド型のデータベースサービス
- NoSQLによるデータ管理
- 大量のリクエストに対応できる拡張性
- オンデマンドまたはプロビジョンドによるキャパシティ管理
- AWSのほかのサービスとの連携
例えば、アクセス数が変動するWebアプリケーションや、ユーザーごとの設定情報を管理するシステムなどで利用できます。
ただし、DynamoDBがあらゆるデータベース用途に適しているわけではありません。データの構造や検索方法、整合性の要件などを考慮して選択する必要があります。
▪️NoSQLデータベースとは？
DynamoDBを理解するうえで重要なのが、NoSQLという考え方です。
データベースにはさまざまな種類がありますが、代表的なものとしてリレーショナルデータベースとNoSQLデータベースがあります。
♦︎リレーショナルデータベース
リレーショナルデータベースは、データをテーブルとして管理し、テーブル間の関係を扱えるデータベースです。
例えば、ユーザー情報を次のように管理できます。
| ユーザーID | ユーザー名 | 年齢 |
|---|---|---|
| 001 | 田中 | 25 |
| 002 | 佐藤 | 30 |
| 003 | 鈴木 | 22 |
このように、行と列を使ってデータを整理します。
AWSでは、Amazon RDSやAmazon Auroraが代表的なリレーショナルデータベースのサービスです。
♦︎NoSQLデータベース
NoSQLは、リレーショナルデータベースとは異なるデータモデルを採用するデータベースの総称です。
DynamoDBは、その中でも主にキー・バリュー型とドキュメント型のデータを扱えます。
例えば、ユーザー情報を次のように保存できます。
{
"UserId": "001",
"UserName": "田中",
"Age": 25,
"Address": {
"Prefecture": "東京都",
"City": "八王子市"
}
}
このように、ひとつの項目に複数の属性や、入れ子になったデータを持たせることもできます。
DynamoDBでは、キーとなる属性を定義し、それを利用してデータを取得します。キー以外の属性は、項目ごとに異なる構成にすることも可能です。
つまり、RDSのように決まった列を持つテーブルだけで考えるのではなく、アクセス方法に合わせてデータを設計することが重要になります。
▪️RDSとDynamoDBの違い
AWSのデータベースを学ぶとき、RDSとDynamoDBの違いを理解しておくと、使い分けがしやすくなります。
| 比較項目 | Amazon RDS | Amazon DynamoDB |
|---|---|---|
| データモデル | リレーショナル | NoSQL |
| データの管理 | テーブル・行・列 | テーブル・項目・属性 |
| 主な操作 | SQL | DynamoDB APIなど |
| データの関連付け | JOINなどを利用可能 | RDSのような一般的なJOINはない |
| スケーリング | エンジンや構成に応じて設計 | マネージドな拡張機能を利用 |
| 運用管理 | AWSが多くの管理作業を担う | AWSがデータベース基盤を管理 |
| 向いている用途の例 | 複雑なSQLや関連データの処理 | キーを使った高速な読み書き、大規模なリクエスト処理 |
例えば、複数のテーブルを結合して複雑な条件で検索したい場合は、RDSが適していることがあります。
一方、ユーザーIDなどのキーを使ってデータを頻繁に取得するシステムでは、DynamoDBが有力な選択肢になります。
ただし、どちらが優れているという話ではありません。
システムでどのようにデータを読み書きするのかを考えたうえで、適切なデータベースを選ぶことが重要です。
▪️DynamoDBの基本構造
DynamoDBでは、主に以下の要素を使ってデータを管理します。
- テーブル（Table）
- 項目（Item）
- 属性（Attribute）
それぞれの役割を確認しましょう。
♦︎テーブル（Table）
テーブルは、関連するデータをまとめて管理する単位です。
例えば、ユーザー情報を保存する場合は、Usersというテーブルを作成できます。
DynamoDB
|
└── Usersテーブル
♦︎項目（Item）
項目は、テーブルに保存するひとつひとつのデータです。
例えば、Usersテーブルに3人のユーザーを登録すると、3つの項目が存在します。
| UserId | UserName | Age |
|---|---|---|
| 001 | 田中 | 25 |
| 002 | 佐藤 | 30 |
| 003 | 鈴木 | 22 |
この場合、それぞれの行がひとつの項目に相当します。
♦︎属性（Attribute）
属性は、項目が持つ個々のデータです。
例えば、UserId、UserName、Ageなどが属性に該当します。
Usersテーブル
|
├── 項目1
| ├── UserId
| ├── UserName
| └── Age
|
├── 項目2
| ├── UserId
| ├── UserName
| └── Age
|
└── 項目3
├── UserId
├── UserName
└── Age
なお、DynamoDBでは、キー以外の属性をすべての項目で統一する必要はありません。ある項目にはAgeがあり、別の項目にはAddressがある、といった設計も可能です。
このように、DynamoDBは柔軟なデータ構造を扱えることが特徴です。
▪️パーティションキーとソートキー
DynamoDBで特に重要なのが、パーティションキーとソートキーです。
テーブルを作成するときには、データを一意に識別するための主キーを定義します。
DynamoDBでは、主に次の2種類があります。
♦︎パーティションキーのみ
パーティションキーだけを主キーにする方式です。
例えば、ユーザー情報を管理するテーブルを考えてみましょう。
| UserId | UserName |
|---|---|
| 001 | 田中 |
| 002 | 佐藤 |
| 003 | 鈴木 |
この場合、UserIdがパーティションキーです。
UserIdが001のデータを取得したい場合、キーを指定して対象の項目を取得できます。
パーティションキーだけを主キーとする場合、同じキーの値を持つ項目を複数登録することはできません。
♦︎パーティションキーとソートキー
もうひとつが、パーティションキーとソートキーを組み合わせる方式です。
例えば、ユーザーごとの注文履歴を管理する場合を考えます。
| UserId | OrderDate | OrderAmount |
|---|---|---|
| 001 | 2026-01-10 | 3000 |
| 001 | 2026-01-15 | 5000 |
| 002 | 2026-01-12 | 2000 |
この例では、次のように設定できます。
- パーティションキー：UserId
- ソートキー：OrderDate
パーティションキーが同じでも、ソートキーが異なれば複数の項目を保存できます。
例えば、UserIdが001の注文履歴を取得したり、特定のユーザーの注文履歴を日付の範囲で検索したりできます。
UserId = 001
|
├── 2026-01-10
└── 2026-01-15
このように、パーティションキーとソートキーを組み合わせることで、データの取得方法に合わせた設計ができます。
なお、パーティションキーは内部的にデータの分散配置にも利用されます。そのため、偏ったアクセスが集中しにくいキーを選ぶことも重要です。
DynamoDBでは、テーブルを作ってから検索方法を自由に考えるのではなく、どのようなキーでデータを取得するのかを先に考えることが大切です。
▪️DynamoDBのデータ操作
DynamoDBでは、データの登録・取得・更新・削除などを行えます。
代表的な操作を見てみましょう。
| 操作 | APIの例 | 内容 |
|---|---|---|
| 登録・置き換え | PutItem | 項目を書き込む |
| 取得 | GetItem | 主キーを指定して項目を取得する |
| 更新 | UpdateItem | 項目の属性を更新する |
| 削除 | DeleteItem | 主キーを指定して項目を削除する |
| 条件に合う項目の検索 | Query | パーティションキーなどを指定して検索する |
| テーブル内の広範な検索 | Scan | テーブル内の項目を走査する |
例えば、UserIdが001のユーザー情報を取得したい場合、GetItemを利用できます。
アプリケーション
|
| UserId = 001
v
DynamoDB
|
v
UserId = 001 の項目
一方、特定のユーザーに紐づく注文履歴を取得したい場合は、パーティションキーを指定してQueryを利用する方法があります。
Scanはテーブル内の項目を走査するため、データ量が大きいテーブルで頻繁に利用すると、処理量やコストが大きくなる可能性があります。
そのため、DynamoDBでは、キーやインデックスを活用して、必要なデータを効率よく取得する設計が重要です。
▪️DynamoDBとLambdaの連携
DynamoDBは、AWS Lambdaなどのサーバーレスサービスと組み合わせて利用できます。
例えば、ユーザーがWebアプリケーションでデータを登録したときに、Lambdaで処理を実行し、DynamoDBに保存する構成を考えてみましょう。
ユーザー
|
v
API Gateway
|
v
Lambda
|
v
DynamoDB
この構成では、それぞれのサービスが異なる役割を担います。
- API Gateway：HTTP APIへのリクエストを受け付ける
- Lambda：リクエストに応じてアプリケーション処理を実行する
- DynamoDB：データを保存・取得する
例えば、ユーザー登録APIであれば、Lambdaが入力内容を確認し、DynamoDBにユーザー情報を書き込みます。
また、LambdaにDynamoDBの更新をトリガーとする処理を設定することもできます。DynamoDB StreamsとLambdaを組み合わせれば、テーブルの変更をもとに後続処理を実行する構成も可能です。
このようにDynamoDBは、サーバーレスアーキテクチャを構成するデータベースとしても活用できます。
ただし、LambdaからDynamoDBを操作するには、Lambdaの実行ロールに必要なIAM権限を設定する必要があります。
▪️DynamoDBのキャパシティモード
DynamoDBでは、読み込みや書き込みの処理量に応じて、キャパシティモードを選択できます。
代表的な方式は次の2つです。
♦︎オンデマンドモード
オンデマンドモードでは、読み込みや書き込みのリクエスト量に応じて料金が発生します。
利用者が事前に読み書きのキャパシティを細かく設定する必要がないため、アクセス量の予測が難しい場合などに適しています。
リクエスト量に応じて処理
|
v
DynamoDB
例えば、アクセス数が時間帯によって大きく変化するアプリケーションなどで利用できます。
♦︎プロビジョンドモード
プロビジョンドモードでは、読み込みと書き込みのキャパシティを事前に設定します。
必要な処理量を予測できる場合には、キャパシティを計画的に管理できます。
また、Auto Scalingを利用して、設定した範囲内でキャパシティを自動調整する構成も可能です。
♦︎どちらを選ぶべきか？
| モード | 向いているケース |
|---|---|
| オンデマンド | 利用量が予測しにくい、容量管理を簡単にしたい |
| プロビジョンド | 利用量が比較的安定している、キャパシティを計画的に管理したい |
どちらが適しているかは、アクセスパターンやコスト、性能要件によって変わります。
なお、オンデマンドモードでも料金が無制限に抑えられるわけではありません。利用量に応じて請求されるため、コストを監視することが重要です。
▪️DynamoDBのセキュリティとバックアップ
データベースを利用する場合、データを安全に保護し、障害や誤操作に備えることも重要です。
♦︎IAMによるアクセス制御
DynamoDBでは、IAMポリシーを利用して、誰がテーブルを読み書きできるかを制御できます。
例えば、LambdaからDynamoDBを操作する場合、Lambdaの実行ロールに必要な権限を付与します。
Lambdaの実行ロール
|
| 必要な操作を許可
v
DynamoDB
アプリケーションに不要なテーブルまで操作できる権限を与えないよう、最小権限の原則に従って設計することが大切です。
♦︎保存データの暗号化
DynamoDBでは、保存データの暗号化が標準で提供されています。
AWS所有キーやAWS管理キー、カスタマーマネージドキーなど、要件に応じた暗号化キーを利用できます。
カスタマーマネージドキーを利用する場合は、KMSキーの権限や利用できない状態になったときの影響なども考慮する必要があります。
♦︎バックアップ
DynamoDBでは、主に次のバックアップ機能を利用できます。
- オンデマンドバックアップ：必要なタイミングでバックアップを作成する
- ポイントインタイムリカバリ（PITR）：有効化しておくことで、設定可能な保持期間内の過去の時点にテーブルを復元できる
PITRは、誤操作やデータ破損などに備える際に役立ちます。
ただし、バックアップを利用できるようにするだけでなく、実際に復元できることを確認しておくことも重要です。
▪️DynamoDBを利用するときの注意点
DynamoDBを利用する際には、いくつか押さえておきたいポイントがあります。
① データの取得方法から設計する
DynamoDBでは、どのようなキーでデータを取得するのかが重要です。
テーブルを作成する前に、アプリケーションが必要とする検索パターンを整理しましょう。
② パーティションキーを適切に選ぶ
特定のキーにアクセスが集中すると、処理が偏る可能性があります。
アクセスを適切に分散できるキーを検討することが大切です。
③ Scanを多用しない
Scanはテーブル内の項目を走査するため、大規模なテーブルでは処理量が増えることがあります。
必要なデータを効率よく取得できるよう、Queryやインデックスなどを検討しましょう。
④ コストを監視する
DynamoDBでは、読み込み、書き込み、データ保存、バックアップなどの利用状況に応じて料金が発生します。
キャパシティモードやデータ取得方法を適切に設計し、利用状況を確認することが重要です。
⑤ RDSとの使い分けを考える
DynamoDBは便利なサービスですが、複雑なSQLやリレーショナルなデータ処理が必要な場合には、RDSなどのほうが適していることもあります。
サービスの特徴だけで判断するのではなく、システム要件に合わせて選択しましょう。
▪️まとめ
今回はAmazon DynamoDBについて解説しました。
DynamoDBを一言で表すと、
「AWSが提供する、キーを利用してデータを管理するフルマネージド型のNoSQLデータベース」
です。
重要なポイントを整理すると、以下のようになります。
- DynamoDBはNoSQLデータベースサービス
- テーブル・項目・属性を使ってデータを管理する
- パーティションキーとソートキーがデータ設計の重要な要素
- GetItemやQueryなどを利用してデータを取得する
- LambdaやAPI Gatewayと連携できる
- オンデマンドとプロビジョンドのキャパシティモードがある
- IAMによるアクセス制御、暗号化、バックアップも重要
特に重要なのは、DynamoDBでは、データをどのように取得するかを考えてから設計することです。
RDSのようにSQLを使ってさまざまな条件で検索する考え方とは異なり、DynamoDBではパーティションキーやソートキー、インデックスなどを活用して、必要なデータを効率よく取得できるように設計します。
AWSを学ぶ際には、DynamoDB単体の機能だけでなく、LambdaやAPI Gatewayなどと組み合わせたシステム全体の構成も理解していきましょう。
次は、イベントに応じてコードを実行できるAWS Lambdaについて学ぶと、DynamoDBとサーバーレスアーキテクチャのつながりがさらに理解しやすくなります。
＊「AWS Lambda」の記事はこちら
→「https://lovelabengineer.com/2026/10/09/aws-lambdaとは？サーバーレスでプログラムを実行する仕/」
No responses yet