AWS DataSyncを用いてEC2上のファイルデータをFSx for OpenZFSに移行してみた

はじめに

みなさんこんにちは、クラウド事業本部コンサルティング部の浅野です。
前回 Amazon EC2上で管理しているファイルデータを「rsync」コマンドを用いてFSx for OpenZFS に移行する検証記事を作成しました。

https://dev.classmethod.jp/articles/2025-12-14-aws-ec2-file-data-migration-fsx-openzfs-use-rsync/

「rsync」コマンドでもデータの移行実施が可能ですが、数TBを超えるような大規模データの高速転送や継続的なデータ同期が必要な場合は、AWSがインフラ基盤を管理するオンラインデータ転送サービスである「AWS DataSync」の使用をご検討ください。

今回は上記「rsync」コマンドを用いたデータ移行記事と同じような条件で「AWS DataSync」を用いてEC2上のデータをFSx for OpenZFSに移行してみたいと思います。

AWS DataSyncとは

AWS DataSyncは、様々なデータソース間のデータ移行を簡素化し、ファイルやオブジェクトデータを迅速・安全・簡単に移行・同期するためのフルマネージドサービスです。

「AWS↔︎オンプレミスストレージ」間はもちろんのこと、今回の検証のように「AWS↔︎AWS」間の別ストレージサービスへの転送や、「AWS↔︎その他クラウドストレージサービス」間の転送・同期など非常に多くのストレージサービスをサポートしています。

詳しくは下記公式ドキュメントにサポート対象のサービスとユースケースが記載されているのでご参考ください。

https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/what-is-datasync.html

DataSync エージェントについて

DataSync Agentは、オンプレミスやEC2上のストレージとAWS DataSyncサービス間の通信を仲介するコンポーネントです。今回のようにNFS/SMBファイルサーバーからデータを転送する場合、このエージェントが必要になります。S3やその他AWSストレージサービスとの間でデータを移行する際など、条件に応じてはエージェントを使用しなくても良いです。エージェントの設定にはVPCエンドポイント、セキュリティグループなど複数の要素の構成が必要となるため、事前準備に時間を要します。

エージェントをEC2にデプロイする方法は、AWSが提供するDataSync Agentプリインストール済みの専用AMIを使用する方法と、既存のインスタンスにパッケージ経由でインストールする方法がありますが、設定が楽なため今回は専用AMIを使用しています。

専用AMI IDはSSM Parameter Storeから以下のように取得できます。

aws ssm get-parameters-by-path --path "/aws/service/datasync"

{
    "Parameters": [
        {
            "Name": "/aws/service/datasync/al2-qawsedzs",
            "Type": "String",
            "Value": "ami-02196f041578ad56e",
            "Version": 4,
            "LastModifiedDate": "2021-11-04T23:14:22.415000+09:00",
            "ARN": "arn:aws:ssm:ap-northeast-1::parameter/aws/service/datasync/al2-qawsedzs",
            "DataType": "text"
        },
        {
            "Name": "/aws/service/datasync/ami",
            "Type": "String",
            "Value": "ami-04499b07d4768bf1b",
            "Version": 134,
            "LastModifiedDate": "2025-12-13T03:52:29.168000+09:00",
            "ARN": "arn:aws:ssm:ap-northeast-1::parameter/aws/service/datasync/ami",
            "DataType": "text"
        }
    ]
}

/aws/service/datasync/ami のValueが最新のAMI IDです。

また、DataSync Agentのインストールには以下の最小要件があるため、今回は移行元ファイルサーバーとは別のEC2インスタンスとしてデプロイします。

https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/deploy-agents.html

https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/agent-requirements.html

タスクモードについて

AWS DataSyncを用いたデータ転送を行う場合は以下のような設定を行う「タスク」を作成する必要があります。

• ソースの場所 – DataSync がデータを転送する元のストレージシステムまたはサービス。
• 転送先の場所 – DataSync がデータを転送する先のストレージシステムまたはサービス。
• タスクオプション – 転送するファイル、データの検証方法、タスクの実行日時などの設定。

その際にタスク内で選択できる転送モードに「ベーシックモード」と「拡張モード」という2種類があります。

ベーシックモード

標準的なデータ転送向けのモードです。データの準備・転送・検証を順次実行するため、拡張モードと比較すると転送速度は遅くなります。

拡張モード

大規模データセットの高速転送向けのモードです。データの準備・転送・検証を並列実行するため、ほとんどのワークロードでベーシックモードより高速に転送できます。

拡張モードはより詳細なメトリクスや構造化ログも提供されるため、大規模なデータ移行プロジェクトでの可視性が向上します。

拡張モードで対応しているソース/宛先の組み合わせ

拡張モードは現時点で宛先がAmazon S3の場合のみ利用可能です。具体的には以下のパターンです。

https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/choosing-task-mode.html

https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/datasync-limits.html#task-hard-limits

料金体系

AWS DataSyncはシンプルな従量課金制で、初期費用や最低利用料金はありません。

※ 上記は東京リージョン（ap-northeast-1）の料金です。

クロスリージョン転送を行う場合は、上記に加えてリージョン間のデータ転送料金が別途発生します。

https://aws.amazon.com/jp/datasync/pricing/

構成

今回のEC2ファイルサーバーからDataSync Agentを通してFSx for OpenZFSのファイルサーバーにデータを移行する構成です。

※ 今回は検証のため同一プライベートサブネット内にデータ転送元と転送先を設定しているためネットワークの垣根を超えた設定等は考慮していません。

DataSync用のVPCエンドポイントとタスクなどの作成はイメージを掴むためにコンソールから行いますので、それ以外のリソースをCDKで構築しました。

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as fsx from 'aws-cdk-lib/aws-fsx';
import * as iam from 'aws-cdk-lib/aws-iam';

export class DemoFsxOpenzfsMigrationStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // VPC
    const vpc = new ec2.Vpc(this, 'FsxMigrationVpc', {
      ipAddresses: ec2.IpAddresses.cidr('10.0.0.0/24'),
      maxAzs: 1,
      natGateways: 0,
      subnetConfiguration: [
        {
          cidrMask: 26,
          name: 'Private',
          subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
        },
      ],
    });

    // VPCエンドポイント用セキュリティグループ
    const vpcEndpointSg = new ec2.SecurityGroup(this, 'VpcEndpointSg', {
      vpc,
      securityGroupName: 'vpc-endpoint-sg',
      description: 'Security group for VPC Endpoints',
      allowAllOutbound: true,
    });

    // SSM/DataSync VPCエンドポイント用
    vpcEndpointSg.addIngressRule(
      ec2.Peer.ipv4(vpc.vpcCidrBlock),
      ec2.Port.tcp(443),
      'HTTPS for SSM'
    );

    // SSM用VPCエンドポイント
    vpc.addInterfaceEndpoint('SsmEndpoint', {
      service: ec2.InterfaceVpcEndpointAwsService.SSM,
      subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
      securityGroups: [vpcEndpointSg],
    });

    vpc.addInterfaceEndpoint('SsmMessagesEndpoint', {
      service: ec2.InterfaceVpcEndpointAwsService.SSM_MESSAGES,
      subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
      securityGroups: [vpcEndpointSg],
    });

    // S3ゲートウェイエンドポイント（yumリポジトリアクセス用）
    vpc.addGatewayEndpoint('S3Endpoint', {
      service: ec2.GatewayVpcEndpointAwsService.S3,
      subnets: [{ subnetType: ec2.SubnetType.PRIVATE_ISOLATED }],
    });

    // EC2ファイルサーバー用セキュリティグループ
    const ec2FileServerSg = new ec2.SecurityGroup(this, 'Ec2FileServerSg', {
      vpc,
      securityGroupName: 'ec2-fileserver-sg',
      description: 'Security group for EC2 File Server',
      allowAllOutbound: true,
    });

    // DataSync Agent用セキュリティグループ
    const ec2AgentSg = new ec2.SecurityGroup(this, 'Ec2AgentSg', {
      vpc,
      securityGroupName: 'ec2-agent-sg',
      description: 'Security group for DataSync Agent',
      allowAllOutbound: true,
    });

    // EC2ファイルサーバーへのNFSアクセス許可（DataSync Agentから）
    ec2FileServerSg.addIngressRule(ec2AgentSg, ec2.Port.tcp(111), 'NFS RPC from DataSync Agent');
    ec2FileServerSg.addIngressRule(ec2AgentSg, ec2.Port.tcp(2049), 'NFS from DataSync Agent');
    ec2FileServerSg.addIngressRule(ec2AgentSg, ec2.Port.udp(111), 'NFS RPC from DataSync Agent');
    ec2FileServerSg.addIngressRule(ec2AgentSg, ec2.Port.udp(2049), 'NFS from DataSync Agent');

    // DataSync Agent → VPCエンドポイント
    vpcEndpointSg.addIngressRule(ec2AgentSg, ec2.Port.tcp(22), 'Support channel');
    vpcEndpointSg.addIngressRule(ec2AgentSg, ec2.Port.tcpRange(1024, 1064), 'Control plane');

    // DataSync FSxロケーションENI用セキュリティグループ
    const datasyncFsxEniSg = new ec2.SecurityGroup(this, 'DatasyncFsxEniSg', {
      vpc,
      securityGroupName: 'datasync-fsx-eni-sg',
      description: 'Security group for DataSync FSx location ENI',
      allowAllOutbound: true,
    });

    // DataSync Agent → FSxロケーションENI (TCP 443)
    datasyncFsxEniSg.addIngressRule(ec2AgentSg, ec2.Port.tcp(443), 'DataSync protocol from Agent');

    // FSx用セキュリティグループ
    const fsxSg = new ec2.SecurityGroup(this, 'FsxOpenzfsSg', {
      vpc,
      securityGroupName: 'fsx-openzfs-sg',
      description: 'Security group for FSx OpenZFS',
      allowAllOutbound: false,
    });

    // FSx へのNFSアクセス許可（DataSync ENIから）
    fsxSg.addIngressRule(datasyncFsxEniSg, ec2.Port.tcp(111), 'NFS RPC from DataSync ENI');
    fsxSg.addIngressRule(datasyncFsxEniSg, ec2.Port.tcp(2049), 'NFS from DataSync ENI');
    fsxSg.addIngressRule(datasyncFsxEniSg, ec2.Port.tcpRange(20001, 20003), 'NFS mount/status/lock from DataSync ENI');

    fsxSg.addIngressRule(datasyncFsxEniSg, ec2.Port.udp(111), 'NFS RPC from DataSync ENI');
    fsxSg.addIngressRule(datasyncFsxEniSg, ec2.Port.udp(2049), 'NFS from DataSync ENI');
    fsxSg.addIngressRule(datasyncFsxEniSg, ec2.Port.udpRange(20001, 20003), 'NFS mount/status/lock from DataSync ENI');

    // EC2ファイルサーバー（Amazon Linux 2）
    new ec2.Instance(this, 'Ec2FileServer', {
      vpc,
      vpcSubnets: {
        subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
      },
      instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),
      machineImage: ec2.MachineImage.latestAmazonLinux2({
        cpuType: ec2.AmazonLinuxCpuType.X86_64,
      }),
      securityGroup: ec2FileServerSg,
      role: new iam.Role(this, 'Ec2FileServerRole', {
        assumedBy: new iam.ServicePrincipal('ec2.amazonaws.com'),
        managedPolicies: [
          iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),
        ],
      }),
      blockDevices: [
        {
          deviceName: '/dev/xvda',
          volume: ec2.BlockDeviceVolume.ebs(20, {
            volumeType: ec2.EbsDeviceVolumeType.GP3,
          }),
        },
      ],
    });

    // DataSync Agent EC2インスタンス
    // DataSync Agent専用AMI（aws ssm get-parameters-by-path --path "/aws/service/datasync" で取得）
    new ec2.Instance(this, 'DataSyncAgent', {
      vpc,
      vpcSubnets: {
        subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
      },
      instanceType: ec2.InstanceType.of(ec2.InstanceClass.M5, ec2.InstanceSize.XLARGE2),
      machineImage: ec2.MachineImage.genericLinux({
        'ap-northeast-1': 'ami-04499b07d4768bf1b',
      }),
      securityGroup: ec2AgentSg,
      role: new iam.Role(this, 'DataSyncAgentRole', {
        assumedBy: new iam.ServicePrincipal('ec2.amazonaws.com'),
        managedPolicies: [
          iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),
        ],
      }),
      blockDevices: [
        {
          deviceName: '/dev/xvda',
          volume: ec2.BlockDeviceVolume.ebs(80, {
            volumeType: ec2.EbsDeviceVolumeType.GP3,
          }),
        },
      ],
    });

    // FSx for OpenZFS
    new fsx.CfnFileSystem(this, 'FsxOpenzfs', {
      fileSystemType: 'OPENZFS',
      storageCapacity: 64,
      subnetIds: [vpc.isolatedSubnets[0].subnetId],
      securityGroupIds: [fsxSg.securityGroupId],
      openZfsConfiguration: {
        deploymentType: 'SINGLE_AZ_2',
        throughputCapacity: 160,
        rootVolumeConfiguration: {
          dataCompressionType: 'LZ4',
        },
        automaticBackupRetentionDays: 0,
      },
      tags: [
        {
          key: 'Name',
          value: 'fsx-openzfs-migration',
        },
      ],
    });
  }
}

環境情報

• リージョン: ap-northeast-1（東京）
• VPC CIDR: 10.0.0.0/24
• サブネット: Private Isolated（単一AZ）
• NAT Gateway: なし

VPCエンドポイント

• SSM / SSM Messages: Interface型（Session Manager接続用）
• S3: Gateway型（yumリポジトリアクセス用）
• セキュリティグループ: vpc-endpoint-sg

EC2 FileServer（移行元）

• インスタンスタイプ: t3.micro
• OS: Amazon Linux 2（x86_64）
• EBSボリューム: 20GB（gp3）
• セキュリティグループ: ec2-fileserver-sg
• 移行元ディレクトリ: /data

DataSync Agent EC2

• インスタンスタイプ: m5.2xlarge
• AMI: DataSync専用AMI（ami-04499b07d4768bf1b）
• EBSボリューム: 80GB（gp3）
• セキュリティグループ: ec2-agent-sg

FSx for OpenZFS（移行先）

• デプロイタイプ: SINGLE_AZ_2
• ストレージ容量: 64GB
• スループット: 160 MBps
• 圧縮: LZ4
• 自動バックアップ: 無効
• セキュリティグループ: fsx-openzfs-sg

DataSync FSxロケーションENI用セキュリティグループ

DataSyncサービスがタスク実行時に自動生成する宛先ロケーションに割り当てるENI用のセキュリティグループをあらかじめ作成しています。詳細は後述しています。

• セキュリティグループ: datasync-fsx-eni-sg

やってみた

上記CDKをデプロイした状態から始めます。

「rsyncコマンド」を用いる場合は手動でEC2内でFSx ファイルシステム先にマウントを行う手順が必要でしたが、今回は「DataSync Agent」を用いるのでEC2内での手動マウント設定は必要ありません。また、DataSyncサービスとDataSync Agent間の通信のためにVPCエンドポイントが別途必要です。

DataSync用 VPCエンドポイントの作成

プライベートサブネットからDataSync Agentがサービスと通信するためにVPCエンドポイントが必要です。

また、エージェントのアクティベーション時にはDataSyncサービスへの通信経路が必要なため、先にVPCエンドポイントを以下の設定で作成します。

AWSコンソール: 「VPC」 > 「エンドポイント」 > 「エンドポイントを作成」から以下の設定で作成します。

無事にエンドポイントの作成が確認できました。

移行用データの作成

続いて、移行元データを以下のような構造のファイルにてEC2内に用意します。

/data
├── documents
│   ├── doc_1.txt
│   ├── doc_2.txt
│   ├── ...
│   └── doc_10.txt
└── large
    └── largefile_10gb.bin (10GB)

まず、ファイルサーバー用EC2インスタンスにSSM(セッションマネージャー)経由で接続します。

テキストファイル用と大容量ファイル用のディレクトリを作成します。

sudo mkdir -p /data/documents /data/large

続いて、以下のスクリプトを入力して10個の適当なテキストファイルを作成します。

for i in {1..10}; do echo "This is document file $i - $(date)" | sudo tee /data/documents/doc_$i.txt > /dev/null; done

cd /data/documents/
ls
doc_1.txt  doc_10.txt  doc_2.txt  doc_3.txt  doc_4.txt  doc_5.txt  doc_6.txt  doc_7.txt  doc_8.txt  doc_9.txt

続いて、ddコマンドでランダムデータの10GBファイルを作成します。
実行に数分かかります。

sudo dd if=/dev/urandom of=/data/large/largefile_10gb.bin bs=1M count=10240

10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 80.2873 s, 134 MB/s

作成したファイルそれぞれのサイズを確認します。

du -sh /data/*

40K     /data/documents
10G     /data/large

無事にテキストデータと10GBの大容量データが用意できました。

NFSエクスポート設定

DataSync AgentがEC2ファイルサーバーからデータを読み取るために、NFSエクスポートを設定します。

ファイルサーバーEC2に接続したまま、nfs-utilsがインストールされているか確認します。
以下のように表示されたらすでにインストールされています。

rpm -q nfs-utils

nfs-utils-1.3.0-0.54.amzn2.0.2.x86_64

インストールされていない場合は以下でインストールします。

sudo yum install -y nfs-utils

以下のコマンドにて/etc/exports にエクスポート設定を追加します。

10.0.0.0/24はこのVPC内のリソースすべてを表しています。

echo "/data 10.0.0.0/24(ro,no_root_squash)" | sudo tee /etc/exports

/etc/exports は設定ファイルのため、実際にNFSエクスポートを提供するにはNFSサーバーを起動する必要があります。

sudo systemctl start nfs-server

sudo exportfs -v

以下のように出力できていればNFSエクスポート設定は終了です。

/data           10.0.0.0/24(ro,sync,wdelay,hide,no_subtree_check,sec=sys,secure,no_root_squash,no_all_squash)

DataSync エージェントのアクティベーション

続いて、DataSyncとDataSync Agentがやり取りできるようにエージェントをアクティベートします。

まず、「DataSync」>「エージェント」>「エージェントを作成」から以下を設定します。

下記画面のようにアクティベートするには、アクティベーションキーを取得してAWSアカウントに関連付ける必要があります。

アクティベーションキーの取得方法

アクティベーションキーの取得には主に自動と手動の2つの方法があります。

「自動取得」はブラウザからDataSync AgentへHTTP接続するため、パブリックアクセス可能な環境が必要です。

今回はプライベート環境なので、SSM(セッションマネージャー)経由でDataSync Agent EC2に接続して直接コンソール画面のターミナルからキーを取得しようと思います。

ローカルコンソールからの取得手順

まず、DataSync Agent EC2にSSM Session Managerで接続します。

接続できたら、以下のコマンドでadminユーザーに切り替えます。

sudo su - admin

切り替えるとDataSync Agent設定メニューがこのように表示されればOKです。

0: Get activation keyを選択したいので0を入力します。

続いてAWSリージョンとDataSync↔︎エージェント間の通信方法を確認されるのでそれぞれ
ap-northeast-1と3: VPC Endpoints using AWS PrivateLinkを入力します。

この後の画面でPrivate IPv4 or IPv6 address of VPC endpoint: を入力する項目があるので先ほど作成したDataSyncVPCエンドポイントで使用しているプライベートIPアドレスを確認します。

「VPC」>「エンドポイント」>「datasync-endpointのVPCエンドポイントID」を選択

表示された「IPv4アドレス」を確認し、コピーします。

DataSync Agent EC2内ターミナル画面に戻りコピーしたアドレスを入力するとネットワーク接続がうまく出来ている場合、

下記画面のようにアクティベーションキー（例: AAAAA-BBBBB-CCCCC-DDDDD-EEEEE）が表示されます。

エージェント作成画面に戻り「アクティベーションキー」と残りの設定をして「エージェントを作成する」ボタンを選択するとエージェントのアクティベーションは完了です。

ロケーションの設定

DataSyncにおける「ロケーション」とは、データ転送の送信元または宛先となるストレージの場所を定義したものです。タスクを作成する前に、送信元（ソース）と宛先（デスティネーション）の2つのロケーションを作成する必要があります。

送信元ロケーションの作成（NFS）

作成にファイルサーバーEC2のプライベートIPアドレスが必要になるので事前に取得しておきます。

「EC2」>「インスタンス」>「ファイルサーバーEC2」を選択し、「プライベートIPv4アドレス」をコピーしておきます。

プライベートIPv4アドレスが取得できたら「DataSync」>「ロケーション」>「ロケーションを作成」から以下の「送信元ロケーション」を設定します。

「送信元ロケーション」が設定できたら同じようにFSx for OpenZFSをDataSyncの宛先として登録します。

以下の設定値で「宛先ロケーション」を設定します。

エージェントEC2からの接続テスト

ここまででエージェントのアクティベーションとNFSエクスポートも含めたネットワークの設定とロケーションの作成が終わりました。

データ移行のタスクを実行する前に、今一度DataSync AgentをデプロイしたEC2インスタンスにSSM接続で入り送信元ロケーション(EC2ファイルサーバー)にネットワークが疎通されているか、以下の手順で確認しましょう。

まず接続できたらアクティベーション時と同様にadminユーザーに切り替えます。

sudo su - admin

送信元ロケーションへのネットワーク疎通確認

AWS DataSync - Configuration 画面が表示されたら3: TestConnectivity to Self-Managed Storageを選択します。

ロケーションタイプの選択項目が表示されるので1: NFS serverを選択すると、IPv4 or IPv6 address or NFS server name:の入力欄が出てくるので先ほど確認したファイルサーバーEC2のプライベートIPアドレスである10.0.0.56を入力して2049(NFS)ポートでの疎通が問題ないことが確認できました。

この段階でエラーが出たり疎通確認が取れない場合はIPアドレスの再確認、セキュリティグループ、ネットワークACL、VPCエンドポイントなどの設定を再確認してください。

FSxボリュームの「no_root_squash」設定追加

タスクを作成して実行する前にFSxのボリュームのNFSオプションに「no_root_squash」を追加しましょう。ルート権限でないとファイルが正常に転送できない可能性があります。

この設定をせずにタスクを実行すると以下のように「DataSync is unable to create, modify, or read temporary directories in destination location」のようなエラーになる可能性があります。

FSxのコンソール画面から「ボリューム」>「概要のボリュームID」から編集を行い、
「NFSオプション」がrw,crossmnt,no_root_squashに設定すればOKです。

この詳しい設定の内容は以前私が記載した「rsync」コマンドを用いてEC2上のファイルデータをFSx for OpenZFSに移行してみた | DevelopersIOという記事にも記載しています。確認してみてください。

タスクの作成とデータ移行確認

ロケーションの設定とネットワーク疎通確認が完了したら、データ転送タスクを作成して実行します。

まずは小さなテキストファイル群（documents/）で概要動作確認を行い、その後、設定値をより本格的にして大容量ファイル（large/）の転送を実行します。

documents/ の転送タスク作成

「DataSync」>「タスク」>「タスクを作成」から以下を設定します。

送信元データオプション設定

転送オプション設定

スケジュール設定

スケジュール設定では、毎時・毎日・毎週などの定期実行や、cron式による詳細なスケジュール設定が可能です。

継続的なデータ同期が必要な場合に活用できます。今回はフルデータを１発で移行するため設定しません。

タスクレポート

タスクレポートには「概要のみ」と「標準レポート」があります。標準レポートでは成功とエラーなどレポートの粒度を設定できます。

ログ記録

実行結果の確認

タスクを作成したら「開始」>「デフォルトで開始」で実行します。

ステータスが「実行中」に変わり「タスク実行履歴」に履歴がエントリされます。基本的にはここと「CloudWatchログ」と「レポート作成用のS3」を総合的に確認して監視する形になります。

タスク実行履歴でステータスが以下のように「成功」になることを確認します。ちなみにこのレベルのファイルサイズとファイル数なら1分程度で完了します。

CloudWatchの「基本情報」レベルのログは成功すると以下のようになります。

S3の概要レポートですが以下の階層にてファイルが格納されます。

中身はこのようなレポートが保存されています。

{
  "AccountId": "************",
  "TaskExecutionId": "exec-0e06f6839f3e0d305",
  "SourceLocation": {
    "LocationType": "Network File System (NFS)",
    "LocationId": "loc-07b06fc895af5269d",
    "CreationTime": "2025-12-30T11:06:16.528000000Z"
  },
  "DestinationLocation": {
    "LocationType": "Amazon FSx for OpenZFS (NFS)",
    "LocationId": "loc-029c042c890b380b4",
    "CreationTime": "2025-12-30T12:58:32.820000000Z"
  },
  "StartTime": "2025-12-30T13:03:02.154000000Z",
  "EndTime": "2025-12-30T13:03:27.905000000Z",
  "TotalTime": 25751,
  "OverallStatus": "SUCCESS",
  "Result": {
    "FilesTransferred": 12,
    "FilesDeleted": 0,
    "FilesVerified": 12,
    "FilesSkipped": 0,
    "BytesWritten": 551,
    "BytesTransferred": 551,
    "BytesCompressed": 200,
    "PrepareDuration": 22001,
    "PrepareStatus": "SUCCESS",
    "TransferDuration": 3417,
    "TransferStatus": "SUCCESS",
    "VerifyDuration": 327,
    "VerifyStatus": "SUCCESS"
  },
  "Options": {
    "VerifyMode": "ONLY_FILES_TRANSFERRED",
    "OverwriteMode": "ALWAYS",
    "Atime": "BEST_EFFORT",
    "Mtime": "PRESERVE",
    "Uid": "INT_VALUE",
    "Gid": "INT_VALUE",
    "PreserveDeletedFiles": "PRESERVE",
    "PreserveDevices": "NONE",
    "PosixPermissions": "PRESERVE",
    "BytesPerSecond": -1,
    "TaskQueueing": "ENABLED",
    "LogLevel": "BASIC",
    "TransferMode": "ALL",
    "SecurityDescriptorCopyFlags": "NONE",
    "ObjectTags": "PRESERVE"
  },
  "Filters": {
    "Includes": [
      {
        "FilterType": "SIMPLE_PATTERN",
        "Value": "/documents/*"
      }
    ],
    "Excludes": []
  },
  "TaskReportConfig": {
    "Destination": {
      "S3": {
        "S3BucketArn": "arn:aws:s3:::my-report-bucket",
        "BucketAccessRoleArn": "arn:aws:iam::************:role/service-role/AWSDataSyncTaskReportS3BucketAccess-*****"
      }
    },
    "OutputType": "SUMMARY_ONLY"
  }
}

large/ の転送タスク作成

documents/の転送が成功したので、同様の手順で大容量(10GB)ファイルの転送タスクを作成します。
S3レポートとCloudWatchのログをより詳細にしてみます。

「DataSync」>「タスク」>「タスクを作成」から以下を設定します。

「documents/」タスクと同じなので画像は割愛します。

送信元データオプション設定

転送オプション設定

スケジュール設定

タスクレポート

レポートタイプとレベルを「documents/」タスクと比べてより厳密に詳細に設定します。

ログ記録

ログレベルを「documents/」タスクと比べてより詳細に設定します。

こちらもタスクを作成したら「開始」>「デフォルトで開始」で実行します。

今回のケースで10GBのファイル転送を行うと実際に「１時間15分」程度で成功になりました。想定よりも時間を要する結果となりました。

CloudWatchログに関しては先ほどよりも詳細に記録されています。

S3に関しては転送したファイル数が少なかったのもあり、「概要」レベルとの違いがわかりませんでした。

{
  "AccountId": "************",
  "TaskExecutionId": "exec-0c9492ed7f5b6dbed",
  "SourceLocation": {
    "LocationType": "Network File System (NFS)",
    "LocationId": "loc-07b06fc895af5269d",
    "CreationTime": "2025-12-30T11:06:16.528000000Z"
  },
  "DestinationLocation": {
    "LocationType": "Amazon FSx for OpenZFS (NFS)",
    "LocationId": "loc-029c042c890b380b4",
    "CreationTime": "2025-12-30T12:58:32.820000000Z"
  },
  "StartTime": "2025-12-30T13:47:04.962000000Z",
  "EndTime": "2025-12-30T14:54:17.950000000Z",
  "TotalTime": 4032988,
  "OverallStatus": "SUCCESS",
  "Result": {
    "FilesTransferred": 3,
    "FilesDeleted": 0,
    "FilesVerified": 3,
    "FilesSkipped": 0,
    "BytesWritten": 10737418240,
    "BytesTransferred": 10737418240,
    "BytesCompressed": 10736640000,
    "PrepareDuration": 26160,
    "PrepareStatus": "SUCCESS",
    "TransferDuration": 3946966,
    "TransferStatus": "SUCCESS",
    "VerifyDuration": 59856,
    "VerifyStatus": "SUCCESS"
  },
  "Options": {
    "VerifyMode": "ONLY_FILES_TRANSFERRED",
    "OverwriteMode": "ALWAYS",
    "Atime": "BEST_EFFORT",
    "Mtime": "PRESERVE",
    "Uid": "INT_VALUE",
    "Gid": "INT_VALUE",
    "PreserveDeletedFiles": "PRESERVE",
    "PreserveDevices": "NONE",
    "PosixPermissions": "PRESERVE",
    "BytesPerSecond": -1,
    "TaskQueueing": "ENABLED",
    "LogLevel": "TRANSFER",
    "TransferMode": "ALL",
    "SecurityDescriptorCopyFlags": "NONE",
    "ObjectTags": "PRESERVE"
  },
  "Filters": {
    "Includes": [{ "FilterType": "SIMPLE_PATTERN", "Value": "/large/*" }],
    "Excludes": []
  },
  "TaskReportConfig": {
    "Destination": {
      "S3": {
        "S3BucketArn": "arn:aws:s3:::my-report-bucket",
        "BucketAccessRoleArn": "arn:aws:iam::************:role/service-role/AWSDataSyncTaskReportS3BucketAccess-*****"
      }
    },
    "OutputType": "STANDARD",
    "ReportLevel": "SUCCESSES_AND_ERRORS",
    "ObjectVersionIds": "NONE"
  }
}

最後に

内容が大量になりましたが、本記事では、AWS DataSyncを使用してAmazon EC2上のNFSサーバーからFSx for OpenZFSへデータを移行する手順を検証しました。

前回の記事で検証した「rsyncコマンド」と比較すると、DataSyncはエージェントの準備やVPCエンドポイントの作成、セキュリティグループの設定（Agent → DataSync ENI → FSx の通信フロー）など、事前準備の手間が多くかかります。特にセキュリティグループの設定を誤ると、タスクが長時間「実行中」のまま進まないといった事象が発生するため注意が必要です。

一方で、CloudWatchログやS3レポートによる転送状況の可視化・監視が容易であり、転送バイト数や検証結果などの詳細なメトリクスを取得できる点はDataSyncの大きなメリットです。また、スケジュール実行による定期的なデータ同期や、大規模データの高速転送にも対応しているため、数TB以上のデータ移行や継続的な同期が必要なケースではDataSyncの利用を検討してみてください。

この記事がどなたかの参考になれば幸いです。今回は以上です。