AWS DataSyncのタスクを複数個作成しようとした時に空きIPアドレス不足となってしまった場合の対処方法

のんピ
2025.03.25
 AWS DataSyncのタスクを複数個作成しようとすると、空きIPアドレスが無いと言われるんだがこんにちは、のんピ(@non____97)です。
皆さんはAWS DataSyncのタスクを複数個作成しようとすると、空きIPアドレスが無いと言われた経験はありますか? 私はあります。
現在、DataSync Agentを介して転送する場合、転送先リソースがあるサブネットにENIが4つ作成されます。
ドキュメントには以下のように書かれています。


場所
デフォルトで作成されるネットワークインターフェース
パブリックエンドポイントまたは FIPS エンドポイントを使用するときにネットワークインターフェースが作成される場所
プライベート (VPC) エンドポイントを使用するときにネットワークインターフェースが作成される場所


Amazon S3
4
該当なし
DataSync エージェントをアクティベートするときに指定するサブネット。

Amazon EFS
4
Amazon EFS ロケーションを作成するときに指定するサブネット。
同左

Amazon FSx for Windows File Server
4
ファイルシステムの優先ファイルサーバーと同じサブネット。
同左

Amazon FSx for Lustre
4
ファイルシステムと同じサブネット。
同左

Amazon FSx for OpenZFS
4
ファイルシステムと同じサブネット。
同左

Amazon FSx for NetApp ONTAP
4
ファイルシステムと同じサブネット。
同左

参考 : AWS DataSync 転送用のネットワークインターフェイス - AWS DataSync
例えばオンプレミスのSMBファイルサーバーが転送元で、Amazon FSx for NetApp ONTAP(以降FSxN)を転送先とするDataSyncタスクを作成すると、FSxNが存在するサブネットにENIが4つ作成されてしまいます。DataSyncタスク作成時にENIが生成されるVPCやサブネットを選択することはできません。
一つ例を挙げると、SMBファイル共有が30個あり、SMBファイル共有単位で転送する場合はDataSyncタスクも30個作成する必要があります。つまり、消費するIPアドレス数は30 DataSyncタスク × 4 IPアドレス = 120個です。
図示すると以下のとおりです。
NACLやルートテーブルの関係でFSxやEFSなど転送先リソース専用のサブネットを作成している場合、/26や、/27など小さめのサブネットマスクとしている場合も多いのではないでしょうか。このようにサブネットマスクを細かく区切っている場合、タスク数によってはサブネット内の空きIPアドレスが足りないことがあります。
そのような状況においてDataSyncを用いてファイル転送する場合は、何かしらの対応が必要となります。
DataSyncを用いることで以下のメリットを享受できます。
マルチセッション、圧縮、ロードバランスを用いた高速データな転送
TLSおよび自動再送によるセキュアで高信頼性な転送
多数のメタデータの転送
差分転送
リアルタイムな帯域制御
データの整合性の検証
空きIPアドレスが足りないからといって、安易にRobocopyやrsyncに切り替えたくはありません。
考えられる対応策を以降紹介します。
 考えられる対応の整理 リストアップ考えられる対応をリストアップしてみます。
ざっと以下の5つのパターンがあると考えます。
転送単位毎にDataSyncタスクを作成し、ローテーションする
転送先ロケーションのリソースを空きIPアドレスが十分なサブネットで作り直す
空きIPアドレスが十分なサブネットに一次転送用のリソースを作成し、転送完了後に一次転送用のリソースのバックアップから本来のサブネット上にリストアする
(FSxNのみ) 空きIPアドレスが十分なサブネットに一次転送用のFSxNファイルシステムを作成し、転送完了後に本来の転送先FSxNファイルシステムへSnapMirrorをする
DataSyncタスクの転送ロケーションを本来転送したい起点の上位のディレクトリとし、Includes/Excludesで絞り込む
以降それぞれのパターンについて整理します。
 1. 転送単位毎にDataSyncタスクを作成し、ローテーションする複数のDataSyncタスクを作成したことによって空きIPアドレスが枯渇するのであれば、転送単位毎にこまめにDataSyncタスクを作成と削除のローテーションをするというアプローチです。
DataSyncタスクを空きIPアドレスが許す限り作成し、以降の転送分は転送が完了したDataSyncタスクを削除し、新しく転送元/転送先に対応したDataSyncロケーションを作り直して実行するといった形です。
図示すると以下のような形です。
ここで、「転送元や転送先を変更するだけなのであれば、DataSyncタスクをわざわざ作り直す必要は無いのでは?」と思われるかもしれません。
残念ながら、2025/3/18時点ではDataSyncタスクに設定したDataSyncロケーションは転送元、転送先いずれも変更することもできません。つまりは転送元や転送先の起点をDataSyncタスク作成後に変更する場合、DataSyncタスクを再作成することになります。
こちらの方式は私としては非推奨です。
理由は大きく以下の2点です。
DataSyncタスクを削除すると、マネジメントコンソールから削除したDataSyncタスクの実行結果を確認することができなくなる
DataSyncタスクをスケジューリング実行させて差分同期を行う場合に、毎回DataSyncタスクの作り直しが必要になる
CloudWatch Logsに出力したログやS3バケットに出力したレポートについては継続して確認できます。
とはいえ、GUIでどのような転送が行われていたのか確認できなくなるのは大きなデメリットでしょう。
実際に確認してみましょう。
実行履歴は以下のように確認できます。
AWS CLIでも確認できます。
>  aws datasync describe-task-execution --task-execution-arn arn:aws:datasync:us-east-1:<AWSアカウントID>:task/task-00600a02964ae7f2e/execution/exec-0706ec578bbf0129d
{
    "TaskExecutionArn": "arn:aws:datasync:us-east-1:<AWSアカウントID>:task/task-00600a02964ae7f2e/execution/exec-0706ec578bbf0129d",
    "Status": "SUCCESS",
    "Options": {
        "VerifyMode": "ONLY_FILES_TRANSFERRED",
        "OverwriteMode": "ALWAYS",
        "Atime": "BEST_EFFORT",
        "Mtime": "PRESERVE",
        "Uid": "NONE",
        "Gid": "NONE",
        "PreserveDeletedFiles": "PRESERVE",
        "PreserveDevices": "NONE",
        "PosixPermissions": "NONE",
        "BytesPerSecond": 10485,
        "TaskQueueing": "ENABLED",
        "LogLevel": "TRANSFER",
        "TransferMode": "CHANGED",
        "SecurityDescriptorCopyFlags": "OWNER_DACL",
        "ObjectTags": "PRESERVE"
    },
    "Excludes": [],
    "Includes": [
        {
            "FilterType": "SIMPLE_PATTERN",
            "Value": "/system/*"
        }
    ],
    "StartTime": "2025-02-24T09:36:57.372000+09:00",
    "EstimatedFilesToTransfer": 7,
    "EstimatedBytesToTransfer": 201331694,
    "FilesTransferred": 7,
    "BytesWritten": 201331778,
    "BytesTransferred": 201331778,
    "BytesCompressed": 849328,
    "Result": {
        "PrepareDuration": 26122,
        "PrepareStatus": "SUCCESS",
        "TotalDuration": 114920,
        "TransferDuration": 88356,
        "TransferStatus": "SUCCESS",
        "VerifyDuration": 435,
        "VerifyStatus": "SUCCESS"
    },
    "FilesDeleted": 0,
    "FilesSkipped": 1,
    "FilesVerified": 7,
    "EstimatedFilesToDelete": 0,
    "TaskMode": "BASIC",
    "FilesPrepared": 0
}
DataSyncタスクを削除します。

実行履歴から、削除したDataSyncタスクの実行履歴が削除されました。
なお、DataSyncタスク削除後もAWS CLIからは実行履歴を確認できます。
>  aws datasync list-task-executions --task-arn arn:aws:datasync:us-east-1:<AWSアカウントID>:task/task-00600a02964ae7f2e
{
    "TaskExecutions": [
        {
            "TaskExecutionArn": "arn:aws:datasync:us-east-1:<AWSアカウントID>:task/task-00600a02964ae7f2e/execution/exec-0706ec578bbf0129d",
            "Status": "SUCCESS",
            "TaskMode": "BASIC"
        },
        {
            "TaskExecutionArn": "arn:aws:datasync:us-east-1:<AWSアカウントID>:task/task-00600a02964ae7f2e/execution/exec-05dfe62094d18c86d",
            "Status": "ERROR",
            "TaskMode": "BASIC"
        },
        {
            "TaskExecutionArn": "arn:aws:datasync:us-east-1:<AWSアカウントID>:task/task-00600a02964ae7f2e/execution/exec-03f858df133e2f459",
            "Status": "SUCCESS",
            "TaskMode": "BASIC"
        }
    ]
}

>  aws datasync describe-task-execution --task-execution-arn arn:aws:datasync:us-east-1:<AWSアカウントID>:task/task-00600a02964ae7f2e/execution/exec-0706ec578bbf0129d
{
    "TaskExecutionArn": "arn:aws:datasync:us-east-1:<AWSアカウントID>:task/task-00600a02964ae7f2e/execution/exec-0706ec578bbf0129d",
    "Status": "SUCCESS",
    "Options": {
        "VerifyMode": "ONLY_FILES_TRANSFERRED",
        "OverwriteMode": "ALWAYS",
        "Atime": "BEST_EFFORT",
        "Mtime": "PRESERVE",
        "Uid": "NONE",
        "Gid": "NONE",
        "PreserveDeletedFiles": "PRESERVE",
        "PreserveDevices": "NONE",
        "PosixPermissions": "NONE",
        "BytesPerSecond": 10485,
        "TaskQueueing": "ENABLED",
        "LogLevel": "TRANSFER",
        "TransferMode": "CHANGED",
        "SecurityDescriptorCopyFlags": "OWNER_DACL",
        "ObjectTags": "PRESERVE"
    },
    "Excludes": [],
    "Includes": [
        {
            "FilterType": "SIMPLE_PATTERN",
            "Value": "/system/*"
        }
    ],
    "StartTime": "2025-02-24T09:36:57.372000+09:00",
    "EstimatedFilesToTransfer": 7,
    "EstimatedBytesToTransfer": 201331694,
    "FilesTransferred": 7,
    "BytesWritten": 201331778,
    "BytesTransferred": 201331778,
    "BytesCompressed": 849328,
    "Result": {
        "PrepareDuration": 26122,
        "PrepareStatus": "SUCCESS",
        "TotalDuration": 114920,
        "TransferDuration": 88356,
        "TransferStatus": "SUCCESS",
        "VerifyDuration": 435,
        "VerifyStatus": "SUCCESS"
    },
    "FilesDeleted": 0,
    "FilesSkipped": 1,
    "FilesVerified": 7,
    "EstimatedFilesToDelete": 0,
    "TaskMode": "BASIC",
    "FilesPrepared": 0
}
削除後24時間ほど経過しましたが、まだ情報は残っています。
また、「DataSyncタスクをスケジューリング実行させて差分同期を行う場合に、毎回DataSyncタスクの作り直しが必要になる」について言及すると、EventBridge RuleとEventBridge Schedulerを用いて、前段のDataSyncタスクの転送が完了したら、古いDataSyncタスクを削除して、新しいDataSyncタスクを作成するというプロセスも踏めますが、どうしても実装難易度は高くなるでしょう。
以上のことから、初期転送で手動で様子を見ながら対応する場合は採用の余地がありますが、カットオーバー当日までの差分同期用途としては採用できないでしょう。
 2. 転送先ロケーションのリソースを空きIPアドレスが十分なサブネットで作り直すそのサブネットの空きIPアドレスに余裕がないのであれば、余裕があるサブネット上にリソースを作り直してしまおうというアプローチです。
図示すると以下のような形です。
こちらのパターンを採用しづらいシチュエーションは以下のとおりです。
既にリソースを作り込んでいる場合
既に他システムとの連携設定を組んでいる場合
VPC上に空きネットワークアドレスが存在しない場合
1つ目と2つ目の理由は再設計、再構築、再テストの工数とスケジュールの兼ね合いかと思います。許容できない場合は別のパターンを選択することになるでしょう。
3つ目の理由ついてはVPCのセカンダリCIDRを追加することで緩和することも可能ですが、セカンダリCIDR導入に伴う全体のネットワークアドレス管理の影響を十分に加味する必要があります。
 3. 空きIPアドレスが十分なサブネットに一次転送用のリソースを作成し、転送完了後に一次転送用のリソースのバックアップから本来のサブネット上にリストアする2つ目のパターンの関連パターンです。
一次転送用のリソースをそのまま本番運用するのではなく、本来のサブネットにリストアして使おうというアプローチです。
図示すると以下のような形です。
FSxNにおいてはバックアップはボリューム単位になるため、FSxNファイルシステムレベルやSVMで作り込んでいた内容についてはそのまま活かすことが可能です。
こちらのパターンを採用しづらいシチュエーションは以下のとおりです。
既にリソースを作り込んでいる場合
既に他システムとの連携設定を組んでいる場合
カットオーバー時のダウンタイムを極力短くしたい場合
バックアップからリストアすると言っても、リストア時に再構築する範囲が広いのであれば、2つ目のパターンと比較した大きな工数的メリットは無いように思えます。
また、バックアップからリストアするため、どうしてもカットオーバー時のダウンタイムは長くなります。
他パターンでは最終同期が完了してから、同期チェックをした上でDNSなどで参照先を切り替える形になるため、そこまでの長時間はかかりません。
ただし、本パターンでは、それに加えてバックアップの取得の時間と、取得したバックアップからのリストア時間が追加でかかります。保存データ量によっては数十時間かかる場合もあるのではないでしょうか。
 4. (FSxNのみ) 空きIPアドレスが十分なサブネットに一次転送用のFSxNファイルシステムを作成し、転送完了後に本来の転送先FSxNファイルシステムへSnapMirrorをする3つ目のパターンをさらに発展させたパターンです。
FSxNではSnapMirrorという2つのボリューム間でブロックレベルで同期レプリケーションする機能が備わっています。
図示すると以下のとおりです。
「Amazon FSx for NetApp ONTAPへの移行方法を整理してみた」にて紹介した、Storage Efficiencyによる物理データ削減を行うためのアプローチとして紹介していることと行っていることとしては同じです。
抜粋 : Amazon FSx for NetApp ONTAPへの移行方法を整理してみた - Speaker Deck
クロスリージョン、クロスアカウントでも転送は可能であるため、一時的なVPC上で動かす形もあり得ます。
SnapMirrorを使うことになるので以下のようなメリットを享受することが可能です。
カットオーバー時間を短くすることが可能
既存のリソースを活かすことが可能
こちらのパターンを採用しづらいシチュエーションは「既に構築済みリソースに手を加えたくない場合」です。
このパターンを選択する場合、オリジナルFSxNで少なくとも触る要素は以下のとおりです。
クラスターピアリング
SVMピアリング
SnapMirror relationship
SnapMirror Policy
ボリューム
特に既にFSxNのボリューム内にデータが存在する場合は注意が必要です。SnapMirrorの転送先となる既存のFSxNボリューム内のデータを削除したくない場合は以下のようなケアが必要です。
オリジナルFSxN から 一次転送用FSxN へSnapMirror
オリジナルFSxN から 一次転送用FSxN へカットオーバー
一次転送用FSxN からオリジナルFSxNへのSnapMirror relationshipを作成し、再同期
SnapMirrorの再同期時の挙動や各種コマンドは以下記事が参考になります。
https://dev.classmethod.jp/articles/amazon-fsx-for-netapp-ontap-snapmirror-smb-server-failback/
 5. DataSyncタスクの転送ロケーションを本来転送したい起点の上位のディレクトリとし、Includes/Excludesで絞り込むこのパターンは以下記事で紹介している「ファイル転送したいファイル共有のパスの上位ディレクトリにパターンに当てはまるファイル共有を作成し、Includeで転送対象がファイル共有のパスになるように絞る」の方法です。
https://dev.classmethod.jp/articles/aws-datasync-smb-share-name-multibyte-character-limitation/
DataSyncは転送ロケーションで指定した箇所を起点として転送を実施します。
上位ディレクトリを起点することでまとめて転送することが可能です。例えばSMB share a、SMB share b、SMB share cおよび、その配下のフォルダを転送する場合を図示すると以下のとおりです。
「SMB share aとSMB share bのみ転送したい」という場合はIncludes/Excludesで絞り込むことも可能です。
このIncludesとExcludesはDataSyncタスク実行時にオーバーライトすることが可能です。
差分同期などで定期実行する場合でも、EventBridge SchedulerでDataSyncタスクの実行する際にオプションとしてIncludes/Excludesを指定することで実現が可能です。転送ロケーションを変更するようにDataSyncタスク自体を作り直す必要はないということです。
また、一つのDataSyncタスクを複数回実行しようとするとキューイングされます。つまり、DataSyncタスクの実行結果を待ってから次のタスク実行をする必要はありません。
タスクがキューに登録されるタイミングを知る
複数のタスクを実行する場合 (大規模なデータセットを転送する場合など)、DataSync は一連のタスク (先入れ先出し) をキューに入れる場合があります。これが発生する場合の例は次のとおりです。
同じ DataSync エージェントを使用するさまざまなタスクを実行するとき。複数のタスクに同じエージェントを使用することは可能ですが、エージェントは一度に 1 つのタスクしか実行できません。
タスクの実行が進行中であり、異なるフィルターまたはマニフェストを使用して同じタスクの追加実行を開始するとき。
各例では、キューに入れられたタスクは、前のタスクが完了するまで開始されません。
データ転送タスクの開始 - AWS DataSync
そのため、一つ目のパターンで紹介したデメリットはありません。
ただし、転送をする際にディレクトリ構造を変更する場合は使用できません。その場合、以下のようにDataSyncタスクを複数用意することになります。
こちらのパターンを採用しづらいシチュエーションは以下のとおりです。
1つのDataSyncタスクに転送対象を上手くグルーピングできない場合
空きIPアドレス的にDataSyncタスクの絶対数が足りない場合
複数のDataSyncタスクを並列で実行させたい場合
先述のとおり、キューイングされるため一つのDataSyncタスクを並列に実行することはできません。
大量の転送対象があり、ボトルネックが転送元や転送先ではなくDataSync Agentとなっている場合においては、並列実行させるためにDataSyncタスクおよびDataSync Agentを複数個作成することになるでしょう。
 採用優先度採用優先度を整理すると以下のとおりです。


パターン
優先度


1. 転送単位毎にDataSyncタスクを作成し、ローテーションする
5

2. 転送先ロケーションのリソースを空きIPアドレスが十分なサブネットで作り直す
4

3. 空きIPアドレスが十分なサブネットに一次転送用のリソースを作成し、転送完了後に一次転送用のリソースのバックアップから本来のサブネット上にリストアする
3

4. (FSxNのみ) 空きIPアドレスが十分なサブネットに一次転送用のFSxNファイルシステムを作成し、転送完了後に本来の転送先FSxNファイルシステムへSnapMirrorをする
2

5. DataSyncタスクの転送ロケーションを本来転送したい起点の上位のディレクトリとし、Includes/Excludesで絞り込む
1

プロジェクトがどのタイミングなのかで大きく対応法は変わるとは思いますが、既存の環境を極力変更したくない場合は5つ目のパターンから検討すると良いでしょう。
 DataSyncタスクのENIが作成されるサブネットやVPCを選択できるようにフィードバックしようAWS DataSyncのタスクを複数個作成しようとした時に空きIPアドレス不足となってしまった場合の対処方法を紹介しました。
FSxを別サブネットや別VPCに移動させることは容易ではありません。場合によってFSxの再作成、さらにはVPCの再作成を行う必要があります。
そういった事象を回避するために、DataSyncタスク作成時に生成されるENIのVPCとサブネットを指定できるようになると非常にありがたいです。是非AWSにフィードバックしましょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
AWS DataSyncのタスクを複数個作成しようとした時に空きIPアドレス不足となってしまった場合の対処方法

AWS DataSyncのタスクを複数個作成しようとすると、空きIPアドレスが無いと言われるんだが

考えられる対応の整理

リストアップ

1. 転送単位毎にDataSyncタスクを作成し、ローテーションする

2. 転送先ロケーションのリソースを空きIPアドレスが十分なサブネットで作り直す

3. 空きIPアドレスが十分なサブネットに一次転送用のリソースを作成し、転送完了後に一次転送用のリソースのバックアップから本来のサブネット上にリストアする

4. (FSxNのみ) 空きIPアドレスが十分なサブネットに一次転送用のFSxNファイルシステムを作成し、転送完了後に本来の転送先FSxNファイルシステムへSnapMirrorをする

5. DataSyncタスクの転送ロケーションを本来転送したい起点の上位のディレクトリとし、Includes/Excludesで絞り込む

採用優先度

DataSyncタスクのENIが作成されるサブネットやVPCを選択できるようにフィードバックしよう

関連記事

主なカテゴリ

AWS

おすすめ

プロダクト

コンテンツ

お問い合わせ

運営会社

場所	デフォルトで作成されるネットワークインターフェース	パブリックエンドポイントまたは FIPS エンドポイントを使用するときにネットワークインターフェースが作成される場所	プライベート (VPC) エンドポイントを使用するときにネットワークインターフェースが作成される場所
Amazon S3	4	該当なし	DataSync エージェントをアクティベートするときに指定するサブネット。
Amazon EFS	4	Amazon EFS ロケーションを作成するときに指定するサブネット。	同左
Amazon FSx for Windows File Server	4	ファイルシステムの優先ファイルサーバーと同じサブネット。	同左
Amazon FSx for Lustre	4	ファイルシステムと同じサブネット。	同左
Amazon FSx for OpenZFS	4	ファイルシステムと同じサブネット。	同左
Amazon FSx for NetApp ONTAP	4	ファイルシステムと同じサブネット。	同左