Pair Run Command error limits with concurrency before a fleet rollout

Stopping further dispatch does not stop commands already executing on managed nodes.

Source facts

Systems Manager Run Command accepts max-concurrency and max-errors as separate controls. The error limit stops dispatch to additional managed nodes after the allowed error count is exceeded. Commands already running are allowed to complete and may also fail. AWS advises concurrency of one when strict sequential failure control is required. The documented default for max-errors is zero, which stops additional dispatch after the first returned error.

Source: AWS — Run commands at scale.

Applicability

This describes Run Command fleet dispatch behavior. It is not an application rollback mechanism and does not describe Patch now concurrency defaults or every Automation control.

DSE recommendation

DSE recommends treating both settings as part of the approved change. Start with a small, explicitly named target set and a harmless command, then decide how many simultaneous failures the service can tolerate. Write down the cancellation and recovery plan for nodes already running. Keep dynamic tag targeting under review so a larger target population cannot silently alter the intended rollout boundary. Separate the dispatch decision from the node-level recovery decision in the rollout record. Ask the change owner to identify the maximum acceptable in-flight population and explain how an operator will find those nodes if further dispatch stops during the pilot.

Verification

Proposed verification: retain the target list, command ID, chosen limits and per-node results from a controlled pilot. Induce a harmless failure on an approved test node and compare subsequent dispatch with in-flight completions. Verify the rollback procedure separately before using the same pattern for a disruptive command.

Official reference

AWS — Run commands at scale. Reviewed October 20, 2026.