Product Updates
Announcing CloudFix Role-Based Access Control
CloudFix announces Role-Based Access Control. Assign granular permissions to control who can view, approve, and implement AWS cost fixes across your team.
Update 2026: CloudFix now runs approved fixes through AWS Systems Manager in your account.
Introduction
We are happy to announce that CloudFix now supports Role-Based Access Control. With this new feature, administrators have much more fine-grained control over permissions and privileges. Additionally, with SSO support and automatic role assignment, it is easier than ever to onboard new users without managing a new permissions mapping. In this blog post, I’ll explain how it works.
Supported User Roles
CloudFix supports 4 different roles: Administrator, Runbook Manager, Executor, and Reader. These roles should be self-explanatory as their names suggest.
Permission | Administrator | Runbook Manager | Resource Manager | Reader |
Full System Access | ✅ | ❌ | ❌ | ❌ |
Execute Finder/Fixers | ✅ | ✅ | ❌ | ❌ |
Submit Finder/Fixers | ✅ | ✅ | ✅ | ❌ |
Read Access | ✅ | ✅ | ✅ | ✅ |
Role Details and Default Roles
Read Access – This default role, Read Access, is for users who simply want to see information produced by the CloudFix UI. This is great for granting access to folks within the organization who may be interested in the information, while controlling access to who can actually make changes. By default, newly created users (or users granted access via SSO) are admitted at a Reader level. Roles can then be updated by the administrator.
Resource Manager – This role, Executor, can execute Finder/Fixers. Executors can select Savings Recommendations, and then click on the Execute button. Note that clicking on the Execute button does not mean that the change happens immediately. It submits the fix to run as an AWS Systems Manager Automation runbook in your account. All changes that CloudFix makes to AWS infrastructure go through Systems Manager, and every execution is logged.
Runbook Manager – The Runbook Manager is able to execute the Systems Manager runbooks. Users with this permission level will be able to make changes to AWS account resources.
Administrator – The administrator is able to do everything that the Executor and the Runbook Manager can do. In addition, the Administrator can change the roles of other users, and also adjust the scope of those roles. To learn more about role scoping, read on.
Permission Scoping
The permissions associated with each user can be seth . This may make sense for smaller organizations, but for larger organizations this may be overly permissive. To deal with this appropriately, each of the roles can be scoped through 4 properties:
Organizational Units (OUs) – AWS Organizations are subdivided into Organizational Units (OUs). OU layout is specific to an organization, but each OU may have one or more member accounts. OUs are typically governed by a single policy, so OU-level cost optimization makes sense.
Accounts – Permissions for an individual CloudFix user can also be scoped to an AWS account.
Regions – Same as above, permissions can also be restricted to a given region.
Tags – Permissions can be restricted to the matching of one or more tags. For example, you could restrict permissions to {“owner” : “user@example.com”, “project” : “code_name”}.
If multiple filters are specified, these filters all apply. For example, you can specify that a user Robert can only work with resources within a certain OU which are tagged with {“owner” : “robert@example.com”}. We do not support logical operators on tags. If you need more sophisticated filtering than what this can provide, let us know. Our CloudFix Professional Services team can create a solution for you.
Automatic Role Assignment
CloudFix also supports Single-Sign On (SSO). SSO offers many benefits vs creating users manually, and is the preferred authentication mechanism. With SSO systems, there are often attributes such as roles attached to the user. The meanings of these roles are internal to the organization. For example, you may have a role such as ‘emea_cloud_admin’. The semantics of this role is defined within the organization and cannot be mechanically mapped to CloudFix permissions. However, using the CloudFix API, it is possible to define a mapping between SSO roles and CloudFix permissions. Consider this example mapping:
sso_role | cloudfix_role | regions | tags |
emea_cloud_admin | Administrator | eu-west-1, eu-central-1, eu-south-1, eu-north-1, me-south-1 | {} |
emea_cloud_reporting | Reader | eu-west-1, eu-central-1, eu-south-1, eu-north-1, me-south-1 | {} |
namer_cloud_admin | Administrator | us-east-1, us-east-2, us-west-1, us-west-2, ca-central-1 | {} |
apac_cloud_admin | Administrator | ap-southeast-1, ap-southeast-2, ap-northeast-1, ap-northeast-2, ap-south-1 | {} |
latam_cloud_admin | Administrator | sa-east-1 | {} |
In this case, there are organization SSO roles which map particular users to administrators of regions within the Cloud. These SSO roles may serve other purposes within the organization, e.g. for IAM user management. With this mapping, the organization SSO roles remain the single source of truth for authorization within the organization, and the CloudFix administrator does not need to manage the role of new users manually.
For help setting up automatic roll assignment, CloudFix professional services can help. Contact your account manager for details.
Ready to start saving on AWS? See how much you could cut from your cloud bill with a free cost optimization assessment, or explore CloudFix automated Finder/Fixers that eliminate waste across 30+ AWS services.
