What this guide is for
This guide explains how CloudFix customers can migrate fixer execution from AWS Change Manager to Direct SSM Automation.
It is intended for:
- CloudFix tenant admins
- AWS platform teams
- Security or cloud operations teams reviewing the change
Why CloudFix is making this change
AWS deprecated Change Manager on November 26, 2025. CloudFix is therefore moving fixer execution to Direct SSM Automation.
This does not change what CloudFix fixes. It changes how CloudFix launches and tracks those automations.
What changes for customers
Previous method: Change Manager
- CloudFix used AWS Change Manager workflows to execute fixers
- Executions were tracked as Change Manager OpsItems
- Identifiers typically looked like
oi-xxxxxxxxxxxx - This path depended on Change Manager-specific AWS services and workflows
New method: Direct SSM Automation
- CloudFix uses AWS Systems Manager Automation directly
- CloudFix shares the required automation documents and starts execution through SSM APIs
- Executions are tracked as SSM automation executions
- Identifiers are UUID-style values such as
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Benefits of Direct SSM Automation
- Future-proofs execution against Change Manager deprecation
- Reduces AWS workflow overhead
- Simplifies execution architecture
- Keeps rollback and remediation logic in the automation document itself
- Improves operational consistency for newly onboarded tenants
What does not change
- The customer’s AWS resources stay in the customer account
- Fixer intent and rollback behavior remain the same
- Existing in-flight Change Manager executions can continue to completion
- CloudFix can still control migration on a per-tenant basis
Migration overview
CloudFix can migrate a tenant by switching the tenant to the Direct SSM execution path and validating that the required runbooks are available.
Recommended migration sequence:
- Validate the tenant is currently using Change Manager
- Verify required CloudFix IAM roles exist in customer accounts
- Verify Direct SSM runbooks are fully deployed for the tenant
- Enable Direct SSM for the tenant
- Test one low-risk fixer
- Monitor closely for the first 24-48 hours
Customer prerequisites
Before migration, customers should confirm:
- Their CloudFix onboarding stack is current
- Their CloudFix IAM roles are deployed successfully
- Their security team permits SSM Automation execution through CloudFix roles
- Their team understands that new executions will use SSM Automation rather than Change Manager
Customer FAQ
Is CloudFix changing what it can fix?
No. This migration changes the execution mechanism, not the functional scope of CloudFix recommendations and fixers.
Do we need to reinstall CloudFix?
Usually no. In most cases this is a configuration and validation exercise rather than a full reinstallation.
Will our existing scheduled or in-progress executions be interrupted?
No. Existing Change Manager executions can continue. The migration affects new executions after cutover.
Can we roll back if needed?
Yes. CloudFix can revert the tenant back to Change Manager for new executions if a migration issue is detected.
Is Direct SSM faster?
Usually yes at initiation time, because it removes Change Manager overhead. Actual remediation time depends on the AWS operation being performed.
How is audit history handled?
Change Manager uses OpsItems and Change Manager history. Direct SSM uses SSM Automation execution history plus CloudFix execution records.
Bill Gleeson
Comments