Why I Ship an Agent You Run in Your Environment

Most cloud cost tools work one of two ways: either you hand them a cross-account IAM role and they pull data directly from your account, or you export CSVs and upload them. Both have problems.

Cloud Cost Analyzer does something different. You run an agent in your environment — your laptop, an EC2 instance, a container in your CI/CD pipeline. The agent collects resource and cost data using your AWS credentials, sends the collected metrics to the CCA service, and the service runs 89 detection rules against your data. You see findings on the dashboard and in the CLI output.

Here’s why I designed it this way.

Credentials never leave your environment

This is the big one. The CCA agent uses your existing AWS credentials — the same ones in your ~/.aws/credentials or your environment variables, or an instance/task role if you’re running on EC2 or ECS. The agent calls AWS APIs directly, collects the results, and sends the collected data to the CCA service over HTTPS.

Your access keys, session tokens, and role ARNs stay on your machine. The CCA service never sees them, never stores them, and couldn’t use them even if it wanted to.

Your Environment                    CCA Service
+--------------------+             +--------------------+
| CCA Agent          |             | Rules Engine       |
| - uses YOUR creds  | -- sends -> | - 89 rules         |
| - calls AWS APIs   |   metrics   | - recommendations  |
| - creds stay here  |   only      | - dashboard        |
+--------------------+             +--------------------+

Compare this to a tool that holds a cross-account role with direct access to your AWS account 24/7. With the agent model, nothing in Dragon Fractal’s infrastructure can call your AWS APIs. If the CCA service were compromised tomorrow, attackers would have collected metrics — not access to your account.

What data does leave your environment

I want to be explicit about this:

Data	Where it goes
AWS credentials (access keys, role ARN, session tokens)	Stays on your machine. Never sent to CCA.
Resource metadata (instance types, volume sizes, NAT Gateway IDs)	Sent to CCA service for rule evaluation.
CloudWatch utilization metrics (CPU, memory, network)	Sent to CCA service for rule evaluation.
Cost Explorer data (spend by service, usage amounts)	Sent to CCA service for rule evaluation.
Detection results and recommendations	Generated by CCA service, shown on dashboard.

The collected data is sensitive — it tells a story about your infrastructure. But it’s not credentials. You can’t use it to access anyone’s account.

How to run it

Sign up at www.dragonfractal.com to get your API key, then:

# Install
curl -sSL https://releases.dragonfractal.com/install.sh | sh

# Or pull the Docker image
docker pull dragonfractal/cca

# Run a scan
cloud-cost-analyzer scan --api-key <your-key> --regions us-east-1

# Or via Docker
docker run dragonfractal/cca scan --api-key <your-key> --regions us-east-1

The agent collects data, sends it to the CCA service, and the results show up in your CLI output and on the dashboard. Output formats include table (default), JSON, YAML, markdown, and PDF.

Why Docker?

The agent is a single Rust binary. You can download it and run it directly. So why also ship a Docker image?

Two reasons:

1. CI/CD integration. Teams that want to run the agent on a schedule in their pipeline don’t want to manage binary versions and OS compatibility. docker pull dragonfractal/cca works the same in GitHub Actions, GitLab CI, Jenkins, and any other runner that supports containers.

2. No install friction. Some engineers can’t (or won’t) install arbitrary binaries on their work machines. Docker is already approved in most environments. Pulling an image and running it is a lower trust bar than downloading and executing a binary.

Rules run server-side (and that’s a feature)

In managed mode, the CCA agent collects data and the service evaluates the rules. This means new detection rules take effect immediately for all users. When I add a rule for idle SageMaker endpoints, the next time your agent sends data, the service applies the new rule automatically. No agent update needed.

For teams that can’t send data to an external service — regulated environments, air-gapped networks — CCA also supports an air-gapped mode where all 89 rules run locally on your machine with a license file. No data leaves your environment at all. Same rules, same recommendations, fully offline.

The business case for the agent model

The agent model costs me more engineering effort than a simple hosted service. I have to build a reliable collector, handle credential discovery across different environments, manage data serialization and compression, and support multiple execution modes.

Three reasons it’s worth it:

1. Lower trust bar. “Run our agent in your environment” is an easier conversation than “give us a role in your account.” Security teams can inspect exactly what the agent does — monitor its network traffic, audit the binary, review the IAM policy.

2. Works everywhere. Laptop, EC2, ECS, CI/CD runner, air-gapped data center. The agent model adapts to wherever the customer’s credentials live.

3. Credentials are the customer’s, forever. I don’t want to be in the business of storing other people’s AWS credentials. The agent model means I never have to.

Try it: sign up at www.dragonfractal.com and pull the agent:

docker pull dragonfractal/cca