🎮

Unreal Engine HordeのデプロイをAWS CDKでやってみた

に公開

Unreal Engine HordeのデプロイをAWS CDKでやってみた

この記事は、Unreal Engine の Horde を AWS 上に立てるための AWS CDK サンプル(IaC) を OSS として公開したので、その背景と設計・ハマりどころをまとめたものです。

https://github.com/wilddogjp/horde-aws-cdk-example

はじめに

Unreal Engine 5.4 以降、Horde という CI/CD(ビルド・テスト・配布)基盤が利用できるようになりました。
一方で、2025 年末時点では英語/日本語ともに情報がまだ少なく、特に「クラウド上にどうやって立てるのか」「OIDC 認証や UGS(UnrealGameSync)とどう繋ぐのか」が分かりづらいのがつらいところです。

そこで私は、以下をなるべく 手戻り少なく 実現するための IaC を用意しました。

  • Horde サーバーのセットアップ(ECS Fargate)
  • OIDC(OpenID Connect)認証基盤のセットアップ(Keycloak)
  • 付随する AWS リソース一式(VPC / ALB / DB / Redis / EFS / Secrets 等)

Epic Games(Fortnite)も Terraform 等で IaC 化していると思われますが、本プロジェクトは AWS に寄せる前提 だったので、
インディー/小規模スタジオでも扱いやすい AWS CDK(TypeScript) を採用しました。

なお、この構成は弊社 株式会社ワイルドドッグ で実運用している Horde 環境に近い形になっています(OSS 版として一般化/簡略化しています)。

対象読者

  • UE の Source Build を使っていて、ビルドを自動化したい
  • Perforce + UGS を使っていて、Horde と繋げたい(この記事では UGS の使い方自体は扱いません)
  • 「Horde を AWS に立てたいが、認証/ネットワーク/永続化まで全部つらい」

前提条件

  • Unreal Engine 5.6.1 以上(README の前提に合わせています。環境により 5.5+ でも動く可能性はあります)
  • UE は Source Build を使用
  • UE プロジェクトが Engine ソース配下 にある(Horde/UGS 想定の構成)
  • Perforce を使用
  • UnrealGameSync (UGS) を使う予定がある、または利用中

この OSS がやること(ざっくり)

このリポジトリは「Horde を動かす」だけでなく、現実に運用するうえで必要になる周辺まで含めて IaC 化しています。

  • Horde Server: ECS Fargate 上で稼働
  • 認証: Keycloak(OIDC) を同じく ECS Fargate 上で稼働
  • データ: DocumentDB / Redis / RDS(PostgreSQL; Keycloak 用)
  • 設定ファイル: EFS(server.jsonglobals.json など)
  • 入口: ALB(必要に応じて Route53 + ACM)
  • 秘密情報: Secrets Manager

アーキテクチャ(概要)

README にある図をそのまま載せます(詳細は README 参照)。

┌─────────────────────────────────────────────────────────────┐
│                         Internet                            │
└───────────────────────────┬─────────────────────────────────┘

                ┌───────────▼──────────┐
                │  Application ALB     │
                │  + ACM Certificate   │
                │  (Optional Route53)  │
                └───────────┬──────────┘

┌───────────────────────────┼────────────────────────────────┐
│                          VPC                               │
│                           │                                │
│  ┌─────────────────┐      │    ┌────────────────────────┐  │
│  │ Public Subnet   │      │    │  Private Subnet        │  │
│  │  (NAT Gateway)  │      │    │                        │  │
│  └─────────────────┘      │    └───────┬────────────────┘  │
│                           │            │                   │
│                           ├─────┬──────▼──────────────┐    │
│                           │     │  ECS Fargate        │    │
│                           │     │  - Horde Server     │    │
│                           │     │  - Keycloak Auth    │    │
│                           │     └─────────────────────┘    │
│                           │                                │
│         ┌──────────────┐  │  ┌───────────┐  ┌──────────┐   │
│         │  DocumentDB  │  │  │   Redis   │  │   EFS    │   │
│         │  (MongoDB)   │  │  │  (Cache)  │  │ (Config) │   │
│         └──────────────┘  │  └───────────┘  └──────────┘   │
│                           │                                │
│         ┌──────────────────────────────────────────────┐   │
│         │  PostgreSQL RDS (Keycloak Database)          │   │
│         └──────────────────────────────────────────────┘   │
└────────────────────────────────────────────────────────────┘

苦労した点:OIDC と UGS(offline_access)

ドキュメント上、Horde は OIDC プロバイダーとして Azure / Google 等が使えるように見えます。
ただ、実際に UGS 経由でログイン しようとするとハマりどころがありました。

  • Google の OAuthでは offline_access(リフレッシュトークン) に対応しておらず、
    • Web からのログインはできる
    • しかし UGS 経由のログインができない

ここで「じゃあ Okta や Azure AD に移行するか」となると、小規模スタジオでは現実的ではないケースが多いと思います。

そこで弊社では、間に Keycloak を立てて OIDC の口を揃える 方針にしました。

  • Keycloak 自体は ECS Fargate 上でホスティング
  • 必要なら Keycloak 側で Google OAuth を Identity Provider として連携(= 既存の Google アカウントでログイン可能)

もちろん Keycloak の運用コストは増えますが、どんな認証プロバイダーも使えますし、組み合わせやゲストアカウントの発行も容易です。

CDK サンプルプロジェクトのポイント

1) すべて IaC(CDK)で完結させる

VPC からデータストア、ECS、ALB、EFS、Secrets までまとめて定義しています。
手作業が増えるほど再現性が落ちるので、新しい環境を作り直せることを重視しました。

2) 設定は cdk.context.json を推奨

config.example.jsoncdk.context.json にコピーして、必要な値を埋めるだけで動き始めるようにしています。

cp config.example.json cdk.context.json

3) セットアップ手順は SETUP.md に集約

記事内で全手順を書き切ると長くなるので、詳細は SETUP.md にまとめています。

特に以下は初見だと詰まりやすいので、手順化しました。

  • Secrets Manager に事前に作るべきシークレット
  • Horde のコンテナイメージを ECR に入れる手順(ghcr.io/epicgames/horde-server → ECR)
  • Keycloak の初期設定(Realm / Client / Secret)

使い方(最短ルート)

  1. リポジトリを clone
  2. npm install / npm run build
  3. Secrets Manager のシークレットを作成
  4. Horde Server イメージを ECR に push
  5. cdk.context.json を用意
  6. cdk bootstrap(初回のみ)
  7. cdk deploy

詳しくは SETUP.md を参照してください。

今後やりたいこと(TODO)

  • ビルドマシン(Horde Agent)の Auto Scaling機能 を動作させたい (現状だとうまく動いておらず模索中です。Horde側のプラグインで動きそうなところまではわかっています。)
  • UnrealGameSync 向けの Precompiled バイナリを Horde から生成/配布 する仕組みの整備(設定例・スクリプトを公開したいと考えています。)

おわりに

「社内で動いている仕組みを、できるだけそのまま OSS として共有する」ことを目標に、まずは土台となる IaC を切り出しました。

  • セットアップ手順通りに構築できない
  • ここが分かりづらい / ここがハマった
  • こういう機能が欲しい

…など、フィードバックや Issue を歓迎です。インディーゲームでもHordeのような基盤を使えるように情報交換できればと思っています。

最後に宣伝ですが、株式会社ワイルドドッグでは Unreal Engine を使った開発を行っています。
2025年は Keep Digging というマルチプレイの穴掘りゲームをリリースしました。
本タイトルもこの基盤を利用して開発をスムーズに進めることができました。

Keep Digging (Steam)
https://store.steampowered.com/app/3585800/Keep_Digging/?l=japanese

宣伝

現在、株式会社ワイルドドッグではゲーム開発を中心とした仲間を募集しています。
企画・開発・運営まで一貫して関われる環境で、「プレイヤーの楽しさを第一に、プレイヤーファーストなゲーム作り」を追求しています。

👉 詳しい募集内容・働き方はこちら
https://wilddog.jp/recruit

Discussion