AWS Bedrock HIPAA compliance: what the BAA covers

By Mat Steinlin, Head of Information Security

Last updated: July 2026

For teams running on AWS, Bedrock is often the most straightforward path to HIPAA-compliant AI. One AWS Business Associate Agreement covers all Bedrock-accessible models (Claude, Llama 3, Amazon Titan, Mistral, and others) without requiring separate negotiations with each underlying model provider. For teams already in an AWS enterprise agreement, the BAA path is part of standard onboarding, not a separate sales process.

The compliance setup still requires configuration. Having a BAA doesn't mean Bedrock is ready for PHI workloads out of the box.

AWS Bedrock is HIPAA-eligible

Amazon Bedrock, including Amazon Bedrock AgentCore, is listed as a HIPAA-eligible service on AWS's official reference. For organizations with an active AWS BAA, Bedrock usage is covered.

The AWS BAA process:

For enterprise customers: The AWS BAA is part of AWS's standard enterprise agreement. Organizations with an existing enterprise relationship typically have BAA terms in place already. Confirm that your current agreement covers Amazon Bedrock specifically, since the list of eligible services is updated as AWS adds new offerings.

For other customers: AWS BAA terms are available through AWS Artifact. Review and accept the BAA directly in the AWS Management Console without going through a separate sales negotiation. This is a meaningful difference from Anthropic's or OpenAI's sales-assisted processes.

What the AWS BAA covers: AWS operates as a business associate for PHI processed through HIPAA-eligible services. AWS's data handling commitments prohibit using customer data for training or improving services. AWS maintains an extensive set of compliance certifications (HITRUST, FedRAMP, SOC 1/2/3, ISO 27001) that apply to the infrastructure layer.

The multi-model advantage

The clearest practical advantage of Bedrock for healthcare teams is that one AWS BAA covers access to multiple model providers. For practitioners advising on HIPAA-compliant AI, this is typically the first recommendation: get a BAA with a cloud provider and use their hosted model solutions.

When you call Claude through the Anthropic API, you need an Anthropic BAA. When you call GPT-4 through the OpenAI API, you need an OpenAI BAA. When you access both through Bedrock, you need one AWS BAA.

One important caveat: not every model available on Bedrock is HIPAA-eligible. The AWS HIPAA Eligible Services reference lists Amazon Bedrock with an explicit exclusion: Fable and Mythos models are not covered. If you're routing PHI through Bedrock, verify that the specific model you're using appears on the eligible list before treating it as covered.

HIPAA-eligible models through Bedrock as of July 2026 include:

• Anthropic Claude (3.5 Sonnet, 3.5 Haiku, Claude 3 family)

• Meta Llama 3 (multiple sizes)

• Amazon Titan (text, embeddings, image)

• Amazon Nova Act

• Amazon Kiro (excluding Kiro Web)

• Mistral AI models

• AI21 Labs models

• Stability AI models (image generation)

Amazon Nova Act and Amazon Kiro (excluding Kiro Web) were added to the HIPAA-eligible services list in the May 2026 update.

Model availability on Bedrock typically lags a few weeks to months behind direct provider availability for new releases. If your team needs the latest model immediately on release, the direct provider API is the faster path. For teams where compliance simplicity matters more than model recency, Bedrock consolidates the BAA landscape significantly (but verify model-level eligibility before routing PHI).

Compliance configuration for Bedrock workloads

A HIPAA-eligible designation and an active BAA are the starting point. Configuring Bedrock for PHI workloads requires additional steps.

Model invocation logging. Model invocation logging is disabled by default; you must configure it. When enabled, Bedrock logs inputs, outputs, and metadata to S3 and/or CloudWatch Logs. One limitation, however, is that invocation logging only captures calls through the bedrock-runtime endpoint. Calls through other endpoints (such as the Responses API) are not currently captured. Verify which API paths your application uses before treating invocation logging as a complete audit trail. These logs will contain PHI and require encrypted storage, restricted access, and appropriate retention policies. The logging destination must itself meet HIPAA requirements.

VPC endpoints. AWS Bedrock supports VPC interface endpoints via AWS PrivateLink, keeping traffic within your AWS infrastructure and off the public internet. Recommended for any production workload that processes PHI.

IAM permissions. Bedrock API access should be granted through IAM roles with the minimum permissions required. Avoid granting bedrock:* permissions broadly. Scope by model, by action, and by environment. Access to model invocation logs requires separate IAM permissions; control these carefully.

Bedrock Guardrails as a PII pre-processing gate. For teams that need to detect or redact PHI before it reaches the model, Bedrock Guardrails can function as a PII detection layer applied at the pre-processing stage, before the LLM call. Practitioners building PHI redaction pipelines have found Bedrock Guardrails (using Claude Haiku) more reliable and lower cost than AWS Comprehend for this use case. Guardrails does not eliminate the need for application-level audit logging, but it can reduce the amount of PHI that reaches the model invocation layer in the first place.

Cross-region inference. Bedrock's cross-region inference feature improves availability and latency by routing requests to the best available region. Before enabling it for PHI workloads, verify that this is consistent with your data residency requirements and your BAA terms, since cross-region routing means PHI may be processed in regions outside your primary deployment. See Data residency in healthcare AI systems.

GuardDuty AI Protection. Amazon GuardDuty now includes AI Protection, which detects threats specific to AI workloads: anomalous model invocations, cost harvesting attacks (where an attacker forces your AI resources to consume excessive tokens and GPU time), and prompt injection attempts. It works by analyzing CloudTrail data events from Bedrock and SageMaker, which means CloudTrail data event logging for Bedrock must be enabled first. This is not on by default. Enabling GuardDuty AI Protection without also enabling the underlying CloudTrail data events will not produce useful signal. Once both are enabled, findings surface in AWS Security Hub alongside your other GuardDuty alerts.

Bedrock Agents and agentic workloads

Bedrock Agents extends Bedrock into agentic architectures: models that can execute multi-step workflows, call external APIs, query knowledge bases, and take actions on behalf of users. Amazon Bedrock AgentCore Runtime is HIPAA-eligible, so the BAA coverage that applies to standard Bedrock usage extends to agentic deployments.

The compliance requirements don't change for agentic workloads, but the compliance surface does, and it's substantially larger than model invocation alone.

What Bedrock handles for you:

• HIPAA-eligible infrastructure for agent execution under your existing AWS BAA

• Agent trace logging showing each reasoning step and tool call (valuable for debugging; must be treated as PHI data if PHI flows through the agent)

• VPC endpoint support for keeping traffic off the public internet

• IAM controls at the Bedrock API level

What you're responsible for building:

Per-action audit logging. Model invocation logging captures API-level calls to Bedrock. It does not capture what an agent did with those calls (which tool it called, what data that tool accessed, in response to which user action). For PHI workloads, you need attribution at the action level, not just the inference level.

Identity propagation across agent chains. When one agent delegates to another, or an agent calls an external tool, the original user's identity and permissions need to travel with the request. Bedrock doesn't handle this automatically. An agent that calls an external API without carrying the originating user context creates an authorization gap that isn't visible in model invocation logs.

Human-in-the-loop controls for sensitive actions. Before an agent executes an action that affects real data (writing to a database, sending a message, modifying a record) production healthcare workloads typically require an approval step. This is application logic; Bedrock provides the mechanism but not the policy.

Access control below the IAM level. IAM controls which principals can call which Bedrock APIs. It doesn't control which agent can call which tool, on which data, in which context. Scoped authorization at the tool and action level is yours to implement.

Key considerations for specific Bedrock Agents patterns:

• Each action group has its own data flow. If an agent calls an external API that receives PHI, that service may need its own BAA.

• RAG pipelines. The compliance risk doesn't sit only at model invocation. The retrieval layer itself (vector database, document ingestion pipeline, chunking logic) is where PHI exposure risk concentrates. Audit the full data path from source document to retrieved context.

• MCP-based tool-calling. For teams using MCP server integrations with Bedrock agents, the MCP security guide covers the compliance requirements for tool-calling architectures where PHI can flow through model-driven workflows.

What the AWS BAA requires of you

The AWS Business Associate Addendum (Section 4 — Your Obligations) specifies explicit customer requirements that apply to every HIPAA Account. These are not recommendations; they are conditions of the BAA.

Use only HIPAA Eligible Services for PHI. You must not include PHI in any AWS services that are not on the HIPAA Eligible Services list. The BAA explicitly requires that you "(a) not include protected health information in any Services that are not HIPAA Eligible Services."

Audit logging at the highest level. You must "utilize the highest level of audit logging in connection with your use of all HIPAA Eligible Services." Default logging configurations are frequently not the highest level — this is an explicit BAA requirement to configure logging beyond defaults.

Maximum log retention. You must "maintain the maximum retention of logs in connection with your use of all HIPAA Eligible Services." This is separate from HIPAA's six-year requirement; it requires using whatever maximum retention AWS makes available in the service.

Encryption required. You must encrypt all PHI stored in or transmitted using the services, in accordance with HHS guidance on rendering PHI unusable, unreadable, or indecipherable.

Necessary consents. You must warrant that you have obtained all necessary authorizations, consents, and permissions required under applicable law before placing PHI on the AWS network.

Breach identification responsibility. Because AWS cannot identify which individuals' PHI may be contained in your customer content, you are solely responsible for identifying which individuals may have been affected by any breach and for providing descriptions of the PHI disclosed.

What the AWS BAA doesn't cover

AWS is responsible for the infrastructure, you're responsible for everything above it. That line runs through the middle of most healthcare AI implementations.

Specifically, what remains on your plate:

• Application-level audit logging. Bedrock's model invocation logging captures API-level events. It does not replace application-level audit logs that attribute specific user actions to specific PHI interactions with specific timestamps. HIPAA's audit control requirement (45 CFR § 164.312(b)) is about your system's audit trail, not AWS's infrastructure logs.

• Log encryption and retention. Configured by you, not AWS by default.

• PHI handling before the model. What you include in the prompt is your responsibility. De-identification before the prompt is not required by HIPAA or the AWS BAA, but reduces exposure if other controls fail.

• Key management and IAM scoping. AWS IAM provides the tools; how you use them is up to you.

See What an AI BAA actually covers for the full breakdown.

The Aptible + Bedrock stack

Aptible LLM Gateway is a compliance proxy that sits between your application and your model providers. It auto-captures every prompt, response, model, key, and timestamp (no setup required) and satisfies HIPAA's audit control requirements out of the box. It also handles PHI de-identification, scoped key management, and model access policies that restrict which models any given environment can call.

For teams running on Aptible and calling AWS Bedrock, routing traffic through LLM Gateway means one Aptible BAA covers the full stack: application infrastructure, Bedrock model inference, and the compliance layer between them. You don't negotiate a separate AWS BAA for AI traffic routed through the gateway.

FAQs

Is AWS Bedrock HIPAA compliant?

Amazon Bedrock is a HIPAA-eligible service under the AWS BAA. Compliance of your full implementation still requires appropriate configuration: invocation logging, VPC endpoints, IAM scoping, and application-level audit controls.

Does the AWS BAA cover all Bedrock models?

No. The AWS HIPAA Eligible Services reference lists Amazon Bedrock with explicit exclusions: Fable and Mythos models are not HIPAA-eligible and cannot be used with PHI under the AWS BAA. For all other models on Bedrock, you have one BAA with AWS covering your usage; you do not need separate BAAs with Anthropic, Meta, or Mistral for models you access through Bedrock.

Do I need separate BAAs for each model on Bedrock?

No, for HIPAA-eligible models. One AWS BAA covers all HIPAA-eligible Bedrock usage, but verify that the specific model you're using is on the eligible list. Fable and Mythos are explicitly excluded. This is still a significant practical advantage over accessing models through their native APIs.

Is Bedrock HIPAA compliant for agentic AI workloads?

Amazon Bedrock AgentCore is listed as a HIPAA-eligible service. The compliance surface expands in agentic architectures because agents can call external tools and APIs that may themselves need BAAs. Audit each action group and external integration independently.

How do I configure AWS Bedrock for HIPAA compliance?

Confirm your AWS BAA covers Bedrock. Enable model invocation logging to an encrypted S3 bucket or CloudWatch log group with appropriate access controls and retention policies. Note that logging only captures calls through the bedrock-runtime endpoint. Configure VPC endpoints for Bedrock access. Scope IAM permissions to the minimum required. For cross-region inference, verify data residency is acceptable under your BAA terms.

How does AWS Bedrock compare to Azure OpenAI for HIPAA compliance?

Both are covered under cloud provider enterprise BAAs, both offer similar ease of BAA access for existing customers, and both provide data residency options. The primary differences are which models are available on each platform and where your infrastructure already lives. See Azure OpenAI for the comparison.

What's next

For teams building agentic AI workloads with Bedrock, the MCP security guide covers the specific compliance and security requirements for tool-calling architectures where PHI can flow through model-driven workflows.

For a comparison of Bedrock vs. Azure OpenAI for teams choosing between cloud providers, see Azure OpenAI.

For managing BAAs across Bedrock and other AI vendors in your stack, see Managing BAAs across multiple AI vendors.

__

Bedrock handles the model. The audit logging and encrypted log retention that HIPAA requires between your application and the model are still yours to build, even with the most straightforward BAA in the stack. Aptible LLM Gateway provides that layer as a managed service, with one Aptible BAA covering Bedrock alongside any other models in your stack. Talk to an engineer to see if it fits.