Architecture

Architecture and data flow, drawn for security reviews.

How CloudFix and RightSpend connect to your AWS environment, what they read, where approval sits, and the narrow boundary inside which each one writes.

Request the diagram files Role permissions

Figure 1 · CloudFix

CloudFix core architecture.

How CloudFix connects to your AWS environment, what it reads, and how an approved fix runs, without any third-party ITSM integration.

Figure 1. Data flows between the CloudFix platform (left) and your AWS account (right). CloudFix reads primarily infrastructure metadata; the security page sets out the finder role's full permission model.

CloudFix platform (AWS us-east-1)
Your AWS account
Approval boundary: you approve before any fix runs

Behind the approval boundary. Once you approve a recommendation, CloudFix starts the fix as an AWS Systems Manager Automation runbook in your account, under cloudfix-ssm-update-role. The CloudFix platform can assume that role only with the external ID unique to your tenant, its runbooks are the CloudFix documents shared with your account, and each execution is logged in Systems Manager and in your CloudTrail. Full trust policies and action lists are in the IAM role architecture and the published CloudFormation templates.

Figure 2 · CloudFix with ITSM

CloudFix and your service desk.

How CloudFix integrates with service desk and ITSM platforms through webhooks and the CloudFix REST API, so approval runs through the workflow you already operate.

Figure 2. CloudFix sends 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 starts the approved runbook through AWS Systems Manager.

Service desk or ITSM platform
CloudFix platform (AWS us-east-1)
Your AWS account
Approval boundary

No customer AWS data passes through the service desk platform. Webhook payloads carry CloudFix recommendation metadata only: AWS resource IDs, estimated savings, service type and approval status. No S3 contents, database records, application data or credentials are ever included. The data processing page lists exactly what crosses each boundary.

Figure 3 · RightSpend

RightSpend core architecture.

How RightSpend connects to your AWS Organization, what it reads, and the narrow boundary within which it writes. RightSpend is a separate product with its own IAM roles, its own platform stack and no shared permissions.

Figure 3. Three separate IAM roles serve three 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)
Your AWS Organization
Write boundary: Reserved Instance APIs only

What RightSpend never 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. It reads resource metadata and Cost Explorer aggregates, never the contents of a workload or data store. Full action lists per role are on the RightSpend page.

Figure 4 · RightSpend loop

The 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 act only on Reserved Instances.

Figure 4. The hourly 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.

Request diagram files Read the security model