CloudSpendGuard

The problem: two backlogs, the same infrastructure

An idle resource can waste money and carry a security misconfiguration at the same time. Separate cost and security reports make engineers reconcile the priorities themselves. This project explores a different workflow: ingest the evidence, detect both kinds of finding, and explain their order in one backlog.

I designed and implemented the ingestion pipeline, rule engines, anomaly detector, joint prioritizer, guarded remediation workflow, reporting, and automated evaluation. The project targets a single AWS account; it is not a replacement for a comprehensive enterprise security platform.

Implementation

Go CLI, static binary

Inputs

CUR, CloudTrail, Terraform

Output

Markdown, HTML, JSON, SARIF

Architecture and design decisions

The layered pipeline separates ingestion, normalization, analysis, ranking, remediation, and presentation. Cost and security analyzers emit a common finding model. Their outputs converge at the joint prioritizer, while an independent verifier checks proposed changes before a diff is shown.

• Local-first operation: local-file analysis needs no AWS credentials. Local Ollama inference is the default; live AWS collection and remote inference are separate opt-ins.
• Transparent ranking: stakeholder profiles weight normalized savings, risk, and a blast-radius penalty. Reports expose score components rather than presenting an unexplained order.
• Human-controlled changes: remediation produces proposed diffs. The tool never applies infrastructure changes automatically.

Results, with their boundaries

These are recorded project measurements from October 2026, not benchmarks rerun for this portfolio page. The fixtures are small or synthetic, and the results do not establish production-wide accuracy.

The memory limitation matters. The analysis path retains CUR records in memory. Extrapolating the observed process-memory ratio suggests roughly 13 GiB for approximately eight million rows, before adding a separately running local model. Streaming aggregation is the first improvement planned, not a capability claimed here.

The comparison is deliberately modest. CloudSpendGuard missed two labeled defects. Checkov found all 34 in the pinned comparison run but tied CloudSpendGuard in a separate local run; the cause of that difference is undetermined. The contribution is the combined workflow, not a claim of superior scanner coverage.

Generated remediation is not self-approved

Resource tags and other metadata are untrusted input. The remediation pipeline combines redaction and instruction filtering with a nonce-fenced data prompt. Candidate patches are re-parsed and checked with both analyzers; structural checks and newly introduced findings can reject a patch. Retries are bounded, and a finding can be reported without a patch.

Verification is limited by the implemented rules and the available input. It does not replace a human review, a Terraform plan, broader security testing, or an assessment of deployment impact.

Explore the implementation

The public engineering repository is the evidence hub. It contains the prototype, design decisions, evaluation method, test fixtures, and commands for reproducing the checks.

• Source code and quick startThe Go implementation and project README.
• Architecture and module designPipeline responsibilities and design trade-offs.
• Evaluation methodologyDetection scoring, benchmark methods, and limitations.
• Demonstration runbookA reproducible walkthrough rather than a claimed video recording.

Try the local sample

git clone https://github.com/WisnuAnggoro/cloudspendguard.git
cd cloudspendguard
make build
./bin/csg run --sample --report ./out.html --top 5

The bundled sample workflow needs no AWS credentials. For the recorded fixtures, it produces 23 findings from 392 CUR line items, eight CloudTrail events, and 22 Terraform resources; consult the repository for toolchain prerequisites and current behavior.

The final academic report, presentation slides, and recorded demonstration are not published on this page yet. Private coursework, instructor feedback, and working drafts are intentionally excluded.

Lessons and next steps

Measurement changed the design. Stage timings showed that the initial database round trip, not the assumed Parquet bottleneck, dominated large runs. Comparing results with established scanners exposed a false positive; adversarial fixtures exposed the limits of the instruction filter. The most useful engineering habit was to keep those failures visible and attach regression checks to the fixes.

Next steps are streaming aggregation, broader Terraform expression support, additional read-only live services beyond S3, an independently labeled evaluation corpus, and collection of the planned human usability study. No real survey results are claimed here.

Built by Wisnu Anggoro as a master's capstone exploring cloud cost governance, security engineering, and local-first AI assistance.