Finn

Finn is your Cloud Cost Expert: every architecture is a budget written in code, and every invoice is an engineering trace. His doctrine is receipt before recommendation. He finds the waste, prices the decision and the work, protects infrastructure margin, and keeps Observed, Calculated, Modeled, and Unknown evidence visibly separate.

Who Finn is#

Finn specializes in cloud economics — billing forensics, commitment risk, right-sizing, allocation, and the connection between infrastructure and revenue — live across AWS Cost Explorer, Azure Cost Management, and Google Cloud's BigQuery billing export. He thinks in unit economics (cost per request, customer, order, or GB), not just total spend.

What makes his advice trustworthy:

• Receipt before recommendation. Every figure is Observed, Calculated, Modeled, or Unknown; missing data stays missing.
• He's precise about pricing. On-demand vs. effective Savings-Plan vs. spot vs. blended rates, and the edge cases AWS pricing hides.
• He's skeptical of vendor claims. When AWS says "save up to 72%", he calculates the realistic number for your workload.
• He weighs commitment against flexibility. He won't blindly push a 3-year All-Upfront RI onto a workload that's about to be torn down.
• He's direct. "You're overspending on idle RDS instances" beats "you might want to consider evaluating your database utilization."

Connecting your clouds#

Connect the live sources in Connections (native cloud credentials remain in Settings) and Finn's evidence surfaces switch on:

• AWS (read-only keys) — Cost Explorer spend, native Savings Plan/RI health and purchase-recommendation receipts, EC2/RDS/Lambda/S3/IAM inventory, Cost Anomaly Detection, resource tags, and CloudTrail (who changed what). This is his authoritative billing source.
• Azure (a read-only service principal) — Cost Management spend and alerts, subscription inventory (VMs, storage, SQL, Functions), resource tags, and the Activity Log (who changed what).
• Google Cloud (your gcloud sign-in or a read-only service account) — spend from the BigQuery billing export, budgets and cost anomalies, Cloud Asset Inventory with labels, and the admin-activity audit log.
• Wiz (GraphQL, read-only) — cloud inventory, security posture, ownership and aggregated cost attribution across clouds.
• Stripe (OAuth, read-only allowlist) — account identity plus Stripe's generic GET-only API reader and resource/documentation search when the revenue side is relevant to unit economics. Generic writes, refund creation, report creation and feedback are blocked.
• Vantage (OAuth, read-only allowlist) — normalized costs, forecasts, recommendations, anomalies, budgets, business metrics, and unit costs across the portfolio.
• OpenCost (your local or HTTPS MCP endpoint) — Kubernetes allocation, assets, cloud cost, and efficiency.
• Datadog (OAuth, read-only allowlist) — cloud-cost recommendations plus metrics, events, logs, services, dependencies, monitors, and full dashboard reads for cost-to-demand correlation. US1 is the default; regional overrides must retain the audited toolsets and use an approved Datadog MCP origin and path.

Large provider catalogs stay useful without flooding every conversation: Finn has a code-backed connection index that searches every audited allowlisted read, fetches the live schema for the one operation he needs, then invokes it through the same read-only policy and provenance boundary. Vantage's full economic catalog and Datadog's cost tools remain reachable even when only the most common schemas are placed in the immediate prompt.

Cost analysis#

Share a bill, CUR data, a Cost Explorer screenshot, or a spending breakdown and Finn dissects it: the top cost drivers, anomalies, and quantified waste. He does the math — amortized costs, effective hourly rates, break-even points, utilization percentages — and shows his work. With AWS connected he grounds "$X on EC2" in a Cost Explorer call he actually ran, citing the period and metric (and uses amortized cost for true SP/RI effective rates).

Unit economics & margin#

Finn's code-backed unit-economics engine combines revenue and costs only when every revenue, infrastructure, COGS, and unit-denominator receipt declares the same period and currency and confirms complete pagination and reconciliation. Infrastructure receipts must also share one explicit treatment of amortization, credits, refunds, and taxes. A single provider total cannot be added to its Vantage or OpenCost allocation view: stable component, scope, and partition identities make duplicate or overlapping cost populations a refusal, not a prettier total. The engine calculates infrastructure as a percentage of revenue, infrastructure contribution, known contribution, and cost/contribution per decision-useful unit. Estimated inputs make the result provisional.

He does not call revenue minus cloud spend “gross margin.” Gross margin appears only when the revenue basis is recognized, no input is estimated, and you explicitly affirm that every COGS category is present. Otherwise he uses infrastructure contribution or cloud contribution margin and tells you what is missing.

Savings realization#

A recommendation is a hypothesis until the after-period closes. Finn's realization verifier matches the same logical cost scope and business unit before and after the change, normalizes the baseline to the after-period volume, subtracts the separately reconciled one-time implementation cost, and checks the reliability or product guardrails that were supposed to hold.

He reports the calculated economics even when evidence is provisional, but says REALIZED only when the financial receipts are complete and observed, the comparison is valid, implementation cost has fully landed, net savings are positive, and every supplied guardrail is complete and non-degraded. It never annualizes a short window or claims the change caused the result.

Cost-anomaly investigation#

Paste a cost-anomaly alert (or just describe one) and Finn runs the full playbook instead of restating the email:

1. Extract the anomaly's dimensions — service, account, region, usage type, date window, dollar impact.
2. Confirm at the source — the real actual-vs-expected spend and the full root-cause list (the email usually truncates it).
3. Attribute the driver — daily spend grouped by usage type or resource, to pinpoint exactly what spiked and on which day.
4. Find the owner — read Owner/Team/CostCenter tags off the actual resources, or attribute by cost-allocation tag across accounts.
5. Find who changed it — CloudTrail names the actor, when, and from where. If it was automation, he labels the deploy role honestly and uses a real recorded IaC/PR artifact to name the human author; without that evidence, the author stays Unknown.

The same playbook runs on every connected cloud — CloudTrail on AWS, the Activity Log on Azure, the audit log on Google Cloud. The report tells you what spiked, by how much, when, who owns it, and who changed it — with the specific resource IDs and the named actor. He separates owner (the team that runs it) from maker (who performed the change); they're often different people.

Architecture cost review#

Share an architecture or tech spec and Finn reviews it through a cost lens: he flags the expensive choices — NAT Gateways, cross-AZ traffic, over-provisioned instances, idle resources — suggests alternatives, and estimates the dollar delta so a design decision has a price tag before you commit to it.

Savings Plans & RIs#

When you're weighing a Savings Plan (Compute, EC2 Instance, SageMaker, or Database), a Reserved Instance, or an equivalent on another cloud, Finn reads AWS's native Savings Plan/RI utilization and coverage first and can retrieve the provider's latest already-generated purchase-recommendation set, preserving its generation timestamp as the freshness receipt. RI health always carries an explicit service filter, so an RDS question cannot silently become AWS's default EC2 answer. He then models break-even utilization and term/payment trade-offs from closed spend, utilization, and quote receipts with periods, filters, completeness, currency, quote identity, timestamp, and eligibility scope. Missing or mismatched evidence produces no verdict—there is no fictional default plan.

Exact break-even is a hold: lock-in has to buy a positive, evidence-backed advantage. AWS recommendations and live quotes are Modeled underwriting inputs, not purchases and not realized savings; Finn never starts recommendation generation or buys a commitment.

For a concrete decision he folds in local context the raw math can't see — the team's memory for dated retirements, migrations and uncertainty that land inside the term (plus anything you just told him). A three-year All-Upfront looks great until he notices the workload is being torn down in month eight; the risk-adjusted verdict cites the exact signals it used.

Cloud inventory#

Finn browses the connected accounts read-only. On AWS: identity and regions, EC2 instances, RDS databases (with tags), Lambda functions, S3 buckets, and IAM users and roles. On Azure: subscriptions, VMs, storage accounts, SQL servers, Function Apps, and role assignments. On Google Cloud: projects, GCE instances, buckets, Cloud SQL, Cloud Functions, and service accounts. It's the fast answer to "what do we actually have running" and the starting point for right-sizing or ownership questions.

Tag hygiene & changes#

Tags are how cost gets attributed, so Finn treats them as governance. He enumerates every value in use for a tag key — the complete set, with how many resources carry each and which services they span — so inconsistency jumps out (prod vs production vs Prod). The same lens runs on Azure tags (with authoritative per-value counts) and Google Cloud labels. When you want to standardize on AWS, he plans the change: he resolves the affected resources, checks with Cody whether Terraform manages each (and drafts the HCL edits), corroborates with CloudTrail, and hands you an interactive card with copy-paste Terraform and CLI commands to apply yourself — he never changes your cloud.

FinOps strategy#

For the bigger picture — tagging strategy, showback/chargeback models, budgets and alerts, cost allocation, or account structure — Finn gives practical, implementable guidance grounded in how AWS, Azure, and Google Cloud actually bill, not abstract best-practice slides.

Wiz (security & cost)#

With Wiz connected, Finn reads your tenant directly through its GraphQL API (read-only) — the underlying data, not dashboard widgets. He introspects the schema to find the real fields before querying, so he never guesses. Wiz's strength is the security-to-cost link: which resources, owned by which teams, with what posture — so he leans into per-team attribution and surfacing orphaned or idle resources. Where a question needs CUR-level detail Wiz doesn't expose (amortized effective rates, blended-vs-unblended nuance), he says so and points you to Cost Explorer or CUR instead of forcing Wiz to be a billing console.

Change-management review#

Finn can also score a change-management doc, runbook, or migration plan for operational safety — a deterministic 0–100 score across rollback, monitoring, blast radius, window, approvals, clarity, validation and data integrity. When live monitors are available, the result says which named alarms were actually verified; unchecked claims remain Unknown. (Cody carries the same review; ask whichever you're already talking to.)

Org sites#

When a cost or ownership question needs the whole org to weigh in — confirming tag owners, collecting cost-center sign-offs — Finn can build the table from real data he pulled and hand you an org site card to publish. Teammates confirm rows, fix values, or add rows in a browser, every action attributed to their identity, syncing back so your copy stays the source of truth. You click Publish; he can't publish for you.

Watches, studios & lessons#

Finn shares the team's toolkit: put a cost query on the Night Shift watchlist to be alerted when spend crosses a threshold; jump into the right studio with a one-click chip; and correct him — "always show the amortized rate", "never treat a forecast as observed" — and he files it as a durable lesson that changes how the team works from then on.