AWS FSxからAzure FilesへAgentless移行する方法｜Azure Storage Mover

AWS FSx for Windows File ServerからAzure Filesへ移行したいものの、AWS側に一時的なEC2インスタンスや移行エージェントを配備したくない場合は、Azure Storage Moverのエージェントレス移行が有力な選択肢です。

2026年9月時点ではPublic Previewですが、AWS FSx for Windows File ServerのSMB共有からAzure FilesのSMB共有へ、移行エージェントを利用者側で配備・管理せずにデータをコピーできます。転送にはAzureとAWSネットワーク間のプライベート接続を使用します。

ただし、エージェントレスとは「事前準備が不要」という意味ではありません。AzureとAWSを結ぶネットワーク、FSxの認証情報を保管するAzure Key Vault、RBAC、Azure Filesの認証方式、差分転送とカットオーバーの設計は必要です。

この記事では、AWS FSxからAzure FilesへのAgentless移行の仕組み、前提条件、Azureポータルでの構成手順、コピーモードの選び方、権限移行で失敗しやすいポイントまで具体的に解説します。

AWS FSxからAzure FilesへのAgentless移行とは

今回追加された機能では、Azure Storage Moverが次の経路でSMBファイルを転送します。

AWS FSx for Windows File Server
        ↓ SMB／プライベート接続
Azure Storage Moverが管理する転送処理
        ↓
Azure Files SMB共有

従来のオンプレミスSMB移行では、ソース共有の近くにStorage Mover Agent用の仮想マシンを配置する構成が一般的でした。AWS FSx向けのクラウド間移行では、利用者が移行エージェントVMを用意する必要がありません。

項目	AWS FSx向けAgentless移行
ソース	AWS FSx for Windows File Server
ソースプロトコル	SMB 2.xまたはSMB 3.x
移行先	Azure FilesのSMB共有
移行エージェント	利用者側での配備・管理は不要
データ経路	AzureとAWS間のプライベート接続
ソース認証情報	Azure Key Vaultに保存
実行管理	Azure Storage Moverのプロジェクトとジョブ
移行方式	初回コピーと差分コピーを繰り返す段階移行

Storage Moverは、FSxの共有をソースエンドポイント、Azure Filesをターゲットエンドポイントとして管理します。プロジェクト内にジョブ定義を作成し、初回コピーと差分コピーを必要な回数だけ実行できます。(Microsoft Learn)

エージェントレスで不要になるものと、引き続き必要なもの

Agentless移行で省略できるのは、主に転送用コンピュートの構築と運用です。

項目	必要性	補足
AWS上の移行エージェントVM	不要	EC2へのエージェント配備や更新管理が不要
AzureとAWS間のネットワーク	必要	FSxのプライベートIPまたはFQDNへ到達できる経路が必要
FSxのSMB認証情報	必要	ユーザー名とパスワードをKey Vaultへ保存
Azure Files共有	必要	ジョブ作成前に移行先を作成
Storage Moverリソース	必要	エンドポイント、プロジェクト、ジョブを管理
RBAC設定	必要	Key VaultとAzure Filesへのアクセス権を付与
利用者向けの認証・権限設定	必要	Azure FilesのIDベース認証と共有レベル権限は別途構成
カットオーバー作業	必要	書き込み停止、最終差分コピー、UNCパス切り替えを実施

特に注意したいのは、Agentless移行がAzureとAWS間のVPNや専用線まで自動構築するわけではない点です。ネットワーク経路とルーティングは利用者側で準備します。

Public Preview時点の対応範囲と制限

AWS FSxからAzure Filesへの移行には、Public Preview時点で次の制限があります。

項目	内容
1ジョブ当たりの上限	最大5億オブジェクト
同時実行数	1サブスクリプション当たり最大10ジョブ
同一ターゲットへの実行	Preview中はAzureファイル共有ごとに同時実行を1ジョブに限定
SMBバージョン	SMB 2.x、SMB 3.xをサポート
SMB 1.x	非サポート
ソースデータ	コピー後もFSxに残る
移行先データ	Azure Filesがサポートする範囲でメタデータを保持

5億オブジェクトはデータ容量ではなく、ファイルとフォルダーを合わせた数です。大量の小さいファイルを保存している共有では、容量が数TB程度でもオブジェクト数が先に上限へ達する可能性があります。共有全体が上限を超える場合は、サブパス単位でジョブを分割します。(Microsoft Learn)

Storage MoverによるSMBからAzure Filesへの移行では、Azure Filesが対応する範囲で、ディレクトリ構造、ファイルやフォルダーのACL、ファイル属性、作成日時、変更日時、更新日時が保持されます。一方、最終アクセス日時は移行先でサポートされません。(Microsoft Learn)

Azure Storage Moverによる移行が適しているケース

次のような環境では、AWS FSxからAzure FilesへのAgentless移行が適しています。

AWSからAzureへのクラウド集約を進めている
FSx上のWindowsファイル共有をAzure Filesへ移したい
移行専用のEC2や仮想アプライアンスを増やしたくない
ファイルとフォルダーのACLやタイムスタンプをできるだけ保持したい
初回コピー後に差分コピーを繰り返し、停止時間を短縮したい
Azureポータルで複数の移行ジョブを一元管理したい

反対に、AzureとAWS間にプライベート接続を用意できない環境、SMB 1.xを使用している環境、Public Preview機能を本番で利用できないポリシーの組織には向きません。

また、Storage Moverは移行を管理するサービスです。双方向のリアルタイム同期や、FSxとAzure Filesを常時Active-Activeで運用する仕組みとして考えるべきではありません。

移行前に準備するもの

作業開始前に、次の項目をそろえます。

分類	必要なもの
AWS	FSx for Windows File Server、対象共有へのアクセス権
FSx情報	FSxのFQDNまたはプライベートIP、共有名
Azure	Azureサブスクリプション、リソースグループ
移行管理	Azure Storage Moverリソース
移行先	Azure Storageアカウント、Azure Files SMB共有
資格情報	Azure Key Vault、ユーザー名とパスワードの2つのシークレット
ネットワーク	AzureからFSxへ到達できるプライベート接続
権限	Storage Mover関連リソースを作成し、RBACを割り当てる権限
監視	Log Analyticsワークスペースと診断設定
利用者アクセス	Azure FilesのIDベース認証、共有レベルRBAC、Windows ACL

FSxの認証情報は、ユーザー名とパスワードを1つのシークレットへまとめるのではなく、それぞれ別のKey Vaultシークレットとして保存します。ソースエンドポイントでは、そのシークレット名またはシークレットURIを指定します。(Microsoft Learn)

Private Connectionの構成を先に固める

AgentlessでもVPNや専用線は必要

Azure Storage Moverが移行エージェントを代行しても、AzureからAWS VPC内のFSxへ到達するネットワークは必要です。

主な選択肢は次のとおりです。

接続方式	適したケース	注意点
Site-to-Site IPsec VPN	パイロット、短期間の移行、比較的小規模なデータ	インターネット品質やVPN Gatewayの性能に影響される
ExpressRouteとAWS Direct Connectの接続	大容量、安定した帯域、長期間の利用	回線調達の期間とコストがかかる
SD-WAN／NVA	既存のマルチクラウドネットワークを利用したい	仮想アプライアンスの性能設計と運用が必要

Site-to-Site VPNは暗号化されたトンネルですが、物理的にはインターネットを経由します。完全な専用経路が必要な場合は、ExpressRouteとAWS Direct Connectを接続する構成を検討します。(Microsoft Learn)

Storage MoverのPrivate Connectionを承認する

ネットワーク経路を構成した後、Storage Mover側でもPrivate Connectionを作成します。

Microsoft Learnでは、Private Link Service Direct Connectを事前に用意し、それを参照するPrivate ConnectionをStorage Mover内に作成する構成が案内されています。作成した接続は承認し、状態をApprovedにする必要があります。Pending、Rejected、Disconnectedの接続は移行ジョブで選択できません。(Microsoft Learn)

確認するポイントは次のとおりです。

Azure側サブネットからAWS VPCのルートが存在する
AWS側からAzure側への戻りルートが存在する
FSxのFQDNをAzure側から名前解決できる
FSxのプライベートIPへTCP 445で到達できる
AWS Security GroupとNetwork ACLが通信を許可している
Azure NSGやNVA、ファイアウォールが通信を遮断していない
Storage MoverのPrivate ConnectionがApprovedになっている

移行用ネットワークと利用者用ネットワークを分けて考える

Storage MoverのPrivate Connectionは、移行サービスがFSxへアクセスするための経路です。移行後に利用者やアプリケーションがAzure Filesへアクセスする経路まで、自動的に完成するわけではありません。

アプリケーションをAWS側に残す場合は、AWSからAzure Filesへ継続的にアクセスするネットワーク、DNS、TCP 445の許可、遅延を別途検証します。アプリケーションもAzureへ移す場合は、Azure FilesのPrivate EndpointやAzure VNet内の名前解決を含めて設計します。

ACLを保持しても、そのままアクセスできるとは限らない

AWS FSx for Windows File Serverは、Microsoft Active Directoryを使ってSMB認証とファイル・フォルダーレベルのアクセス制御を行います。(AWS ドキュメント)

Azure FilesもWindows ACLを利用できますが、アクセス許可は次の2段階で判定されます。

Azure RBACによる共有レベルのアクセス許可
ファイルやフォルダーに設定されたWindows ACL

Azure Filesでは、AD DS、Microsoft Entra Domain Services、Microsoft Entra KerberosのいずれかをIDソースとして使用します。1つのストレージアカウントに設定できるIDソースは1種類です。(Microsoft Learn)

そのため、ファイルACLが正常にコピーされても、Azure Files側で共有レベルのRBACを割り当てていなければ、利用者は共有へ接続できません。Azure Filesでは、ユーザーまたはグループに共有レベルのロールを割り当て、その後にWindows ACLで細かな権限を制御します。(Microsoft Learn)

特に、FSxがAWS Managed Microsoft ADに参加し、Azure Filesが無関係な別ディレクトリを使用する構成では注意が必要です。移行されたACLに元のSIDが残っても、新しいID環境で正しく認証・解決できない可能性があります。

本番移行前に、次の点を決めてください。

FSxとAzure Filesで同じAD DSを利用するか
別ドメインの場合に信頼関係やID移行を行うか
オンプレミスAD DSのユーザーとグループをMicrosoft Entra IDへ同期するか
Azure Filesの共有レベルRBACをどのグループへ割り当てるか
SIDを引き継げないACLをどのように再設定するか
サービスアカウントやコンピューターアカウントのアクセスをどう扱うか

AWS FSxからAzure Filesへ移行する手順

移行対象を棚卸しする

最初に、共有ごとに次の情報を収集します。

FSxのFQDN
共有名
データ容量
ファイル数とフォルダー数
変更頻度
利用者とアプリケーション
ファイル・フォルダーACL
サービスアカウント
現在のUNCパス
許容できる停止時間

複数の業務システムが同じFSxを利用していても、移行プロジェクトはワークロード単位に分ける方が安全です。カットオーバーの日時、検証項目、ロールバック判断を個別に管理できます。

いきなり全共有を対象にせず、データ量が少なく業務影響の小さい共有をパイロットとして選びます。

移行先のAzure Filesを作成する

Azure StorageアカウントとSMBファイル共有を作成します。

この段階で、次の項目を決めます。

Azureリージョン
Azure Filesのストレージ性能
冗長性
必要な容量
ストレージアカウントと共有の分割単位
Public EndpointまたはPrivate Endpoint
利用するIDソース
共有レベルのRBAC

高いIOPSやスループットが必要な共有を、低負荷の共有と安易に同じストレージアカウントへ集約しないようにします。移行速度だけでなく、移行後の通常運用時に必要な性能を基準に選んでください。

AzureとAWS間のプライベート接続を構成する

Site-to-Site VPN、ExpressRouteとAWS Direct Connect、またはSD-WANなどでAzure VNetとAWS VPCを接続します。

接続後は、Azure側の確認用VMなどから次のようなテストを行います。

Resolve-DnsName <FSxのFQDN>
Test-NetConnection <FSxのFQDN> -Port 445

名前解決には成功するもののTCP 445へ接続できない場合は、AWS Security Group、Network ACL、ルートテーブル、Azure NSG、ファイアウォールを確認します。

Azure Key VaultへFSxの資格情報を保存する

Azure Key Vaultへ、次の2つのシークレットを作成します。

fsx-username
fsx-password

本番利用者の個人アカウントではなく、移行専用アカウントを用意するのが安全です。対象共有のファイル、フォルダー、属性、ACLを読み取れる権限を付与し、移行完了後に無効化または削除できるようにします。

Azure Storage Moverリソースを作成する

AzureポータルでAzure Storage Moverを検索し、リソースを作成します。

Storage Moverは移行全体を管理する上位リソースです。その配下に次のリソースを作成します。

Azure Storage Mover
├─ Source endpoint
├─ Target endpoint
├─ Private connection
└─ Project
   └─ Job definition
      └─ Job run

Storage Moverリソースを作成できるリージョンは変更される可能性があるため、ポータルに表示される最新の対応リージョンを確認してください。

AWS FSxのソースエンドポイントを作成する

Storage Moverリソースを開き、次の順に進みます。

Resource Management
→ Storage endpoints
→ Source endpoints
→ Create endpoint

作成画面で次のように設定します。

設定項目	指定内容
Migration type	`Multicloud migration`
Source type	`AWS FSx - SMB`
Host name or IP address	FSxのFQDNまたはプライベートIP
Share name	共有名のみ
Key vault	資格情報を保存したKey Vault
Username secret	ユーザー名のシークレット
Password secret	パスワードのシークレット

共有名には、先頭のバックスラッシュを含めません。

正しい指定例はDataです。

誤った指定例は\\fsx.example.local\Dataや\\Dataです。ホスト名と共有名は別々の欄に入力します。(Microsoft Learn)

ポータルでロールが自動割り当てされなかった場合は、ソースエンドポイントのマネージドIDに対して、Key VaultのKey Vault Secrets Userロールを付与します。

Azure Filesのターゲットエンドポイントを作成する

Storage Moverで次の順に進みます。

Resource Management
→ Storage endpoints
→ Target endpoints
→ Add endpoint

次の項目を指定します。

設定項目	指定内容
Subscription	Azure Filesを作成したサブスクリプション
Storage account	移行先のストレージアカウント
Target type	`File share`
Protocol	SMB
File share	移行先のAzureファイル共有

ロールが自動割り当てされない場合は、ターゲットエンドポイントのマネージドIDにStorage File Data Privileged Contributorを割り当てます。このロールにより、既存ACLを扱いながらAzure Filesへデータを書き込めます。(Microsoft Learn)

Private Connectionを作成して承認する

Storage MoverのStorage endpointsからPrivate Connectionを作成し、事前に構成したPrivate Link Service Direct Connectを関連付けます。

作成後は、接続状態がApprovedであることを確認します。承認されていない接続は、ジョブ定義作成時の候補に表示されません。

プロジェクトとジョブ定義を作成する

Storage MoverのProjectsからプロジェクトを作成します。

プロジェクト名は、技術要素ではなく移行する業務やワークロードに合わせると管理しやすくなります。

推奨例：AccountingFiles-Migration
非推奨例：Migration-01

プロジェクト内でジョブ定義を作成し、次の項目を設定します。

設定項目	指定内容
Migration type	`Multicloud migration`
Source type	`AWS FSx - SMB`
Source endpoint	作成したFSxエンドポイント
Target endpoint	作成したAzure Filesエンドポイント
Source sub-path	必要に応じて対象フォルダーを限定
Target sub-path	必要に応じて格納先を指定
Private connections	`Approved`状態の接続
Copy mode	AdditiveまたはMirror

AdditiveとMirrorは削除動作で選ぶ

Storage Moverのコピーモードは、初回コピーよりも2回目以降の差分コピーで大きな違いが出ます。

コピーモード	動作	適したケース
Additive	ターゲットだけに存在するファイルを残す。同じパスのファイルはソースに合わせて更新する	初回移行、既存データを削除したくない場合
Mirror	ソースに存在しないターゲット側のファイルを削除する	移行先をソースと完全に一致させたい場合

Additiveでは、ソース側でフォルダー名を変更すると、旧フォルダーがターゲット側に残り、重複する可能性があります。Mirrorでは旧フォルダーを削除できますが、移行先だけに存在するデータも削除対象になります。(Microsoft Learn)

重要: AWS FSx向けのMicrosoft Learnには、初回移行でMirrorを設定する記述と、初回はAdditiveを推奨する記述が同じページ内に混在しています。さらに掲載されているCLI例はAdditiveです。削除事故を避けるため、ターゲットに既存データがある場合や初回パイロットではAdditiveを選び、完全同期が必要な専用ターゲットに限ってMirrorを検討するのが安全です。(Microsoft Learn)

ジョブを開始してログを監視する

ジョブ定義を開き、Start jobを選択して初回コピーを開始します。

監視する項目は次のとおりです。

転送済みファイル数
転送済みデータ量
スループット
失敗したファイル数
スキップされたファイル
エラー内容
ジョブの開始時刻と終了時刻

Log AnalyticsワークスペースとStorage Moverの診断設定は、初回ジョブを開始する前に構成してください。診断設定より前に生成されたログは、後からLog Analyticsへ復元できません。(Microsoft Learn)

初回コピー後に検証する項目

ジョブがCompletedになっただけで、本番切り替え可能と判断してはいけません。

検証対象	確認内容
ジョブ結果	失敗ファイル数が0か
ディレクトリ	フォルダー階層が一致しているか
ファイル数	主要フォルダーごとの件数が一致しているか
データ量	論理サイズに大きな差がないか
ファイル内容	重要ファイルのハッシュが一致するか
タイムスタンプ	作成日時と更新日時が保持されているか
Windows ACL	所有者、継承、許可、拒否が想定どおりか
利用者アクセス	読み取り、書き込み、削除が権限どおりか
アプリケーション	ファイル作成、更新、名前変更、ロックが正常か
性能	通常時と高負荷時の応答時間が許容範囲か

重要ファイルの内容は、PowerShellでハッシュを比較できます。

Get-FileHash "\\<FSx-FQDN>\<share>\重要ファイル.xlsx" -Algorithm SHA256
Get-FileHash "\\<storage-account>.file.core.windows.net\<share>\重要ファイル.xlsx" -Algorithm SHA256

ACLはicaclsで確認できます。

icacls "\\<FSx-FQDN>\<share>\対象フォルダー"
icacls "\\<storage-account>.file.core.windows.net\<share>\対象フォルダー"

数百万ファイルをすべてハッシュ計算すると負荷が高くなるため、業務上重要なファイル、サイズの大きいファイル、更新頻度の高いファイルを抽出して確認します。

差分コピーとカットオーバーを実施する

停止時間を短縮するには、初回コピー後もFSxを稼働させたまま、複数回の差分コピーを実行します。

推奨する流れは次のとおりです。

FSxを稼働させたまま初回コピーを実行する
Azure Files側のデータ、ACL、アプリケーション動作を検証する
必要に応じて差分コピーを複数回実行する
カットオーバー日時を利用者へ通知する
FSxへの書き込みを停止する
最終差分コピーを実行する
失敗ファイルがないことを確認する
利用者やアプリケーションの接続先をAzure Filesへ変更する
本番動作を確認する
一定期間FSxを読み取り専用で保持する
ロールバック不要と判断してからFSxを廃止する

Azure Filesの標準的なUNCパスは次の形式です。

\\<storage-account-name>.file.core.windows.net\<share-name>

グループポリシー、ログオンスクリプト、DFS Namespace、アプリケーション設定、サービスアカウントの構成など、旧FSxのUNCパスを参照している場所を漏れなく更新します。Microsoftも、最終差分コピー後に接続先をAzure FilesのUNCパスへ切り替え、FSxを短期間フォールバック用に残す手順を案内しています。(Microsoft Learn)

よくある失敗と対処方法

症状	主な原因	対処
ジョブを開始できない	マネージドIDのRBAC不足	Key Vault Secrets UserとStorage File Data Privileged Contributorを確認
FSxへ接続できない	ルート、DNS、TCP 445、Security Groupの問題	FQDNの名前解決と`Test-NetConnection`を実行
SMB認証に失敗する	Key Vaultのシークレット間違い、資格情報の権限不足	ユーザー名・パスワードとFSx共有権限を確認
Private Connectionを選択できない	接続がApprovedになっていない	Private Endpoint接続を承認して状態を再確認
ジョブは成功したが利用者がアクセスできない	Azure FilesのIDソースまたは共有レベルRBACが未設定	IDベース認証、グループ同期、共有レベルロールを確認
一部のファイルだけ失敗する	ソース上のアクセス権やファイル固有の問題	Copy logsで対象パスとエラーコードを特定
ターゲット側のファイルが消えた	Mirrorモードを使用した	ジョブ定義と削除動作を確認し、必要ならバックアップから復元
Additiveで旧フォルダーが残る	ソース側でフォルダー名を変更した	不要フォルダーを検証後に削除するかMirror利用を再検討
転送が想定より遅い	VPN帯域、遅延、大量の小さいファイル	ネットワーク性能とオブジェクト数を確認し、ジョブを適切に分割

Storage Moverの公式トラブルシューティングでも、最初にRBAC、Private Connection、TCP 445、FSxのホスト名と共有名を確認するよう案内されています。(Microsoft Learn)

移行コストはデータ容量だけで見積もらない

Azure Storage Moverの現行機能自体は無料で提供されています。ただし、次の料金は別途発生します。

Azure Filesの保存容量
Azure Storageのトランザクション
Azure側のネットワーク関連リソース
VPN Gateway、ExpressRoute、NVAなどの利用料金
AWS側のデータ転送
AWS Direct ConnectやVPN関連リソース
移行後のAzure Backupや監視

Azure Storageのトランザクション数は、データ容量だけでなくファイルやフォルダーの個数にも影響されます。同じ1TBでも、数百個の大容量ファイルより、数百万個の小容量ファイルの方が多くの処理を必要とします。(Microsoft Learn)

見積もりではTB単位の容量だけでなく、オブジェクト数、差分コピーの回数、移行先のストレージ階層、AWSからのデータ転送量を含めて計算してください。

本番移行は小規模な共有から始める

AWS FSxからAzure FilesへのAgentless移行により、転送用エージェントの配備と管理は不要になります。一方で、移行の成否を左右するのは、プライベートネットワーク、IDとACL、コピーモード、ログ、カットオーバー設計です。

最初に行うべきことは、全共有の一括移行ではありません。影響の小さい共有を1つ選び、次の順序でパイロットを実施します。

AzureとAWS間のTCP 445疎通を確認する
Key VaultとRBACを構成する
Log Analyticsを有効にする
Additiveモードで初回コピーを実行する
ACLと利用者アクセスを確認する
差分コピーと最終切り替えを試す
結果を基に本番共有の移行計画を確定する

「データをコピーできたこと」と「業務をAzure Filesへ切り替えられること」は別の状態です。最終的な成功条件を、ファイル数や容量だけでなく、利用者認証、アプリケーション動作、性能、バックアップ、ロールバックまで含めて定義することが重要です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

AWS FSxからAzure FilesへAgentless移行する方法｜Azure Storage Mover

AWS FSxからAzure FilesへのAgentless移行とは

エージェントレスで不要になるものと、引き続き必要なもの

Public Preview時点の対応範囲と制限

Azure Storage Moverによる移行が適しているケース

移行前に準備するもの

Private Connectionの構成を先に固める

AgentlessでもVPNや専用線は必要

Storage MoverのPrivate Connectionを承認する

移行用ネットワークと利用者用ネットワークを分けて考える

ACLを保持しても、そのままアクセスできるとは限らない

AWS FSxからAzure Filesへ移行する手順

移行対象を棚卸しする

移行先のAzure Filesを作成する

AzureとAWS間のプライベート接続を構成する

Azure Key VaultへFSxの資格情報を保存する

Azure Storage Moverリソースを作成する

AWS FSxのソースエンドポイントを作成する

Azure Filesのターゲットエンドポイントを作成する

Private Connectionを作成して承認する

プロジェクトとジョブ定義を作成する

AdditiveとMirrorは削除動作で選ぶ

ジョブを開始してログを監視する

初回コピー後に検証する項目

差分コピーとカットオーバーを実施する

よくある失敗と対処方法

移行コストはデータ容量だけで見積もらない

本番移行は小規模な共有から始める

この記事を書いた人

コメント

コメントするコメントをキャンセル

AWS FSxからAzure FilesへAgentless移行する方法｜Azure Storage Mover

AWS FSxからAzure FilesへのAgentless移行とは

エージェントレスで不要になるものと、引き続き必要なもの

Public Preview時点の対応範囲と制限

Azure Storage Moverによる移行が適しているケース

移行前に準備するもの

Private Connectionの構成を先に固める

AgentlessでもVPNや専用線は必要

Storage MoverのPrivate Connectionを承認する

移行用ネットワークと利用者用ネットワークを分けて考える

ACLを保持しても、そのままアクセスできるとは限らない

AWS FSxからAzure Filesへ移行する手順

移行対象を棚卸しする

移行先のAzure Filesを作成する

AzureとAWS間のプライベート接続を構成する

Azure Key VaultへFSxの資格情報を保存する

Azure Storage Moverリソースを作成する

AWS FSxのソースエンドポイントを作成する

Azure Filesのターゲットエンドポイントを作成する

Private Connectionを作成して承認する

プロジェクトとジョブ定義を作成する

AdditiveとMirrorは削除動作で選ぶ

ジョブを開始してログを監視する

初回コピー後に検証する項目

差分コピーとカットオーバーを実施する

よくある失敗と対処方法

移行コストはデータ容量だけで見積もらない

本番移行は小規模な共有から始める

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル