Solution architecture and data flow for CloudFix and RightSpend, for enterprise security reviews.
CloudFix — Core Architecture
How CloudFix connects to your AWS environment, what it reads, and how approved fixes are executed — without any third-party ITSM integration.
Figure 1 — CloudFix core architecture. Data flows left (CloudFix platform) ↔ right (customer AWS account). CloudFix reads primarily infrastructure metadata; see the security page for the finder role's full permission model.
CloudFix Platform (AWS us-east-1)
Customer AWS Account
Approval boundary — customer must approve before fixes execute
Role detail behind the approval boundary. Three roles participate in remediation.
cloudfix-ssm-update-role is assumable by the CloudFix platform and is what authors the SSM document and raises the change request — it cannot modify your resources beyond tagging.
cloudfix-fixer-approver-role, which approves change templates, trusts your account root only in the default deployment (opting into centralized approval additionally trusts CloudFix under an sts:ExternalId condition).
cloudfix-ssm-assumed-role, which performs the change, is invoked by AWS Systems Manager and is not assumable by CloudFix.
Full trust policies and action lists are in the IAM Role Architecture section and the published CloudFormation templates.
CloudFix + ITSM Integration
How CloudFix integrates with service desk and ITSM platforms via webhooks and the CloudFix REST API.
Figure 2 — CloudFix + ITSM integration. CloudFix raises a webhook to your service desk when a recommendation is ready. The service desk routes approval through its own workflow, then calls the CloudFix API to signal approval. CloudFix then triggers execution via AWS Systems Manager.
Service desk / ITSM platform
CloudFix Platform (AWS us-east-1)
Customer AWS Account
Approval boundary
No customer AWS data passes through the service desk platform. Webhook payloads contain only CloudFix recommendation metadata: AWS resource IDs, estimated savings amounts, service type, and approval status. No S3 contents, database records, application data, or credentials are ever included.
RightSpend — Core Architecture
How CloudFix RightSpend connects to your AWS Organization, what it reads, and the narrow boundary within which it writes. RightSpend is a separate product from CloudFix, with its own IAM roles, its own platform stack, and no shared permissions.
Figure 3 — RightSpend core architecture. Three separate IAM roles serve three distinct access patterns, and each is deployed only where it is needed. Read access spans the Organization; write access is confined to Reserved Instance APIs in the designated cRI accounts.
RightSpend Platform (CloudFix AWS account)
Customer AWS Organization
Write boundary — Reserved Instance APIs only
What RightSpend never has. RightSpend has no write access to EC2 instances, EBS volumes, S3 buckets, databases, or any other AWS resource — the only objects it can modify are Reserved Instances, and only in the accounts you designate for that purpose. It reads resource metadata and Cost Explorer aggregates; it does not read the contents of any customer workload or data store. Full action lists per role and the published CloudFormation templates are on the RightSpend page.
RightSpend — Hourly Optimisation Loop
RightSpend runs a closed loop once an hour. Every stage before Execute is read-only; Execute is the single stage that calls a write API, and it can only act on Reserved Instances.
Figure 4 — RightSpend hourly optimisation loop, as orchestrated by AWS Step Functions. Seeding, pricing refresh, reporting and AWS Marketplace metering run on their own daily schedules outside this loop.
Read-only stages
Write stage — Reserved Instance APIs only
Need the diagrams in another format?
Request a Visio, draw.io, or high-resolution PNG version for your security review pack.
