Envission

What Envission is

Most teams end up with a different tool for every angle on their cloud footprint: one dashboard for spend, another for resource inventory, another for security posture. Each one looks affordable when the environment is small. None of them stay that way as usage grows or the environment gets more complex — pricing scales with resource count or evaluation volume, and the rules you'd want to customize live inside someone else's product, on someone else's roadmap.

Envission consolidates all of it into one platform: cloud spend, resource inventory, and security findings across providers, on one data model, with the rules for what counts as a problem written and owned by us — not rented from whichever vendor happens to price it lowest this year.

Why we built our own instead of buying one

Off-the-shelf cost and compliance tools, and a cloud provider's own native rule engines (AWS Config Rules and equivalents elsewhere), share the same shape: a recurring cost per resource evaluated, and logic written in that provider's own syntax, tied to that provider's own roadmap. A change on their end forces a change on ours, on their timeline.

Envission works from a different default: the logic for when to check something and what counts as a problem always lives in our own code, never delegated to a provider's native rule engine. The only thing delegated to each cloud provider is read access to its own data — there's no alternative to asking AWS for AWS's own resource configuration. What happens with that data afterward — the rules, the scheduling, the alerting — is written once, generically, and reused as providers are added, instead of rebuilt in a new vendor's dashboard every time.

Integrating the data

• Cost — ingested daily from each provider's billing API, normalized toward the open FOCUS (FinOps Open Cost and Usage Specification) standard, so a new spend source — another cloud, AI token usage — is a matter of extending rows in an existing model, not redesigning tables.
• Resource inventory — consolidated through each provider's own configuration/discovery service, covering resources whether or not they're tagged, and modeling the real relationships between them (an instance to its security group, to its network) rather than a flat list.
• Access — a read-only role per connected account. Nothing writes back, and credentials never leave the account they belong to.

How it's put together

A scheduled process we control ingests from each provider on our own cadence, not theirs. Underneath sits a provider-agnostic data model — spend events, resources, budgets, alerts — that every rule and every screen reads from; adding a new cloud provider means writing an adapter that translates its native API into that same shape, not rebuilding the rules or the UI for it. A rules layer evaluates resource configuration for security and compliance findings, and spend for budget breaches or anomalies, running as our own scheduled jobs — so evaluation cost doesn't scale per-check the way a provider's native compliance engine does.

Two modules are live today: a Cost Monitor (an executive summary plus a granular breakdown by service, region, and account) and a Resource Monitor (full inventory by type, region, and availability zone). A Health Monitor — uptime and incident tracking across the systems and services a team depends on — is the next module being built on the same foundation, so adding it is one more entry in the sidebar, not a redesign.