Skip to main content

​
Overview

nOps reads Amazon Bedrock Model Invocation Logs from AWS (via S3 large data delivery) to show AI model usage and cost in Inform. In nOps you provide the S3 bucket (and optional prefix) for each Bedrock log destination. You can connect multiple S3 destinations when Bedrock logs are split across buckets or prefixes. This step stores references only — it does not deploy CloudFormation in your account. Complete AWS-side logging and IAM setup first, then connect in nOps.

​
Prerequisites

  • An AWS account with Amazon Bedrock enabled
  • Permission to enable Model invocation logging in Bedrock and configure S3 delivery
  • An existing nOps AWS cloud integration in the account that receives Bedrock logs (see AWS integration setup)
  • Permission to update the nOpsBucketPolicy on your nops-integration-role IAM role for S3 read access
  • nOps organization administrator access
Only admins and owners can connect, re-validate, or disconnect. Members see Admin Only on connectable cards.

​
Step 1: Enable Model Invocation Logs in Bedrock

  1. Sign in to the AWS Management Console and open Amazon Bedrock in the target region.
  2. Go to Settings under Configure and learn.
  3. Enable Model invocation logging and choose which data types to log.
Message content can be sensitive. Disable Text in logging options if you do not want message bodies in logs.
  1. Configure S3 location — bucket and prefix (for example s3://your-bucket/bedrock/).
  2. Use an IAM role that allows Bedrock to write to that bucket and Save settings.
  3. Optionally invoke a model once and confirm objects appear under the prefix.
Logs capture usage from enablement forward only — not historical usage before logging was turned on.

​
Step 2: Grant nOps S3 read access

During AWS onboarding, nOps creates a cross-account role named nops-integration-role (or nops-integration-role-<client_id>) with a customer-managed nOpsBucketPolicy for S3 access. Update that policy in the account that holds the Bedrock log bucket to allow read access to your prefix, for example:
Replace YOUR_BUCKET and YOUR_PREFIX with your Bedrock log destination. Use the payer or child account where the role and bucket live, consistent with your existing AWS integration. See AWS Permissions & Resources for the full nOpsBucketPolicy reference.
nOps does not train on Model Invocation Log content and does not expose message bodies in the product.

​
Connect in nOps

​
Where to open Amazon Bedrock

  • To connect for the first time — go to Settings → Integrations and click the Amazon Bedrock card.
  • To manage existing connections — open the same card or use Settings → Account Status → Connected apps and click the Amazon Bedrock chip.

​
Connect steps

  1. Click the Amazon Bedrock card or chip.
  2. Click Add integration.
  3. Enter the S3 bucket (and optional prefix) using one of these formats:
    • my-bucket
    • s3://my-bucket
    • s3://my-bucket/prefix
  4. Click Add.
Repeat steps 2–4 for each additional S3 destination. nOps stores these references without a live API check — ensure AWS logging and IAM access are correct before connecting.
New Amazon Bedrock integrations accept S3 destinations only. If you previously connected a legacy CloudWatch log group, you can still edit that value on the existing integration, but new connections must use S3.

​
Manage your connections

Administrators can add, edit, re-validate, or remove individual Bedrock integrations from the Amazon Bedrock modal. If data does not appear, fix Bedrock logging or S3/IAM permissions in AWS first, then update the stored S3 bucket or prefix path if the destination changed.

​
Troubleshooting

  • No data after 24–48 hours — confirm Bedrock is writing to the S3 prefix, the nOps IAM role can s3:GetObject on that prefix, and the prefix in nOps matches exactly.
  • Wrong account — Bedrock logs, the S3 bucket, and the nops-integration-role must align with your nOps AWS integration account.
  • Sensitive data — exclude text logging in Bedrock if policy requires it.
  • Invalid bucket format — use a valid bucket name or s3:// URI as shown above. Paths like my-bucket/prefix without the s3:// prefix are not accepted unless the value is a bare bucket name.

​
Security

Model invocation logs may contain sensitive prompts and responses. Restrict S3 bucket policies and logging options to your compliance requirements.