Onboarding: AWS¶

An Engineer or Admin can configure the AWS connector from the guided setup without a human handoff. The flow generates the tenant-scoped Venturi account ID, external ID, connector ID, and pinned Terraform artifact in-product. See Docs authority & product state.

Access boundary¶

The module creates a cross-account IAM role named venturi-readonly-integration by default. Its trust policy requires the exact Venturi account principal and a tenant-scoped sts:ExternalId; sessions expire after 15 minutes.

Read access is limited to:

Cost Explorer, pricing catalog, and the named CUR S3 bucket and prefix.
Bedrock model and invocation metadata when enabled.
Scoped CloudWatch and CloudTrail inventory.
IAM and Organizations inventory.

The standing role has no write permission. Scope bedrock_log_group to the exact log group because model invocation logs can contain content. Venturi extracts allowlisted metadata and never persists prompt or response bodies.

Steps¶

1. Generate configuration¶

Role: Engineer or Admin in Venturi; AWS principal with IAM role-creation permission for the apply.

In guided setup, select AWS, choose the account, and copy or download the generated values. Add customer-owned resource names:

Terraform

aws_region              = "us-east-1"
venturi_account_id      = "<generated in guided setup>"
external_id             = "<generated in guided setup>"
cur_bucket_name         = "my-org-cur-bucket"
cur_report_prefix       = "cur/"
bedrock_log_group       = "/aws/bedrock/modelinvocations"
enable_bedrock_access   = true

2. Deploy and prove read-only access¶

Bash

cd infra/aws/onboarding
terraform init
terraform plan
terraform apply
./scripts/verify.sh

Review the plan before apply. verify.sh assumes the generated role, runs positive Get or List probes for granted services, and confirms that deny-expected write probes cannot mutate provider state.

3. Register outputs and validate¶

Enter the role_arn, CUR bucket, prefix, and enabled regions in the connector step. Automated credential validation checks the external-ID trust condition, role reachability, scoped reads, and denied writes. No output leaves the in-product flow.

4. Inspect evidence¶

Open the readiness result, then the quality feed. Check source coverage, unknown records, and freshness before relying on attribution or export eligibility.

Success evidence¶

terraform apply succeeds and the role policy is read-only.
verify.sh exits 0 with positive reads and denied writes.
Automated credential validation and the 1st readiness probe pass.
The 1st AWS-backed AttributionRecord appears in the quality feed with coverage and freshness evidence.

Recovery¶

Failure	Action
`AccessDenied` on assume-role	Regenerate or recopy the tenant connector values and compare the exact principal and `external_id` in the trust policy.
CUR validation is empty	Confirm the bucket, prefix, region, and `s3:GetObject` resource scope.
Bedrock evidence is absent	Confirm Bedrock access is enabled and the exact invocation log group is configured.
A write probe succeeds	Disable the connector, remove the write grant, reapply, and rerun the complete trust-boundary check.
Freshness becomes stale	Check the readiness probe and CUR delivery timestamp, then rerun ingestion after the source advances.

Support is available for escalation after the in-product recovery evidence has been captured; it is not part of activation.

Rotate or revoke¶

For rotation, generate the next external ID in connector settings, update Terraform, apply, and rerun validation before activating the new value and revoking the previous value. Never leave both values accepted after cutover.

To revoke access, disable the connector in-product, then run: