Online / Offline Data Transferを選択する

データ転送方式を選ぶときは、Data Volumeが大きいからAWS Snow Family、Online TransferだからAWS DataSync、というように1つの条件だけでサービスを決めることはできません。

まずData Volume、実効Bandwidth、利用できる移行期間からOnline Transferが成立するかを確認し、そのうえで転送目的と現在利用できるサービスを組み合わせてTransfer Selectionを行います。

1. Transfer Selectionでは「実現可能性」と「転送目的」を分けて考える

最初の判断は「どのサービスを使うか」ではありません。

Data Volume
↓
実効Bandwidth
↓
利用できる期間
↓
Online Transferで完了できるか

Online Transferが成立するなら、次に転送目的を確認します。

NFS / SMB等のストレージデータ移行
→ AWS DataSync

SFTP / FTPS / FTP / AS2等のファイル転送ワークフロー
→ AWS Transfer Family

既存S3 APIによる遠距離転送の最適化
→ S3 Transfer Acceleration

ネットワークだけでは期間内に移行できず、物理搬送が必要ならOffline Transferを検討します。

サービスの機能が要件に合うだけではなく、その転送方式自体がData Volume、Bandwidth、期間の条件で成立することが必要です。

2. Data Volumeだけではサービスを決めない

例えば70 TBのデータがあっても、70 TBだから必ずOffline Transferとは限りません。

十分な実効Bandwidthと長い事前転送期間があり、ネットワーク転送で期限を満たせるならOnline Transferを利用できます。

反対にデータ量が比較的小さくても、Bandwidthが極端に小さく利用できる期間が短ければ、Online Transferだけでは成立しない場合があります。

Data Volume
+
Bandwidth
+
利用できる期間
↓
Online Transferが成立するか

固定された「○ TB以上ならOffline」というしきい値では判断しません。

3. Online Transferが成立しても、次に転送目的を確認する

同じData VolumeとBandwidthでも、要求される転送方式が異なれば選択するサービスも変わります。

オンプレミスNFS
↓
AWSストレージへ既存データを移行

取引先
↓
SFTP
↓
AWS上の保存先

前者ではストレージデータ移行、後者では既存ファイル転送ワークフローの維持が中心要件です。

つまりData VolumeとBandwidthだけではなく、何を、どの方式で、何のために転送するかまで確認してTransfer Selectionを行います。

4. サービスの役割は比較条件として使う

Transfer Selectionでは、既習の各サービスの役割を次のような比較条件として使います。

「転送先がAmazon S3」という1条件だけではサービスは確定しません。同じAmazon S3を最終保存先にしていても、NFSデータの移行と既存S3 APIによる遠距離アップロードでは選択が異なる場合があります。

5. サービス適合性より先にOnline Transferの成立性を見る場合がある

例えば、200 TB、実効Bandwidth 1 Gbps、利用可能期間5日、既存SFTPワークフローという要件を考えます。

SFTPという条件だけを見ればAWS Transfer Familyが候補ですが、それだけで確定しません。

200 TBを
実効1 Gbpsで
5日以内に
Online Transferできるか

期限内に全量転送できないのであれば、「SFTPだからAWS Transfer Family」という機能面だけの判断では要件を満たせません。

転送プロトコルへの適合性と、Data Volume / Bandwidth / 期間から見た転送方式の成立性の両方を確認します。

6. 同じ転送先でも送信元と転送方式を見る

次の2つは、どちらもAmazon S3を最終保存先にします。

ケースA
オンプレミスNFS
↓
大量の既存データ
↓
Amazon S3

ケースB
世界各地のアプリケーション
↓
既存S3 API
↓
Amazon S3

ケースAの中心要件はストレージデータ移行です。ケースBの中心要件が遠距離S3転送の最適化なら、ケースAとは異なる選択になります。

確認するのは、送信元、現在の転送方式、解決したい制約です。

7. Bandwidthの制約と転送最適化を混同しない

転送経路を最適化する機能があっても、拠点の物理回線上限そのものが消えるわけではありません。

例えば50 TB、拠点回線20 Mbps、2日以内という条件なら、転送経路を最適化するサービスを使うだけでは十分ではありません。

Data Volume
÷
実効Bandwidth
↓
利用可能期間へ収まるか

Online Transfer自体が成立しないのであれば、サービス機能だけを比較しても要件は満たせません。

8. 大量の初期データと最終差分で方式を分ける場合もある

Transfer Selectionでは、全データを1つの方式だけで転送する必要はありません。

例えば180 TBの既存データがあり、切り替えまで少量の更新が継続し、既存データ全量をOnline TransferするとMigration Windowを超える場合を考えます。

大量の初期データ
→ Offline Transfer

初期コピー後の変更分
→ 利用可能なOnline Transfer

判断対象は、初期データ量、更新量、Bandwidth、Migration Windowです。

大量データがあるからすべてOffline、更新データがあるからすべてOnlineと固定するのではなく、転送フェーズごとに成立する方式を組み合わせます。

9. 現在利用できるサービスかもTransfer Selectionの条件

技術的に適しているサービスでも、現在利用できなければ実際のアーキテクチャには採用できません。

2026年現在、新規顧客はAWS Snow Familyデバイスを新規注文できません。

技術的に要件へ適合するか
+
現在その顧客が利用できるか
↓
実際に採用できる候補か

Physical DeviceによるOffline Transferが技術的に適していても、その具体的なサービスを現在利用できないのであれば、BandwidthやMigration Windowを変更できるか、別の利用可能な転送手段があるかを再評価します。

10. Bandwidthが小さいだけでもOfflineへ固定しない

例えば8 TB、実効Bandwidth 25 Mbpsという条件でも、事前転送期間45日を利用でき、実測した転送速度で期限を満たせるのであればOnline Transferを利用できる可能性があります。

さらに転送対象がNFSデータなら、Online Transferが成立することを確認したうえでAWS DataSyncを候補にできます。

Bandwidthが小さい
≠
必ずOffline

Data Volume
÷
実効Bandwidth
↓
利用可能期間へ収まるか

11. 1つの条件を絶対条件にしない

次のような判断は避けます。

大容量
→ 必ずOffline

Online
→ 必ずDataSync

Amazon S3
→ 必ずTransfer Acceleration

ファイル
→ 必ずTransfer Family

代わりに複数の条件を順番に確認します。

Data Volume
↓
実効Bandwidth
↓
利用可能期間
↓
Online / Offlineの実現可能性
↓
送信元と転送方式
↓
転送先
↓
必要なワークフロー
↓
現在のサービス利用可否
↓
Transfer Selection

12. 最終判断フロー

移行するData Volumeを確認
↓
実効Bandwidthを確認
↓
利用可能期間でOnline Transferできるか
↓

YES
↓
転送目的を確認
├─ NFS / SMB等のストレージ移行
│  → AWS DataSync
│
├─ SFTP / FTPS / FTP / AS2
│  → AWS Transfer Family
│
└─ 既存S3 API + 遠距離転送最適化
   → S3 Transfer Acceleration

NO
↓
Offline Transferを検討
↓
Physical Deviceが適合するか
↓
現在利用できるサービスか確認
↓
Transfer Selection

SAP-C02では、Data Volumeやサービス名だけで即決せず、Online / Offlineの実現可能性と実際の転送目的を組み合わせてTransfer Selectionを完成させることが重要です。