EC2 Image BuilderでWindows Updateを含むコンポーネントを使うならタイムアウト延長を検討しよう
こんにちは！クラウド事業本部の吉田です。
お客様の環境でEC2 Image Builderを導入する機会がありました。
Image Builderにより、日本語化とAWS CLIインストール済みのWindows ServerカスタムAMIを作成しておりました。
このImage Builder導入の詳細は別の記事で執筆予定です。
今回、毎月定期実行していたパイプラインが突然失敗するようになりました。
この記事では、原因の特定から対処法までをまとめます。
発生した事象
2026年3月までは正常に動作していたパイプラインが、4月以降に突然失敗するようになりました。
エラーはApplyBuildComponentsステップで発生しており、CloudWatch Logsには以下のメッセージが記録されていました。
Command failed (command id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, state: Failed)
Action failed for step ApplyBuildComponents. Failing step
環境は以下の通りです。
| 項目 | 値 |
|---|---|
| ベースイメージ | Windows Server 2025 English Full Base x86 |
| コンポーネント | 日本語化コンポーネント（言語パックインストール + Windows Update）、AWS CLIインストールコンポーネント |
日本語化コンポーネントは以下の記事を参考に作成しています。
原因の特定
CloudWatch Logsを詳細に分析したところ、原因はWindows Updateの処理時間がワークフローステップのタイムアウトを超過したことでした。
ログから読み取れた流れ
日本語化コンポーネント内のUpdateOSアクション（Windows Update）で、2026年5月のセキュリティ更新プログラム（KB5087539）のダウンロードとインストールに長時間かかっていました。
以下はCloudWatch Logsから抜粋したログです。
Stdout: Downloading '2026-05 Security Update (KB5087539) (26100.32860)'
Waiting for command to complete (command id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Attempt number: 19.
...
Waiting for command to complete (command id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Attempt number: 58.
Stdout: Download output : {"HResult":0,"ResultCode":2}
ダウンロード完了後、インストールが開始されます。
Stdout: Installing '2026-05 Security Update (KB5087539) (26100.32860)'
Waiting for command to complete (command id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Attempt number: 65.
...
Waiting for command to complete (command id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Attempt number: 114.
Stdout: KB Update installation output : {"HResult":0,"RebootRequired":true,"ResultCode":2}
KB5087539のインストールが完了し、再起動が実行されました。
再起動後、Windows Updateが再度更新プログラムを検索しますが、この検索中にタイムアウトが発生しています。
Executor: System has rebooted successfully
Step ApplyWindowsUpdateStep
UpdateOS: STARTED EXECUTION
Stdout: Starting the Windows Update process.
Stdout: Searching for updates.
Waiting for command to complete (command id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Attempt number: 133.
...
Waiting for command to complete (command id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Attempt number: 140.
Command failed (command id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, state: Failed)
Action failed for step ApplyBuildComponents. Failing step
ApplyBuildComponentsステップの実行開始から失敗までの経過時間は約71分でした。
Image Builderのワークフローでは各ステップにタイムアウトが設定されており、このデフォルト値を超過したと考えられます。
なぜ3月は成功して4月以降は失敗したのか
Windows Serverの累積更新プログラムは毎月サイズが増加します。OSリリースからの経過時間が長くなるほど、累積更新のダウンロードとインストールに時間がかかるようになります。
3月時点では許容範囲内だった処理時間が、4月以降の累積更新ではタイムアウトを超えるようになったと推測されます。
そもそもなぜWindows Updateが必要なのか
日本語化コンポーネントでWindows Updateを実行している理由は、Microsoft公式で推奨されているためです。
Windows Updateを実行しない場合、以下の問題が発生する可能性があります。
- 印刷失敗
- 検索機能の不動作
- リモートデスクトップ接続失敗
そのため、言語パックインストール後にWindows Updateを実行することが推奨されています。
詳細は、下記のサポートブログを参照してください。
解決策
カスタムワークフローを作成し、ApplyBuildComponentsステップのtimeoutSecondsを延長します。
カスタムワークフローの作成
Amazonマネージドのbuild-imageワークフローをベースに、タイムアウト設定のみを変更します。
name: build-image-extended-timeout
description: Build workflow with extended timeout for Windows Update
schemaVersion: 1.0
steps:
- name: LaunchBuildInstance
action: LaunchInstance
onFailure: Abort
inputs:
waitFor: "ssmAgent"
- name: ApplyBuildComponents
action: ExecuteComponents
timeoutSeconds: 10800 # 3時間に延長
onFailure: Abort
if:
booleanEquals: true
value: "$.imagebuilder.hasBuildComponents"
inputs:
instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId"
- name: InventoryCollection
action: CollectImageMetadata
onFailure: Abort
if:
and:
- stringEquals: "AMI"
value: "$.imagebuilder.imageType"
- booleanEquals: true
value: "$.imagebuilder.collectImageMetadata"
inputs:
instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId"
- name: RunSanitizeScript
action: SanitizeInstance
onFailure: Abort
if:
and:
- stringEquals: "AMI"
value: "$.imagebuilder.imageType"
- not:
stringEquals: "Windows"
value: "$.imagebuilder.platform"
inputs:
instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId"
- name: RunSysPrepScript
action: RunSysPrep
onFailure: Abort
if:
and:
- stringEquals: "AMI"
value: "$.imagebuilder.imageType"
- stringEquals: "Windows"
value: "$.imagebuilder.platform"
inputs:
instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId"
- name: CreateOutputAMI
action: CreateImage
onFailure: Abort
if:
stringEquals: "AMI"
value: "$.imagebuilder.imageType"
inputs:
instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId"
- name: TerminateBuildInstance
action: TerminateInstance
onFailure: Continue
inputs:
instanceId.$: "$.stepOutputs.LaunchBuildInstance.instanceId"
outputs:
- name: "ImageId"
value: "$.stepOutputs.CreateOutputAMI.imageId"
変更点はApplyBuildComponentsステップにtimeoutSeconds: 10800を追加した1行のみです。
これにより、コンポーネント実行のタイムアウトが3時間に延長されます。
タイムアウト値の目安
| 設定値 | 時間 | 用途 |
|---|---|---|
| 7200 | 2時間 | 最低限の余裕 |
| 10800 | 3時間 | 推奨 |
| 14400 | 4時間 | 大規模な更新がある場合 |
累積更新のサイズは月ごとに変動するため、余裕を持った設定が望ましいです。
パイプラインへの適用
イメージパイプラインの「イメージ作成プロセス」設定で、カスタムワークフロータイプを選択し、ビルドワークフローに作成したカスタムワークフローを指定します。
別の解決策
Windows Updateを実行しない選択肢もあります。
「最新のOSバージョンを使用」設定でベースAMIを選択していれば、AWS側で更新されたベースAMIにある程度のパッチが適用済みです。
ただし、前述の不具合（印刷失敗、検索機能の不動作、リモートデスクトップ接続失敗）が発生する可能性があります。
この方法を選択する場合は、実環境での動作確認が必要です。
さいごに
EC2 Image Builderのコンポーネント上でWindows Updateを実行する場合、累積更新プログラムのサイズ増加によりタイムアウトが発生する可能性があります。
カスタムワークフローを作成してtimeoutSecondsを延長することで、この問題を解決できます。
Amazonマネージドワークフローをベースに1行追加するだけなので、対応は容易です。
どなたかのお役に立てれば幸いです。
以上、クラウド事業本部の吉田でした！
