👀概要
パーソルホールディングス エンジニアリング部 Technical Alliance室の三好です。
今回は、Azure Storage（特にBlob storage）についてAWS経験者向けに3分で解説します。
この記事では、「AWSでいうアレはAzureでは??」という概念やサービスの違いから、AWSエンジニアが初見でハマりがちな仕様のズレまでをサクッと整理します。
👨👩👧👦対象者(Who)
- Azureを初めて触る方（特にAWS経験者）
- インフラエンジニア、クラウドエンジニア
📌関連リンク
🗒️目次
- 基本概念と機能
- ストレージアカウント
- 汎用 v2(Standard)が内包する4つの機能
- Blob Storageの階層構造とS3との対応
- Terraformでの最小構成例
- まとめ
📝 内容
基本概念と機能
ストレージアカウント(最外枠)
AWSでは用途に合わせてS3やSQSを個別に作成しますが、Azureではまずすべてのベースとなる 「ストレージアカウント」 という最外枠の器を作成します。
インフラやネットワーク（IP制限）、セキュリティ（暗号化やTLSバージョン）といった大元のポリシーは、すべてこのストレージアカウント単位で統括されます。
ストレージアカウントを作成する際は、スペックや主目的の異なる3つのグレード（種類） から選択します。
-
汎用 v2 (Standard)
- 用途： Blob, ファイル共有, キュー, テーブルすべてが使える万能タイプ
- 特徴： ほとんどのシステムに対応できる最もコストパフォーマンスが高い推奨設定
- ブロック BLOB (Premium)
- 用途： 大量の小さなファイルを、超高速で読み書きしたいときなどに使用
- 特徴： レスポンスの速さ（低レイテンシ）を最優先した高性能な箱
- ページ BLOB (Premium)
- 用途： 仮想マシンのディスク（VHD）や、データベース（Azure SQL DBなど）の基盤ストレージ
- 特徴： 512バイト単位でデータを細かく書き換える「ランダムアクセス」に特化した特殊な箱
汎用 v2(Standard)が内包する4つの機能
本記事でメインとなる 「汎用 v2 (Standard)」 ストレージアカウントを作成すると、1つの箱の中に以下の4つのストレージ機能が自動的にすべて作成されます。
- 汎用 v2ストレージアカウント
- Blob Storage ──── 【AWS: S3 / EBS】（画像、CSV、ログ、仮想ディスク）
- ファイル共有 ──── 【AWS: EFS / FSx】（SMB/NFSでの共有ファイルサーバー）
- キュー ──── 【AWS: SQS】（システム間のメッセージング）
- テーブル ──── 【AWS: DynamoDB】（簡易NoSQLデータベース）
AWSがそれぞれ完全に独立したサービスとして提供しているのに対し、Azureは 「1つの万能な箱（ストレージアカウント）を作り、その中のどの機能を使うか」 という思想になっています。
Blob Storageの階層構造とS3との対応
実はAzureには、「Blob Storage」という名前の独立したリソースオブジェクトは存在しません。
ストレージアカウントを作ると裏で自動的に有効化される「機能」に過ぎないため、「リソースとしては3層、概念としては4層」 で捉えるのが実務上、最もスッキリします。
コンテナー
Blobを小分けにする箱であり、AWSの「S3バケット」に該当します。
単なるファイル整理のフォルダではなく、具体的なセキュリティや運用ルールを個別適用する境界線となります。
※ コンテナー内にはディレクトリを作成できますが、通常ではAWS S3のプレフィックスの概念と同じく「疑似フォルダ」となっており、ファイル名の一部に 「/」 が含まれているだけというフラットな構造です。
BLOB
コンテナーの中に格納されるデータ（ファイル）そのものです。
Terraformでの最小構成例
ここまで説明した「ストレージアカウント」と「コンテナー」の関係をTerraformで表現すると、以下のようなシンプルな構成になります。
# 1. ストレージアカウント（最外枠）を作成
resource "azurerm_storage_account" "example" {
name = "example001"
resource_group_name = "example-resource-group"
location = "Japan East"
account_tier = "Standard" # パフォーマンス階層の指定（標準プラン）
account_replication_type = "LRS" # コスト最適なローカル冗長
account_kind = "StorageV2" # 汎用v2のスペック
# パブリック公開の「1段階目の鍵」：このアカウント内でのパブリック公開を許可する
allow_nested_items_to_be_public = true
}
# 2. その中にコンテナーを作成・紐付け
resource "azurerm_storage_container" "example" {
name = "example-container"
storage_account_id = azurerm_storage_account.example.id
# パブリック公開の「2段階目の鍵」：このコンテナー自体を実際に一般公開にする
container_access_type = "container"
}
リソース名に注意
AWSのS3バケット名などでは
-(ハイフン)を使用することができましたが、
Azureのストレージアカウントではハイフンを使用することはできません。
AWSとAzureで名前の制約が少しずつ異なるので、ご注意ください。
まとめ
AWSエンジニアがAzure Blob Storageを触る際は、以下のポイントを押さえておけば迷うことが少なくなると思います！
- リソース管理単位の違い
- AWSは用途ごとに個別のサービスを作成するが、Azureはまず全サービス入りの万能ストレージアカウントを作成し、その中で「Blob Storage」「ファイル共有」「キュー」「テーブル」といった機能を使い分ける
- Blob Storageは、リソースとしては3層、概念としては4層
- ストレージアカウント
- Blob Storage
- コンテナー
- BLOB
以上「3分でわかるAzure Blob Storage」でした。
少しでもみなさまの参考になれば幸いです。