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 simultaneously
• MaxErrors: "10%" means stop if more than 10% of targets fail — prevents fleet-wide breakage

Change management workflow:

1. Create change request (SSM Change Manager or ServiceNow integration)
2. Approval workflow (manual or automated based on change type)
3. Execute during maintenance window
4. Validate via Config rules
5. 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.