Bedrock on DNotifier: Setup Guide

Part of a series on running AI workflows across model providers — this one's the first where the model doesn't live in someone else's cloud, it lives in yours.

Every provider earlier in this series works the same way: you paste in an API key, DNotifier talks to that provider's servers, and you're done. Amazon Bedrock breaks that pattern on purpose. Bedrock runs inside your AWS account, behind your IAM policies, in a region you pick — which means connecting it to DNotifier looks less like "add an API key" and more like "grant a service access to a resource you already own." If your company is already running workloads on AWS, or has a security team that wants model calls to stay inside an existing AWS boundary, that difference is the whole reason to use Bedrock in the first place.

What makes Bedrock different, in one sentence

Bedrock doesn't host its own models the way OpenAI or Anthropic host theirs — it's Amazon's managed layer for calling foundation models from Anthropic, Meta, Mistral, Amazon's own Nova family, and others, all through one AWS-native API, billed on your AWS invoice, governed by your existing IAM roles and VPC configuration. You're not trusting a new vendor with your data; you're routing a request through infrastructure you already have a contract, a security review, and a billing relationship with.

Every other provider in this series is DNotifier calling out to a vendor. Bedrock is DNotifier calling into your own AWS account.

Step 1: Confirm model access on the AWS side first

Before touching DNotifier, open the Bedrock console in the AWS account and region you plan to use, and confirm the specific models you want are enabled for your account. Bedrock doesn't grant access to every model automatically — some require a one-time access request that AWS approves, usually within minutes. Skipping this step is the single most common reason a Bedrock integration fails on the first try: DNotifier can be configured perfectly and still get rejected if the underlying AWS account was never granted access to that model.

Step 2: Connect Bedrock in the DNotifier portal

Bedrock's setup path is genuinely different from every other provider's. In the dashboard: Projects → AI Studio → Providers → AWS Bedrock. From there you'll enter either an access key pair or an IAM role for DNotifier to assume, specify the AWS region your Bedrock models are enabled in, and select which of your enabled models to make available. Save, and DNotifier can now call into that account.

Two things worth doing carefully here: use the narrowest IAM permissions that let Bedrock calls succeed (don't hand over a broad admin role because it's faster), and double-check the region matches where you actually enabled model access — a mismatched region is the second most common setup failure.

Four fields, one save button — but each one has to match what's actually configured on the AWS side, or the call fails at runtime instead of at setup time.

Step 3: Install the SDK

npm install @dnotifier-realtime/dnotifier

Step 4: Make a call

Bedrock model IDs are more verbose than most providers' — copy them exactly from the AWS console or the DNotifier portal rather than typing them from memory. A truncated model ID fails at runtime with an error that doesn't always make the cause obvious.

import { DNotifier } from "@dnotifier-realtime/dnotifier";

const notifier = new DNotifier({
  appId: process.env.DNOTIFIER_APP_ID,
  secret: process.env.DNOTIFIER_SECRET,
  userId: "user-4410",
  transport: "ws",
  WebSocketImpl: WebSocket,
});

const response = await notifier.sendAI({
  senderId: "user-4410",
  provider: "aws_bedrock",
  model: "amazon.nova-lite-v1:0",
  message: { messages: [{ role: "user", content: "Summarize this support ticket in two sentences." }] },
  saveHistory: true,
  sessionId: "ticket-88213",
});

Everything downstream — session memory tied to sessionId, the knowledge base for grounding answers in your own documents, the Prompt Testing Studio for comparing Bedrock models against each other or against a different provider entirely, the observability dashboard — works exactly the same as it does for every other connected provider. The AWS-account wiring is a one-time setup cost; day-to-day usage doesn't feel any different once it's done.

A real use case: staying inside an existing AWS boundary

A mid-size fintech company we've talked to had already been through a long AWS security review — VPC configuration, IAM policy audits, a signed BAA-equivalent agreement covering data handling — before they ever thought about adding an AI support agent. Their security team's position was reasonable: any new AI vendor meant restarting that review from scratch, and they didn't have the appetite for it this quarter.

Bedrock let them sidestep that entirely. Because the model calls run inside the AWS account they'd already cleared, no new vendor relationship was needed — the model traffic was covered by the same IAM policies, VPC boundaries, and logging their security team already trusted. They built the support-triage agent with DNotifier's defineAgent/Workflow primitives exactly as they would have with any other provider, pointed it at aws_bedrock with Amazon's Nova Lite model for the first pass and a larger model for anything Nova flagged as uncertain, and shipped it without a second security review. The AWS relationship did the compliance work; DNotifier did the orchestration.

When this setup is worth the extra step

Bedrock's setup is more involved than pasting in an API key, so it's worth being honest about when that's worth it: if your organization already has AWS as an approved vendor and a security team that would rather extend an existing boundary than approve a new one, Bedrock is very often the path of least resistance. If you're starting from scratch with no existing AWS relationship, a provider with a simpler key-based setup will get you running faster — you can always add Bedrock later without touching the rest of your DNotifier workflows.

Frequently asked questions

Does DNotifier store my AWS credentials?

DNotifier needs credentials or an assumable IAM role to make calls on your behalf, scoped to whatever permissions you grant. Follow your organization's standard practice for least-privilege access when creating that role or key.

Can I use Bedrock alongside other providers in the same app?

Yes — this is true of every provider in this series. A single Workflow can route one step to Bedrock's Nova model and another to Anthropic, Gemini, or any other connected provider, based on whatever logic the workflow defines.

Which Bedrock models does DNotifier support?

Whichever models your AWS account has been granted access to and you've enabled in the DNotifier portal — Amazon's Nova family, Anthropic's Claude models on Bedrock, Meta's Llama models, and others, depending on what's available in your region and account.

What happens if my IAM permissions are too narrow?

Calls fail with an access-denied style error. This is usually the first thing to check if a Bedrock integration that was working suddenly stops — a policy change on the AWS side is a more common cause than anything changing on the DNotifier side.

The Bottom Line

Next in this series: what Amazon Bedrock actually is under the hood, and why "one AWS-native API for many foundation models" is a meaningfully different pitch than what most model providers offer.

Read part two: What Is AWS Bedrock?. Explore dnotifier.com.