Azure StorageでAzure Filesを展開する場合、最初に決めるべきことは「SMBを使うのか、NFSを使うのか」「直接マウントするのか、Azure File Syncでオンプレミスにキャッシュするのか」「従来のストレージアカウント配下で作るのか、Microsoft.FileSharesとして作るのか」の3点です。結論から言うと、SMB、Azure File Sync、HDD、既存のWindowsファイルサーバー移行が前提ならClassic file shares（Microsoft.Storage）、NFSで共有単位の分離・性能・課金管理を重視する新規構成ならMicrosoft.FileSharesを優先して検討します。Microsoft Learnでは、Microsoft.FileSharesの作成手順とAzure Filesのネットワークエンドポイント構成が2026年5月20日に更新されており、特に管理モデルとネットワーク設計の違いを事前に理解しておくことが重要です。(Microsoft Learn)
Azure Storageの「Plan for an Azure Files Deployment」で最初に押さえるべき結論
Azure Filesの展開計画では、単に「共有フォルダーをAzureに作る」と考えると失敗しやすくなります。実際には、プロトコル、管理モデル、ネットワーク、認証、冗長性、バックアップ、移行方法が互いに関係しています。
特に2026年5月時点の公式情報で重要なのは、Azure Filesに次の2つの管理モデルがある点です。従来型のClassic file sharesはMicrosoft.Storageリソースプロバイダーのストレージアカウント配下に作成します。一方、Microsoft.FileSharesはストレージアカウントを作らず、ファイル共有をトップレベルのAzureリソースとして作成する新しいモデルです。(Microsoft Learn)
実務では、次のように判断すると迷いにくくなります。
| 判断項目 | 選びやすい構成 |
|---|---|
| WindowsクライアントやActive Directory認証でSMB共有を使う | Classic file shares |
| オンプレミスのWindows Serverにキャッシュしたい | Classic file shares + Azure File Sync |
| LinuxアプリケーションからNFS 4.1で使う | Microsoft.FileSharesまたはClassic file shares |
| 共有ごとにネットワーク・セキュリティ・課金を分離したい | Microsoft.FileShares |
| HDDでコストを抑えたい | Classic file shares |
| GRS/GZRS、カスタマー管理キー、Soft deleteなど幅広い機能が必要 | Classic file shares |
| 新規のNFSワークロードでSSD・Provisioned v2前提 | Microsoft.FileShares |
何が変わるのか：管理モデルの選択が設計の起点になる
今回の公式情報で最も大きなポイントは、Azure Filesの計画時に「ストレージアカウント配下のファイル共有」だけを前提にしないことです。
Microsoft.FileSharesでは、ファイル共有をリソースグループ内のトップレベルリソースとして作成できます。これにより、ストレージアカウント単位で共有されていた容量、IOPS、スループット、ネットワーク、セキュリティ設定を、より共有単位で扱いやすくなります。Microsoft Learnでも、Microsoft.FileSharesは共有ごとの容量・性能・ネットワーク・セキュリティ・課金管理をしやすいモデルとして説明されています。(Microsoft Learn)
ただし、Microsoft.FileSharesは万能ではありません。2026年5月時点の公式情報では、Microsoft.FileSharesはNFSのみをサポートし、SMBが必要な場合はClassic file sharesを選ぶ必要があります。また、HDD、Azure File Sync、GRS/GZRS、カスタマー管理キー、Soft delete、AKS CSI driver、Data plane REST APIsなど、一部の機能はClassic file shares側でのみ利用できます。(Microsoft Learn)
変更点を実務目線で整理
| 変更・注目点 | 実務への影響 | 確認すべきこと |
|---|---|---|
| Microsoft.FileSharesがトップレベルリソースとして扱われる | 共有単位で分離設計しやすい | IaC、RBAC、タグ、コスト配賦の単位を見直す |
| Microsoft.FileSharesはNFSのみ | SMB移行では使えない | Windows共有、AD認証、Azure File Sync要件の有無 |
| ネットワーク設定が共有レベルになるケースがある | ClassicとMicrosoft.FileSharesで手順が変わる | Private Endpointの対象、DNSレコード、CLI/PowerShellの指定 |
| Provisioned v2前提の設計が重要になる | 容量だけでなくIOPS・スループットも設計対象になる | 実測値、ピーク時負荷、将来増加分 |
| 自動移行手段は限定的 | ClassicからMicrosoft.FileSharesへ安易に移せない | 新規作成、データコピー、切り替え手順 |
Classic file sharesとMicrosoft.FileSharesの違い
Azure Filesの展開計画では、まず管理モデルを比較します。ここを誤ると、後から「SMBが使えない」「Azure File Syncが使えない」「必要な冗長性を選べない」といった手戻りが発生します。
| 項目 | Classic file shares（Microsoft.Storage） | Microsoft.FileShares |
|---|---|---|
| リソースの作成場所 | ストレージアカウント配下 | リソースグループ内のトップレベルリソース |
| SMB | 対応 | 非対応 |
| NFS | 対応 | 対応 |
| Azure File Sync | 対応 | 非対応 |
| SSD | 対応 | 対応 |
| HDD | 対応 | 非対応 |
| LRS/ZRS | 対応 | 対応 |
| GRS/GZRS | 対応 | 非対応 |
| 共有単位のネットワーク・セキュリティ設定 | 基本はストレージアカウント単位 | 共有単位 |
| カスタマー管理キー | 対応 | 非対応 |
| Soft delete | 対応 | 非対応 |
| 適した用途 | SMB移行、Windows共有、Azure File Sync、幅広い機能要件 | 新規NFS、共有単位の分離、性能・課金の明確化 |
判断基準は単純です。既存のWindowsファイルサーバーやNASの置き換えなら、まずClassic file sharesを検討します。理由は、SMB、Active Directory認証、Azure File Sync、HDD、バックアップや削除保護などの選択肢が広いからです。
一方、LinuxアプリケーションやHPC寄りのワークロードでNFSを使い、共有ごとに明確な性能・ネットワーク境界・コストを持たせたい場合はMicrosoft.FileSharesが候補になります。
展開方式は「直接マウント」か「Azure File Sync」かで分かれる
Azure Filesの展開方式は、大きく2つあります。1つはAzure file shareをクライアントやサーバーから直接マウントする方式、もう1つはAzure File Syncを使ってSMB共有をオンプレミスのWindows Serverにキャッシュする方式です。公式ドキュメントでも、直接マウントとAzure File Syncでは考慮事項が異なると説明されています。(Microsoft Learn)
| 展開方式 | 向いているケース | 注意点 |
|---|---|---|
| 直接マウント | Azure VM、Linuxサーバー、クラウドアプリ、拠点数が少ない構成 | ネットワーク遅延、ポート445、NFSのネットワーク制限を確認 |
| Azure File Sync | 既存のWindowsファイルサーバーを活かす、拠点ユーザーが多い、オンプレミス性能を維持したい | SMBのみ。Microsoft.FileSharesは対象外 |
| SMB over QUIC + Azure File Sync | ポート445を避けたいリモートアクセス構成 | Azure Files自体がSMB over QUICを直接サポートするわけではない |
直接マウントは、ファイルサーバーやNASの管理を減らせる点が利点です。ただし、オンプレミスからSMBで接続する場合、組織やISPがポート445のアウトバウンド通信をブロックしていることがあります。その場合はVPN、ExpressRoute、Private Endpoint、またはAzure File Syncを使った別設計を検討します。(Microsoft Learn)
Azure File Syncは、既存のWindows ServerをAzure Filesのキャッシュとして使えるため、オンプレミスのユーザー体験を維持しながらデータをAzureに集約したい場合に有効です。ただし、Azure File SyncはSMBファイル共有向けであり、Microsoft.FileSharesのNFS共有には対応しません。(Microsoft Learn)
プロトコル選定：SMBとNFSは同じ共有で併用できない
Azure FilesではSMBとNFSを利用できますが、同じファイル共有でSMBとNFSを同時に有効化することはできません。SMB共有とNFS共有を同じストレージアカウント内に作ることはできますが、1つの共有はどちらかのプロトコルで設計します。(Microsoft Learn)
| 項目 | SMB | NFS |
|---|---|---|
| 主な用途 | Windows共有、ユーザーファイル、Active Directory連携、Azure File Sync | Linuxアプリ、POSIX前提のワークロード |
| 認証 | KerberosなどのIDベース認証、またはストレージアカウントキー | ホストベース、ネットワーク制限が前提 |
| 権限管理 | Windows ACL | UNIX権限 |
| 大文字小文字 | 区別しないが保持する | 区別する |
| インターネット経由 | SMB 3.x暗号化で利用可能 | 制限されたネットワークが前提 |
| Azure File Sync | 対応 | 非対応 |
SMBを選ぶべき典型例は、部門共有、プロファイル置き場、オンプレミスWindowsファイルサーバーの移行、AD DSやMicrosoft Entra Domain Servicesと連携したアクセス制御です。
NFSを選ぶべき典型例は、LinuxアプリケーションがPOSIXセマンティクスを前提としている場合や、コンテナ・分析基盤・開発環境などでLinux側から共有ストレージを扱う場合です。ただし、NFSはネットワークレベルの認証に依存するため、Private EndpointまたはService Endpointを使った制限を前提にします。
ネットワーク設計で確認すべきポイント
Azure Filesのトラブルで多いのは、ストレージ作成後にネットワークを後付けで考えるケースです。特にオンプレミス接続、NFS、Private Endpoint、DNS、ファイアウォールは最初に設計しておくべきです。
Azure Filesにはパブリックエンドポイントとプライベートエンドポイントがあります。Classic file sharesではエンドポイントがストレージアカウントに存在しますが、Microsoft.FileSharesではエンドポイントがファイル共有レベルで作成されます。ここが運用手順の大きな違いです。(Microsoft Learn)
Private EndpointとService Endpointの使い分け
| 構成 | 向いているケース | 注意点 |
|---|---|---|
| Public Endpoint | Azure内のSMBアクセス、検証環境、一時的な利用 | 公開範囲、暗号化、ファイアウォール制限を必ず確認 |
| Service Endpoint | 指定VNet・サブネットからのアクセスに限定したい | パブリックIP経由のまま、許可元を検証する方式 |
| Private Endpoint | オンプレミス接続、静的IP、閉域寄りの設計、高可用性重視 | DNS設計とPrivate DNS Zone連携が必須級 |
| VPN/ExpressRoute + Private Endpoint | オンプレミスからSMB/NFSを安定利用したい | 名前解決と経路制御を事前に検証 |
オンプレミスからPrivate Endpoint経由でSMBまたはNFSを利用する場合は、VPNまたはExpressRouteでAzure VNetへ接続する必要があります。Private Endpointを作成しても、パブリックエンドポイントが自動的に無効になるわけではありません。必要に応じてPublic network accessを無効化し、意図しない経路からの接続を遮断します。(Microsoft Learn)
DNS設計は後回しにしない
Private Endpointを使う場合、名前解決は非常に重要です。Azure内ではPrivate DNS ZoneによってプライベートIPに解決できても、オンプレミス側のDNSがその設定を参照できなければ、クライアントはパブリックIPへ向いてしまう可能性があります。
本番環境では、hostsファイルで個別端末に設定する方法は避けるべきです。クライアントごとに変更が必要になり、Private Endpointやストレージ構成の変更にも追随しにくいからです。公式ドキュメントでも、オンプレミスDNSからAzure側のPrivate DNS Zoneへ転送する設計が選択肢として示されています。(Microsoft Learn)
認証と権限：ストレージアカウントキー運用は避ける
SMB共有では、可能な限りIDベース認証を使います。Azure Filesでは、オンプレミスAD DS、Microsoft Entra Domain Services、Microsoft Entra Kerberosなどの認証方式を利用できます。既存のWindowsファイルサーバーと同じような権限管理を目指す場合は、ストレージアカウントをドメイン参加させ、Kerberosベースの認証を使う構成が現実的です。(Microsoft Learn)
一方、ストレージアカウントキーでSMB共有をマウントする方法は、セキュリティ面で慎重に扱う必要があります。ストレージアカウントキーによるマウントは実質的に管理者権限に近く、共有内のファイルやフォルダーに広い権限を持つためです。やむを得ず使う場合は、Private EndpointやService Endpointでネットワークを制限し、キーの保管・ローテーション・利用者を厳格に管理します。
NFSの場合は、SMBのようなユーザー単位のKerberos認証ではなく、ネットワーク制限を前提にした設計になります。そのため、NFS共有を作る前に「どのVNet・サブネット・オンプレミス拠点から接続できるか」を明確にしておく必要があります。
暗号化：転送中の暗号化を無効化する前に影響を確認する
Azure Filesでは、保存時の暗号化と転送中の暗号化を分けて考えます。保存時の暗号化はAzure Storageのサービス側暗号化により行われます。転送中の暗号化は、SMB、NFS、FileRESTのプロトコルごとに確認が必要です。
新しいストレージアカウントをAzure Portalで作成する場合、SMBやNFSの転送中暗号化を要求する設定は既定で有効です。一方、PowerShell、Azure CLI、FileREST APIで作成した場合は、後方互換性のため既定値が異なる場合があります。既存ストレージアカウントでは、プロトコル別の設定を明示的に構成するまで、従来のSecure transfer required設定が動作に影響します。(Microsoft Learn)
特に古いOSや古いアプリケーションのために転送中暗号化を無効化する場合は、次の点を確認します。
| 確認項目 | 理由 |
|---|---|
| SMB 3.x暗号化に対応しているか | 対応していないクライアントはマウントできない可能性がある |
| SMB 2.1を使う必要が本当にあるか | セキュリティと接続元リージョンの制約が大きい |
| HTTPのFileRESTアクセスを許可していないか | Secure transfer requiredを無効にするとHTTPが許可される場合がある |
| 例外設定が一時対応か恒久対応か | 古いOSの延命策を標準構成にしないため |
性能とコスト：容量だけでなくIOPSとスループットも設計する
Azure Filesのコストと性能は、単純な容量だけでは決まりません。特にMicrosoft.FileSharesではProvisioned v2課金モデルを使い、容量、IOPS、スループットを共有単位で指定します。公式手順でも、Microsoft.FileSharesでは32GiBから262,144GiBまでのProvisioned capacityを指定し、推奨値または手動でIOPS・スループットを設定できると説明されています。(Microsoft Learn)
Classic file sharesでも、複数のファイル共有を同じストレージアカウントに置く場合は注意が必要です。ストレージアカウントは容量、IOPS、スループットの共有プールになります。アクセス頻度の高い共有を同じアカウントに詰め込むと、ピーク時に性能ボトルネックが発生しやすくなります。
SSDとHDDの選び方
| メディア | 向いている用途 | 判断基準 |
|---|---|---|
| SSD | データベース周辺、Webホスティング、開発環境、低遅延が必要なアプリ | レイテンシ、IOPS、安定した性能を重視 |
| HDD | 部門共有、一般的なファイル置き場、低頻度アクセス | コスト重視、数ミリ秒単位の低遅延が不要 |
| Azure File Sync + HDD/SSD | オンプレミスにホットデータを置き、Azureに集約 | ユーザー体験とクラウド集約の両立 |
注意点として、ストレージアカウント内に作成したファイル共有は、作成後にメディア層を直接変更できません。HDDからSSDへ移す場合は、新しいSSD共有を作成し、データをコピーする必要があります。計画段階で「現在の負荷」だけでなく「移行後にアプリがAzure Filesを直接使う可能性」まで考えておくと手戻りを減らせます。(Microsoft Learn)
冗長性とDR：LRS/ZRS/GRS/GZRSは管理モデルとメディアで選択肢が変わる
Azure Filesでは、LRS、ZRS、GRS、GZRSなどの冗長性を選択できます。ただし、すべての構成で全オプションを選べるわけではありません。公式ドキュメントでは、HDD file sharesは4種類の冗長性をサポートし、SSD file sharesはLRSとZRSのみとされています。また、Microsoft.FileSharesはLRSとZRSのみです。(Microsoft Learn)
| 冗長性 | 概要 | 向いているケース |
|---|---|---|
| LRS | 同一リージョン内の単一データセンター相当で複数コピー | コスト重視、検証、影響範囲が限定的な用途 |
| ZRS | 同一リージョン内の複数可用性ゾーンにコピー | リージョン内の可用性を高めたい本番用途 |
| GRS | セカンダリリージョンへ非同期レプリケーション | リージョン障害への備えが必要な用途 |
| GZRS | ZRSとGRSを組み合わせた構成 | 可用性とリージョンDRを両方重視する用途 |
DR計画では、冗長性だけでなく復旧手順も必要です。たとえば、GRS/GZRSは非同期レプリケーションであるため、障害時に未レプリケートのデータが失われる可能性があります。RPO/RTOを業務側と合意し、定期的に復旧テストを行うべきです。
データ保護：Soft delete、スナップショット、Azure Backupを事前に組み込む
Azure Filesのデータ保護では、誤削除、ランサムウェア、設定ミス、リージョン障害を分けて考えます。
Classic file sharesではSoft deleteを利用できます。Soft deleteは削除されたファイル共有を一定期間復元できるストレージアカウントレベルの設定です。新しいストレージアカウントでは既定で有効とされていますが、保持期間や運用ルールは業務要件に合わせて確認します。(Microsoft Learn)
スナップショットは読み取り専用のポイントインタイムコピーです。Azure Filesでは1共有あたり最大200個のスナップショットを作成でき、最大10年保持できます。Azure Backupを使うと、日次、週次、月次、年次といった保持設計を組み込みやすくなります。(Microsoft Learn)
| 対策 | 目的 | 実務上のポイント |
|---|---|---|
| Soft delete | 共有の誤削除対策 | 保持期間を短すぎず長すぎず設定 |
| Share snapshots | ファイル・フォルダー単位の復元 | 変更頻度と保持数を設計 |
| Azure Backup | スケジュール・保持・復元管理 | 監視、アラート、復元手順も確認 |
| Microsoft Defender for Storage | 不審な操作や脅威検知 | サブスクリプション単位の有効化を検討 |
| DR手順 | リージョン障害への備え | フェールオーバー時の影響とRPOを明文化 |
バックアップは「有効化したら終わり」ではありません。復元先を元の場所にするのか、別の共有にするのか、権限をどう戻すのか、業務アプリが開いているファイルをどう扱うのかまで確認します。
移行時の注意点：既存ファイルサーバーの棚卸しから始める
オンプレミスのファイルサーバーやNASからAzure Filesへ移行する場合、最初にやるべきことはツール選定ではなく棚卸しです。次の情報を集めると、Azure Filesの管理モデルと展開方式を決めやすくなります。
| 棚卸し項目 | 確認する理由 |
|---|---|
| 共有数とフォルダー構造 | Azure File Syncの同期グループ、共有数、移行単位を決める |
| ファイル数・フォルダー数 | 初期同期時間、メモリ要件、スキャン時間に影響 |
| 合計容量と増加率 | Provisioned capacity、課金、バックアップ保持に影響 |
| ピーク時IOPS・スループット | SSD/HDD、Provisioned v2、ストレージアカウント分割に影響 |
| ACLと認証方式 | AD DS、Entra Domain Services、Entra Kerberosの選定に影響 |
| 拠点・接続元IP・VNet | Private Endpoint、Service Endpoint、VPN/ExpressRouteに影響 |
| アプリケーション依存 | SMB/NFS、ファイルロック、大文字小文字、POSIX要件に影響 |
Azure File Syncを使う場合は、Windows Server側の要件も確認します。Azure File SyncはWindows Server 2016以降の複数バージョンをサポートしますが、運用では最新のWindows Updateを適用しておくことが推奨されています。また、ファイル数が多い環境ではCPUやメモリ要件が大きくなり、初期同期時には特にリソースを多めに見積もる必要があります。(Microsoft Learn)
管理者が確認すべき設定チェックリスト
本番展開前に、管理者は次の項目を確認します。特にネットワークと認証は、作成後に直すより事前設計した方が安全です。
| 分野 | 確認項目 |
|---|---|
| 管理モデル | Classic file sharesかMicrosoft.FileSharesか |
| プロトコル | SMBかNFSか。同一共有で併用しようとしていないか |
| リージョン | Microsoft.FileSharesの対象リージョンか |
| ストレージ階層 | SSDかHDDか。作成後の直接変更ができないことを理解しているか |
| 課金 | Provisioned v2で容量・IOPS・スループットを見積もったか |
| 冗長性 | LRS/ZRS/GRS/GZRSの選択肢が構成に合っているか |
| ネットワーク | Private Endpoint、Service Endpoint、Public network accessを決めたか |
| DNS | Private DNS Zone、オンプレミスDNSフォワード、名前解決テストを行ったか |
| 認証 | SMBでIDベース認証を使うか。ストレージキー依存を避けているか |
| 暗号化 | SMB/NFS/FileRESTの転送中暗号化設定を確認したか |
| バックアップ | Soft delete、スナップショット、Azure Backupの保持期間を決めたか |
| 監視 | Azure Monitor、Defender for Storage、アラートを設計したか |
| 移行 | データコピー、差分同期、切り替え、ロールバック手順を用意したか |
開発者が確認すべき展開・実装上の注意点
開発者やSREがAzure Filesをアプリケーションから利用する場合は、単にマウントできるかではなく、アプリのファイルアクセス特性に合うかを確認します。
特にNFSを使うLinuxアプリでは、大文字小文字の区別、UNIX権限、ファイルロック、シンボリックリンク、ハードリンクなどがSMBとは異なります。逆にWindowsアプリでSMBを使う場合は、Win32セマンティクス、ACL、Kerberos認証、ファイルロックの挙動を確認します。
また、Microsoft.FileSharesをCLIで作成する場合はfileshares拡張を追加し、az fileshare createでNFS、冗長性、Provisioned capacity、必要に応じてIOPSやスループットを指定します。PowerShellではAz.FileShareモジュールを使う手順が示されています。(Microsoft Learn)
開発環境ではマウントできても、本番環境で失敗する典型例は次の通りです。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| Azure Portalでは見えるがファイル一覧で403になる | ブラウザーからデータプレーンへのアクセス元IPが許可されていない | Azure MonitorログでCallerIpAddressを確認 |
| オンプレミスからPrivate Endpointに向かない | DNSがパブリックIPを返している | DNSフォワードと名前解決を修正 |
| NFS共有に接続できない | ネットワーク制限が未設定、または許可サブネットが違う | Service EndpointまたはPrivate Endpointを確認 |
| SMBが外部からつながらない | ポート445がブロックされている | VPN/ExpressRoute、Azure File Sync、SMB over QUIC構成を検討 |
| 期待した性能が出ない | 共有・ストレージアカウント単位のIOPS/スループット不足 | 実測値を基にProvisioned値や配置を見直す |
既存環境への影響範囲
既存のClassic file sharesを使っている環境では、今回の情報によって直ちに移行が必須になるわけではありません。公式ドキュメントでも、必要機能がMicrosoft.FileSharesにない場合やSMBが必要な場合はClassic file sharesが推奨され、Classic experienceの非推奨化は残る機能差が埋まるまで始まらないと説明されています。また、Classic file sharesからMicrosoft.FileSharesへの自動移行サポートは現時点で用意されていません。(Microsoft Learn)
そのため、既存環境では次の方針が現実的です。
| 既存構成 | 推奨アクション |
|---|---|
| SMB共有を運用中 | 継続利用を前提に、認証・暗号化・ネットワーク・バックアップを点検 |
| Azure File Syncを利用中 | Classic file shares前提で設計を維持 |
| NFS共有を新規作成予定 | Microsoft.FileSharesとClassic file sharesを比較 |
| 複数共有を同一ストレージアカウントに集約中 | IOPS、スループット、セキュリティ境界を再確認 |
| パブリックエンドポイントを許可中 | Private EndpointやService Endpointへの移行可否を評価 |
展開前に決めるべき実践的な設計順序
Azure Filesの設計は、次の順序で進めると手戻りを減らせます。
| 手順 | 決めること | 成果物 |
|---|---|---|
| 1 | SMBかNFSか | プロトコル選定表 |
| 2 | Classic file sharesかMicrosoft.FileSharesか | 管理モデルの決定 |
| 3 | 直接マウントかAzure File Syncか | 展開方式 |
| 4 | SSDかHDDか、容量・IOPS・スループット | 性能・コスト見積もり |
| 5 | LRS/ZRS/GRS/GZRS | 可用性・DR方針 |
| 6 | Public/Private/Service Endpoint | ネットワーク構成図 |
| 7 | DNS、認証、暗号化 | セキュリティ設計 |
| 8 | Soft delete、スナップショット、Azure Backup | データ保護設計 |
| 9 | 移行・切り替え・ロールバック | 移行手順書 |
| 10 | 監視・アラート・運用権限 | 運用設計書 |
この順序で整理すると、「あとからSMBが必要だと分かった」「NFSなのにネットワーク制限を設計していなかった」「性能不足で共有を作り直す」といった典型的な失敗を避けやすくなります。
まとめ：Azure Files Deploymentは管理モデル・ネットワーク・認証を先に決める
Azure Storageの「Plan for an Azure Files Deployment」で重要なのは、Azure Filesを単なるクラウド上の共有フォルダーとして扱わないことです。
SMB、Azure File Sync、Windowsファイルサーバー移行、HDD、幅広いデータ保護機能が必要ならClassic file sharesを中心に考えます。NFSの新規ワークロードで、共有単位の分離、Provisioned v2、SSD、LRS/ZRS、ファイル共有レベルのネットワーク設定を重視するならMicrosoft.FileSharesを検討します。
次に取るべき行動は、既存または予定しているファイル共有ごとに「プロトコル」「管理モデル」「接続元」「認証方式」「容量・性能」「冗長性」「バックアップ」を1枚の一覧にすることです。その一覧をもとに、Classic file sharesで進める共有とMicrosoft.FileSharesを検討する共有を分ければ、移行・展開・運用の判断が具体化します。
コメント