Overview

I think skip_create_ami no image runs can avoid the source instance AMI preparation steps.

The order I observed was:

1. Source instance stop starts.
2. Packer waits for the instance to stop.
3. The create image step later handles skip_create_ami.

For workflows that use Packer as remote execution and collect outputs before cleanup, stopping the source instance for AMI preparation adds time without producing an image.

Reproduction shape

1. Run an Amazon EBS build with skip_create_ami = true.
2. Copy outputs during the build.
3. Run with PACKER_LOG=1.

Observed order:

==> example.amazon-ebs.test: Stopping the source instance...
==> example.amazon-ebs.test: Waiting for the instance to stop...
==> example.amazon-ebs.test: Skipping AMI creation...

Measurements

The source instance stop wait in a c5.metal run took about 19m16s.

A local patch that passes skip_create_ami into the stop and modify steps skipped that stop wait. A separate cleanup wait remained, which I think should be treated as a separate concern.

Expected behavior

My theory is that skip_create_ami = true can skip AMI preparation steps because no image will be created.

Versions

Packer 1.15.1 for local plugin validation.
Amazon plugin 1.8.1 for the released plugin comparison.
Local plugin build from current main for the proposed patch.