Skip to content
Trust Center
Back to cloudfix.com
Menu

Security

How CloudFix protects your AWS environment and data.

Scoped IAM roles you deploy and can read first, read-oriented discovery, and fixes that run in your own account only after you approve them. This page sets out every role and permission boundary.

Request the permission supersetSee the diagrams

Finder-fixer lifecycle

Four steps. You control the data and every change.

  1. Connect via CloudFormation StackSet

    You connect your AWS account through a CloudFormation StackSet provided by CloudFix. It creates carefully scoped IAM roles with only the permissions needed for analysis and for the fixes you approve.

  2. Collect metadata

    The finder role reads Cost and Usage Reports, CloudWatch metrics and resource metadata, overwhelmingly with Describe, List and Get actions. The few narrower permissions are set out in full below.

  3. Recommend

    110+ automated finders analyze the metadata. Each recommendation appears in your dashboard with estimated savings, effort and risk.

  4. Run after approval

    When you approve a fix, CloudFix starts it as an AWS Systems Manager Automation runbook in your account, under cloudfix-ssm-update-role. Every execution is logged.

No change to core resources (EC2, EBS volumes, S3, RDS and the rest) is made unless you approve it. The approved fix runs as an AWS Systems Manager Automation runbook inside your account, under a role created by your own CloudFormation stack, and every execution is recorded in Systems Manager and in your CloudTrail.

IAM role architecture

Minimally scoped roles, each limited to one job.

CloudFix creates a small set of IAM roles in your account. Each follows least privilege and is limited to specific service areas. Every role CloudFix can assume is gated on an sts:ExternalId unique to your tenant.

Core functionality

cloudfix-athena-query-execution-role

Queries AWS Cost and Usage Reports through Amazon Athena. Manages AWS Organizations data and CloudFormation stack operations. It processes billing data, not infrastructure data.

Fixes, after approval

cloudfix-ssm-update-role

The role approved fixes run under. CloudFix shares its Automation runbooks with your account and, once you approve a recommendation, starts the runbook with ssm:StartAutomationExecution under this role. The CloudFix platform can assume it only with your tenant's external ID. Each execution is logged in the Systems Manager execution history, and every API call it makes appears in your CloudTrail.

Finder role

cloudfix-finder-role discovers optimization opportunities across your AWS services.

The vast majority of its permissions are Describe, List and Get: passive read operations that change nothing. It also holds a small set of non-read permissions required for normal operation. Most are resource tagging (ec2:CreateTags, ec2:DeleteTags, tag:TagResources and the per-service equivalents) and query execution (athena:StartQueryExecution, logs:StartQuery).

A few individual finders additionally require an action that is neither a read nor a tag, and each is present only when that finder is entitled for your subscription: s3:GetObject and s3:PutObject (RDS reserved-instance scan), ssm:SendCommand (CloudWatch agent configuration check and SQL Server migration assessment), lambda:InvokeFunction and networkmanager:StartRouteAnalysis (VPC endpoint consolidation), bedrock:InvokeModel (S3 bucket partitioning) and ce:StartCommitmentPurchaseAnalysis (savings-plan analysis).

These are granted at Resource: '*' like the rest of the finder policy, so s3:PutObject and ssm:SendCommand in particular are genuinely write-capable. If that is outside your change policy, disabling the corresponding finders removes the actions from your rendered template entirely.

The finder role does not write to CloudWatch Logs and does not publish SNS notifications: its CloudWatch Logs and SNS permissions are reads only (logs:StartQuery, logs:GetQueryResults, logs:DescribeLogGroups, sns:ListTopics, sns:GetTopicAttributes). SNS topic creation and subscription confirmation (sns:CreateTopic, sns:ConfirmSubscription) belong to cloudfix-ssm-update-role.

CloudFix applies only tag keys prefixed cloudfix: or CloudFix:, and IAM enforces it: the tagging policy carries a ForAllValues:StringLike condition on aws:TagKeys scoped to cloudfix:* and CloudFix:*, so the role cannot create or delete a tag under any other key.

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 holds no delete action and no destructive compute, storage or database modify action. 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 finders need targeted reads beyond configuration metadata to do their job, for example returning CloudWatch Logs Insights result rows for Lambda right-sizing. Each is granted only when that finder is enabled. The action list is generated per tenant from the finders your subscription entitles, so a deployment with fewer 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, 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.

Services the finders cover

  • EC2
  • S3
  • RDS
  • CloudWatch
  • CloudTrail
  • DynamoDB
  • Lambda
  • ECS
  • EKS
  • ElastiCache
  • Aurora
  • Redshift
  • OpenSearch
  • EBS
  • EFS
  • Kinesis
  • SageMaker
  • Bedrock
  • CloudFront
  • VPC
  • ELB
  • EMR
  • Neptune
  • MemoryDB
  • MSK
  • MQ
  • DMS
  • Kendra
  • QuickSight
  • Transfer Family
  • AWS Backup

Helper and cleanup roles

Auxiliary roles support housekeeping such as resource cleanup after completed operations, and AWS Backup jobs used by specific fixers. They follow the same least-privilege rules, with account-level and resource-level scoping where possible, and the AWS service roles among them (for example cloudfix-backup-job-role, assumed by AWS Backup) cannot be assumed by CloudFix. The published resource-account template lists every role and its trust policy.

CloudFormation templates

Read the exact templates before you deploy.

All CloudFix infrastructure is deployed with CloudFormation. The CUR templates are the static ones used at onboarding and are also served from cloudfix-templates.s3.amazonaws.com.

TemplatePurposeFile
Onboarding stackMain organization stack: deploys all resources and roles CloudFix requires.cloudfix-onboarding.yaml
CUR stackSets up the Cost and Usage Report, Glue crawler and Athena workspace.cloudfix-cur.yaml
CUR roleIAM role for CUR access and Athena query execution.cloudfix-cur-role.yaml
Resource account rolesFinder and fixer IAM roles deployed to resource accounts via StackSets.cloudfix-resource-account-roles.yaml

The resource account roles template 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 contains a subset of these actions, and CloudFormation shows you the exact template before you accept it. Contact us if your review needs the rendered template for your own tenant.

Infrastructure security

AWS-native, one region, fully auditable.

  • CloudFix runs on AWS (us-east-1) with VPC isolation and security groups
  • No public endpoints for data processing
  • Onboarding by CloudFormation StackSet: auditable infrastructure as code
  • Every fix runs as an AWS Systems Manager Automation runbook, after your approval
  • All data encrypted in transit (TLS 1.2+) and at rest (AES-256)
  • Dashboard delivered by Amazon CloudFront; no third-party CDN

AWS-native footprint

CloudFix deploys no agents and no third-party code into your AWS account. The only AWS services it uses there are:

  • AWS CUR
  • CloudWatch
  • S3
  • Athena
  • Glue
  • Lambda
  • SSM
  • CloudFormation
  • SNS

CloudTrail auditability

Every API call CloudFix makes into your account is logged in AWS CloudTrail and attributed to the CloudFix IAM role, and where relevant to the originating user. That gives you a complete audit trail of CloudFix activity that does not rely on CloudFix's own logs.

Controls

Application, access and encryption.

  • Application security

    • SOC 2 Type 2 audited
    • Regular security assessments and penetration testing
    • HTTPS enforced on all endpoints
    • Session management with secure cookies
    • Role-based access control for multi-account setups
    • SSO/SAML available on Scale+ plans

  • Access control

    • Least privilege: every IAM role is scoped to the actions it needs
    • Per-account isolation keeps customer data separate
    • Every fix operation is logged and auditable
    • No credential storage: CloudFix uses IAM role assumption

  • Encryption

    • In transit: TLS 1.2 minimum on all endpoints; HTTP is redirected to HTTPS
    • At rest: AES-256 on all AWS storage services (S3, RDS, EBS)
    • API calls use scoped, rotatable tokens over TLS
    • No long-lived credentials: STS AssumeRole only

Network connectivity

Standard HTTPS. No links, VPNs or tunnels.

CloudFix needs no dedicated network links, VPNs or firewall tunnels, and makes no inbound connection into your VPCs or private subnets.

  • From your account

    • CloudFix roles in your account are used over HTTPS (port 443): standard AWS STS and SSM Automation traffic
    • No inbound connections into your VPC or private subnets
    • StackSets are deployed from AWS-managed infrastructure

  • Webhooks (optional)

    For ITSM and service desk integrations, CloudFix sends HTTPS POST requests to the endpoint you specify. They originate from CloudFix infrastructure in AWS us-east-1 and carry JSON recommendation metadata only (resource IDs, savings amounts, status), never customer AWS data.

    Using webhooks in CloudFix

  • IP allow-listing

    No IP needs allow-listing for access to your AWS accounts: IAM role trust relationships govern that. If your ITSM platform allow-lists inbound webhooks, contact CloudFix support for the current egress IP range.

API documentation

A REST API for recommendations, approvals and reporting.

The API is the integration surface for ITSM and service desk platforms. The architecture page shows how an ITSM approval flows back to CloudFix.

API authentication. The CloudFix API uses bearer tokens generated in the CloudFix dashboard and scoped to your account. All API traffic is HTTPS (TLS 1.2+). There is no OAuth or service-account model; API keys are the current mechanism.

User authentication. CloudFix user accounts are managed in AWS Cognito user pools, which handle sign-in, session tokens and password policy. Integrations acting through the API use API keys rather than Cognito directly. SSO/SAML is available on Scale+ plans and federates with your identity provider.

Incident response

Incident response and vulnerability management.

The full support model, severity levels and escalation path are on the support and SLA page.

  • Documented incident response plan aligned with SOC 2 requirements
  • Customer notification within 24 hours of a confirmed security incident
  • Post-incident review and remediation, with root cause documented
  • Regular security assessments and third-party penetration testing (results under NDA)
  • Vulnerability reports through the contact form, acknowledged within 1 business day

Have security questions?

Ask the security team, or request the SOC 2 Type 2 report, the permission superset or your tenant's rendered template.

Request documentationContact the security team