Azure Files

解決する課題

オンプレミスのファイルサーバー（NAS）をクラウドへ「持ち上げ＆移行（リフト＆シフト）」したり、複数サーバー間でファイルを共有したい場面で使います。

• 複数の VM・コンテナから同じファイルを共有したい（アプリの構成ファイル、アップロード領域、共有コンテンツ）
• オンプレのファイルサーバー / 共有ドライブをそのまま置き換えたい（SMB なのでアプリ改修が不要）
• 容量の見積り・拡張を気にせず使いたい
• オンプレにローカルキャッシュを残しつつ、実体はクラウドに集約したい（Azure File Sync）

主要概念と用語

• ストレージアカウント: Azure Files / Blob / Queue / Table を束ねる入れ物。ファイル共有はこの中に作る
• ファイル共有（File Share）: 実際にマウントする共有単位。\\<account>.file.core.windows.net\<share> でアクセス
• プロトコル: SMB（3.1.1 / 3.0、Windows・Linux・macOS）と NFS v4.1（Linux、Premium のみ）。1つの共有は SMB か NFS のどちらか一方
• パフォーマンス階層: Standard（HDD ベース、汎用 v2 アカウント）と Premium（SSD ベース、FileStorage アカウント。低レイテンシ・高 IOPS）
• 課金モデル: Standard は 従量課金（使った分） または プロビジョニング v2、Premium は プロビジョニング（容量に応じて IOPS/スループットが決まる）
• ID ベース認証: Microsoft Entra Domain Services / オンプレ AD DS / Entra ID（Kerberos） による SMB アクセスで、NTFS の ACL をそのまま適用
• Azure File Sync: オンプレの Windows Server を Azure Files と同期させ、アクセス頻度の低いファイルをクラウドへ階層化（クラウドのティアリング）する機能
• プライベートエンドポイント: 共有へのアクセスを VNet 内のプライベート IP に限定する

仕様・制限・クォータ

• SMB 3.1.1 / 3.0 と NFS v4.1 で複数同時マウントに対応
• 冗長性オプション: LRS（ローカル冗長）/ ZRS（ゾーン冗長）/ GRS（地理冗長）/ GZRS。Premium は LRS / ZRS のみ
• 共有の最大サイズ: 既定 5 TiB、大きいファイル共有を有効にすると 最大 100 TiB
• 1ファイルの最大サイズ: 4 TiB
• Standard の従量課金共有は容量の事前確保が不要（使った分だけ）。Premium はプロビジョニングした容量に比例して IOPS・スループットが決まる
• SMB Multichannel（Premium）で帯域・IOPS を集約し性能を向上できる

内部の仕組み

Azure Files は、ストレージアカウントというマネージドな基盤の上で動く分散ファイルストレージです。クライアントは TCP 445 番ポート（SMB） または NFS のポート経由で、<account>.file.core.windows.net のエンドポイントへ接続します。Standard は HDD ベースの汎用ストレージ、Premium は専用の FileStorage アカウントで SSD を使い、低レイテンシ・高 IOPS を実現します。

• Azure マネージドディスクが1つの VM にアタッチするブロックストレージなのに対し、Azure Files は多数のクライアントから同時に使える共有ファイル
• 同じストレージアカウントでも、Blob はオブジェクト（HTTP/REST 配信）、**Files は共有ファイル（SMB/NFS マウント）**と役割が異なる
• Premium はゾーン冗長（ZRS）に対応し、データセンター障害をまたいで可用性を確保できる

設計パターン / ベストプラクティス

• リフト＆シフト: オンプレの SMB 共有を Azure Files に置き換え、アプリの UNC パスだけ向き先変更
• Azure File Sync でハイブリッド化: オンプレの Windows Server にホットデータをキャッシュし、コールドデータはクラウドへ階層化。複数拠点間の同期にも使える
• Premium + プライベートエンドポイント: 低レイテンシが要る本番ワークロードは Premium 階層にし、アクセスは VNet 内に閉じる
• ID ベース認証で ACL を活用: アクセスキー共有ではなく、AD / Entra ID と NTFS ACL でユーザー単位の権限制御
• コンテナの永続ボリューム: AKS で azureFile ボリュームとしてマウントし、ReadWriteMany な共有ストレージを実現

運用・監視

• Azure Monitor / Storage メトリクスでトランザクション数、レイテンシ（SuccessE2ELatency）、使用容量、スロットリング（Throttling）を監視
• Premium で性能が頭打ちなら、プロビジョニング済み IOPS / スループットの上限到達を疑う。バーストクレジットの消費も確認する
• マウントできないときは、SMB の 445 番ポートがファイアウォール / ISP でブロックされていないか、ストレージアカウントのネットワーク設定（ファイアウォール・プライベートエンドポイント）、ID 認証・アクセスキーを確認する
• ソフト削除を有効にしておくと、誤って削除した共有を一定期間内に復元できる

コスト

Standard と Premium で課金の考え方が異なります。Standard はトランザクション課金があり、Premium は確保した容量で性能と料金が決まる点が肝です。

• Standard はアクセスが少ないほど安く、トランザクションが多いと割高になることがある
• Premium は未使用でもプロビジョニング容量に課金されるため、容量を過剰に確保しない
• GRS / GZRS は地理冗長の分だけ単価が上がる。要件に応じて LRS / ZRS を選ぶ

セキュリティ

• 保存時暗号化は既定で有効（Microsoft 管理キー、または Key Vault のカスタマー管理キー）
• 転送時暗号化: SMB 3.x は暗号化に対応。「セキュリティで保護された転送が必須」を有効にし、暗号化なしの接続を拒否する
• ID ベース認証（オンプレ AD DS / Entra Domain Services / Entra ID Kerberos）で NTFS ACL を適用し、ユーザー単位にアクセス制御
• ネットワーク制限: ストレージファイアウォールやプライベートエンドポイントで、インターネット経由のアクセスを遮断し VNet 内に閉じる
• RBAC（Storage File Data SMB Share Reader/Contributor 等）で共有レベルの権限を割り当てる

関連サービス・比較（AWS との対応）

Azure Files は1つで SMB と NFS を扱えるため、AWS では用途によって EFS と FSx に分かれます。

ハンズオン / CLI例

# リソースグループとストレージアカウントを作成（汎用 v2 / ZRS）
az group create --name demo-rg --location japaneast

az storage account create \
  --name demofiles$RANDOM \
  --resource-group demo-rg \
  --location japaneast \
  --sku Standard_ZRS \
  --kind StorageV2

# ファイル共有を作成（クォータ 100 GiB）
az storage share-rm create \
  --resource-group demo-rg \
  --storage-account <account-name> \
  --name shared \
  --quota 100

# 接続用キーを確認
az storage account keys list \
  --resource-group demo-rg \
  --account-name <account-name> -o table

# Linux から SMB でマウント（445 番ポートが開いている必要あり）
sudo mount -t cifs \
  //<account-name>.file.core.windows.net/shared /mnt/azfiles \
  -o vers=3.1.1,username=<account-name>,password=<account-key>,serverino

# Windows から共有ドライブ（Z:）としてマウント
net use Z: \\<account-name>.file.core.windows.net\shared `
  /user:Azure\<account-name> <account-key>