オンプレストレージ（SAN・NAS・DAS）とクラウドの対応表｜AWS・Azureサービスへのマッピングと移行判断ガイド

オンプレ時代のストレージ設計はSAN・NAS・DASの三択から始まった。SANはiSCSIかFibre Channelでブロックデバイスをマウントして、NASはNFSかSMBで共有フォルダを作って、DASはサーバーに直付け——という構成を何度も繰り返してきたインフラエンジニアは多いはずだ。
ところがAWSやAzureへの移行を検討しはじめると、「SANはEBSに置き換えればいいのか？」「NASの代わりはEFSかFSxかAzure Filesか？」という疑問にぶつかる。クラウドのストレージ体系はオンプレとは分類が違うため、そのままの感覚で当てはめようとするとミスマッチが起きる。
この記事では、SAN・NAS・DASの違いを整理したうえで、AWSとAzureの対応サービスへのマッピングを具体的に示す。移行判断の実務チェックリストと料金の目安も合わせて解説する。

SAN・NAS・DASの違いをおさらいする

まず出発点として、3つのストレージ構成の基礎を整理しておこう。

1. DAS（Direct Attached Storage）

DASはサーバーに直接つながったストレージだ。サーバー内蔵のSATAやSAS、NVMeドライブがこれにあたる。ケーブル1本でつながっているため、レイテンシは最小になる。一方でサーバーに物理的に紐づくため、他のサーバーとの共有はできない。
・接続方式: SATA、SAS、NVMe
・アクセス単位: ブロック（OSがフォーマットしてファイルシステムを作成）
・典型的な用途: DBのデータ領域、OSボリューム、一時ファイル領域
・弱点: サーバー障害でデータへのアクセスも失う。拡張にはサーバーを止める必要がある

2. SAN（Storage Area Network）

SANはFibre Channel（FC）やiSCSIを使い、ストレージ専用ネットワーク越しにブロックデバイスを提供する仕組みだ。サーバーからはローカルのDASと同様にブロックデバイスとして見える。OSがフォーマットしてファイルシステムを作成する点はDASと同じだが、ネットワーク越しなので複数サーバーで同じLUNを扱えるクラスタ構成（VMware VMFSやOracle RAC）も組める。
・接続方式: Fibre Channel（FC）、iSCSI
・アクセス単位: ブロック
・典型的な用途: 仮想マシンのデータストア（VMware）、Oracleなどの高I/O DB、共有クラスタ構成
・弱点: FC構成はHBAカードやSANスイッチが必要で初期コストが高い。iSCSIは安価だがネットワーク設計が肝になる

3. NAS（Network Attached Storage）

NASはLAN経由でファイルシステムを共有するストレージだ。NFSやSMB（CIFS）プロトコルでマウントし、複数サーバーが同一ディレクトリを同時に読み書きできる。SANと違い、ストレージ側がファイルシステムを管理するため、クライアントは「フォルダ」として扱える。
・接続方式: NFS（v3/v4）、SMB/CIFS
・アクセス単位: ファイル
・典型的な用途: ファイル共有サーバー、ホームディレクトリ、Webコンテンツ共有、コンテナの共有ストレージ
・弱点: ブロックレベルのI/O性能はSANに劣る。プロトコルのオーバーヘッドが発生する

三者の比較表

項目	DAS	SAN	NAS
接続方式	SATA・SAS・NVMe	FC・iSCSI	NFS・SMB
アクセス単位	ブロック	ブロック	ファイル
複数サーバー共有	不可	可（クラスタFS要）	可（そのまま）
レイテンシ	最小	低（FC）・中（iSCSI）	中
主な用途	OS・DB領域	VM・高I/O DB	ファイル共有・共有NFS

クラウドでは「ブロック・ファイル・オブジェクト」の三分類に変わる

オンプレのSAN・NAS・DASはどれも「データをどのネットワーク経路で運ぶか」が分類基準だった。クラウドではこの視点が変わり、「データをどの単位でアクセスするか」が分類の軸になる。
・ブロックストレージ: ブロック単位でアクセス。DASやSANに相当
・ファイルストレージ: ファイル・ディレクトリ単位でアクセス。NASに相当
・オブジェクトストレージ: オブジェクト（ファイル＋メタデータ）単位でHTTP/APIアクセス。オンプレには直接の相当物がない
クラウドにはオンプレのSANスイッチやFCファブリックが存在しない。すべてのストレージアクセスはネットワーク（クラウド内部の高速ネットワーク）越しになる。この前提を押さえてからマッピングを見ると理解しやすい。

AWS対応サービスのマッピング

DAS・SAN（ブロックストレージ）→ Amazon EBS

Amazon EBS（Elastic Block Store）は、EC2インスタンスにアタッチするブロックストレージだ。オンプレで言えばDASかSANのLUNに相当する。
・1対1の紐づき: 基本的に1つのEBSボリュームは1つのEC2インスタンスにアタッチ（Multi-Attachオプションで複数アタッチも可能だがDBクラスタ用途に限る）
・ボリュームタイプ: 汎用SSD（gp3）・プロビジョンドIOPS SSD（io2）・スループット最適化HDD（st1）・コールドHDD（sc1）の4種類
・オンプレのSANとの主な違い: EBSはAZ（アベイラビリティゾーン）に紐づく。EBSをアタッチするEC2インスタンスも同じAZに置く必要がある。AZ間のデータ移動にはスナップショット経由が必要になる

オンプレでSANをVMwareのデータストアとして使っていた場合、AWSではEBSを直接扱うよりもAmazon ECSやEKSなどのコンテナ基盤のボリューム、あるいはAMI（Amazon Machine Image）としてEC2インスタンス自体を移行する形が一般的だ。

NAS（NFSファイル共有）→ Amazon EFS

Amazon EFS（Elastic File System）は、複数のEC2インスタンスからNFS v4でマウントできるマネージドNASだ。オンプレのNFSサーバーを置き換える用途に向いている。
・特徴: 容量を事前に決める必要がなく、データ量に応じて自動で拡縮する
・パフォーマンスモード: 汎用（General Purpose）とMax I/O。ほとんどのワークロードは汎用で十分
・スループットモード: バーストとプロビジョニング。ファイルサイズが小さく高頻度アクセスの場合はプロビジョニングを検討する
・向いている用途: コンテナの共有ストレージ、CMSのメディアファイル共有、ホームディレクトリ
・向かない用途: Windows SMB共有、高I/Oを要求するDB、Windowsファイルサーバーの移行先

NAS（SMB・Windowsファイルサーバー）→ Amazon FSx

Amazon FSxはFSx for Windows File ServerとFSx for Lustreの2系統がある。
・FSx for Windows File Server: SMB（CIFS）プロトコルに対応。Active Directory統合、DFSレプリケーション、シャドウコピーもサポートしており、オンプレのWindowsファイルサーバーをほぼそのまま移行できる。オンプレのNASがWindowsベースの場合はこちら
・FSx for Lustre: 機械学習やHPCの大容量高速ストレージ向け。S3と連携してデータを処理する設計パターンが多い。LinuxベースのNFSに近いが、用途は高性能コンピューティング特化

大容量アーカイブ・テープ → Amazon S3 + ストレージクラス

オンプレのテープライブラリやアーカイブ用途はAmazon S3のストレージクラスが対応する。特にS3 GlacierやS3 Glacier Deep Archiveは、取得に数時間かかる代わりに1GB当たり0.00099ドル（2026年現在）という非常に安価なストレージを提供する。

AWSストレージサービス対応表

オンプレ構成	対応AWSサービス	接続方式	主な用途
DAS（内蔵HDD/SSD）	Amazon EBS（gp3/io2）	ブロック	EC2のOS・DBボリューム
SAN（FC/iSCSI LUN）	Amazon EBS（io2 / Multi-Attach）	ブロック	高I/O DB・共有クラスタ
NAS（NFS共有）	Amazon EFS	NFS v4	Linuxコンテナ・共有ファイル
NAS（SMB/Windowsファイルサーバー）	Amazon FSx for Windows File Server	SMB	Windowsファイル共有・AD統合
NAS（高性能HPC）	Amazon FSx for Lustre	Lustre	ML・HPC・大容量高速処理
テープ・アーカイブ	Amazon S3 Glacier	オブジェクト（HTTP）	長期保管・コンプライアンス
オブジェクトストレージ（なし）	Amazon S3（Standard/IA等）	オブジェクト（HTTP）	静的ファイル・ログ・バックアップ

Azure対応サービスのマッピング

DAS・SAN（ブロックストレージ）→ Azure Managed Disks

Azure Managed DisksはAzure VMにアタッチするブロックストレージで、EBSに相当する。ディスクタイプはUltra Disk・Premium SSD v2・Premium SSD・Standard SSD・Standard HDDの5種類があり、I/O要件によって使い分ける。
・Ultra Disk: ミリ秒未満のレイテンシが必要なSAP HANAやOracle DBなど。IOPSとスループットをデプロイ後にも変更できる点が特徴
・Premium SSD v2: Ultra Diskより低コストで高性能。汎用高I/O DBに向く
・Premium SSD: 一般的な本番VMのデータディスク。オンプレのSAN LUN代替として使いやすい

NAS（NFSファイル共有）→ Azure Files / Azure NetApp Files

Azure FilesはSMBとNFSの両方に対応するマネージドファイルストレージだ。SMBはWindowsファイルサーバー移行に、NFSはLinux共有ファイルストレージに使える。
・Azure Files（Premium）: SSD ベースで低レイテンシ。大量の小さいファイルへの高I/Oに対応
・Azure NetApp Files: NetApp ONTAPをクラウドで動かすマネージドサービス。オンプレでNetApp NASを使っていた場合は最も移行が容易。NFSv3・NFSv4.1・SMBをすべてサポートし、クラウドでもNetAppの豊富な機能（スナップショット・クローン・効率化）を使い続けられる
・SMBファイル共有: Azure FilesはAD DS統合（Azure AD DSやオンプレAD DS）に対応。オンプレのWindowsファイルサーバーのACLをほぼそのまま移行できる

Azureストレージサービス対応表

オンプレ構成	対応Azureサービス	接続方式	主な用途
DAS（内蔵HDD/SSD）	Azure Managed Disks（Premium SSD）	ブロック	VM OS・DBボリューム
SAN（高I/O LUN）	Azure Managed Disks（Ultra / Premium SSD v2）	ブロック	SAP HANA・Oracle DB
NAS（NFS共有）	Azure Files（Premium）/ Azure NetApp Files	NFS v3/v4.1	Linux共有・コンテナ
NAS（SMB・Windowsファイルサーバー）	Azure Files	SMB 3.0	Windowsファイル共有・AD統合
NetApp NAS	Azure NetApp Files	NFS/SMB	そのままのNetApp機能維持
テープ・アーカイブ	Azure Blob Storage（Cold / Archive）	オブジェクト（HTTP）	長期保管・コンプライアンス
オブジェクトストレージ（なし）	Azure Blob Storage（Hot / Cool）	オブジェクト（HTTP）	静的ファイル・ログ・バックアップ

Azure Blob Storageの詳細については、アクセス層（Hot/Cool/Cold/Archive）の設計判断も含めて別記事で解説している。

移行判断の実務チェックリスト

「何を何に移行するか」を決めるための判断フローを整理する。

1. アクセスプロトコルは何か

・ブロックデバイスとしてフォーマットして使う: EBS（AWS）/ Azure Managed Disks（Azure）
・NFSマウントで使う: EFS（AWS）/ Azure Files NFSまたはAzure NetApp Files（Azure）
・SMBマウントで使う: FSx for Windows File Server（AWS）/ Azure Files SMB（Azure）
・HTTPのAPIで読み書きする: S3（AWS）/ Azure Blob Storage（Azure）

2. 複数サーバーから同時にアクセスするか

単一サーバーからしかアクセスしないなら、EBSまたはManaged Disksのシンプル構成でよい。
複数サーバーから同時に読み書きするなら、EFS・FSx（AWS）またはAzure Files・Azure NetApp Files（Azure）の共有ファイルストレージを選ぶ。SANのように見せかけたブロック共有はEBS Multi-Attachで可能だが、クラスタファイルシステム（GFS2など）が別途必要になるため、用途がOracleRAC等に限定される。

3. I/O性能の要件は何か

性能要件	AWS推奨	Azure推奨
超低レイテンシ（0.1ms未満）	EBS io2 Block Express	Azure Ultra Disk
高IOPS（汎用DB）	EBS gp3（プロビジョニング）	Azure Premium SSD v2
高スループット（順次I/O）	EBS st1	Azure Standard HDD（大容量）
NFS高性能	Amazon EFS（Provisioned Throughput）	Azure NetApp Files（Ultra）

4. データの移行手段は何か

オンプレからクラウドへデータを転送する際は、AWS DataSyncやAWS Storage Gatewayが有効な選択肢になる。DataSyncはNFS・SMBサーバーからS3・EFS・FSxへの高速差分転送に対応しており、移行期間中の並行運用にも使いやすい。

料金の仕組みと目安（2026年7月時点）

ストレージの選択は性能と同時にコストにも直結する。東京リージョン（ap-northeast-1）の代表的な料金を示す。

サービス	料金（目安）	課金単位
EBS gp3	約$0.096/GB/月	プロビジョニング容量
EBS io2	約$0.131/GB/月 + $0.065/IOPS/月	容量＋プロビジョニングIOPS
Amazon EFS（汎用）	約$0.36/GB/月	実際に保存したデータ量
FSx for Windows	約$0.23/GB/月～	デプロイ容量
S3 Standard	約$0.025/GB/月	実際に保存したデータ量
S3 Glacier Deep Archive	約$0.002/GB/月	実際に保存したデータ量

EFSはEBSと比べると単価が高いが、事前に容量を確保する必要がなく、実際に保存したデータ量だけ課金される。オンプレNASの「容量が足りなくなったらLUN追加」という手間がなくなる点でトータルコストは下がるケースが多い。
またS3・EBS・EFSの詳細比較については、ユースケース別の使い分けを含めて別記事でも解説している。

移行でよくあるつまずきポイント

ポイント1: EBSはAZをまたげない

EBSはAZに紐づく。同じAZ内でしかEC2にアタッチできないため、AZをまたいだ共有（SANのクロスサーバー共有と同じ感覚）は直接できない。AZをまたぐには、EBSスナップショットからAMIを別AZに展開するか、EFSやFSxなどのAZ横断型のファイルストレージに切り替えるかのどちらかになる。

ポイント2: EFSの「バーストクレジット」枯渇

Amazon EFSはデフォルトのバーストモードでは、ファイルシステムサイズが小さいと許容スループットが低い。ファイルシステムを新規作成した直後や、データ量が少ない段階でI/Oが集中するとバーストクレジットが枯渇し、スループットが極端に落ちる現象が起きる。大量データをEFSに一気に転送するマイグレーション時に多い。解決策はプロビジョニングスループットモードに切り替えること。

ポイント3: NASのACLはFSx以外では移行しにくい

オンプレのWindowsファイルサーバーにはNTFS権限（ACL）が複雑に設定されていることが多い。EFSはPOSIX権限のみのため、既存のWindowsACLをそのまま持ち込めない。FSx for Windows File ServerはNTFS ACLをそのまま移行できるため、Windowsファイルサーバーの移行先は原則としてFSxを選ぶべきだ。

ポイント4: オブジェクトストレージへの変換コスト

S3はブロックストレージでもファイルストレージでもない。既存アプリがローカルパスや共有NFS前提で作られている場合、S3に直接移行するにはアプリ側の修正が必要だ。短期的にはEFS・FSx・Storage Gatewayを橋渡しとして使い、長期的にアプリをS3対応に改修するロードマップが現実的な移行手順になる。

本記事のまとめ

SAN・NAS・DASのオンプレストレージとクラウドの対応関係を整理すると次のようになる。
・DAS/SANのブロックストレージ: EBS（AWS）・Managed Disks（Azure）に対応
・NASのNFS共有: EFS（AWS）・Azure Files NFS / Azure NetApp Files（Azure）に対応
・NASのSMB共有: FSx for Windows File Server（AWS）・Azure Files SMB（Azure）に対応
・テープ・アーカイブ: S3 Glacier（AWS）・Azure Blob Storage Archive（Azure）に対応
クラウドではDAS/SANの物理ケーブルや専用ネットワークの概念がなくなり、すべてクラウド内部ネットワーク越しのAPIになる。この「ブロック・ファイル・オブジェクト」の三分類を軸に移行先を選び、AZの制約・NTFS ACLの移行可否・パフォーマンスモードの選択を事前に確認することが、移行失敗を防ぐポイントだ。