Azure Files 完全ガイド｜SMB/NFS・Standard/Premium・Entra Kerberos・Azure File Sync

Azure Files は、SMB (Server Message Block) / NFS (Network File System) / REST API で マウント可能な Microsoft マネージドのファイル共有サービス。Storage Account の File サービスとして提供され、Azure VM・オンプレ Windows / Linux・AKS Pod・App Service などから標準ファイルシステムプロトコルでマウント可能。代表的なユースケース: 1) Lift and Shift で オンプレファイルサーバーを Azure 移行、2) Container Persistent Volume・3) アプリケーションの共有設定・ログ集約、4) Cross-region のファイル共有。コスト面でも従量課金で運用負荷が極めて低く、伝統的なファイルサーバーの代替として広く採用されています。

Standard File Storage: HDD ベース、汎用シナリオ向け・コスト安、最大 100 TB/Share。トランザクション課金 (操作回数ベース)。Premium File Storage: SSD ベース、低レイテンシ (1-2 ms) / 高 IOPS (100,000+)、最大 100 TB/Share、容量ベース固定課金 (操作無料)。判断: アプリケーションの File I/O が頻繁・低レイテンシ必須 (DB ファイル・ML データセット) → Premium、Lift and Shift・アーカイブ・低頻度アクセス → Standard。Premium は専用 FileStorage アカウント種別が必要 (汎用 StorageV2 では Premium File 不可)。本番要件分析時に IOPS / Throughput / レイテンシの 3 軸で要件定義してから選定するのが定石です。

SMB プロトコル: Windows ネイティブ、Active Directory 認証 (Entra Domain Services・オンプレ AD)、Windows ファイルサーバー互換、SMB 2.1/3.0/3.1.1 対応。代表的ユースケース: Windows VM のファイル共有・ユーザープロファイル・Office ドキュメント共有。NFS プロトコル: Linux / Unix ネイティブ、NFSv4.1 対応 (Premium FileStorage のみ)、Active Directory 不要 (匿名アクセス、IP ベース制御)。代表的ユースケース: Linux VM / AKS Pod のファイル共有・HPC ワークロード・データ分析パイプライン。判断: Windows ワークロード = SMB、Linux / Container = NFS が標準。SMB と NFS を同一 Share で混在不可、用途別に別 Share を作成する必要があります。

Azure Files SMB は 3 つの AD 認証方式: 1) On-premises Active Directory Domain Services (AD DS): 既存オンプレ AD に Domain Join した VM からアクセス、Storage Account を AD Computer Object として登録、最も柔軟。2) Microsoft Entra Domain Services (Entra DS): クラウド側のマネージド AD、Entra ID と同期、オンプレ AD なし環境向け。3) Microsoft Entra Kerberos (Hybrid User): ハイブリッド ID 環境で Microsoft Entra ID 直接認証、Entra Connect 同期ユーザー対象、最新推奨方式。設定: Storage Account → File shares → Active Directory: → 認証方式選択 + Domain Join 構成。RBAC ロール (Storage File Data SMB Share Contributor 等) で アクセス制御。本番では Entra Kerberos が現代的なベストプラクティスです。

Azure File Sync は、オンプレ Windows ファイルサーバーと Azure Files を同期する Microsoft マネージドハイブリッドファイルサーバー機能。代表的シナリオ: 1) オンプレファイルサーバーから Azure Files への段階的移行 (Cloud Tiering で頻繁アクセスファイルはローカル、それ以外は Azure へ移動)、2) ブランチオフィスファイルサーバーの中央集約 (各拠点 Windows Server → 中央 Azure Files に統合)、3) DR (Disaster Recovery、オンプレ障害時に Azure Files から復旧)。設定: Azure に Storage Sync Service リソース作成 → オンプレ Windows Server に Azure File Sync Agent インストール → Server Endpoint で Sync 開始。コスト最適化 (Cloud Tiering で 80% ストレージ削減可能) と運用簡素化を両立する重要機能です。

AKS では Azure File CSI Driver (Container Storage Interface、組み込み) 経由で Azure Files を Persistent Volume として利用可能。Pod の StorageClass で azurefile-csi (SMB) または azurefile-csi-nfs (NFS) を指定、PVC (Persistent Volume Claim) で容量・アクセスモード (ReadWriteMany 対応) 要求。複数 Pod 間でのファイル共有が可能 (Azure Disk の ReadWriteOnce と対照的)。代表的ユースケース: 1) WordPress の wp-content 共有、2) ML データセット共有、3) ログ集約。Static Provisioning (既存 Azure File Share を Mount) と Dynamic Provisioning (Pod 起動時に自動 Share 作成) の両方をサポート。本番 AKS では Premium FileStorage NFS を選択して低レイテンシ要件に対応する構成が標準です。

重要施策: 1) Private Endpoint で Public 公開を完全遮断 (privatelink.file.core.windows.net Private DNS Zone)、2) Microsoft Entra Kerberos 認証で Entra ID 統合、3) Network Access を Selected Networks に制限 (Allow Trusted Microsoft Services)、4) SMB 3.0+ 強制 (SMB 1.0/2.0 を Disable、暗号化)、5) RBAC で File Share レベル権限制御 (Storage File Data SMB Share Reader/Contributor/Elevated Contributor)、6) Microsoft Defender for Storage 有効化 (悪意のあるファイル検知)、7) Soft Delete 有効化 (誤削除対策、14-365 日)、8) Diagnostic Logs を Log Analytics 送信、9) Backup の Azure Backup for Azure Files 定期取得、10) Customer-Managed Key で暗号化。本番運用では事故防止のためすべての施策が組み合わせとして必要です。

AZ-104 (Administrator) のドメイン 2 (Storage 15-20%) で Azure Files が深く問われる本領域の本命認定。AZ-204 (Developer Associate) で開発者視点での File 操作、AZ-305 (Solutions Architect Expert) でアーキテクチャ選定 (Files vs Blob vs Disk)、AZ-800 / AZ-801 (Windows Server Hybrid) で Azure File Sync 統合、AZ-140 (AVD Specialty) で FSLogix Profile Container 用途。Azure を扱うすべてのエンジニアにとって Azure Files の理解は必須スキルです。