Security
How CloudFix protects your AWS environment and data.
Finder-Fixer Lifecycle
CloudFix uses a secure four-step lifecycle to analyze and optimize your AWS infrastructure. At every stage, you maintain full control over your data and changes.
Connect via CloudFormation StackSet
You connect your AWS account to CloudFix through a CloudFormation StackSet provided by CloudFix. This creates carefully scoped IAM roles with only the permissions needed for analysis and approved optimizations.
Metadata Collection
The Finder role collects resource metadata using standard AWS tools — AWS Cost and Usage Reports (CUR), CloudWatch metrics, and resource metadata. Discovery is performed overwhelmingly with Describe, List, and Get actions. A small number of finders require narrower, targeted permissions beyond that — including limited writes such as resource tagging and Athena/CloudWatch Logs operations — and each is granted only when the corresponding finder is enabled for your subscription. The permission model is set out in full in the IAM section below.
Optimization Recommendations
75+ automated finders analyze the collected metadata to identify cost savings opportunities. Recommendations appear in your CloudFix dashboard with estimated savings, effort, and risk for each finding.
Approved Execution via AWS Systems Manager
When you approve a fix, CloudFix executes it through AWS Systems Manager (Change Manager and Automation runbooks). You must explicitly approve the change template before any changes are made. Changes are executed by a role on your account that CloudFix creates but cannot itself assume or access.
cloudfix-ssm-assumed-role) is created by CloudFix but cannot be assumed or accessed by CloudFix directly — it is invoked only by AWS Systems Manager within your account, and in the default deployment the approver role trusts your account alone.
IAM Role Architecture
CloudFix creates a set of minimally-scoped IAM roles in your AWS account. Each role follows the principle of least privilege and is limited to specific service areas.
Core Functionality Roles
cloudfix-athena-query-execution-role — Queries AWS Cost and Usage Reports via Amazon Athena. Manages AWS Organizations data and CloudFormation stack operations. This role processes billing data, not infrastructure data.
Finder Role
cloudfix-finder-role — Discovers optimization opportunities across your AWS services. The vast majority of permissions are Describe, List, and Get — passive read operations that make no changes to your resources. The role also holds a small set of non-destructive write permissions required for normal operation: resource tagging (ec2:CreateTags, ec2:DeleteTags, tag:TagResource), writing to CloudWatch Logs, querying Athena, and publishing SNS notifications. CloudFix applies only tag keys prefixed cloudfix:; note that this is a product behaviour, not an IAM condition — the tagging permissions in the published template are not key-scoped, and you may add an aws:TagKeys condition to the template before deployment if your change policy requires it. The finder role holds no broad data-plane access. It cannot read secrets, Parameter Store values, log events, DynamoDB items, Kinesis records, queue messages, or EBS snapshot block contents, and it cannot modify or delete your resources — secretsmanager:GetSecretValue, ssm:GetParameter, logs:GetLogEvents, dynamodb:GetItem/Scan/Query, kinesis:GetRecords, sqs:ReceiveMessage, rds-data:ExecuteStatement, ebs:GetSnapshotBlock and kms:Decrypt are all absent. A small number of individual finders do require targeted reads that go beyond configuration metadata in order to do their job — for example returning CloudWatch Logs Insights result rows for Lambda right-sizing. Each such permission is granted only when the corresponding finder is enabled for your subscription. The exact action list is generated per tenant from the finders your subscription entitles, so a deployment with fewer entitled finders receives a strictly shorter policy, and tagging permissions are omitted entirely if tagging is not enabled.
For security reviews: we maintain a complete action-level superset — the union across all registered finders, i.e. the maximum any tenant could receive — with every data-plane permission identified and its purpose explained. Request it here and we will send it to your review team.
Fixer Roles (Require Approval)
Three roles participate in remediation, and the distinction between them is the control boundary:
cloudfix-ssm-assumed-role— the role that actually performs the change. Its trust policy admits onlyssm.amazonaws.com,lambda.amazonaws.com, and your own account root. CloudFix cannot assume it. It is invoked by AWS Systems Manager inside your account, after approval.cloudfix-fixer-approver-role— lists and approves SSM change templates. In the default deployment its trust policy admits your account root only, so approval authority rests entirely with you and CloudFix has no path to approve its own changes. If you opt into centralized approval at onboarding, the role additionally trusts two CloudFix roles under ansts:ExternalIdcondition, allowing CloudFix to approve on your behalf. This is a deployment-time choice you make and it is visible in the template you deploy — organisations that require approval to remain in-house should deploy with centralized approval disabled.cloudfix-ssm-update-role— this role is assumable by the CloudFix platform. Every CloudFix-assumable role is gated on ansts:ExternalIdcondition unique to your tenant. It authors SSM documents and raises change requests (ssm:CreateDocument,ssm:UpdateDocument,ssm:StartChangeRequestExecution,ssm:StartAutomationExecution) and can passcloudfix-ssm-assumed-roleto Systems Manager. It cannot itself modify your resources beyond tagging.
So the guarantee is precise: CloudFix can propose a change and hand it to Systems Manager, but the change executes only once a change template has been approved by a principal in your account. The approval gate — not an inability to invoke — is the boundary, and it is enforced by AWS Systems Manager Change Manager rather than by CloudFix. Every step is recorded in your CloudTrail, independently of CloudFix logs.
The exact trust policies and action lists for all three roles are in cloudfix-resource-account-roles.yaml, linked below.
Helper & Cleanup Roles
Auxiliary roles support housekeeping functions like resource cleanup after completed operations. These roles also follow least-privilege principles with account-level and resource-level permissions where possible.
CloudFormation Templates
All CloudFix infrastructure is deployed via CloudFormation. You can review the exact templates before deployment:
| Template | Purpose | Link |
|---|---|---|
| Onboarding Stack | Main org stack — deploys all resources and roles required by CloudFix | cloudfix-onboarding.yaml |
| CUR Stack | Sets up Cost and Usage Report, Glue Crawler, Athena workspace | cloudfix-cur.yaml |
| CUR Role | IAM role for CUR and Athena query execution | cloudfix-cur-role.yaml |
| Resource Account Roles | Finder and fixer IAM roles deployed to resource accounts via StackSets | cloudfix-resource-account-roles.yaml |
The CUR templates above are the static templates used during onboarding and are also served from cloudfix-templates.s3.amazonaws.com. The Resource Account Roles template is different: it is generated per tenant at onboarding from the finders and fixers your subscription entitles, so the copy published here is a representative maximum. Your deployed policy will contain a subset of these actions, and CloudFormation shows you the exact template before you accept it. Contact us if your security review needs the rendered template for your own tenant.
Infrastructure Security
- CloudFix runs on AWS infrastructure (us-east-1) with VPC isolation and security groups
- No public endpoints for data processing
- Customer onboarding via CloudFormation StackSet — fully auditable IaC
- All fixes implemented via AWS Systems Manager (Change Manager / Automation) with explicit customer approval
- All data encrypted in transit (TLS 1.2+) and at rest (AES-256)
- Dashboard delivered via Amazon CloudFront (AWS CDN) — no third-party CDN providers
AWS-Native Footprint
CloudFix deploys no user agents or third-party code into your AWS account. The only AWS services used within your account are:
CloudTrail Auditability
Every API call made by CloudFix into your AWS account is logged in AWS CloudTrail and annotated with the CloudFix IAM role, identifying it as CloudFix-originated access. Where relevant, logs also identify the originating user. This gives you a complete, independent audit trail of all CloudFix activity — without relying on CloudFix's own logs.
Application Security
- SOC 2 Type 2 certified
- Regular security assessments and penetration testing
- HTTPS enforced on all endpoints
- Session management with secure cookies
- Role-based access control (RBAC) for multi-account setups
- SSO/SAML available on Scale+ plans
Access Control
- Principle of least privilege — every IAM role is scoped to only the actions it needs
- Customer data isolation — per-account isolation ensures data separation
- Audit logging — all fix operations are logged and auditable
- No credential storage — CloudFix uses AWS IAM role assumption, not stored credentials
Encryption Standards
- Data in transit: TLS 1.2 minimum enforced on all endpoints. HTTPS enforced; HTTP connections are redirected.
- Data at rest: AES-256 encryption on all AWS storage services (S3, RDS, EBS).
- API authentication: All API calls use token-based authentication transmitted over TLS. Tokens are scoped and rotatable.
- No credentials stored: CloudFix uses AWS IAM role assumption (STS AssumeRole) — no long-lived credentials are stored.
Network Connectivity Requirements
CloudFix operates entirely over standard HTTPS. There are no requirements for dedicated network links, VPNs, or firewall tunnels.
Outbound from Customer Account
- CloudFix IAM roles in your AWS account call back to CloudFix over HTTPS (port 443) — standard AWS STS and SSM Automation traffic.
- No inbound connections are made into your VPC or private subnets.
- CloudFormation StackSets are deployed from AWS-managed infrastructure.
Webhooks (Optional — for ITSM and other integrations)
CloudFix supports outbound webhooks for integrating with external platforms such as service desk and ITSM tools. When configured, CloudFix sends HTTPS POST requests to the webhook endpoint you specify.
- Webhooks originate from CloudFix infrastructure hosted in AWS
us-east-1. - If your ITSM platform requires IP allow-listing, contact CloudFix support to obtain the current egress IP range.
- Webhook payloads are JSON over HTTPS. No customer AWS data payload beyond recommendation metadata (resource IDs, savings amounts, status).
IP Allow-listing
CloudFix does not require customers to whitelist specific IPs for inbound access to their AWS accounts — IAM role trust relationships govern access. For outbound webhook allow-listing requirements, contact the CloudFix support team.
Architecture Diagrams
Visual data flow diagrams covering the core CloudFix architecture and ITSM / service desk integration.
View Architecture Diagrams →API Documentation
CloudFix provides a REST API for programmatic access to recommendations, approval workflows, and reporting. This is the primary integration surface for ITSM and service desk platforms.
Endpoint Summary
Full list of available endpoints, parameters, and response schemas.
View Endpoints →Workflows & Examples
Example flows for listing, approving, and tracking recommendations via API.
View Examples →Incident Response & Vulnerability Management
- Documented incident response plan aligned with SOC 2 requirements
- Customer notification within 24 hours for confirmed security incidents
- Post-incident review and remediation process with root cause documentation
- Regular security assessments and third-party penetration testing (results available under NDA)
- Vulnerability disclosure: report security issues via the contact form — acknowledged within 1 business day