Deploying Claude on AWS Bedrock for HIPAA Workloads: A Reference Architecture

Why Bedrock for regulated workloads

Teams shipping AI features into regulated environments all run into the same tension. The product side wants the best available models. The compliance side wants data that does not leave the environment. The security side wants a clean audit trail. Picking a provider is no longer just a quality question. It is a boundary question.

AWS Bedrock is one of the cleanest answers for AWS-native organizations. Foundation model inference runs inside AWS. Data stays within the AWS boundary. Bedrock is HIPAA-eligible under the standard AWS Business Associate Addendum, and is in scope for SOC, ISO, CSA STAR Level 2, GDPR, and other common frameworks. The call can be routed through AWS PrivateLink VPC endpoints so nothing touches the public internet.

Same developer experience as calling an LLM provider's API directly. Very different compliance posture.

This post is a reference architecture for setting this up the right way. The details matter. A Bedrock deployment done wrong still leaks data.

The compliance prerequisites

Before touching Bedrock, make sure the base AWS account is in shape.

BAA in place. AWS provides a standard BAA through AWS Artifact. Execute it. Keep a copy with your compliance documentation.

Account structure. PHI workloads should live in a dedicated AWS account, separate from non-PHI. Use AWS Organizations and Control Tower if you have more than a few accounts.

Encryption keys. KMS keys in the same account as the workload. Customer-managed keys, not AWS-managed. Key policies that restrict access to specific roles. Rotate on a schedule.

Logging baseline. CloudTrail on all regions, logs to an S3 bucket with object lock. CloudTrail data events for the S3 buckets holding PHI. GuardDuty enabled. Security Hub aggregating findings.

These are prerequisites for any HIPAA-eligible AWS workload, not Bedrock-specific. Do not skip them.

Enabling Bedrock in the right region

Bedrock is not available in every region. For HIPAA workloads in the US, us-east-1 and us-west-2 are common defaults, both HIPAA-eligible with broad model availability. Check the Bedrock regional availability page for the current list. AWS adds eligible regions regularly, and some use cases (FedRAMP, GovCloud) have different defaults.

Enable model access. In the Bedrock console, explicitly enable the models you will use. Pick the ones that match your quality and cost requirements. Enable embedding models separately.

Disable the models you are not using. Model access is granted per-model. Teams accidentally enable too many and end up with a compliance surface they did not intend. Periodically review the enabled set and trim.

Network isolation with VPC endpoints

This is where most deployments get it wrong.

By default, calls to Bedrock go over the public internet, even from inside a VPC. Traffic is encrypted and stays within the AWS network, but the request leaves your VPC boundary. For strict environments, this is not acceptable.

The fix is a Bedrock VPC endpoint.

• Create an interface VPC endpoint for com.amazonaws.{region}.bedrock-runtime.
• Attach it to the private subnets where your application runs.
• Update the endpoint's security group to allow HTTPS from your application security groups only.
• Update your application's Bedrock client to use the VPC endpoint DNS name.

Now every Bedrock call stays on private networking. No internet gateway traversal. No NAT gateway traffic. Traffic shows up in VPC Flow Logs, which makes audit trails cleaner.

For maximum isolation, also add endpoints for bedrock, bedrock-agent-runtime, and bedrock-agent depending on which features you use.

IAM for Bedrock calls

The IAM policy pattern that audits well.

• A dedicated IAM role for each application that calls Bedrock. Not a shared role. Not an IAM user with long-lived keys.
• The role grants bedrock:InvokeModel scoped to specific model ARNs. Not bedrock:*. Not Resource: *.
• The role's trust policy restricts assumption to the specific compute service running the application (ECS task, Lambda execution role, EKS service account).
• Every call is signed with SigV4 from a role, never from a user.

A minimum policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0",
        "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0"
      ]
    }
  ]
}

Scoped to specific models. Easy to review. Easy to audit.

Logging every model call

CloudTrail logs Bedrock API calls by default, but it does not log prompt content or responses. For HIPAA workloads, you often need more.

Bedrock model invocation logging solves this.

• Enable model invocation logging in the Bedrock console.
• Send logs to CloudWatch Logs or S3. For HIPAA, S3 with object lock is typically preferred.
• Logs include the full request and response content, along with model version and invocation identifier.

This is the log stream that answers the audit question "what prompts touched PHI and what responses came back." Without it, you cannot answer that question.

A few details:

• Invocation logs are large. Size your retention and storage accordingly.
• The S3 bucket should be in the same account, with KMS encryption and object lock.
• Access to invocation logs should be tightly restricted. These contain the most sensitive data in your system.
• Set up a lifecycle policy. Invocation logs typically need to be retained for six or seven years under HIPAA, but can transition to Glacier after a shorter hot retention period.

Guardrails for safety and compliance

Bedrock Guardrails provide a policy layer between your application and the model. Useful for HIPAA workloads in two ways.

PII redaction. Configure guardrails to detect and redact PII categories before they reach the model. Redundant with your application-level redaction, which is the point. Defense in depth.

Content policies. Block topic areas the model should never respond on. Block specific harmful content categories. Enforce your acceptable use policy at the API layer, not just in application code.

Guardrails are not a substitute for prompt engineering or eval-based quality assurance. They are a backstop. Configure them, test them with adversarial inputs, and keep them tuned.

The reference architecture

Putting it all together, a HIPAA-ready Bedrock deployment looks like:

• Dedicated AWS account in AWS Organizations with SCPs blocking non-compliant regions.
• VPC with private subnets for application compute.
• Bedrock VPC endpoints for all Bedrock services the application uses.
• ECS Fargate, Lambda, or EKS for the application layer, running in private subnets.
• IAM roles scoped to specific model ARNs with no user-based credentials.
• KMS customer-managed keys for all data at rest.
• S3 buckets with object lock for document storage and invocation logs.
• Bedrock Guardrails configured for PII redaction and content policies.
• CloudTrail, VPC Flow Logs, and Bedrock invocation logs streaming to a central logging account.
• Security Hub and GuardDuty monitoring across the account.

Every layer has a specific compliance purpose. Every layer shows up in an audit response cleanly.

What this is not

This architecture is not the simplest way to ship a Claude-powered feature. If you are building a non-regulated B2B product, direct Anthropic API calls are faster to set up and have a better developer experience.

This architecture is for teams where the data boundary is the hard requirement. Healthcare with PHI. Financial services with NPI. Government with CUI. Legal work with privileged documents.

For those teams, Bedrock with the configuration above is the cleanest path to running modern AI on regulated data. The alternative is self-hosting models on EC2 or EKS, which works but is dramatically more operational overhead.

Before you deploy

A short checklist:

1. BAA executed with AWS.
2. Dedicated account with full logging baseline.
3. KMS customer-managed keys created and policies scoped.
4. VPC endpoints for Bedrock in place.
5. IAM roles scoped to specific model ARNs.
6. Model invocation logging enabled and flowing to S3 with object lock.
7. Guardrails configured and tested.
8. Runbook for incident response that references the invocation logs.

If any of those are missing, fix them before putting real PHI through the system. The cost of fixing after is always higher than the cost of fixing before.

Kai Token leads cloud AI engineering at Fraktional. Works on secure model deployment patterns for teams across regulated industries. Believes the boring details are where the compliance wins are.