aws-runpacker document fails The limit in the output payload of aws:executeScript is 100 KB.

The error you're encountering with the aws-runpacker document is related to a size limitation in AWS Systems Manager. The error message "The limit in the output payload of aws:executeScript is 100 KB" indicates that the script is generating output that exceeds the maximum allowed size.

This is a hard limit in the aws:executeScript action within Systems Manager documents. When your Packer build process generates logs or output that exceeds 100 KB, the execution fails with this error.

To resolve this issue, you have a few options:

1. Reduce the verbosity of your Packer build process to generate less output. You can modify your Packer template to minimize unnecessary logging.

2. Redirect the output to a file instead of returning it directly from the script. You could modify the document to write logs to a file in Amazon S3 or CloudWatch Logs instead of capturing them in the script's output.

3. Split your Packer build process into smaller steps that generate less output individually.

4. If you're customizing the document, ensure you're handling the output properly and not trying to return large amounts of data from the script execution.

This limitation is similar to other AWS service quotas, such as the 256 KB limit for SQS messages or the 63 KB limit some users experience with MQTT messages in IoT. These are hard limits designed to ensure service stability and performance.

If you continue to face issues after implementing these suggestions, you might need to consider a different approach to your Packer deployment workflow that works within these AWS service constraints.
Sources
SendMessageBatch API response when size of individual or combination of 10 logs exceeds 256KiB | AWS re:Post
Can´t use a MQTT message payload greater than 63KB with AWS IoT Device SDK for Python | AWS re:Post

You’re running into a known constraint in AWS Systems Manager when using the aws-runpacker document. The aws:executeScript action has a strict 100 KB limit on its output payload. This is not adjustable, and it’s often triggered when the underlying process (in this case, the Packer build step) produces verbose logs or large serialized data that Systems Manager tries to capture and return.

Here’s how you can handle it effectively:

1. Redirect Logs to CloudWatch or S3 Instead of Output Payload This is the most reliable fix. Rather than letting the aws:executeScript return large JSON or console output, modify or extend the document to write build logs to Amazon CloudWatch Logs or Amazon S3, and only return a lightweight success or failure message.

Example concept:

packer build ... | tee /tmp/packer.log aws s3 cp /tmp/packer.log s3://your-bucket/build-logs/ echo "Build complete"

This keeps your script output well under the limit while retaining full visibility into your build.

2. Adjust Packer’s Logging Verbosity Reduce output noise by using the PACKER_LOG=0 environment variable or by selectively disabling debug output in your Packer template. See Packer Logging Documentation for reference : https://developer.hashicorp.com/packer/docs/commands#logging

3. Split the Build Process into Smaller Stages If your Packer workflow performs multiple provisioning or validation tasks, consider breaking it into smaller steps, each run through separate automation documents or Systems Manager runbooks. This keeps individual script outputs below the quota and makes debugging easier.

4. Use a Custom SSM Document Derived from aws-runpacker If you need more flexibility, clone the aws-runpacker document and edit it so that the aws:executeScript step writes to S3 or CloudWatch Logs. You can find the original AWS-provided document in the AWS Systems Manager Document Reference : https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-action-executeScript.html . When you create your version, make sure you:

Use the same IAM role permissions as the original document, including s3:PutObject or logs:PutLogEvents if you add log exports.

Limit the returned output from the aws:executeScript action to simple key/value pairs, such as status or build ID.

5. Confirm You’re Using a Current Amazon Machine Image (AMI) You mentioned AL2023. Ensure your source_ami_filter or builders block in the Packer template references a valid AMI ID and region combination. Sometimes failed image lookups can generate long error chains that exceed the payload limit.

If you want to validate the limitation, check the official Systems Manager quota documentation here: AWS Systems Manager quotas

Summary: This isn’t a Packer or AL2023 issue, but a fixed constraint within Systems Manager’s aws:executeScript. The key is to stop sending verbose logs back in the payload and instead redirect them to an external sink like CloudWatch Logs or S3. That small architectural change usually eliminates the error permanently while improving observability.

I can share a minimal working example of a modified aws-runpacker document that’s production-safe and avoids the 100 KB limit. It’s a good exercise in customizing automation workflows and helps deepen your understanding of how SSM’s output management really works.