3.3.2.3. Applying Configuration Changes to Systems
3.3.2.3. Applying Configuration Changes to Systems
When an incident requires configuration changes across your fleet — rotating a compromised credential, patching a vulnerability, updating a config file — you need reliable, auditable mechanisms.
SSM Run Command for immediate changes:
# Rotate API key across all application servers
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets "Key=tag:Service,Values=OrderAPI" \
--parameters 'commands=[
"aws secretsmanager get-secret-value --secret-id prod/api-key --query SecretString --output text > /etc/app/api-key",
"systemctl restart order-api"
]' \
--max-concurrency "25%" \
--max-errors "10%"
SSM Automation for multi-step changes:
- Stop the service → update config → validate → restart → verify health
- Built-in approval steps for production changes
- Automatic rollback if validation fails
Rate controls for safe fleet changes:
MaxConcurrency: "25%" means only 25% of targets are updated simultaneouslyMaxErrors: "10%" means stop if more than 10% of targets fail — prevents fleet-wide breakage
Patch compliance after an install run: patches that need a restart but were installed with RebootOption: NoReboot are reported as InstalledPendingReboot, and the instance shows NON_COMPLIANT until it reboots.
Change management workflow:
- Create change request (an ITSM tool such as ServiceNow or Jira Service Management; SSM Change Manager closed to new customers on November 7, 2025, and AWS recommends AWS Partner change-management solutions)
- Approval workflow (manual or automated based on change type)
- Execute during maintenance window
- Validate via Config rules
- Audit trail in CloudTrail
Exam Trap: SSM Run Command MaxErrors is a cumulative threshold — not per-batch. If MaxErrors is "5" and you're updating 100 instances at 25% concurrency, the entire operation stops after 5 total failures across any batch. This is a safety mechanism to prevent cascading a bad change across the fleet.