ストレージ

ブロックストレージは、OSからは普通のディスクに見えます。データを決まった大きさのブロックに分けて読み書きし、その上にOSがファイルシステム（ext4やXFS）を作ります。一部だけを素早く書き換えられ、レイテンシが低いので、DBのデータ置き場やOSの起動ディスクに向いています。AWSではEBSで、基本は1台のインスタンスに接続し、同じAZの中で使います。

ファイルストレージは、ネットワーク越しの共有フォルダです。NFSなどで複数のサーバーが同じディレクトリを同時に読み書きできます。複数台のサーバーで共有したいアップロードファイルや設定に使います。AWSではEFS（Linux向け）やFSxです。便利ですが、ブロックストレージより遅く高めです。

オブジェクトストレージは、HTTPのAPIで、キー（名前）を指定してデータを丸ごと出し入れする箱です。フォルダのように見えるのはキーに「/」が入っているだけで、実際には階層がありません。容量は事実上無制限で安く、耐久性も非常に高い一方、ファイルの一部だけを書き換えることはできず、全体を置き換えます。AWSではS3で、静的ファイル、ログ、バックアップ、データ分析の置き場に使います。

補足：インスタンスストアは、EC2のホストに物理的についている高速なディスクですが、インスタンスを停止すると中身が消えます。一時的なキャッシュや作業領域にだけ使います。

「DBのデータをS3に置く」「ログをEBSに貯め続ける」など、性質に合わない使い方が障害やコストの原因になる。

IOPS（I/O Operations Per Second）は、1秒間に何回の読み書きができるかです。DBのように小さなデータをあちこち読み書きする処理では、IOPSが性能を決めます。スループットは1秒間に運べるデータ量（MB/s）で、ログやバックアップ、動画のように大きなデータを順番に読み書きする処理で効きます。2つは「スループット ＝ IOPS × 1回あたりのサイズ」の関係にあり、処理の種類によって、どちらの上限に先に当たるかが変わります。

レイテンシは1回の読み書きにかかる時間です。IOPSとレイテンシは、同時に出している要求の数（キュー深度）でつながっていて、「IOPS ＝ キュー深度 ÷ レイテンシ」の関係があります（リトルの法則）。1回1msのディスクに1つずつ順番に要求を出すと、最大でも1,000 IOPSしか出ません。逆に、キューが長く溜まっているのにIOPSが上がらないなら、ディスク側が上限に達しています。

性能はボリュームだけでは決まりません。インスタンスのサイズごとにEBSとの間の帯域やIOPSの上限があり、小さいインスタンスでは高性能なボリュームを使い切れません。また、gp2やT系インスタンスのバーストは、普段は余裕があっても、クレジットを使い切った瞬間に急に遅くなるので、「昨日まで速かったのに急に遅い」障害の原因になります。

小さいデータの読み書きはIOPSの上限に、大きいデータはスループットの上限に先に当たる。

ボリュームの性能を上げても、インスタンス側の上限が低ければ速くならない。

S3では、バケットの中に、キー（例：logs/2026/11/app.log）で識別するオブジェクトを保存します。オブジェクトはデータ本体とメタデータからなります。2020年12月以降、書き込み直後の読み取りでも最新のデータが返る強い整合性になっています。データは複数のAZに保存され、非常に高い耐久性（イレブンナイン、99.999999999%）があります。

安いクラスほど取り出しに時間と料金がかかる。「本当に取り出せるか」まで確認しておく。

バケットを公開せずに、利用者に一時的な権限だけを渡せる。