S3 も EC2 も RDS も DynamoDB も、名前と役割は言える。それでも「画像をアップロードできるようにしたい」「社内で共有するファイルを置きたい」と言われると、どれに置くか迷う。特徴を覚えているだけで、要件から置き場を選ぶ順番がないと「とりあえず RDS」「とりあえず S3」になりがちです。この記事は、その順番を作ります。
この記事の結論
- 置き場の選択は、サービス名ではなく「データをどう読み書きするか」を先に書き出すことから始めます。
- まず形で絞ります。OS が使うディスクは EBS、複数台で共有するファイルは EFS、URL やキーで出し入れする塊は S3、行と表で検索・結合するなら RDS、キーで引くなら DynamoDB です。
- 迷ったら「検索条件が後から増えるか」を見ます。増えるなら RDS、アクセスパターンが固定のキー引きなら DynamoDB が候補です。
- 1つに決め切らなくてよく、ファイル本体は S3、一覧用の情報は DB のように用途別に分けるのが基本です。
- 可用性・耐久性・バックアップの要件は、選んだ後ではなく選ぶ軸に入れます。
データの置き場は、なぜサービス名からではなく「読み書きの形」から選ぶのか
「S3 は安くて丈夫」「RDS は何でもできる」のように、サービスごとの特徴で覚えると、要件が来たときに「どれが一番良いか」を探してしまいます。でも置き場に一番良いものはなく、データの使い方に合うものがあるだけです。
AWS の Well-Architected フレームワーク（パフォーマンス効率の柱）も、最適なデータ管理は固定の答えではなく、データの種類（ブロック・ファイル・オブジェクト）、アクセスパターン、スループット、アクセス頻度、更新頻度、可用性・耐久性の制約によって変わる、という考え方を取っています。つまり、先に書き出すべきなのは「サービス名」ではなく「そのデータがどう読まれ、どう書かれるか」です。
書き出すときの問いは、次のくらいで足ります。
- 読むのは人か、プログラムか。1件ずつか、まとめてか
- 書き換えるのか、一度置いたら変えないのか
- 複数のサーバーから同時に触るのか
- 後から検索条件が増えそうか
サービスの個別の特徴は、この問いの答えに合うものを選ぶための材料にします。
CHECK 1ここまでの確認
置き場を選ぶ前に、最初に書き出すべきものはどれ?
答えと解説
答え: 2. データをどう読み書きするか（誰が・どんな単位で・どれくらい）
サービス名から入ると、要件に合わない置き場を選びやすくなります。「読み書きの形」から入る理由は最初の章を読み直してください。
置き場を決める5つの軸は何か
読み書きの形を整理するために、5つの軸を使います。
| 軸 | 問い | 例 |
|---|---|---|
| データの種類 | OS が見るディスクか、ファイルか、オブジェクトか、表か | 起動ディスク、共有フォルダ、画像、注文 |
| アクセスパターン | どう読み書きするか。キーで引くか、条件で探すか | 会話 ID で引く、期間と顧客で絞る |
| 共有 | 複数のサーバーから同時に触るか | 全サーバーで同じ設定ファイルを読む |
| 規模と増え方 | どれくらい、どんな速さで増えるか | 画像は増え続ける、マスタはあまり増えない |
| 止められない度合い | どれだけ止められず、どれだけ失えないか | 注文は失えない、一時ファイルは作り直せる |
最後の軸は、選んだ後に付け足すものではなく、選ぶときの条件です。たとえば複数の AZ にまたがって使いたいのか、1つの AZ に収まればよいのかで、候補は変わります。
最初の3つ（種類・アクセスパターン・共有）で候補が1〜2個に絞れることが多く、残りの2つで決め手をつけるイメージです。
ブロック・ファイル・オブジェクトの置き場（EBS・EFS・S3）はどう選び分けるのか
この3つは、データの種類で分けて考えます。
WHERE TO PUT DATA問いで置き場が分かれる
置き場はデータの形への4つの問いで絞れる
-
OS が使うディスクか
はい → EBS
-
複数台で共有するファイルか
はい → EFS
-
URL・キーで出し入れする塊か
はい → S3
-
行と表で扱うか
はい → RDS / DynamoDB
EBS：OS が使うディスク
EBS は EC2 のための永続的なブロックストレージで、つないだサーバーからは普通のディスクとして見えます。OS やデータベースのファイルなど、ディスクとして使うものに向きます。1つの AZ の中で複製される前提のため、AZ をまたいで使いたいときは別の手立てが要ります。バックアップはスナップショットで取ります。
EFS：複数台で共有するファイル
EFS は Linux 向けの共有ファイルシステムで、複数の EC2 から同時にマウントして使えます。複数の AZ にまたがって使える作りです。「全サーバーで同じファイルを見たい」という要件が出たら、候補は EFS です。
S3：URL やキーで出し入れする塊
S3 はオブジェクトストレージで、ファイルをキーで出し入れします。OS のディスクとして使うものではなく、画像・動画・ログ・バックアップのような「塊」を置く場所です。アクセスの頻度に応じて、ストレージクラスを選んでコストを調整できます。たとえば、ほとんど取り出さない長期保管は、取り出しが遅くなる代わりに安く置けるクラスが向きます。
間違えて消した・上書きしたときに戻したいなら、S3 ではバージョニングという機能で複数のバージョンを残せます。置き場ごとに保護の手段が違う点も、選ぶ前に確認しておくとよい点です。
| 置き場 | データの形 | 共有 | 保護の手段の例 |
|---|---|---|---|
| EBS | ブロック（ディスク） | 基本は1台のインスタンス | スナップショット |
| EFS | ファイル | 複数台で共有 | AWS Backup など |
| S3 | オブジェクト | URL・キーで誰からでも | バージョニング、ストレージクラスの設計 |
CHECK 2ここまでの確認
複数のサーバーから同じファイルを同時に読み書きしたいとき、まず候補になるのはどれ?
答えと解説
答え: 2. EFS
EFS は複数のサーバーから共有できるファイルの置き場です。EBS は基本的に1台のインスタンスにつなぐディスクです。ブロック・ファイル・オブジェクトの章を読み直してください。
表のデータベースは RDS と DynamoDB のどちらを選ぶのか
表の形のデータは、RDS か DynamoDB が候補です。分かれ目は「検索条件の自由度」です。
RDS VS DYNAMODB表のデータベースの分かれ目
探し方が変わるなら RDS、キーで引くなら DynamoDB
RDS
リレーショナル
- 条件検索・結合が得意
- 検索条件が後から増えても対応しやすい
- 表の設計から始める
DynamoDB
キーで引く NoSQL
- キーでの読み書きが得意
- アクセスの形が決まっている場面に合う
- アクセスパターンから設計を始める
RDS：行と表で、条件を変えながら探す
RDS はリレーショナルデータベースを AWS が管理するサービスで、パッチやバックアップなどの運用を任せられます（どこまで任せられるかは rds-toha で扱います）。複数の表を結合したり、条件を変えて検索したりするのが得意なので、「後から集計の切り口が増えそう」「画面ごとに検索条件が違う」業務データに向きます。
DynamoDB：キーで引く
DynamoDB はキーで項目を読み書きする NoSQL で、サーバーの管理が要りません。会話 ID から会話履歴を引く、利用者 ID からセッションを引く、のようにアクセスの形が決まっている場面に合います。有効期限を設定して、期限が過ぎた項目を自動で消すこともできます。逆に、あとから「この条件でも探したい」が増えると、設計を見直すことになりがちです。
迷ったときの見分け方
- 検索条件が後から増える → RDS
- 読み書きはほぼキーだけで決まる → DynamoDB
- 設計の始め方は逆になる。RDS は表の形（何をどの表に置くか）から、DynamoDB は「どうアクセスするか」から決める
どちらが優れているかではなく、アクセスの形と合っているかで選びます。
CHECK 3ここまでの確認
検索条件が後から増えていく業務データを、複数の表にまたがって調べたい。向くのはどちら?
答えと解説
答え: 2. RDS のようなリレーショナルデータベース
条件検索や結合は行と表の RDS が得意な領域です。DynamoDB はアクセスパターンが決まったキー引きで力を出します。RDS と DynamoDB の章を読み直してください。
1つの要件に複数の置き場を組み合わせるとは
実際のシステムでは、1つの要件でも形の違うデータが混ざっています。そのときは、1つの置き場に無理に押し込まず、形ごとに分けます。
SPLIT BY SHAPE画像アップロードの例
形の違うデータは置き場を分けて組み合わせる
全部を1か所に
- 処理中の一時ファイル（EBS）
- 一覧用の情報（DB）
- 画像の本体（S3）
形ごとに分ける
- 処理中の一時ファイル（EBS）
- 一覧用の情報（DB）
- 画像の本体（S3）
無理に押し込む合う置き場に任せる
たとえば画像アップロードなら、次のように分けます。
- 画像の本体：S3。数が増え続ける塊で、キーで出し入れすれば足ります
- 一覧用の情報（投稿者・日時・タイトルなど）：DB。条件で絞ったり並べたりするため
- 処理中の一時ファイル：EBS。サーバーのディスクとして使い、消えても作り直せる
こうしておくと、画像が増えても DB は小さいままで、検索は DB に任せられます。どれか1つに寄せるより、それぞれの得意に任せたほうが、あとからの変更にも強くなります。
CHECK 4ここまでの確認
画像アップロード機能で、画像の本体と一覧表示用の情報（投稿者・日時など）はどう置くのが基本?
答えと解説
答え: 2. 本体は S3、一覧用の情報は DB に分ける
形の違うデータは、それぞれに合う置き場に分けます。組み合わせの章を読み直してください。
具体例で選んでみる
最後に、4つの要件で、5つの軸を当てはめてみます。
| 要件 | 読み書きの形 | 置き場 |
|---|---|---|
| 画像アップロード | 塊を出し入れ。一覧は条件で絞る | 本体は S3、一覧用の情報は DB |
| 社内ファイル共有 | 複数台から同じファイルを読み書き | EFS |
| 注文データ | 条件で検索、集計、失えない | RDS |
| ログイン後のセッション | ID で引く、期限が来たら消える | DynamoDB（有効期限の設定） |
どれも最初から答えが決まっていたわけではなく、「誰が・どう読み書きするか」を書き出した結果として決まっています。
選んだ置き場のコスト・バックアップ・可用性は設計のどこで効くのか
置き場を選んだあとにも、決めることが3つ残ります。深掘りはそれぞれの記事に譲り、ここでは入口だけ押さえます。
- コスト：S3 はアクセスの頻度でストレージクラスを選べます。使わないデータを高頻度向けのクラスに置き続けない、というのが基本です。
- バックアップ：EBS はスナップショット、S3 はバージョニング、RDS は管理されたバックアップ、というように置き場ごとに手段が違います。AWS Backup を使うと、EBS・RDS・DynamoDB・EFS などをまとめて保護できます。
- 可用性：EBS は1つの AZ の中、EFS や S3 は複数の AZ にまたがる、というように前提が違います。複数の AZ でどう守るかは、置き場の選択と一緒に考えます。RDS の冗長化の仕組みは rds-multiaz-replica-shikumi で扱います。
これらを「選んだあとで考える」と、置き場の選び直しになることがあります。選ぶ段階で、軸の1つとして入れておくのが設計です。
Cloudory 執筆者（AWS 認定 全冠）
置き場の選択は、一度に正解を当てる作業ではありません。読み書きの形を書き出し、5つの軸に当てはめ、足りなければ分ける。この順番を持っておけば、新しいサービスが出ても同じ問いで比べられます。次は RDS と DynamoDB を個別に読んで、それぞれの得意と制約を確かめてください。
READ ALSO — 学習中向け・段2 構成
Amazon RDS とは何か｜マネージドの範囲と、EC2 に DB を置く場合との責任の違い
まとめ
- 先に「どう読み書きするか」を書き出し、種類・アクセスパターン・共有・規模・止められない度合いの5つの軸で絞ります。
- EBS はディスク、EFS は共有ファイル、S3 はオブジェクト、RDS は条件検索、DynamoDB はキー引きです。
- 形の違うデータは1つに押し込まず、置き場を分けて組み合わせます。
- コスト・バックアップ・可用性は、選んだあとではなく選ぶ軸に入れます。
参照ソース
- AWS Overview: Storage services — EBS・EFS・S3 の位置づけ（ブロック・共有ファイル・オブジェクト）、ストレージクラスの考え方、AWS Backup の対象の根拠に使用
- AWS Well-Architected Framework: Performance Efficiency Pillar（Data management） — データの種類・アクセスパターン・可用性などの制約でデータ管理の最適解が変わる、という考え方の根拠に使用
