CloudMechanic: The AWS Scanner That Acts Like an OBD-II Port for Your Cloud
A read-only Go CLI with a TUI twin, a uniform scanner interface, and a concurrent execution model that makes cloud hygiene feel local, fast, and safe.
- CloudMechanic’s strongest idea is trust: it inspects AWS in read-only mode, which makes adoption feel safer than a tool that asks for write access first.
- Its real technical trick is not a long list of checks, but a single scanner contract that lets many service probes run through one concurrent pipeline.
- The TUI and CLI are two faces of the same backend, so the tool serves both automation and human exploration without duplicating logic.
- Its value comes from workflow compression, because it turns scattered AWS hygiene checks into one local diagnostic run.
CloudMechanic is not trying to be a full cloud-security platform. It is trying to be the tool you reach for when you want fast answers without handing a scanner the keys to the car.
That matters. AWS environments are often audited with a mix of ad hoc scripts, console clicks, and heavyweight SaaS dashboards. CloudMechanic takes a narrower path: inspect, do not mutate, then present the findings in a way that works for both terminals and humans.
Why a Read-Only Scanner Wins Trust
The OBD-II analogy fits because it describes the social contract as much as the software. A diagnostic port can read what is happening inside a system without becoming part of the system’s control loop. CloudMechanic borrows that posture for AWS.
That choice removes a common adoption blocker. Security tools often ask for broad permissions, then hope the operator trusts them. CloudMechanic flips the burden: it is explicitly read-only, so the default risk profile is inspection, not intervention.
The One-Scanner Contract
The architectural center of the repo is simple: every check implements the same scanner interface. That means a service-specific probe for S3, IAM, EC2, RDS, Lambda, or Security Groups still plugs into the same execution path.
type Scanner interface {
Name() string
Scan(ctx context.Context) ([]Issue, error)
}That is the sort of small abstraction that pays rent. Instead of baking service logic into the CLI, CloudMechanic can build a list of scanners, wrap them with region context, and treat them uniformly from there on out.
The elegance here is not just extensibility. It is that the interface also keeps the mental model small. If you can write one scanner, you can add another without redesigning the whole tool.
How CloudMechanic Stays Fast
CloudMechanic’s speed comes from not waiting on AWS serially. The scan path fans out across scanners and regions in parallel, then gathers results through a buffered channel with a WaitGroup coordinating completion.
That matters because AWS checks are uneven. Some return quickly. Others, like CloudWatch-backed heuristics, take longer. The concurrency model keeps one slow probe from dragging the whole run into line.
The interesting part is that this is not just parallelism for its own sake. The concurrent shape is what makes the local workflow feel credible. Without it, the promise of a fast terminal audit would sound like marketing.
The Checks That Catch What Humans Miss
CloudMechanic’s value is in the heuristics. It is not merely listing resources. It is asking whether a resource is actually risky or merely present.
That shows up in the details. Security Groups treat the protocol value -1 as effectively open access, which catches a class of permissive rules that a shallow port check could miss. RDS checks can look at CloudWatch DatabaseConnections over a lookback window before calling an instance idle. Lambda warnings can come from a local deprecated-runtime map, which keeps the feedback immediate.
// Example of the kind of heuristic CloudMechanic favors:
// do not just inventory the resource, test whether it is truly active, open, or obsolete.That is the difference between a report and a judgment. A good audit tool should save you from false confidence, not just from missing records.
CLI and TUI, Same Brain
The repo’s dual surface is one of its best design choices. The CLI is built for automation, scripting, and piping results into other tools. The TUI gives a human a better way to inspect the same findings interactively.
That split is useful because it does not split the code. The scanner core stays shared. Only the presentation changes. In practice, that means the project can support batch workflows and exploratory triage without drifting into two separate products.
| Dimension | CloudMechanic | SaaS dashboards | Ad hoc AWS scripts |
|---|---|---|---|
| Setup friction | Low, because it uses existing AWS credentials and runs locally | Medium to high, because it adds a platform and workflow | Low at first, then high as scripts accumulate |
| Trust model | Read-only by design | Often broad permissions and external control planes | Depends on the script author |
| Speed | Fast through concurrent fan-out | Varies with network and UI overhead | Usually slow or inconsistent |
| Extensibility | Strong, through one scanner interface | Strong, but tied to the platform | Fragile, because every script is different |
| Human exploration | Built in through the TUI | Built in through the dashboard | Usually weak unless you add your own UI |
| Automation fit | Strong, because CLI output is structured | Strong, but platform-bound | Strong in the short term, weaker over time |
The point of the comparison is not feature parity. It is workflow compression. CloudMechanic shrinks the distance between “I should check this” and “I know what is wrong.”
What It Is Replacing
For some teams, the default alternatives are either a security platform with lots of ceremony or a pile of scripts that only one person understands. CloudMechanic sits between them.
It is smaller than a dashboard, but more disciplined than a grab bag of shell commands. That makes it a strong fit for teams that want local, repeatable audits without signing up for another operational layer.
Where It Stands Today
The repo already shows production-shaped habits. The scanner interface is clean, the concurrency model is explicit, and the code is organized around testable units rather than monolithic commands.
The scope is still narrow, though. It suggests fixes, but it does not remediate automatically. It reports issues, but it does not maintain suppression rules or policy exceptions yet. That restraint is a feature at this stage, not a flaw.
CloudMechanic is strongest when it behaves like a sharp local instrument. It is not trying to be the whole observability stack. It is trying to make AWS hygiene quick enough that you actually do it.
