AWS Migration & Transfer Vol1｜DMS×SCT×Hub×SFTP×DataSync

なぜ Migration & Transfer Vol1 か — 移行5層アーキテクチャ概観

全25軸にわたってAWS本番運用の設計力を積み上げてきた読者が次に直面する壁がある。それがデータ移行・継続的データ転送の運用設計だ。

コンピュート・ネットワーク・ストレージ・セキュリティ・監視の各領域でインフラ基盤を整備した後、オンプレミスや他クラウドからAWSへのデータ移行を設計する段階で多くのCloud ArchitectやMigration Engineerが立ち止まる。「DMSのCDC設定でリトライ条件がわからない」「SCTのアセスメント結果の読み方がわからない」「Transfer FamilyとDataSyncの使い分けが曖昧」——こうした詰まりポイントを体系的に解消するのが本記事の目的だ。

本記事は第26軸目の起点としてMigration & Transfer本番運用シリーズを立ち上げる。59記事から60記事化への到達点でもある。

Migration本番運用 Vol1 との差別化

Migration本番運用Vol1（既存）は、サーバー/アプリケーション移行（Re-host/Re-platform）を主題としている。DMS・MGN・Snow Familyをサーバー移行の文脈で解説し「どうインフラをAWSに載せるか」に焦点を当てた。

本記事はその姉妹編として「データ転送・継続的同期」という独立した技術領域をカバーする。既存Vol1とは対象サービスも視点も異なる。

移行5層アーキテクチャの概観

本記事で体系化する5サービスは、データ移行・転送を5つの役割層として整理できる。

第1層：DB移行・継続的同期（AWS DMS）
リレーショナルDB・NoSQLデータベースの移行と、本番停止を最小化したCDC継続レプリケーションを担う中核サービス。MySQL binlogやOracle LogMinerを活用してソースDBの変更を継続的にターゲットへ伝播する。

第2層：スキーマ変換（AWS SCT）
OracleからAurora PostgreSQLへの移行など、異種DB間のスキーマ変換を自動化する。変換率・手動対応アクション項目をレポートし、データ型マッピングルールのカスタマイズも可能。データ抽出エージェントを組み合わせればオンプレDBからのデータ抽出もSCT主導で完結できる。

第3層：移行追跡・戦略立案（AWS Migration Hub）
DMS・MGN等の複数ツールをまたいだ移行進捗を一元管理する。Strategy RecommendationsによるAIベースのアプリケーション移行戦略提案、Refactor Spacesによるマイクロサービス分解支援が差別化機能だ。

第4層：マネージドファイル転送（AWS Transfer Family）
SFTP/FTPS/FTP/AS2のエンドポイントをサーバー管理なしでAWS上に展開できる。既存のファイル転送ワークフローをそのままクラウドへ移行でき、パートナーB2B連携（AS2）やカスタムIDプロバイダによるAD認証統合が主なユースケースだ。

第5層：ハイブリッドデータ同期（AWS DataSync）
オンプレNFS/SMBとS3/EFS/FSxの間で大量データを高速・安全に同期する。エージェントベースのアーキテクチャで帯域制御・スケジュール実行・整合性検証をネイティブにサポートし、DRサイト同期や定期バッチ転送に最適だ。

本記事で獲得できる設計力

本記事を通じて以下の具体的な設計力を獲得できる:

• DMS CDC設計: binlog有効化からCDC開始ポイント・LOBモード選択まで、継続レプリケーションを本番停止なしに運用するためのタスク設計
• SCTアセスメント活用: 変換率レポートの読み方、手動対応が必要なストアドプロシージャ・パッケージの優先度付け
• Migration Hub戦略立案: Strategy Recommendationsの出力を移行計画に組み込み、アプリケーショングループを使った移行ウェーブ管理
• Transfer Family高可用性設計: マルチAZエンドポイント・カスタムIDプロバイダ・CloudWatch監査ログの組み合わせ
• DataSync帯域制御: スケジュールタスクと帯域幅スロットリングを組み合わせた業務影響ゼロの同期設計
• 詰まりポイント解決力: §7でカバーする7つの頻出失敗パターンと、アンチパターン→正解パターン変換の5演習

5サービスの連携パターン

典型的なエンタープライズ移行プロジェクトでは以下のフローで5サービスが連携する:

1. SCT でソースDB（Oracle/SQL Server）のアセスメントを実施し変換計画を策定
2. 変換済みスキーマをターゲットDB（Aurora/RDS）に適用
3. DMS でフルロードを実行し完了後にCDCを自動起動
4. Migration Hub で移行進捗をリアルタイム追跡しステークホルダーへ可視化
5. ファイルシステムの移行は DataSync で並行実施
6. カットオーバー後のパートナーSFTP連携を Transfer Family に移行

この5層の全体像を念頭に置きながら、§2のDMS本番運用設計から読み進めていただきたい。

AWS DMS 本番運用 — CDC継続レプリケーション / フルロード+CDC / バリデーション

DMSはAWSが提供するデータベース移行・継続的レプリケーションサービスだ。オンプレMySQLからAurora MySQL、Oracle RDSからAurora PostgreSQLへの異種DB移行、あるいは本番DB停止を最小化したCDC継続レプリケーションまで幅広いシナリオをカバーする。本番運用の鍵はレプリケーションインスタンスの適切なサイジング、エンドポイント設定、そしてCDCの継続性維持にある。

レプリケーションインスタンスの設計

レプリケーションインスタンスはDMSが実際にデータ変換・転送を処理するコンピュートリソースだ。ここの設計ミスがパフォーマンスボトルネックの主な原因となる。

インスタンスクラスの選定指針

選定の実務ルール: フルロード時はI/O集約、CDC時はCPU/メモリ集約になる。フルロード+CDCを同一タスクで動かす場合は、フルロードピーク時のCPU使用率（CloudWatch CPUUtilization）を監視し70%超なら1段上のクラスを検討する。

Multi-AZの設定

本番移行では必ずMulti-AZを有効化する。スタンバイインスタンスがAZ障害時に自動フェイルオーバーし、CDCの継続性が保たれる。フェイルオーバー時はタスクが一時停止するが、CDCオフセットは保存されており自動再開する。フェイルオーバー時間は通常60〜90秒だ。

aws dms create-replication-instance \
  --replication-instance-identifier prod-dms-instance \
  --replication-instance-class dms.c5.4xlarge \
  --allocated-storage 200 \
  --multi-az \
  --vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \
  --replication-subnet-group-identifier prod-dms-subnet-group

VPCサブネットグループ

レプリケーションサブネットグループは最低2つのAZにまたがるプライベートサブネットで構成する。ソースDBがオンプレの場合はDirect Connect/VPNのルーティングが通るサブネットを選択し、ターゲットがRDS/Auroraの場合は同じVPC内のサブネットに配置するとネットワークレイテンシを最小化できる。ネットワークACLとセキュリティグループで必要なポートのみを許可し、不要なインバウンド通信は遮断する。

ソース・ターゲットエンドポイントの設定

エンドポイントはDMSがソースDBおよびターゲットDBに接続するための設定を保持する。接続テストを必ず実施し「テスト成功」の状態でタスクを開始することがトラブル防止の基本だ。

ソースエンドポイントの主要設定

Extra Connection Attributes（ECA）の設定例

MySQLソースエンドポイントのCDC最適化:

initstmt=SET FOREIGN_KEY_CHECKS=0;addSupplementalLogging=Y

Oracleソースエンドポイント（LogMiner使用時）:

accessAlternateDirectly=false;useLogminerReader=Y;useBfile=Y

PostgreSQLソースエンドポイント（wal2json使用時）:

PluginName=pglogical;SlotName=dms_replication_slot

SSL/TLS設定

本番環境ではSslMode=requireを最低限として設定する。証明書検証が必要な場合はverify-fullを指定し、AWS Certificate Manager Private CAの証明書をDMSの証明書ストアにインポートする。オンプレDBへの接続では特にSSL/TLSを必須として移行計画に組み込む。

CDC継続レプリケーションの設計

CDCはソースDBのトランザクションログを読み取り、変更（INSERT/UPDATE/DELETE）をリアルタイムにターゲットへ伝播する。本番停止を最小化した「ライブ移行」の核心技術だ。

ソースDB側の前提条件

DMSがCDCを実行するには、ソースDB側でのトランザクションログ保持設定が必須だ。事前に確認しないとCDCタスク開始直後にログ読み取りエラーが発生する。

MySQLの場合（binlog設定の確認）:

-- binlogの有効状態を確認
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_row_image';

RDS MySQL / Aurora MySQLの場合は、パラメータグループでbinlog_format=ROWとbinlog_row_image=FULLを設定し、インスタンスの自動バックアップを有効にすることでbinlog保持が有効になる。binlogの保持期間はcall mysql.rds_set_configuration('binlog retention hours', 72)で最低72時間を設定する。

Oracleの場合（Supplemental Logging有効化）:

-- Supplemental Logging有効化（全カラム補完推奨）
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

-- 有効化の確認
SELECT SUPPLEMENTAL_LOG_DATA_MIN, SUPPLEMENTAL_LOG_DATA_ALL
FROM V$DATABASE;

CDCオフセットの開始ポイント指定

フルロード完了後にCDCを開始する場合、CDCの開始ポイントを明示的に指定することでデータギャップを防止する。

フルロード+CDC自動連携タスクでは、DMS自身がフルロード完了時のログ位置を保存して自動的にCDCへ切り替える（推奨フロー）。この場合はCDC開始ポイントの手動指定が不要だ。

LOB処理モードの選択

LOB（Large Object）カラム（TEXT, BLOB, CLOB, NCLOB等）の処理モードは移行速度とデータ完全性のトレードオフを決定する。

実務では事前にソースDBのLOBカラム最大サイズを計測する。

-- LOBカラムの最大サイズ計測
SELECT MAX(LENGTH(lob_column)) AS max_size_bytes,
 AVG(LENGTH(lob_column)) AS avg_size_bytes
FROM schema_name.table_name;

この計測値をInline LOBのしきい値設定（LobMaxSizeパラメータ）の根拠とする。AVGサイズが小さくMAXが大きい場合はInlineモードが最適だ。

フルロード + CDC コンビネーション

フルロードとCDCを同一タスクで組み合わせる構成は本番移行の標準フローだ。DMSはフルロード完了後、自動でCDCに切り替えてソースDBの変更を追跡し続ける。

フルロード設定のチューニング

{
  "FullLoadSettings": {
 "TargetTablePrepMode": "DROP_AND_CREATE",
 "CreatePkAfterFullLoad": true,
 "StopTaskCachedChangesApplied": false,
 "StopTaskCachedChangesNotApplied": false,
 "MaxFullLoadSubTasks": 8,
 "TransactionConsistencyTimeout": 600,
 "CommitRate": 50000
  }
}

MaxFullLoadSubTasks（同時ロード可能テーブル数）はデフォルト8で最大49。レプリケーションインスタンスのvCPU数に合わせて調整する（目安: vCPU × 2）。CommitRateはターゲットDBへの1トランザクションあたりのコミット行数で、大きいほど高速だがターゲットDB側のトランザクションサイズ制限に注意する。

フルロード完了 → CDC自動切替フロー

1. TargetTablePrepMode: DROP_AND_CREATEでターゲットテーブルを再作成
2. フルロード実行中、ソースDBの変更はDMSメモリキャッシュに一時保持
3. CreatePkAfterFullLoad: trueで全行挿入後に主キー/インデックスを作成（高速化）
4. フルロード完了後、キャッシュ変更を適用してCDCに自動切替
5. 以降はCDCLatencySource/Targetでリアルタイム監視

キャッシュサイズが不足する場合はレプリケーションインスタンスのメモリを増強するか、ChangeProcessingTuningパラメータで上限を調整する。

テーブルマッピング（JSON形式）

テーブルマッピングはDMSタスクの中核設定だ。移行対象の選択（selection rules）、カラム名やテーブル名の変換（transformation rules）、テーブルごとの並列処理設定（table-settings）をJSON形式で定義する。

selection rules の基本構造

{
  "rules": [
 {
"rule-type": "selection",
"rule-id": "1",
"rule-name": "include-all-tables",
"object-locator": {
  "schema-name": "mydb",
  "table-name": "%"
},
"rule-action": "include"
 },
 {
"rule-type": "selection",
"rule-id": "2",
"rule-name": "exclude-temp-tables",
"object-locator": {
  "schema-name": "mydb",
  "table-name": "tmp_%"
},
"rule-action": "exclude"
 }
  ]
}

transformation rules — カラム名の大文字/小文字変換

{
  "rule-type": "transformation",
  "rule-id": "3",
  "rule-name": "convert-column-names-lowercase",
  "rule-action": "convert-lowercase",
  "rule-target": "column",
  "object-locator": {
 "schema-name": "%",
 "table-name": "%",
 "column-name": "%"
  }
}

table-settings — 巨大テーブルの並列ロード

{
  "rule-type": "table-settings",
  "rule-id": "4",
  "rule-name": "parallel-load-orders",
  "object-locator": {
 "schema-name": "mydb",
 "table-name": "orders"
  },
  "parallel-load": {
 "type": "partitions-auto",
 "number-of-partitions": 16,
 "collection-count-from-metadata": true,
 "max-records-skip-per-page": 1000000
  }
}

1億行を超える巨大テーブルではpartitions-autoでDMSが自動的に並列分割を決定する。主キー範囲が既知の場合はtype: rangesで手動指定することで偏りのない並列化が可能だ。

タスクバリデーション

タスクバリデーションはソースとターゲットのデータ整合性を検証する機能で、移行完了後の品質確認として必ず有効化する。

バリデーションエラーが発生した場合、DMSはエラー詳細をawsdms_validation_failures_v1テーブルに記録する。

-- バリデーションエラーの確認
SELECT failure_type, table_name, key_type, failure_message
FROM awsdms_validation_failures_v1
WHERE failure_type IN ('RECORD_NOT_FOUND', 'DATA_MISMATCH')
ORDER BY failure_time DESC
LIMIT 100;

RECORD_NOT_FOUNDはターゲットに行が存在しないケース（フルロードの欠損または削除の競合）、DATA_MISMATCHはカラム値の不一致（文字コード差異やデータ型変換ミス）を示す。バリデーションエラーが増加傾向にある場合はCDCLatencyTargetも併せて確認する。

タスク監視（CloudWatchメトリクスとテーブル統計）

DMSタスクのヘルスはCloudWatchとコンソールのテーブル統計で監視する。

主要CloudWatchメトリクス

CDCLatencySourceが増大している場合はソースDBのbinlogアーカイブが追いついていない可能性がある。CDCLatencyTargetの増大はターゲットDBへの適用が遅れていることを示し、レプリケーションインスタンスのアップグレードを検討する。

テーブル統計の活用

DMSコンソールの「テーブル統計」では、テーブルごとの移行状況（フルロード行数、CDC INSERT/UPDATE/DELETE件数、エラー数）をリアルタイムで確認できる。CLIからも取得可能だ。

aws dms describe-table-statistics \
  --replication-task-arn arn:aws:dms:ap-northeast-1:123456789012:task:XXXXXXXXXXXXXXXX \
  --query 'TableStatistics[?TableState==`Table error`]' \
  --output table

AWS SCT 本番運用 — アセスメントレポート / マッピングルール / データ抽出エージェント

sequenceDiagram
 participant Source as Source Schema
 participant SCT as AWS SCT
 participant Assessment as Assessment Report
 participant DMS as AWS DMS
 participant Target as Target Schema
 Source->>SCT: スキーマ解析
 SCT->>Assessment: 変換率・アクション項目レポート
 SCT->>Target: スキーマ変換適用
 Note over SCT: マッピングルールで<br/>カスタム変換定義
 SCT->>DMS: フルロード開始トリガー
 DMS->>Target: データ移行 (Full Load + CDC)

SCT アセスメントレポートの読み方

AWS Schema Conversion Tool (SCT) は移行元データベースのスキーマをスキャンし、「変換率」「アクション項目数」「手動変換必要箇所」を含む詳細アセスメントレポートを生成する。レポートは HTML/PDF 形式で出力され、移行プロジェクトの規模見積もりと工数計算の基礎となる。

アセスメントサマリーの構成

Green/Yellow/Red トリアージ分類:

• Green — 自動変換完了。DMS での移行作業がそのまま進行可能。
• Yellow — 一部手動変更が必要。SCT が変換候補を提示するが、DBA によるレビューが求められる。
• Red — 自動変換不可。ストアドプロシージャ・パッケージ・DB リンクなど DB 固有機能を含むオブジェクト。手動書き換えまたは機能分離が必要。

Red アクション項目は移行コストに直結するため、プロジェクト開始前に全件洗い出しを行い、アプリケーション改修コストと天秤にかけた判断が求められる。

マッピングルール設計

SCT のマッピングルールは変換時の命名規則やデータ型変換の挙動をカスタマイズする仕組みだ。デフォルト変換では対応できない企業固有の命名規則や型要件に対応できる。

スキーマ名・テーブル名・カラム名変換

{
  "rules": [
 {
"rule-type": "transformation",
"rule-id": "1",
"rule-name": "schema-rename",
"object-locator": {
  "schema-name": "HR_PROD",
  "table-name": "%"
},
"rule-action": "convert-lowercase",
"value": "hr_prod_aws"
 },
 {
"rule-type": "transformation",
"rule-id": "2",
"rule-name": "col-uppercase-to-lower",
"object-locator": {
  "schema-name": "HR_PROD",
  "table-name": "%",
  "column-name": "%"
},
"rule-action": "convert-lowercase"
 }
  ]
}

SCT の GUI から「Mapping Rules」タブで設定する方法と JSON ファイルをインポートする方法がある。スキーマ名変換は Oracle の大文字スキーマ名を PostgreSQL の小文字に統一する際に頻繁に使用される。

データ型マッピング

Oracle → Aurora PostgreSQL の主要な型変換:

SQL Server → Aurora MySQL の主要な型変換:

カスタム変換スクリプト

Red アクション項目のうち SCT が変換候補を提示できないオブジェクトは Extension Pack または手動スクリプトで対応する:

-- Oracle パッケージを PostgreSQL 関数群に分解する例
-- Oracle 側: PKG_EMPLOYEE.get_salary(p_emp_id)
CREATE OR REPLACE FUNCTION pkg_employee_get_salary(p_emp_id INTEGER)
RETURNS NUMERIC AS $$
DECLARE
 v_salary NUMERIC;
BEGIN
 SELECT salary INTO v_salary
 FROM employees
 WHERE employee_id = p_emp_id;
 RETURN v_salary;
END;
$$ LANGUAGE plpgsql;

SCT Extension Pack は Oracle DBMS_CRYPTO・UTL_FILE・DBMS_SCHEDULER などの組み込みパッケージを PostgreSQL 互換関数として提供する。インストールはターゲット DB への SCT 接続後「Extension Pack and Custom SQL」メニューから実行する。

データ抽出エージェント (Extraction Agents)

大規模データベース (数十 TB 以上) の移行では DMS レプリケーションインスタンス経由でのデータ転送がボトルネックになる。SCT のデータ抽出エージェントはこの制約を解消するための機能だ。

エージェントの役割と配置

データ抽出エージェントはソース DB サーバーまたは同一サブネット上の EC2 インスタンスに配置し、S3 に直接データを書き出す。これにより DMS レプリケーションインスタンスの帯域幅制約を回避できる。

配置パターン1: オンプレミス配置

オンプレミス DC 内の専用サーバーにエージェントをインストールし、Oracle DB からデータを抽出して Direct Connect 経由で S3 ステージングバケットに書き込む。ソース DB への負荷を最小化しながら並列抽出が可能で、1 エージェントあたり 12〜16 並列スレッドが推奨値となる。

配置パターン2: EC2 配置 (RDS ソース)

RDS ソースの場合は同一 VPC 内の EC2 にエージェントを配置し、VPC Endpoint 経由で S3 に転送する。VGW や Transit Gateway を経由しないためデータ転送コストを抑制できる。

エージェント設定ファイル

# extraction-agent.properties
agent.name=oracle-extract-agent-01
agent.host=10.0.1.50
agent.port=27000
agent.working.folder=/opt/sct/agent/working
s3.bucket=migration-staging-bucket
s3.region=ap-northeast-1
s3.prefix=oracle-extract/
# 並列抽出スレッド数 (CPU コア数 × 0.75 が目安)
extraction.threads=12
# チャンクサイズ (MB)
chunk.size=256

S3 中間ステージング + ターゲット DB ロード

エージェントが S3 に書き出した Parquet/CSV ファイルを各ターゲット DB へロードする:

-- Redshift COPY コマンド
COPY target_schema.employees
FROM 's3://migration-staging-bucket/oracle-extract/employees/'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftS3CopyRole'
FORMAT AS PARQUET
SERIALIZETOJSON;

-- Aurora PostgreSQL: aws_s3 拡張機能経由ロード
SELECT aws_s3.table_import_from_s3(
  'employees',
  '',
  '(format csv, header true)',
  'migration-staging-bucket',
  'oracle-extract/employees/',
  'ap-northeast-1'
);

移行プレイブック

Oracle → Aurora PostgreSQL

SCT で Red になりやすいオブジェクト上位: カーソル操作・バルクコレクション・パイプライン関数・DB リンク経由クロスDB参照・Advanced Queuing 依存ロジック。

AWS Migration Hub 本番運用 — ディスカバリ / 移行追跡 / Strategy Recommendations / Refactor Spaces

ディスカバリ — 移行対象の可視化

Migration Hub を活用する第一ステップは移行対象インフラストラクチャの完全な可視化だ。AWS Application Discovery Service (ADS) または直接インポートの2つのアプローチがある。

Application Discovery Service

エージェントレス方式 (Discovery Connector)

VMware vCenter に Discovery Connector (OVA) を展開し、vCenter API 経由で仮想マシンのメタデータ (CPU/メモリ/ディスク/OS) を収集する。ネットワーク接続情報は取得できないが vSphere 環境への影響が最小限に抑えられる。OVA のデプロイは vCenter から「Deploy OVF Template」で実施し、収集開始は Migration Hub コンソールの「Discover → Data Collectors」から行う。

エージェントベース方式 (Discovery Agent)

各オンプレミスサーバーに Discovery Agent をインストールし、プロセス一覧・ネットワーク接続・パフォーマンスメトリクスを収集する。TCP/IP 接続ログからアプリケーション間の依存関係マップを自動生成できる点が最大の強みだ。

# Linux 向け Discovery Agent インストール
curl -o ./aws-discovery-agent.tar.gz \
  https://s3.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz
tar -xzf aws-discovery-agent.tar.gz
sudo bash install -k <AWS_ACCESS_KEY_ID> -s <AWS_SECRET_ACCESS_KEY> -r ap-northeast-1
sudo systemctl start aws-discovery-daemon
sudo systemctl enable aws-discovery-daemon

ネットワーク依存関係マッピング

エージェントベース収集後、Migration Hub コンソールの「Discover → Network Diagram」でサーバー間の TCP 接続を可視化できる。移行グループ策定時の依存関係切り分けに活用する:

• 強結合 — 同一ウェーブで移行 (API 同期呼び出し・DB 直接接続)
• 疎結合 — 別ウェーブで分割可能 (メッセージキュー経由・非同期接続)
• 外部依存 — オンプレミス残存コンポーネントへの接続 (移行後の代替手段が必要)

CSV インポート (既存 CMDB 連携)

既存の CMDB (ServiceNow/Remedy/独自スプレッドシート) のサーバー台帳を Migration Hub にインポートできる。コンソールからテンプレートをダウンロードし必須フィールドを入力する:

ExternalId,HostName,IPAddress,OSName,OSVersion,CPUCount,RAMInKB
srv-001,web-prod-01,10.0.1.10,Red Hat Enterprise Linux,7.9,8,16777216
srv-002,db-prod-01,10.0.1.20,Oracle Linux,8.4,16,67108864
srv-003,app-prod-01,10.0.1.30,Windows Server,2019 Standard,4,8388608

インポート後は Migration Hub コンソールで重複サーバーを統合し、ADS 収集データと CMDB データをマッチングさせる。

移行追跡 — 進捗の一元管理

マイグレーションタスク登録

Migration Hub は DMS・MGN・AMS・SMS と統合されており、各ツールの移行タスクを自動集約する。AWS CLI で手動登録する場合:

# 進捗更新ストリーム作成
aws migrationhub create-progress-update-stream \
  --progress-update-stream-name "DMS-Migration-Stream"

# タスク進捗更新
aws migrationhub notify-migration-task-state \
  --progress-update-stream "DMS-Migration-Stream" \
  --migration-task-name "oracle-to-aurora-employees" \
  --task '{"Status":"IN_PROGRESS","StatusDetail":"Full Load 60% complete","PercentComplete":60}' \
  --update-date-time "2026-05-27T10:00:00Z"

Strategy Recommendations — 7Rs 移行戦略エンジン

Migration Hub Strategy Recommendations は Discovery Agent の収集データ・アプリケーション情報・コードリポジトリを分析し、7Rs 移行戦略を自動推奨するサービスだ。

7Rs 推奨エンジンの仕組み

Strategy Recommendations はアプリケーションごとの推奨 R とその信頼スコアを表示する。DBA 利用率・コードの複雑度・ビジネス重要度スコアを入力として与えることで推奨精度が向上する。

ビジネスケース分析 (TCO 比較)

Strategy Recommendations は現在のオンプレミスコスト (ハードウェア更改/保守/電力/人件費) と AWS 移行後コスト (EC2/RDS/データ転送) を比較した TCO レポートを生成する。TCO 試算で考慮すべき主要項目:

オンプレミス年間コスト内訳:
  - ハードウェア減価償却: 150,000 USD
  - ソフトウェアライセンス  :  80,000 USD
  - データセンター運営費 :  60,000 USD
  - 運用人件費 (FTE 2名)  : 160,000 USD
  合計: 450,000 USD

AWS 移行後年間コスト:
  - EC2/RDS インスタンス費  :  90,000 USD
  - データ転送・ストレージ費:  25,000 USD
  - 運用工数削減後人件費 :  65,000 USD
  合計: 180,000 USD

削減率: 60% / 投資回収期間: 18 ヶ月 (移行費用 120,000 USD 含む)

右サイジング推奨

Discovery Agent のパフォーマンスメトリクス (CPU/メモリ使用率の P50/P90/P99) に基づき、過剰プロビジョニングされたサーバーに対して適切な EC2/RDS インスタンスタイプを推奨する。平均 CPU 使用率 15% 以下のサーバーは t3/t4g バースト可能インスタンスへのダウングレードが推奨される傾向にある。Strategy Recommendations の右サイジング画面では推奨インスタンスタイプと年間コスト削減額が一覧で確認できる。

Refactor Spaces — Strangler Fig パターン実装

Migration Hub Refactor Spaces はモノリシックアプリケーションを段階的にマイクロサービスへ移行するための環境を提供する。新機能を独立したマイクロサービスとして開発しつつ、旧モノリスを段階的に絞り込む Strangler Fig パターンの実装基盤となる。

ルーティング設定 (URL パスベース)

Refactor Spaces の Environment と Application を作成し、新旧サービスへのルーティングを設定する:

# Environment 作成 (Transit Gateway ベース)
aws migration-hub-refactor-spaces create-environment \
  --name "ecommerce-migration-env" \
  --network-fabric-type TRANSIT_GATEWAY

# Application 作成 (API Gateway ベース)
aws migration-hub-refactor-spaces create-application \
  --environment-identifier env-01234567890abcdef \
  --name "ecommerce-app" \
  --proxy-type API_GATEWAY

# 新マイクロサービス登録 (Lambda)
aws migration-hub-refactor-spaces create-service \
  --environment-identifier env-01234567890abcdef \
  --application-identifier app-01234567890abcdef \
  --name "orders-service" \
  --endpoint-type LAMBDA \
  --lambda-endpoint '{"Arn":"arn:aws:lambda:ap-northeast-1:123456789012:function:orders-service"}'

# URL パスベースルーティングルール設定
aws migration-hub-refactor-spaces create-route \
  --environment-identifier env-01234567890abcdef \
  --application-identifier app-01234567890abcdef \
  --service-identifier svc-01234567890abcdef \
  --route-type URI_PATH \
  --uri-path-route '{"SourcePath":"/api/orders","ActivationState":"ACTIVE","Methods":["GET","POST"]}'

段階的マイクロサービス移行フロー

移行は機能単位で段階的に実施し、各フェーズで旧モノリスとの切り戻しを担保する:

1. Shadow Mode — 新マイクロサービスに同一リクエストを複製送信し、レスポンス差分を検証
2. Canary Release — 全トラフィックの 5% → 20% → 50% → 100% と段階的に切り替え
3. Monolith Decommission — 全トラフィック移行完了後に旧コードパスを削除

Refactor Spaces はルーティングの変更をコンソールまたは CLI から即時に適用・ロールバックできるため、カナリアリリースの調整が容易だ。ヘッダベースルーティング (include-header フィールド) も利用可能で、特定のユーザーグループのみを新サービスに誘導するテストも可能となる。

アプリケーショングループ

Migration Hub のアプリケーショングループは複数サーバーを論理的なアプリケーション単位で束ねる機能だ。Application Discovery Service で収集したサーバーを手動またはグルーピングルール (タグ/ホスト名パターン/ネットワーク接続) で分類する。

# アプリケーションにサーバーを追加
aws discovery associate-configuration-items-to-application \
  --application-configuration-id d-application-01234567890 \
  --configuration-ids d-server-01 d-server-02 d-server-03

# アプリケーション一覧とサーバー数の確認
aws discovery describe-applications \
  --filters Name=resourceCount,Values=3 \
  --query 'applicationDescriptions[*].{Name:name,ServerCount:numberOfServers}'

アプリケーショングループに登録したサーバーは Migration Hub の進捗ダッシュボードでグループ単位の移行ステータスが一覧化される。サーバー単体の移行完了だけでなく、アプリケーション全体として「全サーバーが Completed」になるまでグループステータスが Completed にならない点に注意が必要だ。

マルチアカウント移行の統合管理

AWS Organizations 環境では Migration Hub ホームリージョンを1ヶ所に集約し、複数アカウントの移行状況を一元管理できる。ホームリージョンは初回設定後に変更できないため、移行プロジェクト開始前に必ず確定させる。

# ホームリージョン設定 (変更不可のため慎重に)
aws migrationhub-config create-home-region-control \
  --home-region ap-northeast-1 \
  --target '{"Type":"ACCOUNT"}'

# ホームリージョン確認
aws migrationhub-config describe-home-region-controls \
  --home-region ap-northeast-1 \
  --query 'HomeRegionControls[0].HomeRegion'

マルチアカウント構成ではメンバーアカウントの DMS/MGN タスク結果がホームリージョンアカウントの Migration Hub に自動集約される。各アカウントに ADS エージェントをインストールする際は Organizations の SCPs でエージェントの通信ポート (443) を許可し、ホームリージョンエンドポイントへの到達性を確保すること。

AWS Transfer Family 本番運用 — SFTP/FTPS/FTP/AS2 / カスタムIDプロバイダ / S3/EFS統合

プロトコル選定: SFTP / FTPS / FTP / AS2

AWS Transfer Familyは単一のマネージドサービスで4つのプロトコルをサポートする。プロトコル選定はパートナー要件・セキュリティ要件・既存インフラの3軸で判断する。

FTPは平文通信のため、パブリックエンドポイントでの利用は禁止。VPC内部テスト環境に限定すること。

B2B統合: AS2とEDI連携パターン

AS2 (Applicability Statement 2) はB2B電子商取引の標準プロトコル。Transfer FamilyのAS2サポートにより、EDIパートナーとのファイル交換をAWSネイティブで実現できる。MDN (Message Disposition Notification) による配送確認が組み込まれており、パートナーごとにプロファイルを設定する。

{
  "ServerId": "s-1234567890abcdef0",
  "As2Config": {
 "LocalProfileId": "p-local-profile",
 "PartnerProfileId": "p-partner-profile",
 "MessageSubject": "EDI Order",
 "Compression": "ZLIB",
 "EncryptionAlgorithm": "AES256_CBC",
 "SigningAlgorithm": "SHA256",
 "MdnSigningAlgorithm": "SHA256",
 "MdnResponse": "SYNC",
 "BasicAuthSecretId": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:as2-basic-auth"
  }
}

本番EDI連携では MdnResponse: SYNC で配送確認を同期取得すること。非同期MDNは再送ロジックが複雑になるため、SYNCが原則。

サーバー設定: エンドポイントタイプ・ホスト名・セキュリティポリシー

エンドポイントタイプ選定

PublicエンドポイントにElastic IPを付与することでIPホワイトリスト管理が可能。最大3件のEIPを設定できるため、Multi-AZ構成でも固定IPを維持できる。

aws transfer create-server \
  --endpoint-type PUBLIC \
  --endpoint-details '{"AddressAllocationIds":["eipalloc-12345678","eipalloc-87654321"]}' \
  --protocols SFTP \
  --identity-provider-type SERVICE_MANAGED \
  --security-policy-name TransferSecurityPolicy-2024-01

カスタムホスト名 + Route 53設定

Transfer Familyのデフォルトエンドポイントは s-<server-id>.server.transfer.<region>.amazonaws.com 形式。ビジネス向けFQDN (sftp.example.com) を提供するにはRoute 53のCNAMEレコードを設定する。

# Route 53 CNAMEレコード例
# sftp.example.com → s-1234567890abcdef0.server.transfer.ap-northeast-1.amazonaws.com
aws route53 change-resource-record-sets --hosted-zone-id Z1234567890 \
  --change-batch '{
 "Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
  "Name": "sftp.example.com",
  "Type": "CNAME",
  "TTL": 60,
  "ResourceRecords": [{"Value": "s-1234567890abcdef0.server.transfer.ap-northeast-1.amazonaws.com"}]
}
 }]
  }'

セキュリティポリシー (TLS最小バージョン)

TLS 1.0/1.1を許可するポリシーは廃止予定。新規サーバーには必ず 2024-01 以降を指定すること。

カスタムIDプロバイダ

SERVICE_MANAGED (デフォルト) はユーザーをTransfer Family内部で管理する。大規模環境・既存IDシステム統合にはカスタムIDプロバイダが必要。

Lambda + API Gateway認証

Transfer Familyは認証時にAPI GatewayのRESTエンドポイントへパスワード・SSH鍵・セッション情報を送信し、Lambdaが認証結果とユーザー設定 (ホームディレクトリ・IAMロール) を返す。

import json

def lambda_handler(event, context):
 username = event.get("username")
 password = event.get("password")

 # 独自認証ロジック (例: RDSやLDAPとの照合)
 if not authenticate_user(username, password):
  return {}  # 空レスポンス = 認証拒否

 return {
  "Role": "arn:aws:iam::123456789012:role/transfer-user-role",
  "HomeDirectory": f"/my-bucket/{username}",
  "HomeDirectoryType": "LOGICAL",
  "HomeDirectoryMappings": [
{"Entry": "/", "Target": f"/my-s3-bucket/{username}"}
  ]
 }

Lambdaが空オブジェクト {} を返すと認証拒否となる。例外をthrowするのではなく、必ず空オブジェクトを返すこと。例外はTransfer Family側でエラーとして扱われ、ログが見づらくなる。

AWS Directory Service統合

aws transfer update-server \
  --server-id s-1234567890abcdef0 \
  --identity-provider-type AWS_DIRECTORY_SERVICE \
  --identity-provider-details '{"DirectoryId":"d-9067654321"}'

AWS Managed Microsoft ADのユーザーはADパスワードでSFTPログインできる。グループポリシーや既存AD管理フローをそのまま活用できる点が最大のメリット。

Secrets Manager統合 (シンプルパターン)

ユーザー数が少ない場合は、Secrets Managerに認証情報を格納するパターンが効率的。シークレット名の命名規則: SFTP/<server-id>/<username>

{
  "Password": "HashedPasswordValue",
  "PublicKey": "ssh-rsa AAAAB3NzaC1yc2EAAA...",
  "Role": "arn:aws:iam::123456789012:role/transfer-user-role",
  "HomeDirectory": "/my-bucket/alice",
  "HomeDirectoryDetails": "[{\"Entry\":\"/\",\"Target\":\"/my-bucket/alice\"}]"
}

パスワード + SSH鍵ハイブリッド認証

パートナーによってパスワード認証・SSH公開鍵認証が混在する場合、Lambdaカスタムプロバイダでどちらの認証情報も処理できるよう実装する。event.get("password") が存在する場合はパスワード認証、event.get("publicKey") が存在する場合はSSH鍵認証として分岐する。

ストレージバックエンド: S3 / EFS統合

S3バケット統合と論理ディレクトリマッピング

ホームディレクトリタイプを LOGICAL に設定し、SFTPディレクトリとS3プレフィックスをマッピングする。

{
  "HomeDirectoryType": "LOGICAL",
  "HomeDirectoryMappings": [
 {"Entry": "/upload", "Target": "/my-bucket/uploads/${transfer:UserName}"},
 {"Entry": "/download", "Target": "/my-bucket/shared/downloads"},
 {"Entry": "/archive", "Target": "/archive-bucket/2026/${transfer:UserName}"}
  ]
}

${transfer:UserName} はTransfer Family変数でログインユーザー名に展開される。ユーザーごとのS3プレフィックスを動的に制御でき、バケット共有設計でも論理的なディレクトリ分離が実現できる。

EFS統合とPOSIX UID/GIDマッピング

EFSをバックエンドにする場合、POSIX UID/GIDのマッピングが必要。EFSはNFSベースのため、ファイルシステムのUID/GIDとTransfer FamilyユーザーのUID/GIDが一致しないとアクセスエラーになる。

aws transfer create-user \
  --server-id s-1234567890abcdef0 \
  --user-name alice \
  --home-directory /efs-root/alice \
  --role arn:aws:iam::123456789012:role/transfer-efs-role \
  --posix-profile '{"Uid":1001,"Gid":1001,"SecondaryGids":[1002,1003]}'

EFSアクセスポイントと組み合わせる場合、アクセスポイントのPOSIX設定とTransfer FamilyのposixProfileを必ず一致させること。不一致はサイレントな書き込み失敗の原因になる。

ホームディレクトリ制限 (chroot相当)

HomeDirectoryType: PATH で restricted: true を設定すると、ユーザーはホームディレクトリ配下のみアクセス可能になる (chroot相当)。B2Bパートナー・外部ユーザーには必ず制限を設定し、バケット全体へのアクセスを防ぐこと。

ログ・監査

CloudWatch Logs (構造化ログ)

CloudWatch Logsへの構造化ログ出力を有効化するには、CloudWatch Logsへの書き込み権限を持つIAMロールをサーバーに設定する。

{
  "LoggingRole": "arn:aws:iam::123456789012:role/transfer-cloudwatch-role",
  "StructuredLogDestinations": [
 "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/transfer/s-1234567890abcdef0"
  ]
}

ログフィールド: user, client-ip, session-id, command, file-size, transfer-duration。CloudWatch MetricFilterでアップロード失敗率・不審なIPアドレスからのアクセスを検知できる。

CloudTrailイベント

Transfer FamilyのAPIイベントはCloudTrailに記録される。監視すべき主要イベント:

• CreateServer / DeleteServer — サーバーの作成・削除
• CreateUser / DeleteUser — ユーザー管理
• UpdateServer — セキュリティポリシー・エンドポイント変更
• ImportSshPublicKey / DeleteSshPublicKey — SSH公開鍵管理

高可用性: Multi-AZ + Route 53フェイルオーバー

Multi-AZ自動フェイルオーバー

Transfer FamilyはAWSマネージドサービスのため、自動的にMulti-AZで冗長化される。ユーザー側での追加設定は不要だが、VPCエンドポイントを使用する場合は複数AZにサブネットを配置すること。

aws transfer create-server \
  --endpoint-type VPC \
  --endpoint-details '{
 "VpcId": "vpc-12345678",
 "SubnetIds": ["subnet-az1a-id", "subnet-az1c-id"],
 "SecurityGroupIds": ["sg-12345678"]
  }' \
  --protocols SFTP FTPS

カスタムドメイン + Route 53ヘルスチェックによるフェイルオーバー

マルチリージョン構成では、プライマリリージョン障害時にRoute 53フェイルオーバールーティングでセカンダリリージョンへ切り替える。

# プライマリレコード (ap-northeast-1)
aws route53 change-resource-record-sets --hosted-zone-id Z1234567890 \
  --change-batch '{
 "Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
  "Name": "sftp.example.com",
  "Type": "CNAME",
  "SetIdentifier": "primary",
  "Failover": "PRIMARY",
  "HealthCheckId": "hc-primary-id",
  "TTL": 60,
  "ResourceRecords": [{"Value": "s-primary.server.transfer.ap-northeast-1.amazonaws.com"}]
}
 }]
  }'

ヘルスチェックはTCPポート22への疎通確認で設定する。フェイルオーバーのRPO目標は通常60秒以内 (TTL + ヘルスチェック判定時間)。

Managed Workflows: ファイルアップロード後の自動処理

Managed Workflowsは、ファイルアップロード完了後にワークフローステップを自動実行する機能。Lambda呼び出し・タグ付け・コピー・復号化ステップを直列で組み合わせられる。

{
  "WorkflowId": "wf-1234567890abcdef0",
  "Description": "アップロード後処理: ウイルスチェック → タグ付け → アーカイブコピー",
  "Steps": [
 {
"Type": "CUSTOM",
"CustomStepDetails": {
  "Name": "VirusScan",
  "Target": "arn:aws:lambda:ap-northeast-1:123456789012:function:virus-scan",
  "TimeoutSeconds": 60
}
 },
 {
"Type": "TAG",
"TagStepDetails": {
  "Name": "TagFile",
  "Tags": [
 {"Key": "processed", "Value": "true"},
 {"Key": "uploaded-by", "Value": "${transfer:UserName}"}
  ]
}
 },
 {
"Type": "COPY",
"CopyStepDetails": {
  "Name": "ArchiveCopy",
  "DestinationFileLocation": {
 "S3FileLocation": {
"Bucket": "archive-bucket",
"Key": "2026/${transfer:UserName}/"
 }
  }
}
 }
  ],
  "OnExceptionSteps": [
 {
"Type": "CUSTOM",
"CustomStepDetails": {
  "Name": "NotifyFailure",
  "Target": "arn:aws:lambda:ap-northeast-1:123456789012:function:notify-failure",
  "TimeoutSeconds": 30
}
 }
  ]
}

WorkflowをサーバーまたはユーザーのWorkflowDetailsに設定するだけで有効化される。OnExceptionSteps で処理失敗時のLambda通知を設定しておくこと。

Step Functionsとの連携

Lambdaのタイムアウト制限 (最大15分) を超える長時間処理はStep Functionsへ委譲する。Managed WorkflowsのCUSTOMステップでStep FunctionsをトリガーするLambdaを起動し、非同期実行 + 完了後コールバックのパターンで実装する。

ワークフローを特定ユーザーにのみ適用

サーバー全体ではなく特定ユーザーへのWorkflow適用は、ユーザー設定のWorkflowDetailsで上書きする。

aws transfer create-user \
  --server-id s-1234567890abcdef0 \
  --user-name partner-acme \
  --workflow-details '{"OnUpload":[{"WorkflowId":"wf-1234567890abcdef0","ExecutionRole":"arn:aws:iam::123456789012:role/transfer-workflow-role"}]}'

AWS DataSync 本番運用 — エージェント配置 / タスク設計 / スケジュール / 帯域制御

sequenceDiagram
 participant OnPrem as On-premises NFS/SMB
 participant Agent as DataSync Agent
 participant Task as DataSync Task
 participant Target as S3 / EFS / FSx
 OnPrem->>Agent: データ読み取り
 Agent->>Task: タスク実行 (フィルタ/帯域制御)
 Task->>Target: データ転送・同期
 Note over Task: スケジュール実行<br/>差分転送・整合性検証
 Target-->>Task: 検証レポート

エージェント配置

AWS DataSyncのオンプレミスエージェントは、VMware ESXi・Hyper-V・KVM上にデプロイするVMイメージ、またはEC2 AMIとして提供されます。エージェントはソースデータへのアクセスとAWSとの暗号化通信を担い、本番環境では1拠点に対して最低1台のエージェントを配置します。

対応プラットフォームと推奨スペック:

VPCエンドポイント経由アクティベーション (本番推奨):

VPCエンドポイント経由では、エージェントとAWS DataSyncエンドポイント間の通信がAWSネットワーク内に閉じます。パブリックインターネットを経由しないため、厳格なネットワークポリシーの環境でも導入可能です。

{
  "ActivationKey": "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX",
  "AgentName": "prod-datasync-agent-01",
  "VpcEndpointId": "vpce-0a1b2c3d4e5f67890",
  "SubnetArns": [
 "arn:aws:ec2:ap-northeast-1:123456789012:subnet/subnet-abcdef01"
  ],
  "SecurityGroupArns": [
 "arn:aws:ec2:ap-northeast-1:123456789012:security-group/sg-0a1b2c3d4e5f67890"
  ]
}

パブリックエンドポイント経由ではHTTPS (TCP 443) でインターネット経由に通信します。PoC・小規模環境向けです。

エージェントステータス監視:

# エージェントリスト確認
aws datasync list-agents --region ap-northeast-1

# エージェント詳細確認
aws datasync describe-agent \
  --agent-arn arn:aws:datasync:ap-northeast-1:123456789012:agent/agent-0a1b2c3d4e5f67890 \
  --query '{Name: Name, Status: Status, EndpointType: EndpointType, LastConnectionTime: LastConnectionTime}'

ステータスが OFFLINE の場合は、ネットワーク接続・VPCエンドポイントへの到達性・エージェントVM稼働状態を順に確認します。

タスク設計

DataSyncタスクは「ソースロケーション → 転送設定 → デスティネーションロケーション」の3要素で構成されます。

ソースロケーション対応プロトコル:

デスティネーション対応ストレージ:

転送モード設定:

{
  "Name": "prod-datasync-task-nfs-to-s3",
  "SourceLocationArn": "arn:aws:datasync:ap-northeast-1:123456789012:location/loc-nfs",
  "DestinationLocationArn": "arn:aws:datasync:ap-northeast-1:123456789012:location/loc-s3",
  "Options": {
 "TransferMode": "CHANGED",
 "VerifyMode": "ONLY_FILES_TRANSFERRED",
 "PreserveDeletedFiles": "PRESERVE",
 "Overwrite": "ALWAYS",
 "Mtime": "PRESERVE",
 "Atime": "BEST_EFFORT"
  }
}

TransferMode は CHANGED（差分のみ転送）と ALL（全ファイル転送）から選択します。本番の継続的同期では CHANGED を使用し、初回フルコピーや月次整合性確認時のみ ALL を使用するパターンが標準的です。

フィルタ設定

Include / Exclude フィルタ (glob形式):

{
  "Includes": [
 { "FilterType": "SIMPLE_PATTERN", "Value": "/data/**" },
 { "FilterType": "SIMPLE_PATTERN", "Value": "*.csv" }
  ],
  "Excludes": [
 { "FilterType": "SIMPLE_PATTERN", "Value": "/data/temp/**" },
 { "FilterType": "SIMPLE_PATTERN", "Value": "*.tmp" }
  ]
}

** はゼロ以上のディレクトリ階層にマッチし、* は単一階層内の任意の文字列にマッチします。Include と Exclude を同時指定した場合、Exclude が優先されます。

ファイルサイズフィルタは MinFileSize / MaxFileSize（バイト単位）で設定し、大容量ファイルの除外や小ファイルのみの高頻度同期に使用します。

帯域制御

DataSync はデフォルトで使用可能な全帯域を使い切るため、本番ネットワークでは必ず帯域制御を設定します。

タスクレベル帯域制限:

{
  "Options": {
 "BytesPerSecond": 104857600
  }
}

上記は 100 MB/s への制限例です。-1 を指定すると帯域制限なし (デフォルト動作) になります。

スケジュールと帯域制御の組み合わせ (夜間フル帯域 / 日中制限):

ビジネス時間帯と夜間で帯域を切り替えるには、タスクを2系統作成してスケジュールで制御します。

# 日中タスク: 10 MB/s 制限 (JST 09:00-18:00 = UTC 00:00-09:00)
aws datasync create-task \
  --source-location-arn "arn:aws:datasync:ap-northeast-1:123456789012:location/loc-nfs" \
  --destination-location-arn "arn:aws:datasync:ap-northeast-1:123456789012:location/loc-s3" \
  --schedule '{"ScheduleExpression":"cron(0 */2 0-9 * ? *)"}' \
  --options '{"BytesPerSecond":10485760,"TransferMode":"CHANGED"}'

# 夜間タスク: 無制限 (JST 18:00-09:00 = UTC 09:00-00:00)
aws datasync create-task \
  --source-location-arn "arn:aws:datasync:ap-northeast-1:123456789012:location/loc-nfs" \
  --destination-location-arn "arn:aws:datasync:ap-northeast-1:123456789012:location/loc-s3" \
  --schedule '{"ScheduleExpression":"cron(0 9 * * ? *)"}' \
  --options '{"BytesPerSecond":-1,"TransferMode":"CHANGED"}'

スケジュール設定

DataSync タスクの cron 式は AWS 標準の 6 フィールド形式（分・時・日・月・曜日・年）を使用します。

{
  "Schedule": {
 "ScheduleExpression": "cron(0 2 * * ? *)"
  }
}

定期差分同期の実践パターン: 週次で TransferMode: ALL（フルコピー）を実行し、その他の日は TransferMode: CHANGED（差分）を組み合わせることで、データ整合性と転送効率を両立します。

データ整合性検証

VerifyMode オプション:

本番の継続的同期では ONLY_FILES_TRANSFERRED を基本とし、月次フルコピー時のみ POINT_IN_TIME_CONSISTENT を適用する運用が実際的です。POINT_IN_TIME_CONSISTENT はファイル数に比例して検証時間が増加するため、大規模データセットでは実行時間の見積もりが重要です。

S3 / EFS / FSx 統合

S3 バケットポリシー + IAM ロール設定:

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Principal": { "Service": "datasync.amazonaws.com" },
"Action": [
  "s3:GetBucketLocation",
  "s3:ListBucket",
  "s3:ListBucketMultipartUploads"
],
"Resource": "arn:aws:s3:::your-datasync-dest-bucket"
 },
 {
"Effect": "Allow",
"Principal": { "Service": "datasync.amazonaws.com" },
"Action": [
  "s3:AbortMultipartUpload",
  "s3:DeleteObject",
  "s3:GetObject",
  "s3:ListMultipartUploadParts",
  "s3:PutObject",
  "s3:GetObjectTagging",
  "s3:PutObjectTagging"
],
"Resource": "arn:aws:s3:::your-datasync-dest-bucket/*"
 }
  ]
}

EFS マウントターゲット + セキュリティグループ設定:

# EFS マウントターゲットのセキュリティグループに DataSync エージェントからの NFS アクセスを許可
aws ec2 authorize-security-group-ingress \
  --group-id sg-efs-mount-target \
  --protocol tcp \
  --port 2049 \
  --source-group sg-datasync-agent

# DataSync EFS ロケーション作成
aws datasync create-location-efs \
  --efs-filesystem-arn arn:aws:elasticfilesystem:ap-northeast-1:123456789012:file-system/fs-abcdef01 \
  --ec2-config '{
 "SubnetArn": "arn:aws:ec2:ap-northeast-1:123456789012:subnet/subnet-abcdef01",
 "SecurityGroupArns": [
"arn:aws:ec2:ap-northeast-1:123456789012:security-group/sg-datasync-agent"
 ]
  }' \
  --subdirectory "/"

FSx for Windows File Server へ転送する場合は、FSx ファイルシステムのセキュリティグループで DataSync エージェントからの TCP 445 (SMB) を許可し、Active Directory 認証情報を DataSync ロケーション作成時に指定します。

詰まりポイント7選 + アンチパターン→正解パターン変換

詰まりポイント1: DMS CDCでソースDB binlog未有効化→レプリケーション停止

-- binlog 設定確認
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_row_image';
-- 必要な値: log_bin=ON, binlog_format=ROW, binlog_row_image=FULL

# my.cnf に追加 (MySQL サービス再起動が必要)
[mysqld]
log_bin= /var/lib/mysql/mysql-bin.log
binlog_format= ROW
binlog_row_image = FULL
expire_logs_days = 3

詰まりポイント2: SCTアセスメントのRed項目放置→移行後アプリエラー多発

# SCT アセスメント実行結果の確認
aws dms describe-replication-task-assessment-runs \
  --filters Name=replication-task-arn,Values=arn:aws:dms:ap-northeast-1:123456789012:task:xxx \
  --query 'ReplicationTaskAssessmentRuns[*].{Status:Status,FailureMessages:ResultLocationFolder}'

詰まりポイント3: Transfer Familyカスタム IDプロバイダのLambda認証タイムアウト

# Lambda Provisioned Concurrency を設定
aws lambda put-provisioned-concurrency-config \
  --function-name sftp-custom-idp-authenticator \
  --qualifier prod \
  --provisioned-concurrent-executions 5

# 設定確認
aws lambda get-provisioned-concurrency-config \
  --function-name sftp-custom-idp-authenticator \
  --qualifier prod

詰まりポイント4: DataSyncエージェントのNFSマウント権限不足でタスク失敗

# /etc/exports 設定例 (NFS サーバー側)
# DataSync エージェントの IP を指定して no_root_squash を付与
/data/source  192.168.1.100(rw,sync,no_subtree_check,no_root_squash)

# exports 再読み込み
exportfs -ra

# DataSync 側でエージェント IP を確認
aws datasync describe-agent \
  --agent-arn arn:aws:datasync:ap-northeast-1:123456789012:agent/agent-xxx \
  --query 'PrivateLinkConfig'

詰まりポイント5: DMS LOBモード誤選択で大容量データ欠損

-- MySQL: 最大 LOB サイズ確認
SELECT MAX(LENGTH(blob_column)) AS max_size_bytes
FROM your_table;

{
  "ReplicationTaskSettings": {
 "TargetMetadata": {
"LobMode": "LimitedLOB",
"LobMaxSize": 102400
 }
  }
}

詰まりポイント6: Migration Hubディスカバリエージェントのポート未開放

# エージェント状態確認 (Linux)
sudo systemctl status aws-discovery-daemon

# 疎通確認
curl -v https://arsenal.us-west-2.amazonaws.com/

詰まりポイント7: DataSync帯域制御未設定で本番ネットワーク圧迫

# 既存タスクの帯域制限を更新 (50 MB/s に制限)
aws datasync update-task \
  --task-arn arn:aws:datasync:ap-northeast-1:123456789012:task/task-xxx \
  --options "BytesPerSecond=52428800"

# 帯域設定確認
aws datasync describe-task \
  --task-arn arn:aws:datasync:ap-northeast-1:123456789012:task/task-xxx \
  --query "Options.BytesPerSecond"

アンチパターン → 正解パターン変換

問1: DMS エンドポイント接続テストをスキップして移行開始

❌ アンチパターン:

# エンドポイント作成後、接続テストなしでタスクを即起動
aws dms create-replication-task \
  --replication-task-identifier prod-migration-task \
  --source-endpoint-arn arn:aws:dms:ap-northeast-1:123456789012:endpoint:source-xxx \
  --target-endpoint-arn arn:aws:dms:ap-northeast-1:123456789012:endpoint:target-xxx \
  --migration-type full-load-and-cdc \
  --table-mappings file://table-mappings.json

✅ 正解パターン:

# 1. ソースエンドポイントの接続テスト
aws dms test-connection \
  --replication-instance-arn arn:aws:dms:ap-northeast-1:123456789012:rep:instance-xxx \
  --endpoint-arn arn:aws:dms:ap-northeast-1:123456789012:endpoint:source-xxx

# 2. テスト結果確認 (Status = successful になるまで待機)
aws dms describe-connections \
  --filters Name=endpoint-arn,Values=arn:aws:dms:ap-northeast-1:123456789012:endpoint:source-xxx \
  --query 'Connections[*].{Status:Status,LastFailureMessage:LastFailureMessage}'

# 3. ターゲットエンドポイントも同様にテスト後、タスク作成
aws dms create-replication-task ...

問2: SCTマッピングルールなしで全テーブルを変換

❌ アンチパターン:

<!-- SCT マッピングルール: 変換なし (デフォルト状態) -->
<rules>
  <rule>
 <rule-type>selection</rule-type>
 <rule-id>1</rule-id>
 <rule-name>select-all</rule-name>
 <object-locator>
<schema-name>%</schema-name>
<table-name>%</table-name>
 </object-locator>
 <rule-action>include</rule-action>
  </rule>
</rules>

✅ 正解パターン:

<!-- 移行先スキーマ名変換 + 一時テーブル除外 -->
<rules>
  <rule>
 <rule-type>selection</rule-type>
 <rule-id>1</rule-id>
 <rule-name>select-prod-schema</rule-name>
 <object-locator>
<schema-name>SOURCE_SCHEMA</schema-name>
<table-name>%</table-name>
 </object-locator>
 <rule-action>include</rule-action>
  </rule>
  <rule>
 <rule-type>transformation</rule-type>
 <rule-id>2</rule-id>
 <rule-name>rename-schema</rule-name>
 <rule-action>convert-lowercase</rule-action>
 <rule-target>schema</rule-target>
 <object-locator>
<schema-name>SOURCE_SCHEMA</schema-name>
 </object-locator>
 <value>target_schema</value>
  </rule>
  <rule>
 <rule-type>selection</rule-type>
 <rule-id>3</rule-id>
 <rule-name>exclude-temp-tables</rule-name>
 <object-locator>
<schema-name>SOURCE_SCHEMA</schema-name>
<table-name>tmp_%</table-name>
 </object-locator>
 <rule-action>exclude</rule-action>
  </rule>
</rules>

問3: Transfer FamilySFTP ユーザーにバケット全体の権限付与

❌ アンチパターン:

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
  "arn:aws:s3:::company-sftp-bucket",
  "arn:aws:s3:::company-sftp-bucket/*"
]
 }
  ]
}

✅ 正解パターン:

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": [
  "s3:ListBucket",
  "s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::company-sftp-bucket",
"Condition": {
  "StringLike": {
 "s3:prefix": [
"home/${transfer:UserName}/*",
"home/${transfer:UserName}"
 ]
  }
}
 },
 {
"Effect": "Allow",
"Action": [
  "s3:PutObject",
  "s3:GetObject",
  "s3:DeleteObject",
  "s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::company-sftp-bucket/home/${transfer:UserName}/*"
 }
  ]
}

${transfer:UserName} 変数を使用してユーザーごとのホームディレクトリに権限を限定します。これにより他ユーザーのディレクトリへのアクセスを IAM ポリシーレベルで防止できます。

問4: DataSync タスクのエラーを無視して完了と判断

❌ アンチパターン:

# タスク実行後にステータスのみ確認して完了と判断
aws datasync describe-task-execution \
  --task-execution-arn "arn:aws:datasync:ap-northeast-1:123456789012:task/task-xxx/execution/exec-yyy" \
  --query "Status"
# "SUCCESS" が返ったので完了とみなす

✅ 正解パターン:

# タスク実行結果の詳細確認 (エラーカウントも必ず確認)
aws datasync describe-task-execution \
  --task-execution-arn "arn:aws:datasync:ap-northeast-1:123456789012:task/task-xxx/execution/exec-yyy" \
  --query '{
 Status: Status,
 FilesTransferred: FilesTransferred,
 FilesSkipped: FilesSkipped,
 FilesFailed: FilesFailed,
 BytesTransferred: BytesTransferred,
 Result: Result
  }'

FilesFailed が 1 件でもある場合は転送完了とみなしてはいけません。CloudWatch Logs でエラー詳細を確認し、原因解消後にタスクを再実行します。

問5: DMS レプリケーションインスタンスをシングルAZで本番稼働

❌ アンチパターン:

# マルチ AZ なし + メンテナンスウィンドウ未設定でレプリケーションインスタンスを作成
aws dms create-replication-instance \
  --replication-instance-identifier prod-replication-instance \
  --replication-instance-class dms.r5.xlarge \
  --allocated-storage 200 \
  --no-multi-az

✅ 正解パターン:

# マルチ AZ 有効化 + メンテナンスウィンドウをオフピーク時間帯に設定
aws dms create-replication-instance \
  --replication-instance-identifier prod-replication-instance \
  --replication-instance-class dms.r5.xlarge \
  --allocated-storage 200 \
  --multi-az \
  --preferred-maintenance-window "sun:17:00-sun:21:00" \
  --auto-minor-version-upgrade

CDC 継続レプリケーション中にレプリケーションインスタンスのメンテナンスが実行されるとフェイルオーバーが発生します。マルチ AZ を有効にしてフェイルオーバー時間を短縮し、メンテナンスウィンドウを業務への影響が少ない時間帯（週末深夜）に設定します。

まとめ — Migration & Transfer Vol1 起点宣言 + 全軸クロスリンク

AWS の Migration & Transfer サービス群は、オンプレミスからクラウドへの「一回限りの移行」だけでなく、ハイブリッド環境における「継続的なデータ転送・同期基盤」としての役割を担います。本記事で解説した5サービスはそれぞれ独立して動作しますが、実際の移行プロジェクトでは連携して使用することが多く、設計フェーズから5サービスの役割分担と連携方式を明確にすることが本番品質に直結します。

典型的な本番移行シナリオでは、まず Migration Hub のディスカバリエージェントでオンプレミス環境を可視化し、SCT でスキーマ変換アセスメントを実施します。フルロード移行中は DataSync でファイルシステムデータを並行転送し、カットオーバー後は DMS CDC で継続レプリケーションを維持しながら転換期を乗り越えます。パートナーとのファイル連携は Transfer Family に移行することで、FTP サーバーの運用負担を AWS マネージドサービスにオフロードできます。

5サービス 要点まとめ

本記事で解説した5つの AWS サービスの要点を整理します。

DMS 本番運用 重要設定一覧:

SCT 本番運用 フェーズ別アクション:

Transfer Family 本番運用 重要設定一覧:

DataSync 本番運用 重要設定一覧:

全軸クロスリンク

本記事は AWS 本番運用シリーズの第26軸目の起点です。以下の既存25軸との連携で、包括的な AWS 運用ノウハウを体系化できます。

データ移行軸 (関連性: 最高)

AWS Migration本番運用 Vol1 — DMS × MGN × Snow Family × AMS は、サーバー・アプリケーション移行（6Rs / Lift & Shift）を扱う本記事の兄弟シリーズです。本記事がデータ転送・継続同期の深堀り編として位置づけられるのに対し、Migration Vol1 はサーバー移行プロジェクト全体の戦略立案から実行までをカバーします。データ移行フェーズでは両シリーズを組み合わせて参照することを強く推奨します。

データベース軸 (関連性: 高)

DMS の移行先として RDS・Aurora を使用する場合、パラメータグループ設定・マルチ AZ・フェイルオーバー設計の詳細は RDS 本番運用シリーズおよび Aurora 本番運用シリーズで解説しています。特に Aurora MySQL への DMS CDC 設定では、Aurora クラスターのバイナリログ保持期間設定が重要です。DynamoDB への DMS ターゲット設定については、DynamoDB 本番運用シリーズのプロビジョンドキャパシティ設計と組み合わせて参照してください。

ストレージ軸 (関連性: 高)

DataSync の主要転送先である Amazon S3 の詳細設計（バケットポリシー・ストレージクラス・ライフサイクルポリシー）は S3 本番運用シリーズで解説しています。Transfer Family と DataSync の共通ターゲットである Amazon EFS のマウントターゲット・セキュリティグループ設計の詳細は EFS 本番運用シリーズを参照してください。大容量ファイル共有を FSx for Windows File Server に移行する場合は、FSx 本番運用シリーズの Active Directory 統合設計が参考になります。

ネットワーク軸 (関連性: 高)

DataSync VPC エンドポイントと Transfer Family プライベートエンドポイントの設計基礎は VPC 本番運用シリーズで解説しています。オンプレミスと AWS 間の専用線による DataSync 高速転送を構築する場合は Direct Connect 本番運用シリーズのルーティング設計を参照してください。複数 VPC をまたいで DataSync エージェントを接続する場合は Transit Gateway 本番運用シリーズのルート伝搬設計が参考になります。

サーバーレス・コンテナ軸 (関連性: 中)

Transfer Family のカスタム ID プロバイダとして Lambda を使用する場合、コールドスタート対策・Provisioned Concurrency・タイムアウト設定の詳細は Lambda 本番運用シリーズで解説しています。DataSync タスク完了後の後続処理ワークフローを Step Functions で構成する場合は、Step Functions 本番運用シリーズのエラーハンドリング設計を参照してください。Transfer Family 受信ファイルのトリガーを EventBridge で構成する場合は、EventBridge 本番運用シリーズのルールフィルタ設計が参考になります。

監視・運用軸 (関連性: 中)

DMS タスクの ReplicationLatency・DataSync の BytesTransferred・Transfer Family の接続ログなど、各サービスのメトリクス監視とアラーム設計の詳細は CloudWatch 本番運用シリーズで解説しています。コスト最適化の観点では、DMS レプリケーションインスタンスのサイジングと DataSync の転送コスト試算について、Cost Optimization 本番運用シリーズを参照してください。

CI/CD・インフラコード軸 (関連性: 低〜中)

DMS エンドポイント・レプリケーションインスタンス・DataSync タスクを Terraform または AWS CDK で管理する場合は、IaC 本番運用シリーズのステートファイル管理・ドリフト検出設計を参照してください。

次記事予告 + Migration & Transfer シリーズ展望

次記事予告: Migration & Transfer Vol2 — Snow Family × DataSync × 大容量データ移行パターン

Vol2 では、物理デバイスによる大容量データ移行と DataSync の組み合わせを深堀りします。

• Snowball Edge: ストレージ最適化 vs コンピューティング最適化 の使い分けと注文から返却までのオペレーション
• Snowball → S3 → DataSync の3段階パイプラインによる段階的クラウド移行設計
• Snow Family + DMS の組み合わせ: 大容量 DB を Snowball で初期ロード後、DMS CDC で差分同期を継続
• DataSync + S3 Transfer Acceleration によるグローバル拠点からの転送高速化
• 大容量転送のコスト試算: Snowball vs DataSync vs Direct Connect の ROI 比較

Migration & Transfer シリーズ 全体展望:

第26軸目の重要性:

本シリーズは AWS 本番運用シリーズの第26軸として、他の25軸と密接に連携します。Migration & Transfer は「一度使ったら終わり」ではなく、継続的なデータ転送・同期基盤として長期運用される領域です。Vol1 で確立した設計パターン（帯域制御・VerifyMode 選択・カスタム ID プロバイダ設計）は、Vol2 以降のシリーズでも共通の基礎となります。

本記事により AWS 本番運用シリーズは第26軸目・全60記事体系を達成しました。EC2 から DataSync まで、AWS 主要サービスの本番運用ノウハウを包括する技術ライブラリが完成しています。

読者アクションリスト

本記事を読んだ後、実際の環境で取り組む具体的なアクションを示します。

今すぐ実行できるアクション (PoC 環境):

• [ ] DMS: 開発環境 MySQL で binlog_format = ROW を設定し、Aurora への フルロード + CDC を試す
• [ ] SCT: ソース DB のアセスメントレポートを生成し、Red / Orange 項目の件数を把握する
• [ ] Transfer Family: サービスマネージド ID プロバイダで SFTP エンドポイントを作成し、S3 バケットへのアップロードを確認する
• [ ] DataSync: EC2 エージェントをデプロイし、NFS から S3 への転送タスクを実行する

本番移行前に実施すべきアクション:

• [ ] DMS: CDC の binlog/WAL 設定をソース DB DBA と協議・適用（RDS/Aurora は パラメータグループで設定）
• [ ] SCT: アセスメントの Red 項目を全件対応し、統合テストで動作確認
• [ ] Transfer Family: カスタム認証 Lambda に Provisioned Concurrency を設定してコールドスタートを排除
• [ ] DataSync: 帯域制御値を本番ネットワーク容量に基づいて設定（日中は 20〜30% 以下）
• [ ] DMS / DataSync: CloudWatch アラーム設定（エラー通知・遅延監視）
• [ ] 本番カットオーバー前に切り戻し手順を文書化

設計・アーキテクチャレビューで確認すべきポイント:

• [ ] DMS: マルチ AZ レプリケーションインスタンスの採用有無
• [ ] DMS: テーブルマッピングルールで除外すべきテーブル（tmp_*・session_* 等）の定義
• [ ] DataSync: VPC エンドポイント vs パブリックエンドポイントの選択根拠
• [ ] DataSync: VerifyMode の選択が SLA と整合しているか
• [ ] Transfer Family: カスタム ID プロバイダの SLA 要件（タイムアウト設定）
• [ ] Migration Hub: ホームリージョン設定（後から変更不可）の確認

コスト最適化のアクション:

• [ ] DataSync: TransferMode: CHANGED で差分転送を徹底し転送コストを削減
• [ ] DataSync: S3 転送先のストレージクラスを Intelligent-Tiering に設定
• [ ] DMS: 移行完了後にレプリケーションインスタンスをダウンサイジング
• [ ] Transfer Family: 接続数・転送量に基づいてエンドポイントタイプを選択

CTA

移行・転送設計の詳細は以下の公式ドキュメントとシリーズ記事を参照してください。