はじめに
社内で Azure 推進チームが立ち上がり、自分もメンバーとして Azure を触り始めました。題材は、いちばん身近な「ファイルを置く」ことです。
やることは単純です。hello world と書かれた hello.txt を、S3 と Azure Blob Storage の両方に置いて、取り出す。それだけです。
実際に動かしてみると、S3 との違いが見えてきたので紹介します。
1. 準備
前提条件
この記事は、次の環境がすでにある前提で進めます。
| 必要なもの | 今回の環境 | |
|---|---|---|
| AWS | AWS アカウントと、S3 のバケットを作成・削除できる権限を持つユーザー | 既存の AWS アカウント（管理者権限） |
| Azure | Azure サブスクリプションと、自分にロールを割り当てられる権限 | 無料アカウントで作成したサブスクリプション |
AWS は既存のアカウントの管理者権限を持つ IAM ユーザーで、Azure は新しく作ったサブスクリプションで試しています。権限の条件をそろえた厳密な比較ではない点にご注意ください。
- 作業日：2026 年 9 月
- リージョン：AWS は東京（ap-northeast-1）、Azure は東日本（japaneast）
作業する場所
どちらもブラウザから使えるシェルで作業しました。
- AWS：CloudShell（マネジメントコンソール上部の
>_） - Azure：Cloud Shell（Azure ポータル上部の
>_）
どちらも CLI が最初から入っていて、サインインしたアカウントで認証も済んでいます。ローカルに何もインストールしなくて済むうえ、作業環境がそろうので比較しやすくなります。
送るファイルは、両方のシェルで同じように作ります。
echo "hello world" > hello.txt
2. S3 に置く
# バケットを作る
aws s3 mb s3://maki-hello-20260929 --region ap-northeast-1
# アップロード
aws s3 cp hello.txt s3://maki-hello-20260929
# 確認
aws s3 ls s3://maki-hello-20260929
aws s3 cp s3://maki-hello-20260929/hello.txt -
hello world
バケットを作って、コピーするだけです。最後の - は、標準出力に出す指定です。
The following
cpcommand downloads an S3 object locally as a stream to standard output.
マネジメントコンソールでバケットを開くと、その中にそのまま hello.txt があります。入れ物は 1 段です。
3. Azure Blob Storage に置く
同じことを Azure でやります。
Azure では、S3 のバケットに当たるものを コンテナー と呼びます。コンテナーの 1 つ上に ストレージアカウント があり、リージョンなどはそちらで設定します。
# ① リソースグループを作る
az group create \
--name rg-hello \
--location japaneast
# ② ストレージアカウントを作る
az storage account create \
--name makihello20260929 \
--resource-group rg-hello \
--location japaneast \
--sku Standard_LRS
# ③ 自分にデータを読み書きする権限を付ける
az ad signed-in-user show --query id -o tsv | az role assignment create \
--role "Storage Blob Data Contributor" \
--assignee @- \
--scope "/subscriptions/<subscription>/resourceGroups/rg-hello/providers/Microsoft.Storage/storageAccounts/makihello20260929"
# ④ コンテナーを作る
az storage container create \
--account-name makihello20260929 \
--name hello \
--auth-mode login
# ⑤ アップロード
az storage blob upload \
--account-name makihello20260929 \
--container-name hello \
--name hello.txt \
--file hello.txt \
--auth-mode login
# ⑥ 確認
az storage blob list \
--account-name makihello20260929 \
--container-name hello \
--output table \
--auth-mode login
az storage blob download \
--account-name makihello20260929 \
--container-name hello \
--name hello.txt \
--file out.txt \
--auth-mode login
cat out.txt
hello world
置けました。正直、最初の感想は「Azure 大変だな」でした。
4. つまずいたところ・気になったところ
作った直後のサブスクリプションで SubscriptionNotFound
リソースグループは作れたのに、ストレージアカウントを作ろうとすると次のエラーになりました。
(SubscriptionNotFound) Subscription xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx was not found.
ストレージのリソースプロバイダーを登録してから再実行したところ、作成できました。
az provider register --namespace Microsoft.Storage --wait
作った本人でも、ロールの割り当てが必要
S3 では、管理者権限のユーザーでそのままバケットにファイルを置けました。
Azure では、手順 ③ で自分にロールを割り当てる必要がありました。公式のクイックスタートには次のように書かれています。
コンテナーを作成する前に、ストレージ BLOB データ共同作成者ロールを自分に割り当てます。 アカウント所有者であっても、ストレージ アカウントに対してデータ操作を実行するには、明示的なアクセス許可が必要です。
Azure ロールの割り当てが反映されるまでに数分かかる場合があります。
(出典: クイック スタート: BLOB のアップロード、ダウンロード、一覧表示 - Azure CLI | Microsoft Learn)
5. S3 との対応
やってみて整理した対応表です。
| 項目 | S3 | Azure Blob Storage |
|---|---|---|
| リソースをまとめる単位 | （今回は使っていない） | リソースグループ |
| 入れ物 | バケット | ストレージアカウント → コンテナー（2 段） |
| 置くもの | オブジェクト | BLOB |
| データの読み書き権限 | IAM ポリシー | RBAC のデータ用ロール |
| アップロード | aws s3 cp |
az storage blob upload |
| ダウンロード |
aws s3 cp（向きを逆にする） |
az storage blob download |
| 片付け | aws s3 rb --force |
az group delete（リソースグループごと） |
ストレージアカウントの名前には、次の規則があります。
- ストレージ アカウント名の長さは 3 文字から 24 文字でなければなりません。 数字と小文字のみを含めることができます。
- ストレージ アカウント名は Azure 内で一意である必要があります。 複数のストレージ アカウントが同じ名前を持つことはできません。
6. ドキュメントで確かめたこと
ストレージアカウントは「バケット」ではなく「親」
ストレージアカウントを作ったときの出力を見ると、Blob 以外の入口も並んでいました。
"primaryEndpoints": {
"blob": "https://makihello20260929.blob.core.windows.net/",
"file": "https://makihello20260929.file.core.windows.net/",
"queue": "https://makihello20260929.queue.core.windows.net/",
"table": "https://makihello20260929.table.core.windows.net/",
...
}
ポータルでも、ストレージアカウントの左メニューに「コンテナー」「クラシック ファイル共有」「キュー」「テーブル」が並んでいます。
ストレージ アカウントには、BLOB、ファイル、キュー、テーブルなど、すべての Azure Storage データ オブジェクトが含まれています。
S3 のバケットに当たるのは、その下のコンテナーでした。
AzureはAWSやGoogle Cloudと名称が異なり、バケットではなくコンテナという名称で呼ばれています。本書ではAzureのコンテナもバケットと記載します。また、コンテナを利用する際には、その上位の単位としてリージョンやレプリケーションを構成するストレージアカウントを作成します
(出典: 『かんたん理解 正しく選んで使うためのクラウドのきほん Amazon Web Services・Azure・Google Cloudを横断的に理解しよう』)
実際、リージョン（--location japaneast）と冗長性（--sku Standard_LRS）を指定したのは、コンテナーではなくストレージアカウントを作るときでした。S3 ではバケットを作るときにリージョンを決めますが、Azure ではその設定が 1 つ上のストレージアカウントにあります。
7. 片付け
Azure 側は、リソースグループごと削除します。
az group delete \
--name rg-hello \
--no-wait
AWS 側は、バケットを中身ごと削除します。
aws s3 rb s3://maki-hello-20260929 --force
おわりに
Azure では、ファイルを置く前にリソースグループ、ストレージアカウント、コンテナーを順に作る必要がありました。作った本人でも、データを読み書きするロールの割り当てが必要でした。
また、些細なことですが、Azure のドキュメントは読みやすいなと思いました。
次は、サーバー（AWS なら EC2）を立てて比較してみたいと思います。引き続き、手を動かして学んでいきます。
参照