HULFTをAWS Fargateにデプロイする手順（ハンズオン）— 誰でもできる再現ガイド

「HULFTのコンテナ化は難しそう」——そう身構える必要はありません。HULFT10 for Container ServicesをAWS Fargateへ載せる作業で本当に難しいのはVPC・ECS・Aurora・ALB・IAM・オートスケールの設計ですが、そのほとんどはHULFT公式が用意するCloudFormationテンプレートに畳み込まれています。自作のコンテナイメージもDockerfileも不要。本記事では、AWS Marketplaceのサブスクライブから事前準備、CloudFormationでの一括配備、OutputsとSecrets Managerでの確認、テスト転送までを、そのまま再現できるハンズオンとして整理します。あわせて、私たちがPoC段階で先に踏み抜いて本番では未然に防いだ落とし穴と、本番化で必ず詰めるべき論点も正直に共有します。

01なぜ「誰でもできる」と言い切れるのか

結論から言うと、HULFTのFargate化で難所とされる部分——新規VPCの作成、Amazon ECS（Fargate起動タイプ）のクラスターとタスク定義、管理情報を格納するAurora MySQL、接続管理用のALB、タスクに付与するIAMロール、そしてコンテナのオートスケール——は、HULFT公式が「AWS Marketplaceからの環境構築」用に提供するCloudFormationテンプレートの中にまとめて定義されています。利用者がゼロからコンテナイメージを作る必要も、これらのリソースを手作業で組み上げる必要もありません。前提として、HULFT10 for Container ServicesはAWS MarketplaceでのサブスクライブがあってはじめてECSのFargate起動タイプで動作します（Fargate対応はv10.1.0／2024年6月）。ストレージはEFSではなくAmazon S3が前提です。

つまり「誰でもできる」の実体は、難所が公式テンプレートに畳み込まれているという一点に尽きます。ただし、これはPoCや検証を素早く立ち上げられるという意味であって、本番運用がノーガードで良いという意味ではありません。CIDR設計、IAMの最小権限、監視、コスト、マルチAZ、セキュリティは、テンプレートを流したあとに自分たちできちんと詰める必要があります。この記事では「まず動かす」ところまでを手順化し、そのうえで本番化の論点を分けて説明します。

現場のコツ：公式スタートアップガイドは「マニュアル構成／製品構成／運用構成／AWS Marketplaceからの環境構築／ファイルを転送してみよう／付録（マルチAZ）／付録（アンインストール）」という章立てになっています。ハンズオンで最短に動かすなら「AWS Marketplaceからの環境構築」と「ファイルを転送してみよう」を軸に読み、本番設計に入る段で「運用構成」と付録のマルチAZへ戻る、という読み方が効率的です。

02全体像：デプロイフロー

手を動かす前に、全体の流れを一枚で掴んでおきます。大きくは「AWS Marketplaceでサブスクライブ → 事前準備（VPCのCIDR方針・S3バケット＋IAM・Route 53＋ACM） → CloudFormationでスタックを配備 → スタックがVPC／ECS(Fargate)／Aurora／ALBを一括作成 → Outputsから管理URLを、Secrets Managerから管理者パスワードを取得 → テスト転送で疎通確認」という一本道です。作業のほとんどはCloudFormationが引き受けるため、利用者が主体的に判断するのは「事前準備で何を渡すか」と「配備後にどこを確認するか」の二か所に集約されます。

HULFT10 for Container ServicesをAWS Fargateへデプロイする流れ。CloudFormationがVPC・ECS(Fargate)・Aurora・ALBを一括作成し、利用者はOutputsとSecrets Managerを確認してテスト転送するだけで疎通まで到達できる。

03事前準備：CloudFormationに渡す前にそろえる4点

スタックを流す前に、公式が求める4つの準備を済ませます。ここだけは利用者側の判断が要る部分です。

(1) AWS Marketplaceでサブスクライブする。これがないとFargate起動タイプで起動できません。(2) 新規VPCのCIDRを決める。ガイドの前提はCIDRを/24以上とし、既存VPCやオンプレミスのCIDRと重複させないこと。CloudFormationは実行リージョンに新規VPCを作るので、既存ネットワークとぶつからない範囲をあらかじめ確保しておきます。(3) 集配信用のS3バケットを作成し、ECSタスクがそのバケットへアクセスするためのIAMポリシーを用意する。(4) ドメインをRoute 53のホストゾーンに登録し、ACMでTLS証明書を発行しておく。

# (1) 集配信用の S3 バケットを作成
aws s3 mb s3://<hulft-transfer-bucket> --region <region>

# (2) ECS タスクが上記バケットへアクセスするための IAM ポリシーを作成
aws iam create-policy \
  --policy-name <hulft-s3-access-policy> \
  --policy-document file://<s3-access-policy.json>

# (3) ドメイン登録済みのホストゾーンを確認
aws route53 list-hosted-zones

# (4) ACM で TLS 証明書を発行（DNS 検証）
aws acm request-certificate \
  --domain-name <hulft.example.com> \
  --validation-method DNS

現場のコツ：S3アクセス用IAMポリシーは「対象バケット・対象プレフィックスに絞る」ことを最初から意識してください。ハンズオンで手早く動かしたい誘惑からワイルドカードで広く許可しがちですが、あとで絞り直すより最初から対象リソースを限定しておくほうが安全で、本番移行時の手戻りもありません。ACMの証明書発行はDNS検証の反映に時間がかかることがあるため、CloudFormationを流す前に検証を完了させておくと配備がスムーズです。

04CloudFormationでスタックを配備する

準備が整ったら、公式スタートアップガイドから取得したCloudFormationテンプレートを用いてスタックを配備します。テンプレートの中身（リソース定義やパラメータの正式名・既定値）はガイドに従うのが原則で、ここで勝手に値を決めたり、YAMLを自作したりはしません。渡すパラメータは、区分としては「システム名」「ドメイン名」「オートスケールのコンテナ最大数／最小数」「データベースサイズ」といったものがあります。正確なパラメータ名と既定値は公式スタートアップガイドを参照してください。

# 公式スタートアップガイドから取得したテンプレートで配備
aws cloudformation deploy \
  --template-file <公式ガイドから取得したテンプレート.yaml> \
  --stack-name <hulft-fargate-stack> \
  --parameter-overrides \
      <システム名のパラメータ>=<値> \
      <ドメイン名のパラメータ>=<hulft.example.com> \
      <コンテナ最大数のパラメータ>=<値> \
      <コンテナ最小数のパラメータ>=<値> \
      <DBサイズのパラメータ>=<値> \
  --capabilities CAPABILITY_NAMED_IAM

このコマンド一本で、スタックは実行リージョンに新規VPCを作り、その中にECS（管理コンテナ hulft-control-container と転送コンテナ hulft-transfer-container）、管理情報・履歴を格納するAurora MySQL、インターネット経由のHULFT接続管理を担うALBなどを一括で作成します。IAMロールを含むため、--capabilitiesにIAM系のケイパビリティを付与する点だけ忘れないようにします。

05配備後の確認：Outputsの管理URLとSecrets Managerのパスワード

スタックの作成が完了したら、確認するのは二か所です。ひとつはCloudFormationのOutputsタブに表示される管理（コントロール）URL。もうひとつはAWS Secrets Managerから取得する管理者パスワードです。パスワードはテンプレート内に平文で置かれるのではなくSecrets Managerで管理されるので、そこから取り出します。

# Outputs から管理（コントロール）URL を取得
aws cloudformation describe-stacks \
  --stack-name <hulft-fargate-stack> \
  --query "Stacks[0].Outputs"

# 管理者パスワードを Secrets Manager から取得
aws secretsmanager get-secret-value \
  --secret-id <管理者パスワードのシークレットID>

取得した管理URLへブラウザでアクセスし、管理者パスワードでログインすれば、HULFTの管理画面に到達します。ここまでで「動く状態」の環境は完成です。マネジメントコンソール上でOutputsとSecrets Managerを見るだけなので、コンテナ内部の細工は一切ありません。

06テスト転送：「ファイルを転送してみよう」で疎通確認

環境ができたら、公式ガイドの「ファイルを転送してみよう」に沿って疎通確認を行います。管理画面にログインし、ガイドの手順に従って集配信の設定を投入し、実際に1件ファイルを転送してみて、正常に完了することを確かめます。ここが通れば、CloudFormationが組んだVPC・ECS(Fargate)・Aurora・ALB・S3・IAMが一連で機能していることの証明になります。

現場のコツ：最初のテスト転送は「小さく・1件・往復で」確認するのが鉄則です。いきなり本番相当の大量ファイルや複雑なジョブを流すのではなく、まず単発の送信と受信が通ること、履歴がAurora側に記録されること、集配信ファイルがS3側で意図どおりに扱われることを一つずつ確かめます。疎通が取れた事実を先に固定してから、スケールや自動化の検証に進むと切り分けが楽になります。

07落とし穴：PoCで先に踏み抜いておくべき3点

「誰でもできる」とはいえ、事前準備を雑にやると配備でつまずきます。私たちはこれらをPoC・検証・テストの段階で先に踏み抜き、本番では未然に防ぐ運用を続けています（当社は重大障害ゼロ）。代表的なのは次の3つです。

1つ目はVPCのCIDR。/24未満で切ってしまう、あるいは既存VPCやオンプレミスのCIDRと重複させてしまうケース。検証環境で一度これを踏むと接続や後続の連携で問題が顕在化するため、本番設計に入る前にCIDR方針を固め、重複がないことを確認しておきます。2つ目はS3アクセス用IAMの絞り込み漏れ。とりあえず広く許可して動かし、そのまま本番に持ち込むのが最も危険なので、検証段階で対象バケット・プレフィックスに限定したポリシーへ落とし込んでおきます。3つ目はACM証明書とRoute 53の事前準備漏れ。証明書のDNS検証が未完了だったり、ホストゾーンの登録が済んでいなかったりするとTLS周りで詰まります。これらはいずれも「配備前の準備」で潰せる性質のもので、PoCで一度経験しておけば本番では発生させずに済みます。

08本番化で必ず詰めること

ここまでの手順は「まず動かす」ためのものです。実際の本番運用に載せるには、テンプレートが引き受けてくれない領域を自分たちで設計する必要があります。誇張なく言えば、ここからがエンジニアの仕事です。

具体的には、マルチAZ構成（公式ガイドの付録に手順あり）による可用性の確保、Amazon CloudWatchを用いたコンテナ・Aurora・ALBの監視とアラート設計、Fargateタスク数やAuroraサイズを踏まえたコストの見積もりと最適化、S3・ECSタスクロールを含むIAMの最小権限の徹底、そしてALB／Route 53／ACMや管理画面へのアクセス制御を含むセキュリティの作り込みです。オンプレミスのHULFTと接続する場合は、その経路と証明書、ファイアウォールの扱いも設計対象になります。CloudFormationは土台を素早く整えてくれますが、これらの非機能要件は要件に合わせて個別に詰める——そこを正直に押さえておくことが、PoCの手軽さと本番の堅牢さを両立させる鍵です。

09まとめ：難所はテンプレに、判断は人に

HULFT10 for Container ServicesのFargate化は、難所（VPC／ECS／Aurora／ALB／IAM／オートスケール）が公式のCloudFormationテンプレートに畳み込まれているため、自作コンテナなしで再現性高くデプロイできます。手順としては、Marketplaceでサブスクライブし、CIDR方針・S3＋IAM・Route 53＋ACMを準備し、CloudFormationで配備し、Outputsの管理URLとSecrets Managerのパスワードで管理画面に入り、テスト転送で疎通を確認する——これだけです。一方で、CIDR設計・最小権限・監視・コスト・マルチAZ・セキュリティといった本番の勘所は、テンプレートの外で人が判断すべき領域として残ります。「まず動かす」と「本番で堅くする」を分けて考えることが、このハンズオンを実務へつなげる最短ルートです。