A read-only connection model security teams can review in one sitting.
BedrockOps connects through a read-only cross-account IAM role, never sits in the request path between your application and Bedrock, runs all SaaS-side compute and storage in a single EU region, and uses AWS-managed encryption only. This page states that operating boundary in concrete, verifiable terms.
One read-only role. Verified on every assumption.
Four properties define the connection: a read-only role provisioned by CloudFormation, a per-tenant External ID, verification after every role assumption, and continuous drift detection.
One-click Quick-Create CloudFormation role
Connecting an AWS account is one Quick-Create CloudFormation link that provisions a read-only cross-account IAM role in your account. Read-only is the default: scoped-write capabilities are deferred to later versions and would only ever arrive as a separate, explicit opt-in template.
A per-tenant External ID in SSM Parameter Store
A per-tenant External ID is generated at onboarding and stored in AWS SSM Parameter Store. It is never logged, never returned outside the onboarding response, and never displayed after onboarding.
Confused-deputy defense after every AssumeRole
After every sts:AssumeRole, BedrockOps calls GetCallerIdentity to confirm the assumed account matches the customer-supplied account, and verifies the role’s trust-policy shape via iam:GetRole. A failed check aborts the assumption.
Role-drift and access-revocation detection
BedrockOps detects drift in the role’s trust policy and treats consecutive AssumeRole failures as access revocation — both surface as alerts rather than silent gaps in coverage.
No customer-side runtime. One direction only.
BedrockOps does not sit in the request path between your application and Bedrock — it reads, it interprets, it recommends. It never proxies a Bedrock call, and customer data flows in one direction only: from your AWS account to the BedrockOps SaaS account. The buyer-facing view of this model is on Why AWS; the step-by-step onboarding workflow is on Getting Started.
- Not a Bedrock proxy — no requests are routed through BedrockOps
- Not a vector database — no embeddings are built or stored
- Not a reranker training tool — no models are trained
A single EU region. AWS-managed encryption only.
All SaaS-side compute and storage run in a single EU region — eu-west-3 (Paris) — and the operational database (PostgreSQL with TimescaleDB) and Redis are EU-hosted.
Encryption is AWS-managed only: SSE-S3 for buckets, SSE-SQS for queues, and the AWS-owned default for DynamoDB. Database-tier encryption is provider-managed. BedrockOps holds no customer-managed KMS keys — and there is no BYOK.
Isolated per team. Recorded append-only.
Multi-team isolation from day one
Operational tables are protected with PostgreSQL row-level security enforced per team — every team’s data is isolated at the database layer.
An append-only audit log in PostgreSQL
The append-only audit log lives in PostgreSQL and is the durable record of every state change.
Collection and operations sized to account activity.
The SaaS side runs on AWS-native building blocks — Lambda and Step Functions, S3, CloudFront and API Gateway, SQS, EventBridge and CloudWatch, and SES — in eu-west-3. Telemetry collection itself is part of the Runtime Intelligence pillar.
Activity-sharded collection
Collection cadence varies by account activity — 1-minute for active accounts, 5-minute for quiet, 30-minute for dormant — so dormant accounts do not pay the polling tax of active ones.
SQS event flow with DLQs
Internal work moves through SQS queues with idempotent processors and per-queue dead-letter queues.
Step Functions for cross-pillar workflows
Cross-pillar triage and customer-account verification run as AWS Step Functions workflows.
Daily backup, weekly restore validation
A daily PostgreSQL logical backup is written to S3, and a weekly validator restores it into a temporary database and asserts the schema.
SLO burn-rate monitoring
Service-level objectives carry multi-window burn-rate state, with 1-hour and 6-hour fast and slow burn signals.
Four surfaces, one job each.
Everything customer-facing lives on one of four BedrockOps domains.
bedrockops.io
The public marketing and documentation site.
app.bedrockops.io
The customer dashboard — the product application.
api.bedrockops.io
The BedrockOps API, served from eu-west-3.
templates.bedrockops.io
Customer-launchable IAM templates — the CloudFormation templates behind the Quick-Create onboarding link.
Review the boundary in one sitting, then connect.
Start in AWS Marketplace, connect AWS with a read-only cross-account IAM role, and get a first finding from real Bedrock production signals without changing live traffic flow.
Start 7-Day Trial On AWS Marketplace