Storage

カテゴリ概要

Azure のストレージサービスは、オブジェクト・ブロック・ファイルの各ストレージに加え、アーカイブやデータ転送まで幅広い領域をカバーする。AWS と最も大きく異なるのは「ストレージアカウント」という上位リソースの存在であり、Blob コンテナ・File 共有・Queue・Table がすべてこのストレージアカウントの配下に配置される。AWS では S3、EBS、EFS、Glacier などが独立したサービスとして存在するが、Azure ではストレージアカウントを軸に複数のストレージ機能が統合されている。

サービスマッピング一覧

主要サービス詳細

Azure Blob Storage（AWS: S3）

Azure のオブジェクトストレージサービス。非構造化データ（画像、動画、ログ、バックアップ等）を大量に格納するために使用する。

AWS エンジニアが知っておくべき違い:

• S3 はバケットがトップレベルのリソースだが、Azure では「ストレージアカウント → Blob コンテナ → Blob」という 3 階層構造になる。ストレージアカウントは課金・アクセス制御・冗長性設定の単位でもある
• S3 のバケット名はグローバルに一意だが、Blob コンテナ名はストレージアカウント内で一意であればよい。代わりにストレージアカウント名がグローバルに一意である必要がある
• S3 のストレージクラス（Standard / Intelligent-Tiering / Glacier 等）に対応するのが、Azure のアクセス層（Hot / Cool / Cold / Archive）。Blob 単位でアクセス層を変更でき、Lifecycle Management ポリシーで自動移行も可能
• S3 のバージョニングに相当する機能として Blob のバージョニングがあり、ストレージアカウント単位で有効化する
• アクセス制御は SAS（Shared Access Signature）トークン、ストレージアカウントキー、Microsoft Entra ID + Azure RBAC の 3 方式がある。S3 のバケットポリシーに完全対応するものはないが、RBAC とストレージアカウントのファイアウォールルールで同等の制御が可能

Azure Managed Disks（AWS: EBS）

Azure Virtual Machines にアタッチするブロックストレージ。概念は EBS とほぼ同一。

AWS エンジニアが知っておくべき違い:

• EBS のボリュームタイプ（gp3 / io2 / st1 / sc1）に対応するのが、Azure のディスクタイプ（Premium SSD v2 / Premium SSD / Standard SSD / Standard HDD / Ultra Disk）
• EBS の gp3 に最も近いのが Premium SSD。高 IOPS が必要な場合は Ultra Disk または Premium SSD v2 を選択する
• EBS スナップショットと同様に、Managed Disks のスナップショットを取得できる。増分スナップショットにも対応
• 可用性ゾーン間でのディスク移動は、EBS 同様にスナップショット経由で行う
• Managed Disks は VM と独立したリソースとして管理され、VM を削除してもディスクを残すことが可能（EBS と同じ概念）

Azure Files（AWS: EFS / FSx for Windows File Server）

フルマネージドのファイル共有サービス。NFS と SMB の両プロトコルをサポートする。

AWS エンジニアが知っておくべき違い:

• AWS では NFS ファイル共有は EFS、SMB ファイル共有は FSx for Windows File Server と別サービスに分かれるが、Azure Files は 1 つのサービスで両方をサポートする
• NFS 共有は Premium tier のみで利用可能。SMB 共有は Standard tier と Premium tier の両方で利用可能
• EFS のようなサーバーレス自動スケーリングではなく、プロビジョニングした容量に対して課金される（Standard tier は使用量課金も選択可能）
• Active Directory 統合による認証が可能で、オンプレミス AD または Microsoft Entra Domain Services と連携できる
• Azure File Sync を使うことで、オンプレミスの Windows Server とクラウドの Azure Files を同期できる（AWS Storage Gateway に近い概念）

Azure Managed Lustre（AWS: FSx for Lustre）

HPC（High Performance Computing）や AI / ML ワークロード向けの高性能並列ファイルシステム。

AWS エンジニアが知っておくべき違い:

• FSx for Lustre と同様に、大規模な並列読み書きが必要なワークロードに適している
• Blob Storage との統合が可能で、データを Blob から Managed Lustre にインポートして高速処理し、結果を Blob にエクスポートできる（FSx for Lustre の S3 連携と同じ概念）
• FSx for Lustre に比べると後発のサービスであり、対応リージョンや機能面でまだ差がある

Blob Storage Archive tier（AWS: S3 Glacier / S3 Glacier Deep Archive）

Blob Storage のアクセス層の 1 つで、長期保存・ほぼアクセスしないデータ向け。

AWS エンジニアが知っておくべき違い:

• S3 Glacier は独立したサービス（別の API 体系）だが、Azure の Archive は Blob Storage のアクセス層の 1 つであり、同じ API で操作できる
• Archive 層の Blob にアクセスするには、まず Hot / Cool / Cold のいずれかの層に「リハイドレート（復元）」する必要がある。S3 Glacier の復元リクエストに相当する
• リハイドレートの優先度を Standard（最大 15 時間）または High（1 時間以内）から選択できる。S3 Glacier の Expedited / Standard / Bulk に対応する概念
• Lifecycle Management ポリシーで Hot → Cool → Cold → Archive への自動移行を設定できる。S3 Lifecycle Policy と同じ考え方

Azure Backup（AWS: AWS Backup）

Azure リソースの一元的なバックアップ管理サービス。

AWS エンジニアが知っておくべき違い:

• AWS Backup と同様に、VM、Managed Disks、Azure Files、SQL Database、Blob Storage などの複数リソースを一元管理できる
• Recovery Services コンテナ（またはバックアップコンテナ）にバックアップデータを格納する。AWS Backup のバックアップボールトに相当
• バックアップポリシーで保持期間やスケジュールを定義する点は同じ

Azure Data Box（AWS: Snowball / Snowcone）

大容量データをオフラインで Azure に転送するための物理デバイス。

AWS エンジニアが知っておくべき違い:

• Snowball に相当する Data Box（最大 80 TB）、より大容量の Data Box Heavy（最大 1 PB）、小型の Data Box Disk（最大 40 TB / SSD）がある
• AWS Snowcone のような超小型デバイスに直接対応するものはない
• データのエクスポート（Azure → オンプレミス）にも対応している

Azure File Sync（AWS: Storage Gateway に近い）

オンプレミスの Windows Server と Azure Files 間でファイルを同期するサービス。

AWS エンジニアが知っておくべき違い:

• Storage Gateway のファイルゲートウェイに概念が近いが、Azure File Sync は双方向同期を基本とする
• クラウド階層化機能により、アクセス頻度の低いファイルを自動的に Azure Files にオフロードし、オンプレミスのストレージ容量を節約できる
• 複数の Windows Server を同一の Azure Files 共有に同期できるため、マルチサイトのファイルサーバー統合に適している
• 旧 Azure StorSimple は非推奨となり、Azure File Sync への移行が推奨されている

AWS との主要な違い

ストレージアカウントという上位リソース

Azure ストレージの最も特徴的な概念が「ストレージアカウント」である。AWS では S3 バケット、EBS ボリュームなどがそれぞれ独立したリソースだが、Azure ではストレージアカウントの配下に Blob コンテナ、File 共有、Queue、Table が配置される。ストレージアカウント単位で以下が決まる:

• 冗長性: LRS（ローカル冗長）/ ZRS（ゾーン冗長）/ GRS（地理冗長）/ GZRS（地理ゾーン冗長）
• パフォーマンス tier: Standard（HDD）/ Premium（SSD）
• アクセス制御: ストレージアカウントキー、SAS トークン、ネットワーク制限
• 課金単位: ストレージアカウント配下のすべてのサービスが一括管理

AWS では S3 バケットごとにバージョニングやライフサイクルを独立設定するが、Azure ではストレージアカウントレベルの設定がその配下のリソースに影響する点に注意が必要。

アクセス層モデル vs 独立サービスモデル

AWS では S3 Standard / S3 Glacier / S3 Glacier Deep Archive がそれぞれ異なるストレージクラス（Glacier は歴史的に独立サービスでもある）として存在する。Azure では Hot / Cool / Cold / Archive の 4 つのアクセス層が Blob Storage の機能として統合されている。層の変更は Blob 単位で行え、API も共通であるため、運用がシンプルになる。

ファイルストレージの統合

AWS では NFS ファイル共有（EFS）と SMB ファイル共有（FSx for Windows File Server）が別サービスとして提供されるが、Azure Files は 1 つのサービスで NFS と SMB の両方をサポートする。プロトコルの選択はファイル共有作成時に決定し、同一ストレージアカウント内に NFS 共有と SMB 共有を混在させることも可能。

冗長性の考え方

AWS の S3 はデフォルトで 3 AZ にデータを複製するが、Azure のストレージアカウントでは冗長性レベルを明示的に選択する必要がある。LRS（単一データセンター内 3 コピー）が最も安価だが、AZ 障害に対する耐性がない。本番ワークロードでは ZRS（3 AZ に分散）以上を選択すべき。

サービス選定の指針