Skip to content

30-minute quickstart

This is the fast path from zero to Venturi is ingesting my data. It works for AWS, GCP, or Azure: the shape is identical; only the values and the module directory change.

The whole thing in one sentence

Deploy one read-only Terraform module, prove it’s read-only with the bundled verify.sh, and send Venturi the output it prints.

Choose your deployment mode first

Venturi runs in two modes with one identical contract: the SaaS tier (Venturi-operated, single-tenant, residency-pinned; the flow on this page) and a self-hosted in-VPC data plane (arranged with your onboarding contact; same steps, your own hosts). See Deployment modes. Hands-on time is 15–30 minutes either way, plus two short email round-trips and up to one business day for ingestion confirmation.

Before the clock starts

Have these ready (full checklist on Before you begin):

  • Terraform ≥ 1.5 and your cloud CLI installed and authenticated (aws / gcloud / az).
  • Admin-level access in the target account/project/subscription (you’ll create an IAM role / service account / service principal).
  • The onboarding module for your cloud, from infra/<cloud>/onboarding/ in the platform repository (source access is provided during onboarding).
  • An email thread open with contact@venturi.systems, with your cloud-specific values already in hand (Step 1): request them before you start the clock.

What the 30 minutes covers

The 30-minute budget is your hands-on work: deploy, verify, send. It does not include waiting on the Step 1 email reply from Venturi. Request those values ahead of time so the reply is in your inbox when you begin.

Target-state: a file-first path to the same milestone

The onboarding objective this page is measured against also admits a variant that reaches the first attribution record by uploading one provider export file and connecting nothing. That path is specified but not shipped, so it is not an option today: deploying the read-only connector below is currently the only way through. See File import for the specified contract.

Step 1: Get your values from Venturi (before the clock starts)

Email contact@venturi.systems telling us which cloud you’re connecting. On first contact Venturi also creates your tenant and sends the account-team handoff (your dashboard host, admin invitation, and where domain claiming and SSO setup happen later). The reply includes the cloud-specific values you’ll paste into Terraform:

  • venturi_account_id: the AWS account Venturi assumes the role from.
  • external_id: a per-customer string for the sts:ExternalId condition (confused-deputy mitigation).
  • wif_issuer_uri: Venturi’s OIDC issuer URL.
  • wif_allowed_subjects: the exact OIDC subject(s) Venturi federates from (no wildcards).
  • federated_credential_issuer: Venturi’s OIDC issuer URL.
  • federated_credential_subject: the subject claim in Venturi’s federation token.

Step 2: Fill terraform.tfvars (≈5 min)

Copy the terraform.tfvars.example that ships in the module directory, then fill in Venturi’s values plus your own resource names (CUR bucket, billing dataset, subscription ID, see your cloud guide).

aws_region        = "us-east-1"        # region your CUR bucket lives in
venturi_account_id = "<from Venturi>"
external_id       = "<from Venturi>"
cur_bucket_name   = "my-org-cur-bucket"
enable_bedrock_access = true

project_id            = "my-prod-project"
service_account_id    = "venturi-readonly"
use_workload_identity = true
wif_pool_id           = "venturi-pool"
wif_provider_id       = "venturi-provider"
wif_issuer_uri        = "https://<from Venturi>"
wif_allowed_subjects  = ["<from Venturi>"]

subscription_id              = "00000000-0000-0000-0000-000000000000"
use_federated_credential     = true
federated_credential_issuer  = "https://<from Venturi>"
federated_credential_subject = "<from Venturi>"

Step 3: Apply (≈5 min)

cd infra/<cloud>/onboarding   # aws | gcp | azure
terraform init
terraform plan                # review the read-only role/SP it will create
terraform apply

terraform apply prints the outputs you’ll send back in Step 5 (role ARN / service-account email / client ID) plus a human-readable granted_* summary: keep that for your audit trail.

Step 4: Verify the trust boundary (≈2 min)

./scripts/verify.sh

This assumes the identity exactly as Venturi will, then exercises one read and one write per granted service. Reads must succeed; writes must fail. The script exits non-zero if any write succeeds: that would be a security finding, not a pass. A clean exit is your proof the integration is read-only.

What “verified” means in detail

Step 5: Send the outputs to Venturi (≈3 min)

Reply to your onboarding email with the terraform output values. Each cloud guide lists the exact fields, e.g. AWS:

role_arn:   <terraform output>
cur_bucket: <bucket name>
region(s):  us-east-1, ...

Step 6: Venturi confirms (≤ 1 business day)

We validate that the role/SP is reachable, start ingestion, and reply confirming data is flowing. Within ~1–2 hours of confirmation you’ll see your team roster, cost data, and AI model inventory populate in the Venturi dashboard.

You’re done when…

  • terraform apply completed with no errors.
  • ./scripts/verify.sh exited 0 (reads pass, writes denied).
  • You’ve sent Venturi the outputs.
  • Venturi has confirmed ingestion, and the dashboard shows your data.

Now go deeper on your specific cloud:

AWS Google Cloud Azure