オブジェクトストレージ・ブロックストレージ・ファイルストレージの違いとは？クラウドストレージ3種類の特性と使い分け判断ガイド

クラウドへの移行を検討しているインフラエンジニアから、こんな相談をよく受ける。「とりあえずS3に置けばいいですよね？」「オンプレのNASをそのままAWS上に持ってきたいのですが、EBSでいいですか？」。

この2つの質問には、実はクラウドストレージの根本的な誤解が詰まっている。クラウドには大きく分けて3種類のストレージパラダイムがある。ブロックストレージ・ファイルストレージ・オブジェクトストレージだ。この3つは「どれが優れているか」ではなく「何に向いているか」がまったく異なる。用途を間違えると、パフォーマンス問題・コスト爆発・設計の作り直しという三重苦が待っている。

この記事では、3種類のストレージパラダイムの違いと、AWSとAzureで対応するサービスの対応関係、そして「どれを選ぶか」の判断基準を、オンプレ経験者の目線から整理する。

3種類のストレージパラダイムとは何か

まず、オンプレエンジニアに馴染みのある概念から出発しよう。

オンプレのストレージには大きく3つの形態があった。サーバーに直接つないだローカルディスク（またはSAN越しに割り当てたブロックデバイス）、複数サーバーで共有するNAS（NFS/SMB）、そしてクラウド移行前はほぼ使わなかったHTTPベースのオブジェクトストア。この3形態がそのままクラウドに持ち込まれている。

1. ブロックストレージ（Block Storage）

物理ディスクをネットワーク越しに割り当てる仕組みだ。OSから見ると「/dev/xvda」のようなブロックデバイスとして見え、その上に自分でファイルシステム（ext4、XFS、NTFSなど）を作る必要がある。オンプレのSAN（iSCSI、Fibre Channel）をクラウドで実現したものと考えると分かりやすい。

特性は「低レイテンシ・高IOPS・1対1の接続」だ。1台のVM（またはコンテナノード）に専属でアタッチする前提で設計されている。高頻度の読み書きが必要なRDBのデータファイルや、OSのルートボリュームに使う。

・AWS: Amazon EBS（Elastic Block Store）
・Azure: Azure Managed Disks
・オンプレ相当: SAN（iSCSI/FC）、ローカルディスク

2. ファイルストレージ（File Storage）

ファイルシステムをネットワーク越しに「共有」する仕組みだ。複数のVM・コンテナから同じディレクトリをマウントして同時に読み書きできる。オンプレのNAS（NFS/SMB共有）をそのままクラウドに持ってきた形態だ。

特性は「複数クライアントからの同時アクセス・ファイル単位の操作」だ。レイテンシはブロックストレージよりやや高いが、オンプレのNASに慣れたエンジニアには自然に使える。Windowsのアプリが「\\server\share」形式の共有フォルダを期待している場合はSMBプロトコルが必要になる。

・AWS: Amazon EFS（NFS）、Amazon FSx for Windows File Server（SMB）
・Azure: Azure Files（SMBおよびNFS）
・オンプレ相当: NAS（NFS/SMBサーバー）

3. オブジェクトストレージ（Object Storage）

データをオブジェクト（バイナリデータ＋メタデータ）として管理し、HTTPSのAPIでアクセスする仕組みだ。ファイルシステムの階層構造は持たず（バケット/コンテナという単位でフラットに管理する）、マウントして使う概念ではない。オンプレにほぼ対応するものがなく、クラウドならではのストレージ形態と言える。

特性は「無制限のスケール・高耐久性・低コスト・API経由のアクセス」だ。AWSのS3は設計上イレブンナイン（99.999999999%）の耐久性を持つ。画像・動画・ログ・バックアップ・静的Webコンテンツの保管に適している。ただしランダムアクセスが必要なDBのデータファイルには向かない。

・AWS: Amazon S3
・Azure: Azure Blob Storage
・オンプレ相当: （ほぼ相当なし。MinIOなどOSS実装が存在）

3種類の特性比較表

※料金は2026年11月時点・東京リージョン（ap-northeast-1）の目安。実際の見積もりはAWS Pricing Calculatorで確認すること。

使い分けの判断基準

「何を置くか」「誰がアクセスするか」の2軸で考えると判断しやすい。

ブロックストレージを選ぶ場面

・OSのルートボリューム: EC2インスタンスやAzure VMの起動ディスクはブロックストレージ（EBS/Managed Disks）が必須。ファイルストレージやオブジェクトストレージから直接起動することはできない
・RDBのデータファイル: MySQL・PostgreSQL・SQL Serverなどのデータファイルは低レイテンシ・高IOPSが求められる。EBS gp3またはio2を使う
・高IOPS・低レイテンシが必要なアプリ: インメモリDBのウォームキャッシュ用ディスクや、HPC系のワークロードなど
・「1台のVMが専属で使うディスク」の置き換え: オンプレで1台のサーバーに専用ディスクを割り当てていた構成は、そのままEBS/Managed Disksに置き換えられる

ファイルストレージを選ぶ場面

・複数インスタンスからの共有ディレクトリ: Webサーバー3台が同じアップロードディレクトリに書き込む、CIサーバーがビルド成果物を共有するなど、複数のVMが同一パスに書き込む構成
・Windowsアプリのファイル共有: オンプレのWindowsファイルサーバー（\\server\share形式）を使っていたアプリをそのまま移行する場合は、SMBプロトコルに対応したFSx for Windows File ServerまたはAzure Filesを使う
・コンテナのReadWriteMany PV: KubernetesでPod間で共有ボリュームが必要な場合（ReadWriteMany）はEFSやAzure Filesが適している。EBSはReadWriteOnlyが基本
・オンプレのNASを段階的に移行: 既存のNFSマウントポイントをそのままEFS/Azure Filesに差し替える移行では、アプリケーション側の変更が最小限で済む

オブジェクトストレージを選ぶ場面

・画像・動画・ファイルの保管: アプリがアップロードされたファイルをS3/Blob Storageに書き込み、CloudFrontやAzure CDNから配信する構成は典型的なユースケース
・バックアップ・ログ・データレイク: 大量のファイルを安価に長期保管する用途。ストレージクラス（S3 Glacier、Blob Archive層など）を使えばさらにコストを下げられる
・静的Webサイトのホスティング: S3/Blob StorageはHTTPSで直接コンテンツを配信できるため、静的サイトの配信元として使える
・ETLパイプラインの中間ステージ: AWS GlueやAzure Data Factoryがデータを加工する前後の「置き場」として使う場合は、S3/Blob Storageが最も効率的

料金設計の実際

料金の見かけ上の差（EFS $0.30 vs EBS $0.08 vs S3 $0.023）をそのまま比較するのは早計だ。

EFSがEBSの約4倍の単価でも使う理由がある。EFSはストレージを10台のEC2インスタンスで共有できる。EBSでこれをやろうとすると、同じデータを10台分にコピーするか、共有ファイルシステムを自前で構築する必要がある。共有が必要な構成では、EFSの方がトータルのコストが下がる。

S3が最安に見える罠もある。S3はGBあたりの保管料は安いが、GET/PUTリクエスト料やデータ転送料（特にEC2→S3のクロスAZ転送やインターネット向け）が別途かかる。大量のランダムアクセスが発生するユースケースでは、実際のコストがEBSを超えることもある。

想定例として、100GBのデータを1か月保管した場合の単純計算（保管料のみ）:
・EBS gp3: 約$8
・EFS スタンダード: 約$30
・S3 スタンダード: 約$2.3

転送料・リクエスト料は含まないため実際の見積もりにはAWS Pricing Calculatorを使うこと。

よくあるつまずきパターン

1. EBSを複数EC2で共有しようとする

EBSには「Multi-Attach」という機能があるが、io1/io2ボリュームに限定されており、クラスタ対応ファイルシステム（GFS2、OracleなどのCFSなど）が前提だ。一般的なext4/NTFSファイルシステムのまま複数インスタンスにアタッチすると、データ破損の原因になる。複数インスタンスで共有したければ、EFS（NFS）またはFSx（SMB）を使うのが正解だ。

2. S3をファイルシステムのようにマウントして使う

Mountpoint for Amazon S3やs3fsを使えばS3をNFSライクにマウントできる。ただし、これはパフォーマンスがローカルファイルシステムやEFSとは桁違いに遅い。ランダムアクセスが多いワークロード、例えばDBのデータディレクトリとして使うのは実用上問題がある。S3マウントは「シーケンシャル読み込みがメインで、パフォーマンスに余裕がある」ユースケースに限定すべきだ。

3. オンプレのNASをEBSに置き換える

「NASのデータをクラウドに移したい」という相談で、EBSを提案してしまうケースがある。EBSは基本的に1台のVMだけにアタッチできるため、複数の接続元があるNASの置き換えには向かない。正解はEFSまたはFSx for Windows File Serverだ。オンプレのSANをクラウドに持ってくるときはEBS、オンプレのNASはEFS/FSx、と覚えておくといい。

4. Azure Managed DisksとAzure Filesを混同する

Azure環境でも同じ混乱が起きる。Azure Managed DisksはAzure VMの専用ディスクでブロックストレージだ。Azure FilesはSMB/NFS共有を提供するファイルストレージで、複数VMから同時に使える。「Azureのストレージ」と一括りにされることが多いが、両者は完全に別のサービスだ。

AWS・Azure サービス対応まとめ

本記事のまとめ

クラウドのストレージ3種類を整理すると、次のように覚えられる。

・ブロックストレージ（EBS / Azure Managed Disks）: 1台のVMが専属で使う「ディスク」。OS・DBに使う。オンプレのSANに相当
・ファイルストレージ（EFS・FSx / Azure Files）: 複数のVMが共有する「NAS」。共有ディレクトリが必要なアプリに使う。オンプレのNASに相当
・オブジェクトストレージ（S3 / Azure Blob）: HTTPSのAPIでアクセスする「大容量バケット」。ファイル保管・バックアップ・CDNに使う。オンプレにほぼ相当なし

用途を間違えると、パフォーマンス問題・コスト超過・データ破損のリスクがある。「とりあえずS3」ではなく、「誰がどのプロトコルでアクセスするか」を起点に選ぶ習慣をつけてほしい。

AWSのS3・EBS・EFSの料金・IOPS設定など各サービスの詳細は、EBSとS3の違い・EFSとの比較｜Amazon S3/EBS/EFS 徹底比較ガイドで詳しく解説している。オンプレのSAN・NASとクラウドサービスの対応関係についてはオンプレストレージ（SAN・NAS・DAS）とクラウドの対応表も参照してほしい。

ストレージ階層（ホット/ウォーム/コールド）によるコスト最適化についてはホットデータ・ウォームデータ・コールドデータの違いで整理している。Azure FilesはAzure Blob Storageと連携してコストを最適化できる構成もある。詳細はAzure Files入門とAzure Blob Storageコスト最適化入門を参照してほしい。