Overview

You want to know if CloudFix makes changes/updates directly to your AWS accounts.

Information

CloudFix's permission model is read-oriented, not read-only. The finder role that discovers savings opportunities is overwhelmingly made up of passive Describe/List/Get actions, but it also holds a small set of non-destructive write permissions needed for normal operation: resource tagging (ec2:CreateTags, ec2:DeleteTags, tag:TagResource), and, for a small number of finders, Athena queries. None of these let CloudFix modify, delete, or reconfigure the AWS resources you're actually running (EC2 instances, S3 buckets, RDS databases, and so on). CloudWatch Logs writes and SNS notifications are separate: they belong to the execution role used only for a fix run you've already approved (see below), not to the finder role that runs on a routine basis.

Changes to those core resources only happen through a Fixer, and only after you approve the recommendation. Once approved, CloudFix executes the fix through AWS Systems Manager Direct SSM Automation. (CloudFix previously used AWS Change Manager for this; AWS deprecated Change Manager and CloudFix has fully migrated every tenant off it — see the Direct SSM Automation Migration Guide for background.)

The role that performs the actual change (cloudfix-ssm-assumed-role) is created by CloudFix in your account but cannot be assumed or accessed by CloudFix — its trust policy admits only AWS Systems Manager, AWS Lambda, and your own account root, so it can only be invoked by SSM inside your account after approval. A separate role, cloudfix-ssm-update-role, is assumable by the CloudFix platform (gated by a tenant-specific external ID) and is what authors SSM automation documents and starts change executions — but it cannot itself modify your resources beyond tagging. Approval authority rests with a role trusted to your account root by default, so CloudFix has no path to approve its own changes unless you explicitly opt into centralized approval at onboarding.

In short: CloudFix's own roles cannot directly touch your EC2, S3, RDS, or other production resources. Every actual change is executed by a role inside your account that CloudFix cannot assume, invoked only after you approve it, and fully visible in your own CloudTrail. For the complete IAM role breakdown, see the CloudFix Trust Center Security page.

Security & compliance resources

For CloudFix's current certifications, security architecture, data-handling and sub-processor commitments, see the CloudFix Trust Center:

• Security architecture and IAM roles
• Certifications and audit reports (SOC 2)
• Data collection, retention and deletion