AWS Deadline Cloud の CMF + 自前 S3 conda channel で After Effects を動かしてみた
はじめに
3DCG / VFX 制作で利用する DCC (Digital Content Creation) アプリのレンダーファーム運用では、Worker の台数に応じて DCC のライセンス契約数を増やしていく構成が一般的です。AWS Deadline Cloud には、ジョブ実行時間に応じた従量課金でライセンスを供給できる UBL (Usage-Based Licensing) という仕組みがあり、SMF (Service-Managed Fleet) では既定で利用できます。CMF (Customer-Managed Fleet) でも License Endpoint を介して UBL を利用できることが、公式ドキュメントに記載されています。
ただし、Adobe After Effects (AE) は UBL の対象外です。 Adobe 公式ヘルプでは、After Effects CS6 以降、aerender または Watch Folder を non-royalty bearing モード (render-only モード) で実行でき、レンダー専用マシンでの serialization は不要と説明されています。そのため AE には UBL の枠組み自体が登場しません。
一方で、CMF で AE を動かす場合には別の課題があります。deadline-cloud-for-after-effects は、3ds Max や Maya の adaptor package と同じ形で Worker 側 CLI を提供するものではなく、本記事の構成では AE バイナリを conda package として Worker に供給します。AWS は SMF 向けに AE conda package を deadline-cloud channel から提供していますが、CMF Worker からは参照できません。そのため、AWS 公式の AE Submitter と conda Queue Environment の流れに沿って CMF Worker へ AE を供給する場合、自前の S3 conda channel に AE conda package を配置する構成が現実的です。
本記事では、この「CMF + 自前 S3 conda channel」 の構成で AE のレンダリングが実機で成立することを確認した結果と、検証中に得られた知見を 3 点共有します。
AWS Deadline Cloud とは
AWS Deadline Cloud は、3DCG / VFX 制作向けのレンダーファームをクラウド上に構築できるマネージドサービスです。Worker のオートスケーリングやジョブ管理、ライセンス供給などレンダーファーム運用に必要な機能を備えています。
対象読者
- AWS Deadline Cloud で CMF を構築している、もしくは検討している方
- Adobe After Effects のレンダーファームを AWS 上で構築したい方
- AE の render-only モードを利用したレンダーファーム構成を AWS 上で検討している方
参考
- AWS Deadline Cloud Developer Guide: Using software licenses
- AWS Deadline Cloud Developer Guide: Create a conda channel using S3
- aws-deadline/deadline-cloud-for-after-effects
- aws-deadline/deadline-cloud-samples: aftereffects-25.1 recipe
- aws-deadline/deadline-cloud-samples: queue_environments
- Adobe After Effects CS6 公式ヘルプ PDF (non-royalty bearing モード、p.605)
検証ゴールと構成
検証は次の 4 点をすべて満たすことをゴールとしました。
- AE Submitter プラグインから投入したジョブが Worker EC2 上で SUCCEEDED まで完走すること
- ジョブ実行中に Worker で aerender が起動し、Adobe サインインを要求しないこと
- レンダリング結果の PNG 連番が S3 経由で取得できること
- Worker が自前 S3 conda channel から AE conda package を解決して install できること
検証構成は次の通りです。Submitter は macOS で AE Trial と Submitter プラグインを利用し、AWS 側に Render Worker EC2 (Windows Server 2022) を 1 台と、自前 conda channel を持つ S3 バケットを用意しました。検証では AE 2026 を使用しています。
Render Worker には Python と Worker Agent に加え、conda package 解決のための py-rattler、Queue Environment 内部で bash を呼ぶための Git for Windows、そして Adobe non-royalty bearing モードを有効化する ae_render_only_node.txt を事前にインストールしておきます。これらの前提が揃っていないとジョブが失敗するため、Worker のセットアップは構築フローの中で重要な位置を占めます。
検証の結果
検証用シーンとして、640 x 480 / 24fps / 1 秒のコンポジションに平面レイヤーを 1 つ配置しただけのミニマルな AEP プロジェクトを用意し、Submitter プラグインからジョブを投入しました。出力モジュールは PNG Sequence に設定しています。
ジョブのステータスは READY から STARTING、RUNNING を経て SUCCEEDED まで遷移し、3 タスクが 36 秒で完走しました。ジョブの出力は deadline job download-output でローカルに取得でき、24 枚の PNG 連番が得られました。
今回の検証では、次のようなグレー 1 色の PNG を出力しました。

CloudWatch Logs を確認すると、Worker 上で aerender が Finished composition と Total Time Elapsed: 1 Seconds を出力した後に No errors detected, exiting with process return code: 0 で終了しており、Adobe サインインプロンプトが出ていないことも確認できました。
CMF Fleet 上の AE が自前 S3 conda channel から conda package を解決し、non-royalty bearing モードでレンダリングできることを実機で確認できました。
全体の流れ
検証は次の 6 つの Phase で進めました。各 Phase の目的と何をしたかを簡潔に示します。細かな手順は参考リンクと公式ドキュメントを参照してください。
Phase 1. AWS リソース構築
Farm / Queue / Fleet / Queue Environment / Storage Profile / IAM ロール / S3 バケット / セキュリティグループ / Key Pair を AWS CLI でまとめて作成します。CMF Fleet を新規作成するときに指定する Fleet Worker Role には、マネージドポリシー AWSDeadlineCloud-FleetWorker に加えて CloudWatch Logs 権限のインラインポリシーを手動付与する必要があります。これは SMF と異なる点で、詳細は弊社の過去記事AWS Deadline Cloud の CMF + UBL で 3ds Max を動かしてみたで触れています。
Phase 2. AE バイナリの取得と S3 アップロード
一時的に Windows Server 2022 の EC2 を起動して Creative Cloud Desktop App から AE Trial をインストールし、AE の Support Files フォルダを zip 化して S3 の archive_files/ プレフィックスにアップロードします。これは AWS が提供する aftereffects-25.1 recipe の README と同じ手順です。
本検証では、Adobe アカウントが必要になったのはこの段階のみでした。Render Worker でのレンダリング実行時には Adobe サインインプロンプトが出ないことを確認しています。
Phase 3. conda package の構築と S3 channel への配置
ローカル macOS に Miniforge と conda-build をインストールし、AWS 公式の aftereffects-25.1 recipe をベースに aftereffects-26.0 recipe を作成します。meta.yaml の version と sha256 を更新し、win-64 ターゲットで conda package をビルドして S3 channel にアップロードします。
通常は AWS Deadline Cloud の Package Build Queue 経由でビルドするのが公式の推奨ルートですが、AE conda package はネイティブコードのコンパイルを伴わない (Support Files のコピーと activate.d スクリプト生成のみ) ため、macOS からクロスビルドできます。本検証ではこの方法を採用しました。
S3 conda channel は private bucket として作成し、Queue service role と Worker 側の役割から s3://<your-bucket>/Conda/Default への読み取り権限を付与しておきます。AWS 公式の S3 conda channel 手順でも、production queue に /Conda プレフィックスへの read-only 権限を与える例が示されています。
Phase 4. Render Worker EC2 のセットアップ
Render Worker EC2 (Windows Server 2022) を起動し、Python 3.11、Worker Agent、py-rattler、Git for Windows、そして Administrator Documents 配下の ae_render_only_node.txt を順にインストールします。py-rattler は >=0.18,<0.19 でバージョン pin します。0.19 系では Queue Environment 側の API 呼び出しと合わなかったため、本検証では 0.18 系を採用しました。Worker Agent のサービス登録時には worker.toml の run_jobs_as_agent_user=true を有効化し、Worker Agent サービスを再起動して Fleet に IDLE で参加させます。
Phase 5. macOS Submitter のセットアップ
ローカルの macOS に Creative Cloud Desktop App から AE 2026 Trial をインストールし、AE のスクリプト実行権限 (Allow Scripts To Write Files And Access Network) を有効化します。AWS Deadline Cloud Submitter インストーラを実行して AE Submitter プラグインをインストールし、deadline CLI は専用 venv (~/venvs/ae-submitter) に分離してインストールしました。
Phase 6. ジョブ投入と検証
AE で検証用 AEP を開き、Render Queue に追加してから、Submitter UI を起動してジョブを投入しました。

ジョブのステータス遷移と aerender の動作確認は CloudWatch Logs と aws deadline list-jobs で監視できます。
検証で得た知見
deadline-cloud-for-after-effects は Worker 側 CLI を提供しない。Worker は conda package 経由で aerender を取得する
検証当初は、3ds Max や Maya の adaptor package と同様に、deadline-cloud-for-after-effects も pip install すると Worker 側 CLI が PATH に通ると想定しました。3ds Max 検証では deadline-cloud-for-3ds-max を pip install すると 3dsmax-openjd.exe が PATH に通り、これが Worker でジョブ実行される形でした。
しかし pyproject.toml を確認すると [project.scripts] セクションが空で、Worker 側 CLI を一切提供していません。deadline-cloud-for-after-effects は AE Submitter として Submitter 側のみで動作し、作成される job bundle は AE 同梱の aerender を Worker 側で利用する構造になっています。
本検証で成立した経路は、AE Submitter が OpenJD ジョブテンプレートに CondaPackages パラメータ (例えば aftereffects=26.0) を埋め込み、Worker は Queue Environment 経由で conda channel から AE conda package を解決して aerender を起動する設計 です。AE conda package の中身は AE Trial インストールを zip 化したものになります。AWS は SMF 向けに AE 24.6 / 25.1 / 25.2 / 25.6 / 26.0 を deadline-cloud channel から提供していますが、CMF Worker からは参照できないため、自前で AE conda package を作成する必要があります。
AWS Sample の pyrattler 版 Queue Environment は Windows Worker で動作しない
AWS Deadline Cloud Samples の conda_queue_env_pyrattler.yaml は、conda 本体を Worker に install せずに py-rattler 経由で conda package を解決できる Queue Environment です。Worker のセットアップが軽くなるため、当初はこれをそのまま attach すれば動くと想定しました。
しかし Windows Worker でジョブを実行すると、conda env の activation 段階で FileNotFoundError: The system cannot find the file specified で失敗します。原因は Queue Environment 内部の Python スクリプトが、activation 時に subprocess.check_call(["bash", capture_script]) で bash を呼び、capture_script 内で sys.executable を使ってさらに Python を呼び出す構造にあります。Worker Agent は Python を相対パス .\python.EXE で起動するため、sys.executable も相対パスのまま伝播し、bash 経由で異なる CWD から呼ばれるとファイルが見つからずに失敗します。
本検証で成立した経路は、Queue Environment 内の Python スクリプトに sys.executable の絶対パス化フォールバックを追加すること でした。patch の全文は本記事末尾の付録に掲載しています。この知見は本記事の執筆時点で公開された事例が見当たらないため、同じ構成で詰まった方の参考になれば幸いです。
macOS から Windows 向け conda package をクロスビルドできる。ただし build.sh の追加が必要
AE conda package のビルドには、AWS Deadline Cloud Samples の README では Package Build Queue (専用 Build Fleet と Build Worker EC2 を用意する構成) を立てる方法が紹介されています。当初はこの方法に従う想定でした。
しかし AE conda package の中身は AE Support Files をコピーして activate.d スクリプトを生成するだけで、ネイティブコードのコンパイルが発生しません。そのため macOS でも CONDA_SUBDIR=win-64 を指定すればクロスビルドできます。
ただし AWS 公式の AE recipe には bld.bat (Windows 用 wrapper) と build_win.sh (bash 実体) しか含まれず、macOS conda-build はビルドスクリプトを見つけられず空 package を生成してしまいます (WARNING: No files or script found for output が出ます) 。
今回採用した回避策は build_win.sh を build.sh としてコピーするだけ です。macOS conda-build はこれを検出して bash で実行し、win-64 用 conda package を正しく生成します。構築時間は 30 分程度で、Package Build Queue 経由 (Build Worker EC2 の起動と構成込みで 90 - 120 分) と比べて大幅に短縮できます。
cp aftereffects-26.0/recipe/build_win.sh aftereffects-26.0/recipe/build.sh
chmod +x aftereffects-26.0/recipe/build.sh
CONDA_SUBDIR=win-64 conda-build aftereffects-26.0/recipe --no-test --output-folder ./conda-build-output
成果物は conda-build-output/win-64/aftereffects-26.0-0.conda (3.9 GB 程度) として生成され、aws s3 sync で S3 conda channel に配置できます。
まとめ
AWS Deadline Cloud の CMF と自前 S3 conda channel の組み合わせで、AE のレンダリングが成立することを実機で確認できました。本検証では、ae_render_only_node.txt を配置した Worker で Adobe サインインプロンプトなしに aerender が完走することを確認しました。今回の検証はミニマルなコンポジション 1 つのみのため、Pencil+ や V-Ray などのプラグインを含む構成、マルチフレームレンダリング、Fleet のスケール動作の確認は次のステップとなります。本記事が、AWS Deadline Cloud で CMF と AE の構成を検討する際の参考になれば幸いです。
付録: 検証で作成したスクリプトと patch
検証で作成したカスタムスクリプトと patch のうち、既存の公開情報からそのまま流用できないものを以下に折りたたみで掲載します。
pyrattler 版 Queue Environment の Windows 互換 patch
AWS Deadline Cloud Samples の conda_queue_env_pyrattler.yaml 内の Python スクリプトには、conda env の activation 時に bash 経由で sys.executable の Python を呼び出す処理があります。Windows Worker では sys.executable が相対パス (.\python.EXE) のまま伝播してしまい、bash の CWD と Python の CWD が異なるためにファイルが見つからずに失敗します。
そこで sys.executable が指すファイルが存在しなかった場合に、shutil.which で PATH から Python を探し、それでも見つからない場合は決め打ちで C:\Program Files\Python311\python.exe を試す fallback ロジックを追加します。
該当箇所は、Queue Environment の embeddedFiles 内の Python スクリプトの f.write(shlex.join([sys.executable, vars_capture_script, vars_file])) 行です。これを次のように差し替えます。
import shutil as _shutil
_py_exe = sys.executable
if not os.path.isfile(_py_exe):
for _cand in (
_shutil.which("python.exe"),
_shutil.which("python"),
r"C:\Program Files\Python311\python.exe",
):
if _cand and os.path.isfile(_cand):
_py_exe = _cand
break
with open(capture_script, "w", encoding="utf8") as f:
f.write(activation.script)
f.write("\n")
f.write(shlex.join([_py_exe, vars_capture_script, vars_file]))
f.write("\n")
patch を当てた YAML を aws deadline update-queue-environment で適用すれば、Windows Worker でも pyrattler 版 Queue Environment が動くようになります。
AE conda recipe を macOS で cross-build するための build.sh
AWS 公式の aftereffects-25.1 recipe には bld.bat と build_win.sh の 2 ファイルしか含まれず、macOS conda-build は build スクリプトを認識せず空 package を生成します。build_win.sh をそのまま build.sh としてコピーすれば、macOS conda-build がこれを検出して win-64 ターゲットで処理してくれます。
# recipe ディレクトリで実行
cp aftereffects-26.0/recipe/build_win.sh aftereffects-26.0/recipe/build.sh
chmod +x aftereffects-26.0/recipe/build.sh
ビルド前に、meta.yaml の version (25.1 → 26.0) と source の sha256 を、Phase 2 でアップロードした zip のものに置換します。deadline-cloud.yaml の sourceArchiveFilename も 26.0 用に置換します。ビルド実行は次の通りです。
mkdir -p archive_files
aws s3 cp s3://<your-bucket>/archive_files/Adobe_AfterEffects_26_0_Windows_installation.zip archive_files/
mkdir -p conda-build-output
CONDA_SUBDIR=win-64 conda-build aftereffects-26.0/recipe --no-test --output-folder ./conda-build-output
aws s3 sync ./conda-build-output/ s3://<your-bucket>/Conda/Default/
S3 channel の構造は s3://<your-bucket>/Conda/Default/win-64/aftereffects-26.0-0.conda となり、同階層に conda-build が生成する repodata.json も配置されます。Render Queue の Queue Environment で CondaChannels パラメータをこの S3 URL に設定すれば、Worker がジョブ実行時に conda package を解決できます。
Render Worker の事前 install 一括 PowerShell スクリプト
Render Worker EC2 起動後、Administrator として RDP 接続して次の PowerShell を実行すれば、Python 3.11、Worker Agent、py-rattler 0.18.x、Git for Windows、ae_render_only_node.txt をまとめて install できます。Worker Agent のサービス登録だけは Farm ID と Fleet ID をパラメータに必要とするため、個別実行する想定です。
# 1. Python 3.11 silent install
$pyUrl = "https://www.python.org/ftp/python/3.11.9/python-3.11.9-amd64.exe"
$pyInstaller = "$env:TEMP\python-3.11.9-amd64.exe"
Invoke-WebRequest -Uri $pyUrl -OutFile $pyInstaller
Start-Process -FilePath $pyInstaller -ArgumentList "/quiet","InstallAllUsers=1","PrependPath=1","Include_pip=1","Include_launcher=1" -Wait
$env:Path = [System.Environment]::GetEnvironmentVariable("Path", "Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path", "User")
# 2. boto3 region 設定
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.aws" | Out-Null
@"
[default]
region = ap-northeast-1
output = json
"@ | Out-File -Encoding ASCII "$env:USERPROFILE\.aws\config"
# 3. Worker Agent + py-rattler install
python -m pip install --upgrade pip
python -m pip install deadline-cloud-worker-agent "py-rattler>=0.18,<0.19" "pyyaml>=6,<7"
# 4. Git for Windows silent install + Machine PATH 追加
$gitUrl = "https://github.com/git-for-windows/git/releases/download/v2.45.2.windows.1/Git-2.45.2-64-bit.exe"
$gitInstaller = "$env:TEMP\GitInstaller.exe"
Invoke-WebRequest -Uri $gitUrl -OutFile $gitInstaller
Start-Process -FilePath $gitInstaller -ArgumentList "/VERYSILENT","/NORESTART","/SUPPRESSMSGBOXES" -Wait
$existingPath = [System.Environment]::GetEnvironmentVariable("Path", "Machine")
[System.Environment]::SetEnvironmentVariable("Path", "C:\Program Files\Git\bin;C:\Program Files\Git\usr\bin;$existingPath", "Machine")
# 5. Adobe non-royalty bearing モード有効化マーカー配置
New-Item -Path "C:\Users\Administrator\Documents\ae_render_only_node.txt" -ItemType File -Force
py-rattler は厳密にバージョンピンする必要があります。0.19 系では solve() の API が変わり channels キーワード引数を受け付けなくなったため、Queue Environment 内の Python スクリプトが TypeError で失敗します。
Git for Windows のサイレントインストールは Machine PATH への自動追加を行わないため、install 後に PowerShell で手動で C:\Program Files\Git\bin と C:\Program Files\Git\usr\bin を追加しています。





