How Dify with Amazon Bedrock models works in practice
A regulated team that runs Dify in its own infrastructure often wants chat, embedding and rerank models to be served from its own AWS account, so that model traffic and billing sit under existing cloud contracts. Dify reaches Amazon Bedrock through the Amazon Bedrock model provider plugin published by langgenius on the Dify Marketplace. The plugin covers the models of Amazon Bedrock, so the work is a provider configuration inside Dify rather than a separate service you build. Dify itself is an LLM application development platform for building AI workflows, RAG pipelines and agents through a visual interface, and the Bedrock provider simply supplies the model endpoints those apps call.
Because the connection is configuration, most of the decisions sit in AWS and in the plugin settings. The team must choose the region that hosts the models it is allowed to use, create an IAM identity with only the Bedrock actions the plugin needs, and decide which model families to enable separately for chat, embedding and rerank. Not every model is offered in every region, and the available list changes over time, so confirm the exact model list and the IAM actions against the plugin version you install before writing policies. Check the plugin's own setup fields and the Bedrock documentation for your chosen region, and record the result in your change record so that a later plugin upgrade does not silently change what your apps can call.
Treat the credential and network questions as part of the design from the start. The access key stored in Dify is a secret that the platform must protect, so plan who may view or rotate it, and keep separate identities for development and production. Confirm whether your traffic to Bedrock will leave your network through the public endpoint or a private endpoint in your VPC, and whether your outbound proxy settings in Dify allow that path. Test each enabled model with a small chat, embedding and rerank call from the target environment, and confirm that prompts and retrieved documents reach only the AWS services you intended.
What you need before connecting Dify to Bedrock
Connecting Dify to Amazon Bedrock depends on decisions made in three places: the Dify deployment, the AWS account and the network path between them. Confirm each item below before you open the model provider settings, because a gap in any one of them tends to show up later as a failed test call rather than a clear error.
Self-hosted Dify deployment
Dify runs on your own infrastructure, and the Docker Compose path starts the api, worker, web and plugin daemon services along with PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. Plan for at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later. Confirm the current release line on the GitHub releases page before you start, since minor releases arrive roughly monthly and the Bedrock plugin should be installed against the version you deploy.
AWS account and Region
Decide which AWS account will own the Bedrock usage and which Region will serve requests. Bedrock model availability differs by Region, so confirm that each model family you intend to use is offered in the chosen Region before you build workflows around it. Record the Region in your design document, because changing it later means new model identifiers and possibly new data residency review.
Model access for each family
Access to Bedrock models is granted per model in the account, separately from IAM permissions. Request access for every chat, embedding and rerank model you plan to expose in Dify, and confirm that the terms shown in the console are acceptable to your legal team. A model that is enabled in Dify but not granted in Bedrock will fail at runtime, so test each one with a sample call.
Dedicated IAM identity for Dify
Create a separate IAM identity for Dify rather than reusing a developer or administrator credential. Grant only the Bedrock invocation actions needed for the models you enabled, scoped to the Region and, where your policy allows, to specific model resources. Document who owns the key, how it is rotated and where it is stored, because the credential is entered into Dify's model provider settings.
Outbound network path
Dify's plugin runtime must reach Bedrock endpoints over HTTPS. Check whether your outbound route goes through a corporate proxy, a NAT gateway or a firewall, and whether the SSRF proxy used by Dify blocks the destination. Plan an allowlist entry for the Bedrock endpoint in your Region and verify it from the host or container that runs the plugin before you test the provider.
Marketplace plugin version
Install the Amazon Bedrock model provider plugin from the Dify Marketplace, published by langgenius, and confirm that its version is compatible with your Dify release. Record the plugin version alongside the Dify version in your change log, since upgrades to either can change how credentials and model lists are handled.
How to configure the Bedrock provider in Dify, step by step
This sequence takes a self-hosted Dify workspace from no model provider to a verified Amazon Bedrock connection, with a scoped IAM identity, a region choice and only the chat, embedding and rerank model families your applications need.
Confirm the Dify deployment and workspace
Before adding any provider, confirm which Dify version and workspace the provider will serve, and who in your team administers model providers. Your platform or Dify administrator makes this check in the Dify console, and the step is done when you can name the target workspace and the admins who may change its provider settings. Keep the Bedrock configuration in the same environment (development, staging or production) that the applications will use, so credentials are not shared across environments.
Install the Amazon Bedrock plugin from the Marketplace
In the Dify console, install the Amazon Bedrock model provider plugin from the Dify Marketplace. The plugin is published by langgenius and covers the models of Amazon Bedrock. Your Dify administrator performs the install, and the step is done when the Bedrock provider appears in the workspace's model provider list. Check the plugin's listing for the version and compatibility with your Dify release before installing, and record the version in your change log.
Create a dedicated IAM identity for Dify
In your AWS account, create a separate IAM identity used only by Dify for Bedrock calls. Attach a policy that grants only the Bedrock actions needed to invoke the model families you plan to enable, scoped to the specific regions and, where AWS supports it, to specific model resources. Your cloud or identity team performs this step. It is done when the identity exists, its policy lists only the Bedrock permissions you reviewed, and no other AWS services are granted. Confirm the exact action names and resource formats in the AWS IAM and Bedrock documentation for your account.
Store the access credentials in the provider settings
Generate the access key for the dedicated identity under your organization's approved key process, then enter the credentials in the Bedrock provider settings in Dify. Store the key in the provider form rather than in application code or exported DSL files, because exports do not include third-party API keys. The step is done when the provider saves without an error and the stored entry shows as configured. Record who created the key, its rotation date and the environment it belongs to in your credential register.
Select the AWS region for the provider
Choose the AWS region in the Bedrock provider settings that matches your data residency and latency requirements. Model availability differs between regions, so the region decides which model names you can select later. Your architect makes the choice with your compliance lead, and the step is done when the region is saved and recorded in your architecture notes. Confirm region availability for each model family in the AWS console for that region before you commit, because availability changes over time.
Enable the chat, embedding and rerank models intended for apps
In the Bedrock provider settings, add only the model families your applications will use, separately for chat, embedding and rerank. Enable the models in the AWS console first, then add the matching model names in Dify. Keep the list short so that app builders choose from approved models. The step is done when each enabled model appears under the correct model type in Dify's model selection. Confirm model names and identifiers in the AWS console, since they vary by region and can change.
Run a test call from the provider settings
Use the test or validation function in the Bedrock provider settings, or send a short prompt to each enabled chat model from a test app. Then send a single test embedding request through a knowledge base test and, if you enabled a rerank model, run one query that uses it. The step is done when each model returns a valid response and the Dify logs show the call went to the expected region. If a call fails, check the IAM policy, region and model name before changing anything else.
Confirm traffic stays inside AWS and record the setup
Check that the Dify host reaches Bedrock through the networking path your organization approved, such as a private endpoint or a restricted egress route, and that outbound requests use the proxy controls your Dify deployment sets. Then record the plugin version, region, IAM identity, enabled models and test results in your configuration register. The step is done when a network reviewer has confirmed the egress path and the register entry exists. Confirm the AWS networking options available in your account with your cloud team, since they depend on your VPC design.
Which AWS and Dify settings map to each other
This table pairs each AWS value with the Dify setting that must match it, the owner who sets it, and the evidence to keep. Read it as a checklist before the first model call, and treat any mismatch between the account, region, identity and model ID as a blocker. Keep the mapping in a change record so a later audit or key rotation can trace every Dify provider back to its AWS source.
| Setting pair | How they map | Owner | Evidence to keep |
|---|---|---|---|
| AWS account and region to Dify provider region | The Bedrock region chosen in the Dify provider must be the region where the approved model is enabled and where data residency was reviewed. Record the account ID and region together. | Platform team, with security approval | Signed region decision, account ID, screenshot or export of enabled models in that region |
| IAM identity to credentials stored in Dify | The access key or role used by the Dify provider should be a dedicated IAM identity with permissions limited to the Bedrock actions and models the workspace needs. Avoid reusing an administrator or a personal identity. | Security (policy design), platform team (storage in Dify) | IAM policy JSON version, identity ARN, key creation and rotation dates, access review record |
| Bedrock model IDs to chat model names in Dify | Each chat model enabled in Dify should match a Bedrock model ID that the IAM policy allows. Record the exact ID so a model name in Dify is never read as a different model. | Application owner (model choice), platform team (enablement) | List of enabled model IDs per workspace, approval ticket for each model family |
| Bedrock model IDs to embedding model names in Dify | Embedding models must be enabled separately from chat models. Changing the embedding model later affects existing knowledge base indexes, so the chosen ID needs its own approval record. | Application owner (retrieval design), security (data review) | Embedding model ID, dimension notes from the vendor documentation, index rebuild plan if changed |
| Bedrock model IDs to rerank model names in Dify | Rerank models are a separate enablement decision. Confirm in the Bedrock console and the Dify provider settings that the ID is available in the chosen region before building a workflow that depends on it. | Application owner, platform team | Confirmed model ID and region, test run output showing rerank calls succeed |
| Dify workspace to environment | Each Dify workspace that uses a Bedrock provider should map to one environment (development or production) and to one credential set. Do not let a development workspace hold production keys. | Platform team (workspace setup), application owner (sign-off) | Workspace name, environment label, credential reference, promotion record for each app |
| AWS cost and usage tags to Dify workspace | Tag the IAM identity or role and the resources used for Bedrock with the workspace and environment, so spend and usage can be traced back to each Dify workspace. | Platform team (tagging), finance (cost reporting) | Tag policy, cost allocation report filtered by tag, owner of each tag value |
| Network path to Dify egress controls | Confirm that the route from the Dify host to the Bedrock endpoint in the chosen region matches the approved network design, and that outbound requests pass the proxy settings your team has configured in Dify. | Platform team (network), security (review) | Network diagram with the endpoint path, proxy configuration reference, test connection record |
Security settings that keep Bedrock traffic inside AWS
Dify calls Amazon Bedrock with credentials you enter in its model provider settings, so the controls that matter sit in three places: the AWS identity and policy behind those credentials, how Dify stores them, and the network path from the Dify containers to Bedrock. Work through the cards in that order before the first production app goes live.
Scope IAM policies to Bedrock
Create a dedicated IAM identity for Dify whose policy allows only the Bedrock invocation actions it needs, limited to the model resources your team has approved. Avoid broad administrator or wildcard policies that would let a leaked key create resources or call unapproved models. Ask the AWS team to review the policy against the Bedrock model IDs and regions you plan to enable in Dify, since the Bedrock model provider plugin covers the full model catalog and nothing restricts it by default.
Store and rotate provider credentials
Dify keeps the Bedrock access key in its metadata database, and encrypts it using the SECRET_KEY and workspace encryption settings. Changing SECRET_KEY after deployment logs out all users, so set it once, store it in your secrets manager and keep it out of version control. Define a rotation schedule for the IAM access keys, and confirm with your security team whether short-lived role credentials are possible in your setup instead of long-term keys.
Separate identities for each environment
Give development, staging and production their own IAM identities, their own Bedrock provider entries in Dify, and their own key material. A test workspace should never hold a credential that can call production model quotas or read production logs. Confirm with your AWS team how accounts or organizational units are split across environments, because this decides which Bedrock quotas and billing each identity draws on.
Control outbound SSRF proxy routing
Dify's SSRF proxy settings route outbound requests through a proxy that blocks internal and private IP ranges. Bedrock endpoints resolve to addresses that your network may classify as private when you use VPC endpoints, so the Dify containers may not reach them through the default proxy path. Test a Bedrock call from the Dify api container before go-live, and document any allow rule you add so it stays narrow.
Choose private connectivity deliberately
Decide whether Bedrock traffic should leave the Dify host over the public internet with TLS, or travel over AWS private connectivity such as an interface VPC endpoint in the same VPC. Private paths keep model traffic off the public internet but add DNS, routing and security group work that your network team must own. Record the decision, the VPC and subnet in use, and who maintains the endpoint policy.
Confirm model call logging in AWS
Dify's own logs record app runs, but model invocation logging in AWS is a separate setting that your AWS team controls. Ask whether invocation logging is enabled for the Bedrock account, where those logs go, how long they are retained and whether prompts and completions are stored in full. Check that these logs meet your data handling rules before any regulated data reaches a prompt, and confirm who can read them.
How region and model family choices change the design
When data residency fixes the workload to one AWS region, the region becomes the main design constraint. Every Bedrock call from Dify leaves your network for that regional endpoint, so the region you choose decides where prompts, retrieved passages and completions are processed. Confirm in AWS documentation that each model you plan to enable is offered in that region and that the model's terms match your data handling requirements.
- Data location: Prompts and responses are processed in the chosen region, so document that region in your data flow records.
- Model availability: Not every model family is offered in every region. Check the Bedrock model catalog for your region before you build workflows around a specific model.
- Latency: Keep the Dify deployment and the Bedrock region close together to limit round trips on each workflow step.
- Credentials: One IAM identity and one Bedrock provider entry in Dify is the simplest layout, with separate entries per environment if you run development and production.
Before go-live, confirm the regional model list, the IAM permissions for the invoke actions you need, and whether any Dify feature sends data to a second region.",
A multi-region design is justified when failover or model availability requires more than one AWS region. It adds resilience and access to models that are only offered in some regions, but it also widens the set of places where data is processed. Your data residency rules must allow every region in the design, and each region needs its own confirmed model list.
- Data location: Each additional region is another jurisdiction for processing, so legal and compliance owners must approve the full list.
- Model availability: A model available in one region may be missing in another, so failover logic must select a model that exists in the target region.
- Latency: Cross-region calls add network delay. Users in one geography may see slower responses if traffic routes to a distant region during failover.
- Credentials: Plan one provider entry or credential set per region, with clear naming so operators know which endpoint each workflow uses.
Dify does not provide automatic cross-region failover for Bedrock calls in the sources reviewed here, so confirm how routing and failover will be implemented and tested before relying on it.
Some designs use chat, embedding and rerank models from different families, or mix Bedrock with on-premises services. This increases flexibility but multiplies the provider entries, credentials and data paths that Dify and your operators must manage. It also means the data sent to each model type may follow a different route, which matters for knowledge bases that contain sensitive content.
- Data location: Chat, embedding and rerank calls may go to different endpoints. Map each model role to its location, since embedding calls on indexed content may send document text outside your network.
- Model availability: Confirm in AWS documentation which embedding and rerank models are offered in your region, since availability differs by model type.
- Latency: Each separate call adds a hop. Rerank and embedding calls on every query can dominate response time in retrieval workflows.
- Credentials: Each provider and model role may need its own key or IAM identity, which raises the number of secrets to rotate and audit.
Before committing, list every model role, its provider, its region and its credential owner in one table, and confirm that the table matches the workspace default model settings.
A consolidated layout uses Bedrock for chat, embedding and rerank models in one region, with a single provider configuration. It reduces the number of provider entries and credentials, which simplifies rotation and audit. The trade-off is that you accept the model catalog and availability of one region, and any model not offered there must come from another provider.
- Data location: All model calls stay in one region, which keeps the data flow easy to describe to auditors.
- Model availability: You are limited to the models offered in that region, so confirm embedding and rerank options before selecting them for knowledge bases.
- Latency: Calls for all roles share the same network path, which keeps timing predictable for one region.
- Credentials: One IAM role or identity serves all roles, so scope its permissions to the specific invoke actions each role needs.
Verify that the chosen IAM identity cannot reach models or regions outside the approved list, and document that boundary.
The right layout depends on which constraint is fixed. Residency rules usually set the region set first, then model availability determines which families are possible, and resilience goals decide whether a second region is worth its added complexity. Use the situations above as a checklist rather than a single default.
- Residency first: Start with the approved regions and treat any region outside that list as out of scope.
- Model roles second: List the chat, embedding and rerank models you need and confirm each is offered in the approved regions.
- Resilience third: Decide whether failover to another region is required, and accept the added data processing scope if it is.
- Credential count: Count the provider entries and IAM identities the design creates, and confirm your team can rotate them.
- Documentation: Record the final region, model and credential table as part of the design evidence.
Before finalizing, check the current Bedrock regional model availability in the AWS documentation and the Dify Bedrock plugin notes on the Dify Marketplace.
Failures teams hit when connecting Dify to Bedrock
This table lists the connection failures teams most often meet when wiring Dify to Amazon Bedrock, with the likely cause and the first thing to check for each. Read it as a triage guide: find the symptom that matches your error, then work through the cause column before changing configuration.
| Symptom | Likely cause | Check first |
|---|---|---|
| Credentials rejected when saving the Bedrock provider | The IAM identity behind the access key lacks Bedrock invoke permissions, or the key was copied with stray spaces | Confirm the identity's policy allows the Bedrock runtime actions on the models you enabled, then re-enter the key pair in Dify |
| A Bedrock model does not appear in Dify | Model access was not granted for that model in the selected AWS region, so the account cannot see it | In the Bedrock console for the same region as the Dify configuration, confirm the model shows as access granted, then refresh the provider in Dify |
| Embedding or rerank calls fail after swapping an enabled model | The workspace or app still points to the old model ID, or the new model uses different dimensions, input limits or a different request format | Check the default embedding and rerank selections in Dify, then confirm knowledge bases were indexed with the same embedding model before querying |
| Requests time out from the plugin runtime | Outbound paths from the plugin daemon or sandbox to the Bedrock regional endpoint are blocked by firewall rules, a proxy, or egress policy | Test HTTPS from the Dify host or plugin container to the Bedrock endpoint for the chosen region, and review SSRF_PROXY and any sandbox network isolation settings |
| Calls start failing after credential rotation | Dify still holds the old access key, or the rotated key was deactivated before the new one was saved in Dify | Compare the key ID in the AWS console with the one saved in the provider settings, update Dify, then test a short completion before deactivating the old key |
| Unexpected region or data path | The provider was configured for a different region than the one where your data and approvals were planned | Confirm the region in the provider settings and in every app that uses it, and record the endpoint your network team expects |
Questions buyers ask before connecting Dify to Amazon Bedrock
How much effort is the Bedrock connection compared with the rest of a Dify deployment?
The Bedrock connection is usually a small part of the work. Most of the effort sits in the platform itself: hosting Dify, database and storage choices, backups, access control and the security review that goes with them. Connecting Bedrock means installing the Amazon Bedrock model provider plugin from the Dify Marketplace, creating AWS credentials with the right permissions, choosing a region and enabling the model families your apps need for chat, embedding and rerank. The configuration is short. The effort grows with the number of environments, the number of model families and the network and review work needed to keep traffic inside AWS. Confirm the exact steps against the plugin's current documentation before you estimate.
What does the work need from our AWS and security teams?
It needs an AWS account owner who can create an IAM identity with only the Bedrock permissions the plugin requires, and a security reviewer who approves how that credential is stored and rotated. Network staff need to confirm how Dify's outbound traffic reaches Bedrock endpoints in the chosen region, including any VPC endpoints or egress controls. Model access must be requested for each model family in the AWS console, so the account team or cloud administrator should own that step. Ask your security team to review the Dify secret handling settings alongside the AWS credential, since both sit in the same trust path.
Can our in-house platform team connect Dify to Bedrock without a partner?
Yes, a team that already runs Docker or Kubernetes, manages AWS IAM and understands secrets handling can usually do the Bedrock setup itself. The harder questions are the ones a partner is often asked to settle: which region keeps data where your policy requires, how environments are separated, who may add or change providers, and how the setup is tested and documented for auditors. If your team has no one who owns AWS IAM or outbound network policy, the gap is more likely to be ownership than the plugin configuration. Compare your internal capacity with the written scope before deciding.
What drives the cost and duration of a Bedrock integration?
The main drivers are the number of model families you enable, the number of environments such as development, staging and production, the network design and the number of review cycles. Each model family adds testing of chat, embedding or rerank behavior. Each environment needs its own credentials and configuration. A design that keeps traffic inside AWS with private endpoints takes longer to review than a simple outbound path. Ask for a quote that lists each of these as a separate line item, with the review gates and sign-off owners named. No public price or duration for this work is supplied here, so confirm figures in the written scope.
What is one-time and what recurs after a Bedrock integration goes live?
The setup work, such as the credential design, network review, environment configuration and testing, is one-time. Recurring costs have two parts. AWS bills your account for Bedrock model usage according to AWS pricing, and that cost scales with how much your apps call the models. Dify Community edition is free to self-host and is limited to a single workspace. If you need several workspaces or the Enterprise features, the Enterprise edition is custom priced, so ask the vendor for a quote. Upgrades to Dify and the plugin also recur, and the Dify release cadence is roughly monthly, so plan for regular maintenance.
Which parts of the Dify environment should we check after connecting Bedrock?
Check the settings that decide where secrets and outbound requests go. The SECRET_KEY value signs sessions and encrypts OAuth credentials, and changing it after deployment logs out all users, so set it before go-live. The SSRF_PROXY settings route outbound requests through a proxy that blocks internal and private IP ranges, which should be confirmed for the Bedrock endpoint in your region. Confirm that the AWS credential is stored in a way your security team accepts, and that the code sandbox and network isolation match your policy. Record each check so the evidence is available for review.
What should a written scope for a Bedrock integration include?
A written scope should name the Dify version and deployment method, the AWS account and region, each model family to enable for chat, embedding and rerank, and the number of environments. It should state who creates the IAM identity, who approves network changes and who owns model access requests. List the tests that prove each model works from each environment, the documentation delivered and the handover to your operators. Include the backup and upgrade steps for the platform, because Dify's Docker Compose guidance recommends a backup before every upgrade. Finally, define what is out of scope, such as AWS account setup, so both sides know where responsibility ends.
Does using Bedrock keep our data inside AWS?
Traffic from Dify to Bedrock stays inside AWS only if the network path is designed to do that and is verified. Dify sends requests to the Bedrock endpoint for the region you configure, so region choice matters for data residency. Private connectivity, such as VPC endpoints, and egress rules must be set and tested by your network team. Confirm with AWS how Bedrock handles prompts and outputs in your account and region, because that is the vendor's commitment, not something this page can state. Ask your compliance lead which evidence they need to show the path, and keep it with the configuration record.
How DeployOpen scopes and delivers the Bedrock integration
DeployOpen plans, implements, hardens, documents and supports self-hosted Dify inside your own cloud accounts, including the Amazon Bedrock model connection. We start from a written scope that names the Bedrock regions, model families, identity setup and network paths your team has approved, then build and verify the integration in your environment.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists the AWS accounts, regions and Bedrock model families each Dify workspace may use.
- We confirm how IAM credentials will be issued, stored and rotated, and who in your team approves them.
How we build
- We deploy self-hosted Dify in your infrastructure and connect the Amazon Bedrock model provider plugin from the Dify Marketplace.
- We configure chat, embedding and rerank models per workspace and test each one against your agreed use cases.
- We verify that outbound traffic follows the planned AWS network path and that SSRF controls and secrets handling match the scope.
How we hand over
- You receive documentation of the configured regions, model choices, IAM policies, network paths and secret locations.
- We provide a runbook covering key rotation, model enablement changes, backups and the upgrade steps for new Dify releases.
- Knowledge transfer sessions walk your platform and security engineers through the configuration and its verification results.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Retainer work can cover Dify version upgrades, re-checking Bedrock model access after AWS catalog changes and periodic IAM reviews.
- Compliance evidence is prepared for your assessors, while independent auditors and certification bodies issue any formal reports.
