オンプレミス→AWS：HULFT送信の本番構成（VPN/DX・受信基盤・S3ランディング）

基幹・ホスト系はオンプレミスに残したまま、データ活用基盤や周辺システムだけを先にAWSへ寄せていく——移行の入口として最も多いパターンです。このとき鍵になるのが、オンプレミスのHULFTから送られてくるファイルをAWS側でどう受け、どこに置き、後続へどう渡すか。本記事では、経路（VPN／Direct Connect）、オンプレ接続の受け口（NLB）、受信基盤（EC2続投／HULFT10 for Container Services）、そして最も事故りやすい格納先（EBS／EFS／S3）の役割整理までを、現場の設計判断として整理します。

01なぜ「オンプレミスのHULFTからAWSへ送る」構成なのか

オンプレミスの基幹・ホスト系がHULFTで日次のファイル配信を回している一方、その受け手（分析基盤・データ活用基盤・周辺システム）だけをAWSへ移したい。こうした「送信側は据え置き、受信側だけクラウド化」は、移行のリスクを小さく刻める現実的な第一歩です。送信側の既存HULFT定義・スケジュールを大きく触らず、受信側をAWS上のHULFT（EC2でスタンドアロン続投、または HULFT10 for Container Services）へ置き換えます。HULFT10は2024年12月リリースのメジャーバージョンで、メインフレーム（zOS）／ミッドレンジ（IBMi）／UNIX（AIX）／Linux／Windowsのマルチプラットフォームに対応するため、既存の多様な送信側とも接続を組みやすいのが利点です。詳細な対応OSやバージョンは、必ず公式の動作環境ページで確認してください。

02経路設計 — VPN と Direct Connect、そして受け口はNLB

オンプレミスとAWS間の経路は、Site-to-Site VPN もしくは Direct Connect（DX）が基本です。短期・小規模・PoC段階ではVPNで素早く通し、帯域と安定性・遅延要件が本番水準になるならDXへ、という判断が一般的です。HULFTはTCPの固定ポート（配信・要求受付など）で通信するため、経路上のファイアウォール、ルーティング、セキュリティグループでそのポートを確実に通す設計が前提になります。そしてAWS側でオンプレ接続を受ける「受け口」にはNLB（L4ロードバランサ）を使います。ALBはHTTP(S)前提のためHULFTのTCP通信には合いません。NLBで安定したエントリポイントを構え、背後の受信基盤へ振り分けるのが定石です。

現場のコツ：着手前に、オンプレ側HULFTの「配信先定義（ホスト名／IP／ポート番号）」と、経路上のFW・SG許可ルールを棚卸しシートに落としておく。ここが曖昧なまま繋ぎに行くと、接続確立の切り分けに時間を溶かします。

03受信基盤の選択 — EC2でHULFT続投か、Container Servicesか

受信基盤は大きく2択です。（A）EC2上にHULFTをスタンドアロンで立てて続投する構成。既存の運用・定義・ジョブ連携をほぼそのままの感覚で持ち込め、移行の変更量を最小化できます。（B）HULFT10 for Container Services。AWS Marketplaceでのサブスクライブが必要で、Amazon ECS上で動作します。起動タイプはEC2起動タイプと、10.1.0（2024年6月）で対応したFargate起動タイプがあり、いずれも管理コンテナ（hulft-control-container）と転送コンテナ（hulft-transfer-container）で構成されます。転送負荷に応じた転送コンテナの自動起動、障害時の再起動、転送前後のWeb API呼び出しといった、コンテナならではの弾力性が得られます。周辺では管理情報・履歴にAurora MySQL、外部／内部トラフィックにALB、オンプレ接続にNLB、機微情報にSecrets Manager、証明書にACM、監視にCloudWatchなどを組み合わせます。

オンプレミスのHULFT送信からAWS受信基盤・S3ランディングまでの本番構成（VPN/DX → NLB → EC2続投＝EBS または Container Services＝EFS → S3）

04最重要：格納先の整理 — EBS／EFS／S3 を混同しない

ここが本構成でいちばん設計事故の起きやすい急所です。受信したファイルをどのストレージに置くかは、選んだ受信基盤ごとに答えが違います。まずスタンドアロン（非コンテナ）のHULFTをEC2で動かす場合、集配信ファイルの格納先は通常インスタンスのローカルディスク＝Amazon EBS（ブロック）です。EFSをそのまま集配信ターゲットにはできません。どうしてもEFSを使うなら、HULFTの「ネットワークファイル対応」機能が前提となり、NFS（EFSはNFS）上のバイト範囲ロックによる排他制御や、NFSクライアント属性キャッシュの無効化といった条件を満たす必要があります。単一ファイルへ複数プロセス・複数インスタンスから同時にアクセスする使い方は避けるべきで、EFSはEBSの単純な置き換えではありません。一方、EFSが「標準構成」として登場するのはコンテナ版です。HULFT10 for Container Services（EC2起動タイプ）は、複数コンテナ間で共有するファイルの格納先としてEFSを用い、監査ログはS3へ出します。そしてFargate起動タイプはストレージがS3（EFSではない）で、CloudFormationテンプレートで配備します。

現場のコツ：設計の最初に「スタンドアロンEC2＝EBSが基本／コンテナEC2起動タイプ＝EFS共有／Fargate起動タイプ＝S3」を一枚に固定してから議論を始める。EBS・EFS・S3を安易に同列の「集配信先」として並べないことが、後戻りを防ぐ最短ルートです。

05S3ランディングと後続処理への橋渡し

受信基盤で受けたファイルは、最終的にS3をランディングゾーンに集約し、そこから後続へ渡すのが定石です。EC2続投であれば、HULFTの集信完了後の後続ジョブやアプリ／スクリプトでS3へPUTする形になります。Container ServicesのFargate起動タイプであれば、そもそもストレージがS3なので自然にランディングまで繋がります。S3に集めておけば、EventBridgeやLambdaによるイベント駆動、Glueでの変換、Athenaでの分析など、後続処理へ低摩擦で連結できます。ここで役割分担を明確にしておくことが重要です。EBS／EFSはあくまでHULFTが受信・集配信するためのワーク／共有領域であり、S3は活用・連携のためのランディング。この線引きを崩さないことが、後続システムの設計をシンプルに保ちます。

06HULFTの強みを落とさない — 再送・配信確認・突合

そもそもクラウド移行後もHULFTを使い続ける価値は、単なるファイルコピーでは得られない「到達保証」にあります。集信完了時の配信確認、異常時の再送、集信後のジョブ起動連携、コード変換やフォーマット処理、世代管理——これらは長年ミッションクリティカルな連携を支えてきた核心機能です。AWSへ受信基盤を移しても、これらを維持したまま設計することが肝要です。加えて、S3へPUTした後の到達確認や、件数・ハッシュによる突合を後続側に用意しておくと、HULFTの配信確認とS3側の検証が二重のセーフティネットになります。移行を機に「HULFTが担う保証」と「AWSネイティブな検証」を役割分担で重ねておくと、可用性と説明責任の両方が上がります。

07PoC・検証で先に踏み抜いた落とし穴

EMWは重大障害0を継続しています。その裏側は、危ういポイントをPoC・検証段階で先に踏み抜き、本番では未然に防ぐ進め方にあります。今回の構成でも、検証で以下を先に潰してから本番設計へ反映しました。第一に、オンプレ側HULFTの配信先定義・使用ポート・経路（FW／SG）の事前確認が不足していると接続確立でつまずくと検証で判明したため、本番前に棚卸しシートで全て解消しました。第二に、検証でFargate起動タイプはEFSではなくS3前提だと分かったため、本番の永続化設計を先にS3中心へ見直しました。第三に、EFSを安易に集配信先にすると排他制御やキャッシュ整合で事故り得ると検証で確認できたため、EC2続投は基本EBS、共有が必要な場面に限り「ネットワークファイル対応」の条件を満たす、と方針を固定しました。いずれも検証で先に踏み抜き、本番では回避しています。