Connect 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, trusted principal ARN, external ID, connector ID, and pinned Terraform artifact in-product. No long-lived cloud credentials by default: Venturi reaches the account only through short-lived role sessions; no access key is created or exported. See Docs authority & product state.

Access boundary

The module creates a cross-account IAM role and reports its ARN through the role_arn output. The role’s trust policy allows sts:AssumeRole only for the generated Venturi principal ARN, never an account root, and only with the tenant-scoped sts:ExternalId. Venturi requests 15-minute sessions; the role’s maximum session duration is 1 hour, the lowest value IAM accepts.

Read access is limited to:

• Cost Explorer reads: ce:GetCostAndUsage, ce:GetCostAndUsageWithResources, ce:GetCostForecast, ce:GetDimensionValues, ce:GetTags, ce:GetUsageForecast, ce:GetReservationCoverage, ce:GetReservationPurchaseRecommendation, ce:GetReservationUtilization, ce:GetSavingsPlansCoverage, and ce:GetSavingsPlansUtilization.
• CUR reads: s3:ListBucket on the whole CUR bucket and s3:GetObject on objects under cur_report_prefix.
• Price List reads: pricing:DescribeServices, pricing:GetAttributeValues, and pricing:GetProducts.
• IAM list and get actions, Organizations list and describe actions, and sts:GetCallerIdentity.
• With enable_bedrock_access = true:
  • Bedrock list and get actions for models, inference profiles, provisioned throughput, and the model invocation logging configuration.
  • CloudWatch metrics: cloudwatch:GetMetricData, cloudwatch:GetMetricStatistics, cloudwatch:ListMetrics, and cloudwatch:DescribeAlarms.
  • CloudTrail: cloudtrail:LookupEvents, cloudtrail:GetTrailStatus, and cloudtrail:DescribeTrails.
  • CloudWatch Logs describe, get, filter, and Logs Insights query actions on the log group named in bedrock_log_group.

The cost policy also carries aws-portal:ViewBilling, a legacy Billing console permission that grants no API read. The standing role has no write permission.

Content-bearing logs. Read access to a log source is not storage of its content. CloudWatch Logs read access can reach Amazon Bedrock model-invocation logs, which contain prompts and completions when invocation logging is enabled. Scope the grant to the named log group by setting bedrock_log_group; if you leave it empty, the module grants log reads on every log group in the Region. For any record that still contains content, the collector applies a field allowlist in memory, discards prompt and completion fields before a record is materialized, and never persists, logs, retries, or exports them. The normalized InvocationEvent schema has no field for prompt or completion text.

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 download the pinned Terraform artifact for AWS. Extract it: the extracted infra/aws/onboarding/ directory holds the module, terraform.tfvars.example, and scripts/verify.sh. Copy terraform.tfvars.example to infra/aws/onboarding/terraform.tfvars; it declares every module input under the exact name the module expects. Fill in the generated values below, and add your customer-owned resource names:

Set aws_region to the region approved for your AWS account and residency lane. The us-east-1 value below is an example; confirm that the required AWS services and your billing source are available in the region you select.

Terraform

aws_region            = "us-east-1"
trusted_principal_arn = "<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

The example file also declares the variable that holds the Venturi account ID which guided setup generates together with the values above; set it, under the name the example file declares, to the generated account ID. The module keeps the account ID for reference only: trust is scoped to trusted_principal_arn, not to the account. The module has 2 optional inputs that keep their defaults unless you set them: environment, the deployment environment (dev, staging, or prod; default prod), and permission_boundary_arn, the ARN of an IAM permissions boundary to attach to the role for your own compliance (empty by default, so no boundary is attached).

Set bedrock_log_group to the log group that your Bedrock model invocation logging configuration writes to. Run every command on this page from the extracted infra/aws/onboarding/ directory, and keep it, with its Terraform state, for rotation and removal.

2. Deploy and prove read-only access

Role: the setup principal for the apply; for the checks, a principal allowed to call iam:ListAttachedRolePolicies, iam:ListRolePolicies, iam:GetRolePolicy, and iam:SimulatePrincipalPolicy.

Bash

cd infra/aws/onboarding
terraform init
terraform plan
terraform apply

This is the only terraform apply in the setup path; the Deploy step later activates the connector without applying the module again. Review the plan before apply. The role trusts only the Venturi principal, so you cannot assume it from your own account, and the module’s verify.sh, which assumes the role, runs only under that principal. Prove the boundary from your own account instead. List every policy the role holds:

Bash

ROLE_ARN="$(terraform output -raw role_arn)"
ROLE_NAME="${ROLE_ARN##*/}"
aws iam list-attached-role-policies --role-name "$ROLE_NAME" \
  --query 'AttachedPolicies[].PolicyArn' --output json
for POLICY in $(aws iam list-role-policies --role-name "$ROLE_NAME" \
    --query 'PolicyNames[]' --output text); do
  echo "$POLICY"
  aws iam get-role-policy --role-name "$ROLE_NAME" --policy-name "$POLICY" \
    --query 'PolicyDocument.Statement' --output json
done

The attached-policy list must be []. The loop prints each inline policy: venturi-cost-billing-read and venturi-identity-read, plus venturi-bedrock-cloudwatch-read when Bedrock access is enabled, so 3 policies with Bedrock access enabled and 2 without. Every statement must have "Effect": "Allow" and only the actions listed in Access boundary; any other action is a security finding.

Then use the IAM policy simulator to spot-check the 6 write actions that verify.sh probes:

Bash

aws iam simulate-principal-policy \
  --policy-source-arn "$ROLE_ARN" \
  --action-names iam:CreateUser s3:CreateBucket ce:CreateAnomalyMonitor \
    cloudwatch:PutMetricData logs:CreateLogGroup cur:PutReportDefinition \
  --query 'EvaluationResults[].[EvalActionName,EvalDecision]' \
  --output table

No row may show allowed. The simulator evaluates only these 6 actions, so the policy listing is the complete check. See Verify & confirm for what each check covers.

3. Register outputs and validate

Enter the role_arn, CUR bucket, prefix, and enabled regions in the connector step. The module’s other outputs are external_id, marked sensitive, and granted_permissions, a summary of the granted read scopes that reports write_access = false. Automated credential validation assumes the role from the Venturi principal and 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 /invocations. Check source coverage, unknown records, and freshness before relying on attribution or export eligibility.

Success evidence

• terraform apply succeeds, the role has no attached managed policy, and its inline policies allow only the actions in Access boundary.
• The policy simulator spot check shows no allowed decision for the write actions.
• Automated credential validation and the 1st readiness probe pass, with positive reads and denied writes.
• The 1st AWS-backed AttributionRecord appears in /invocations with coverage and freshness evidence.

Recovery

Failure	Action
AccessDenied on assume-role during validation	Recopy the generated trusted_principal_arn and external_id into terraform.tfvars, apply, and rerun validation.
verify.sh exits 2 when you run it	Expected: the trust policy accepts only the Venturi principal. Use the policy listing, the policy simulator spot check, and automated credential validation.
CUR validation is empty	Confirm the bucket, prefix, region, and s3:GetObject resource scope.
Bedrock evidence is absent	Confirm Bedrock access is enabled, invocation logging is on, and bedrock_log_group names its exact log group.
The policy listing shows an attached policy or an action outside the access boundary, or the simulator shows allowed	Disable the connector, detach or remove the grant, reapply, and rerun the policy listing, the simulator spot check, and automated credential validation.
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

The trust policy accepts a single external ID, and terraform apply replaces it in place, so rotation is a coordinated cutover. Old and new values are never accepted at the same time. Rotate at least every 12 months:

1. In Integrations / AWS, generate the next external ID. The current value stays active.
2. Set external_id in terraform.tfvars to the new value, then run terraform plan and terraform apply. The role now rejects the previous value for new sessions; sessions issued before the apply keep working until they expire, at most 15 minutes later.
3. Immediately activate the new value in the connector settings and rerun automated credential validation. Until you activate the new value, Venturi cannot start new sessions, so complete steps 2 and 3 together.
4. If validation fails, confirm that terraform.tfvars holds exactly the activated value, apply again, and rerun validation.

To revoke access, disable the connector in Integrations / AWS, then run:

Bash

cd infra/aws/onboarding
terraform destroy

This deletes the role and its policies. IAM evaluates a session’s permissions on every request, so new assume-role calls and requests from existing sessions fail once IAM propagates the deletion, which can take a few minutes. No Venturi session outlives its 15-minute duration in any case. Confirm revocation in the connector audit record.

Reference

• Verify the trust boundary
• Trust & security
• Rotate & offboard
• AWS: Monitor model invocation using CloudWatch Logs and Amazon S3
• AWS: SimulatePrincipalPolicy
• AWS: Migrating access control for AWS Billing
• AWS: Disabling permissions for temporary security credentials
• AWS: Actions defined by AWS Price List

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details

Docs feedback: Connect AWS
Page: https://docs.venturi.systems/onboarding/aws/