オンプレのNASやファイルサーバーには、長年蓄積されたテラバイト単位のデータが眠っている。AWS移行を検討し始めたとき、避けては通れないのが「このデータをどうやってAWSへ持ち込むか」という問題だ。
rsyncやrobocopyでやれないことはない。しかし数十TBともなると、転送に何日もかかり、途中でネットワークが途絶えたときのリカバリ設計や、転送完了後のデータ整合性確認まで考えると、手作りのスクリプトで対応するのは骨が折れる。エラーログが散在して「どのファイルが抜けたのか」を追うだけで一日がかりになる、というのはよくある話だ。
この記事では、AWS DataSync について、オンプレ経験者にもわかりやすく解説する。エージェントの仕組みから転送先の選び方、料金の計算方法、よく混同される AWS Storage Gateway との使い分けまで、実務視点でまとめる。
AWS DataSyncとは何か
AWS DataSync は、オンプレミスのストレージとAWSのストレージサービスの間でデータを高速・安全に転送するフルマネージドサービスだ。AWSが公式に「オープンソースのツールより最大10倍高速」と謳うように、並列転送とパイプライン最適化によって大量データの移行時間を大幅に短縮できる。
対応する転送元・転送先は以下のとおりだ(2026年7月時点)。
| 方向 | 転送元(ソース) | 転送先(デスティネーション) |
|---|---|---|
| オンプレ → AWS | NFS、SMB(Windows共有)、HDFS、オブジェクトストレージ | Amazon S3、Amazon EFS、Amazon FSx(Windows/Lustre/NetApp/OpenZFS) |
| AWS → オンプレ | Amazon S3、Amazon EFS、Amazon FSx | NFS、SMB |
| AWS ↔ AWS | S3バケット、EFS、FSx | S3バケット、EFS、FSx(リージョン間・アカウント間も対応) |
注目したいのは「AWS間の転送」にも対応している点だ。リージョン間のS3バケットコピーや、別アカウントへのデータ移行にも使える。移行プロジェクトの最終フェーズで「本番アカウントへデータをコピーする」という場面にもDataSyncが活躍する。
Storage GatewayやTransfer Familyとの違い
DataSyncと混同しやすい2つのサービスがあるので、先に整理しておきたい。
| サービス | 主な用途 | 向いているケース |
|---|---|---|
| AWS DataSync | 大量データの高速転送・定期同期 | 一回の大量移行、差分バッチ同期、AWS間コピー |
| AWS Storage Gateway | オンプレとAWSのストレージを常時接続(Hybrid) | 移行後もオンプレアプリからS3を従来のNASのように使い続けたい |
| AWS Transfer Family | SFTPサーバーエンドポイントをS3の前段に立てる | 取引先からSFTPでファイルを受け取ってS3へ格納したい |
一言で言えば、DataSyncは「大量データを効率よく動かすための転送エンジン」だ。Storage GatewayはNASやテープのクラウド延長として常時接続のハイブリッドストレージを実現し、Transfer FamilyはSFTPプロトコルを使う外部連携を担う。「DataSyncで移行し、その後はStorage Gatewayでハイブリッド接続に切り替える」という組み合わせは実務でよく見るパターンだ。
DataSyncのアーキテクチャ:エージェントとタスクの仕組み
DataSyncを使いこなすうえで、構成要素を理解しておく必要がある。大きく3つのコンポーネントで成り立っている。
エージェント(Agent)
オンプレ側に設置するソフトウェアコンポーネント。VMware ESXi、Linux KVM、Microsoft Hyper-V上にデプロイするVM形式か、EC2インスタンス(AWS内転送の場合)として動作する。エージェントがオンプレのNFS/SMBストレージに接続し、データをAWSエンドポイントへ送り出す。
ロケーション(Location)
転送元(ソース)と転送先(デスティネーション)のストレージを定義したもの。「このNASのこのマウントポイント」「このS3バケットのこのプレフィックス」といった接続情報を登録する。
タスク(Task)
「どのロケーションからどのロケーションへ、どんな設定で転送するか」を定義する実行単位。転送対象のフィルタ設定(include/excludeパターン)、転送モード(変更ファイルのみか全ファイルか)、ログ設定などをここで指定する。
エージェントはオンプレ側からAWSのDataSyncエンドポイントへHTTPS(ポート443)で接続する。インターネット経由でも動作するが、大量データを転送する本番環境では AWS Direct Connect または Site-to-Site VPN を経由するのが一般的だ。ネットワーク帯域がボトルネックになるケースが多く、接続形態の選定は転送スケジュールに直結する。
基本的な使い方
1. エージェントのデプロイとアクティベーション
まずAWSコンソールの「DataSync」から「エージェントの作成」を開き、使用するハイパーバイザー向けのOVAファイル(VMware)またはISOイメージ(KVM/Hyper-V)をダウンロードする。ダウンロードしたイメージをオンプレのハイパーバイザーに展開してVMを起動する。
VMが起動したら、ブラウザからエージェントのローカルIPアドレスにアクセスすると、アクティベーション画面が表示される。AWSコンソール側で生成したアクティベーションキーをここに入力すれば、エージェントとAWSアカウントが紐付く。
# エージェントVM起動後、ブラウザで以下URLにアクセス(例) http://192.168.1.100/ # 表示される画面でAWSコンソールが発行したアクティベーションキーを入力する # キーの有効期限は発行から5分間(切れたら再発行すること) # エージェントVMの推奨スペック(AWSガイドライン) # vCPU: 4コア以上 # メモリ: 32GB以上 # ストレージ: 80GB以上
2. ロケーションの設定
AWSコンソールから「ロケーションの作成」を選択し、転送元と転送先をそれぞれ設定する。
転送元ロケーション(例:オンプレNFSサーバー)の設定項目:
・サーバー: オンプレNASのIPアドレスまたはホスト名
・マウントパス: NFSのエクスポートパス(例:/volume1/data)
・エージェント: 先ほどアクティベーションしたエージェントを選択
転送先ロケーション(例:Amazon S3)の設定項目:
・S3バケット: データを格納するバケット名
・S3ストレージクラス: 初回移行ならS3 Standardが無難(後でライフサイクルルールで移動可能)
・フォルダ: バケット内のプレフィックス(省略可)
・IAMロール: DataSyncがS3にアクセスするためのロール(「自動作成」ボタンで最小権限ポリシーが自動生成される)
3. タスクの作成と実行
ロケーションが揃ったら、タスクを作成する。主要な設定は以下のとおりだ。
・転送モード: 「変更されたファイルのみ転送する」か「すべてのファイルを転送する」かを選ぶ。初回移行は全ファイル転送、以降は差分転送に切り替えるとコストと時間を削減できる。
・帯域幅の制限: 業務時間帯のネットワーク圧迫を避けるために上限速度を指定できる。深夜だけ無制限、昼間は100Mbpsに絞るといった設定が可能だ。
・ファイル検証: 転送後にチェックサムでデータ整合性を自動確認する機能。本番移行では有効化を強く推奨する。
・ログ出力: 転送結果をAmazon CloudWatch Logsに出力する設定。エラーの特定に不可欠なので必ず有効にすること。
・スケジュール: cron式で定期実行を設定できる。深夜0時に毎日差分同期、といった運用が組める。
タスクを作成したら「今すぐ開始」または設定したスケジュールで転送が始まる。コンソールの「タスクの実行」画面から、転送済みファイル数・バイト数・残り時間の推定をリアルタイムに確認できる。
転送先の選び方:S3・EFS・FSxの使い分け
DataSyncの転送先はS3、EFS、FSxから選べるが、その後の利用形態によって選択が変わる。
| 転送先 | 向いているデータ・利用形態 |
|---|---|
| Amazon S3 | アーカイブ、バッチ処理向け非構造化データ、静的コンテンツ。ストレージコストが最も安く、後でライフサイクルルールで最終保管先を最適化できる。 |
| Amazon EFS | LinuxのEC2インスタンスから複数同時にマウントしてアクセスするNFS系データ。移行後にEC2のアプリから直接ファイルを読み書きしたい場合に適する。 |
| Amazon FSx for Windows File Server | Windowsファイルサーバー(SMB)のデータ。Active Directory統合が必要な環境や、Windowsアプリがそのままファイルサーバーへアクセスするケースに適する。 |
| Amazon FSx for Lustre | HPC・機械学習ワークロードの高速一時ストレージ。S3と連携してデータを高スループットで処理する用途に適する。 |
ほとんどの移行プロジェクトでは、まずS3に格納しておき、利用形態に応じてEFSやFSxに再配置するアプローチが無難だ。S3はストレージコストが最も安く、後でDataSyncによる二次転送やライフサイクルルールによって最終保管先を変更する柔軟性もある。
料金の仕組みとコスト試算
DataSyncの料金は転送したデータ量に応じた従量課金だ(2026年7月時点)。
| 転送量の範囲 | 料金(USD/GB) |
|---|---|
| 月間150 PBまで | $0.0125/GB(東京リージョン・ap-northeast-1) |
エージェントのソフトウェア自体に費用はかからない。ただし、以下の関連コストは別途発生する。
・ネットワーク転送費用: AWSへのデータ入力(イングレス)は無料。Direct ConnectやVPNを使う場合は接続回線のコストが別途かかる。
・転送先ストレージのコスト: S3/EFS/FSxそれぞれのストレージ料金は別途発生する。
・エージェントVMのホスティングコスト: オンプレのVM実行リソース、またはEC2インスタンスのコスト(AWS間転送の場合)。
# DataSync転送コスト試算例 # オンプレNASからS3(東京リージョン)へ10TBを一回移行する場合 転送量: 10 TB = 10,240 GB DataSync転送費用 10,240 GB × $0.0125/GB = $128.00 S3ストレージコスト(S3 Standard、1か月分) 10,240 GB × $0.025/GB ≈ $256.00 合計(移行初月の概算): 約 $384.00 # ※2026年7月時点の東京リージョン料金。為替・料金変動で変わる可能性あり。 # ※Direct Connectの帯域コストや、転送後のデータ処理コストは含まない。
10TBの一回移行でDataSync転送費用が$128というのは、手動スクリプトの構築・テスト・監視対応の工数コストと比べると十分に低い水準だ。月単位の定期同期で差分データが少ない場合は、さらにコストは下がる。
実務で役立つ運用Tips
【Tips 1】フィルタで転送対象を絞ってコストを削減する
DataSyncのタスクにはinclude/excludeパターンが設定できる。ログファイル(*.log)やサムネイルキャッシュ(.cache/)を除外することで、転送量と時間を大幅に削減できる。フィルタはワイルドカード形式で複数設定可能だ。
# タスク作成時の除外パターン(exclude)設定例 /log/** → ログディレクトリ以下を除外 **/*.tmp → 一時ファイルを除外 **/.cache/** → キャッシュディレクトリを除外 **/*.bak → バックアップファイルを除外 # 包含パターン(include)設定例 /data/** → dataディレクトリ以下のみ転送
【Tips 2】DataSync → Storage Gatewayでハイブリッド移行を完結させる
大規模移行のよくある進め方は次の3フェーズだ。
フェーズ1(初期移行): DataSyncでオンプレのデータを一気にS3/EFSへ移行する。NAS上の10TBを数時間~数日で転送する。
フェーズ2(並行稼働): 移行完了後もオンプレのアプリは旧NASへ書き込む。DataSyncの定期差分同期を走らせて、新旧のデータをほぼリアルタイムな状態で同期し続ける。
フェーズ3(切り替え): オンプレアプリをAWS上のストレージへ接続し直す。または Storage Gateway(ファイルゲートウェイ) を設置して、オンプレアプリからはS3を従来のNASのように見せる構成にする。DataSyncの役割はここで完了する。
【Tips 3】転送スループットの見積もりを必ず行う
ネットワーク帯域がボトルネックになることが多い。DataSync自体は並列転送で最大10Gbpsを処理できるが、インターネット回線が100Mbpsなら転送速度はその上限に張り付く。
目安として、100Mbpsの帯域で1TBを転送するのに約22時間かかる(帯域フル利用時)。Direct Connect 1Gbpsなら約2.2時間だ。本番移行前にネットワーク帯域を確認し、転送完了までのスケジュールを逆算してカットオーバー日程を決めること。
| ネットワーク帯域 | 1TB転送の目安時間(フル利用時) |
|---|---|
| インターネット 100Mbps | 約22時間 |
| Direct Connect 1Gbps | 約2.2時間 |
| Direct Connect 10Gbps | 約13分 |
【Tips 4】CloudWatch Logsのエラーログを必ず確認する
DataSyncは一部のファイルが転送失敗してもタスク全体が「成功」扱いになる場合がある。移行完了後に「あのファイルがない」という事態を防ぐため、CloudWatch Logsの「エラーログ」でアクセス権限がなかったファイルやロック中で転送できなかったファイルを確認すること。移行の「完了」はDataSyncのタスクステータスではなく、ログ確認込みで判断する習慣を付けることを推奨する。
よくあるトラブルと対処法
エージェントのアクティベーションが失敗する
最も多い原因はエージェントVMからAWSエンドポイントへのHTTPS通信がブロックされていることだ。社内ファイアウォールでポート443が許可されているか確認する。プロキシ環境の場合、エージェントのローカルUIからプロキシ設定が必要なケースもある。また、アクティベーションキーの有効期限は5分間なので、コピペに手間取ると期限切れになる。期限切れになったらAWSコンソールで再生成すること。
転送速度が期待値より大幅に遅い
DataSyncは並列転送を前提に設計されているが、転送するファイルが極端に少数の巨大ファイル(例:数TBの仮想ディスクイメージ1本)だった場合、並列性が発揮されない。また、エージェントVMのCPU・メモリが不足していると処理がボトルネックになる。AWSの推奨スペックはvCPU 4コア以上、メモリ32GB以上だ。スペックを見直す前に、まずCPUとメモリの使用率をエージェントのメトリクスで確認するとよい。
IAMロールのアクセス権限エラーが出る
タスク実行時に「AccessDenied」エラーが出る場合、DataSyncに紐付けたIAMロールの権限が不足している。S3への転送なら s3:GetBucketLocation、s3:PutObject、s3:ListBucket、s3:GetObject などが必要だ。コンソールの「IAMロールの自動作成」機能を使えばこれらが自動で付与されるので、手動設定で詰まった場合は一度自動作成に切り替えてポリシーの内容を参考にするとよい。
SMB転送でアクセス拒否になる
SMBロケーション(Windowsファイルサーバー)の転送でアクセス拒否になる場合、DataSyncが使用するWindowsの認証情報(ユーザー名・パスワード)がDomain Adminsまたは共有フォルダへの読み取り権限を持っているか確認する。また、SMB署名の設定(SMB signing)がエージェントとサーバー側で不一致だと接続失敗することがある。サーバー側のSMB署名を一時的に任意(optional)に変更することで解決するケースが多い。
本記事のまとめ
AWS DataSyncを使うことで、テラバイト規模のオンプレストレージをS3・EFS・FSxへ高速・安全に移行できる。手作りのrsyncスクリプトと比べて、並列転送・データ検証・スケジュール同期・ログ管理が標準で備わっており、移行プロジェクトの信頼性を大幅に高められる。
要点を整理する。
・DataSyncの役割: 大量データの高速転送・定期同期に特化したマネージドサービス。Storage GatewayはHybrid継続接続、Transfer FamilyはSFTPエンドポイントとして役割が異なる。
・エージェントはオンプレに設置: VM(VMware/KVM/Hyper-V)で動作。AWSへのHTTPS接続が必要。推奨スペックはvCPU 4コア・32GB以上。
・料金は転送量のみ: $0.0125/GB(東京リージョン・2026年7月時点)。ストレージコストとネットワークコストは別途発生する。
・移行→差分同期→切り替えの3フェーズが定石: DataSyncで初期移行し、Storage Gatewayでハイブリッド接続に移行するパターンが実務でよく使われる。
・CloudWatch Logsは必ず有効化: 一部ファイルのエラーが見逃されやすいため、ログ確認まで含めて移行完了と判断すること。
クラウド移行の方針全体については、AWS移行の6R入門も参考にしてほしい。Rehost(リフトアンドシフト)でDataSyncを活用し、移行が落ち着いてからReplatformやRefactorを検討するのが現実的なアプローチだ。
PR
EC2やS3といった基本サービスから運用設計まで、AWSインフラの全体像をハンズオン形式で学べる一冊。DataSyncを使い始める前後に、AWS全体のサービス体系を整理したいエンジニアにおすすめ。
