If You Use Components That Include Windows Update in EC2 Image Builder, Consider Extending the Timeout

Hello! This is Yoshida from the Cloud Business Division.

I recently had the opportunity to introduce EC2 Image Builder in a customer's environment.

Using Image Builder, I had been creating a custom Windows Server AMI with Japanese localization and the AWS CLI pre-installed.
I plan to write about the details of this Image Builder implementation in a separate article.

This time, the pipeline that had been running on a monthly schedule suddenly started failing.
This article summarizes everything from identifying the cause to the fix.

What Happened

The pipeline, which had been working normally until March 2026, suddenly started failing from April onward.
The error occurred at the ApplyBuildComponents step, and the following messages were recorded in CloudWatch Logs.

Command failed (command id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, state: Failed)
Action failed for step ApplyBuildComponents. Failing step

The environment is as follows.

The Japanese localization component was created with reference to the following article.

https://dev.classmethod.jp/articles/about-ec2-image-builder-windows-server-japanese-component-v2/

Identifying the Cause

After analyzing CloudWatch Logs in detail, the cause turned out to be that the Windows Update processing time exceeded the workflow step timeout.

The Flow Seen in the Logs

In the UpdateOS action (Windows Update) within the Japanese localization component, downloading and installing the May 2026 security update (KB5087539) took a long time.

The following is an excerpt from 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}

After the download completes, the installation begins.

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}

The installation of KB5087539 completed and a reboot was performed.
After the reboot, Windows Update searches for updates again, and the timeout occurs during this search.

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

The elapsed time from the start of the ApplyBuildComponents step to the failure was about 71 minutes.
In Image Builder workflows, a timeout is set for each step, and it is believed that this default value was exceeded.

Why It Succeeded in March but Failed from April Onward

The size of Windows Server cumulative updates increases every month. The longer the time since the OS release, the longer it takes to download and install the cumulative update.

It is presumed that the processing time, which was within the acceptable range as of March, began to exceed the timeout with the cumulative updates from April onward.

Why Is Windows Update Necessary in the First Place?

The reason Windows Update is run in the Japanese localization component is that it is recommended officially by Microsoft.

If Windows Update is not run, the following problems may occur.

• Printing failures
• Search functionality not working
• Remote Desktop connection failures

Therefore, it is recommended to run Windows Update after installing the language pack.

For details, please refer to the support blog below.

https://jpwinsup.github.io/blog/2022/06/22/UserInterfaceAndApps/LanguageSupport_IME/lp-consideration/

Solution

Create a custom workflow and extend the timeoutSeconds of the ApplyBuildComponents step.

Creating a Custom Workflow

Based on the Amazon-managed build-image workflow, change only the timeout setting.

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"

The only change is a single line: adding timeoutSeconds: 10800 to the ApplyBuildComponents step.
This extends the component execution timeout to 3 hours.

Guidelines for Timeout Values

Since the size of cumulative updates varies from month to month, it is desirable to set a generous margin.

Applying to the Pipeline

In the "Image creation process" settings of the image pipeline, select the custom workflow type and specify the custom workflow you created as the build workflow.

Alternative Solution

There is also the option of not running Windows Update.

If you select the base AMI with the "Use latest OS version" setting, the base AMI updated by AWS already has a certain level of patches applied.

However, the issues mentioned earlier (printing failures, search functionality not working, Remote Desktop connection failures) may occur.

If you choose this approach, you need to verify its behavior in the actual environment.

Conclusion

When running Windows Update in an EC2 Image Builder component, timeouts may occur due to the increasing size of cumulative updates.
You can solve this problem by creating a custom workflow and extending timeoutSeconds.
Since it only requires adding one line to the Amazon-managed workflow, the fix is easy.

I hope this helps someone.

That was Yoshida from the Cloud Business Division!

References

• I Tried Creating a Component to Japanize Windows Server OS with EC2 Image Builder – Ver.2 | DevelopersIO
• Considerations When Installing Language Packs | Microsoft Japan Windows Technology Support Blog
• Create a YAML workflow document - EC2 Image Builder