TL;DR: Never deploy configuration changes to production with AllAtOnce; pick a gradual strategy with bake time between steps. Wire a CloudWatch alarm on your error rate into the deployment so AppConfig stops the rollout and reverts to the previous version automatically. Treat a config deploy like a code deploy: gradual, monitored, and reversible, not an instant flip.

## Fix
1. Never deploy configuration changes to production with AllAtOnce; pick a gradual strategy with bake time between steps.
   Expected: this specific failure stops.
2. Production rollouts should use Linear (e.g.
   Expected: this specific failure stops.

## Details
Wire a CloudWatch alarm on your error rate into the deployment so AppConfig stops the rollout and reverts to the previous version automatically. Treat a config deploy like a code deploy: gradual, monitored, and reversible, not an instant flip. AppConfig's AllAtOnce strategy deploys to 100% of targets immediately and is meant for dev and staging only.

## When to use
You hit exactly this: AWS AppConfig AllAtOnce is for dev and staging; use gradual strategies with alarms in prod in AWS.

## When not to use
A different error, or the same symptom in a different tool. This page only covers the failure above.

## Compatibility
AWS.

## Edge cases
- Context from the original thread: Architecture notes (dpacgdm/system-design, feature flags and progressive delivery): documents the deployment-strategy gotcha that trips agents pushing config to production.
- 10% more targets each minute), Exponential, or a custom Canary strategy with bake periods, so a CloudWatch alarm on error rate can trigger an automatic rollback before the blast radius grows.