AWS Bedrock Signup Guide — Setting Up for HIPAA Compliance

Start here — is Bedrock even allowed for PHI?

Read this 60-second framing before you touch the console.

Yes — Amazon Bedrock is a HIPAA-eligible service. AWS lists both Amazon Bedrock and Amazon Bedrock AgentCore on its HIPAA Eligible Services Reference (the page showed a "Last Updated" date in 2026 when we checked). But "eligible" is not "compliant." You may only process, store, or transmit Protected Health Information (PHI) once all three of these are true:

Pick your path

Both paths end at the same place: Shared · Bedrock + HIPAA setup — the steps that actually make the environment HIPAA-ready.

You don't have AWS yet

Create the account and establish a secure identity foundation before enabling any service.

A1 · Create the AWS account

1. Go to portal.aws.amazon.com/billing/signup and follow the prompts. (Quickstart)
2. You'll verify by phone (a call or text with a code), choose a support plan, and add a payment method. A valid payment method is also required later for foundation-model access. (Model access)
3. The email + password you create becomes the root user — the most powerful identity in the account.

A2 · Secure the root user immediately

• Enable multi-factor authentication (MFA) on the root user. (IAM root)
• Don't create access keys for the root user.
• From here on, sign in as the admin user you create in A3 — not root.

A3 · Create an administrative user (don't work as root)

AWS best practice is to manage human access through IAM Identity Center and reserve the root user for the rare tasks that require it. (IAM root)

1. Sign in to the console as root one time to set this up.
2. Enable IAM Identity Center and create a user for yourself with an administrative permission set (or, if you use plain IAM, create an IAM admin user). Enable MFA for that user too.
3. Sign out of root. Sign back in as your new admin user for everything below.

You have AWS, but haven't enabled Bedrock

You can skip account creation. Confirm your security baseline, then enable Bedrock.

B1 · Confirm your security baseline

Before adding a service that will handle PHI, verify the fundamentals AWS recommends for data protection:

• Root user has MFA enabled and no active access keys.
• You're working as an IAM / IAM Identity Center user with least-privilege permissions, not as root.
• MFA is enabled on the identities that will touch Bedrock.
• You communicate with AWS over TLS 1.2+ (default for the console/API; required by Bedrock). (Data protection)

B2 · Decide where Bedrock will live (Region)

Bedrock is Region-specific — models and features differ by Region (commonly us-east-1 or us-west-2). Choose a Region that offers the models you need and fits your data-residency obligations, and use it consistently. (Model access)

B3 · Grant Bedrock permissions

Attach Bedrock permissions to the user/role that will operate it. The managed policy AmazonBedrockFullAccess covers setup and model-access management; scope down to least privilege for production. (Managed policy)

Shared setup — Bedrock + the HIPAA spine

These are the steps that turn an account that can open Bedrock into one that is configured to handle PHI compliantly.

S1 · Sign the AWS BAA (required before any PHI) ★

The Business Associate Addendum is accepted once, in AWS Artifact. It designates the account as one that may legally process PHI. Companies subject to HIPAA typically require this with AWS. (Artifact)

For a single account: (Artifact: account)

1. Open the AWS Artifact console.
2. In the navigation pane, choose Agreements → Account agreements tab.
3. Select the AWS BAA, choose Download agreement, accept the AWS Artifact NDA to download, and review the PDF.
4. With the agreement selected, choose Accept agreement, tick "I agree to all of these terms and conditions," and confirm Accept.

For an AWS Organization (covers all member accounts): sign in to the management account with the required AWS Artifact permissions, choose Agreements → Organization agreements, and accept — all existing and future member accounts are then covered. (Your org must have all features enabled, not just consolidated billing.) (Artifact: org)

S2 · Open Bedrock and confirm model access

Search for Amazon Bedrock in the console (in your chosen Region) to reach the Bedrock dashboard.

• In commercial AWS Regions, access to foundation models is enabled by default when your identity has the right AWS Marketplace permissions (aws-marketplace:Subscribe, Unsubscribe, ViewSubscriptions) — included in AmazonBedrockFullAccess. (Model access)
• The first time you invoke a third-party model, Bedrock auto-initiates a Marketplace subscription in the background (can take up to ~15 minutes). Verify access before production use to avoid AccessDeniedException. (Model access)
• Anthropic models require a one-time First Time Use form (company/use-case details) before first invocation — submitted once per account/Organization. (Exception: this does not apply to Anthropic models accessed through the newer bedrock-mantle endpoint.) (Model access)
• You can review and toggle access on the Model access page under Bedrock configurations.

S3 · Set your data-retention policy (the PHI control) ★

Bedrock uses a Zero Operator Access model (no service operator can read your inputs/outputs) and, by default, a Zero Data Retention posture (Abuse detection) — but retention is governed by an explicit mode you should set deliberately for PHI. (Data retention)

For a HIPAA account, set retention to none at the account (or project) level. At launch there is no console UI for this — use the API. (Data retention) Example (account-wide):

curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "mode": "none" }'

You can enforce this org-wide with a Service Control Policy that denies setting any mode other than none, so no one can weaken it:

{
  "Effect": "Deny",
  "Action": [
    "bedrock-mantle:PutAccountDataRetention",
    "bedrock-mantle:CreateProject",
    "bedrock-mantle:UpdateProject"
  ],
  "Condition": {
    "StringNotEquals": { "bedrock-mantle:DataRetentionMode": "none" }
  }
}

S4 · Turn on model-invocation logging — and secure it

HIPAA wants an audit trail, but Bedrock's invocation logs capture the full request and response, including any PHI in prompts/outputs. Logging is off by default. If you enable it, the logs live in your S3 bucket / CloudWatch group — so you must secure them. (Logging)

1. In the Bedrock console, go to Settings → enable Model invocation logging.
2. Choose data modalities to log (Text, Image, Embedding, Video) and a destination: Amazon S3, CloudWatch Logs, or both. The destination must be in the same account and Region.
3. Encrypt the destination with a KMS key (SSE-KMS on the S3 bucket; KMS on the CloudWatch log group), restrict access with IAM, disable bucket ACLs, and set a retention/lifecycle policy.

S5 · Account-wide audit logging & encryption

• AWS CloudTrail: set up a trail to record API and user activity across the account — your control-plane audit trail (who configured what). (Data protection)
• Encryption in transit: Bedrock requires TLS 1.2 (1.3 recommended); enforced by default. (Data protection)
• Encryption at rest with your KMS keys (CMK): apply customer-managed keys to the Bedrock resources that store data — model-customization jobs & custom models, agents, knowledge-base ingestion, OpenSearch vector stores, evaluation jobs — and use SSE-KMS on any S3 data (training/validation/output, knowledge-base sources). (Encryption)
• FIPS endpoints: if you require FIPS 140-3 validated cryptography, call AWS through FIPS endpoints. (Data protection)
• Never put PHI in free-text fields or tags (e.g. resource names) — AWS may use those in billing/diagnostic logs. (Data protection)
• VPC / AWS PrivateLink to keep Bedrock traffic off the public internet: create interface endpoints for the service(s) you use — bedrock (control plane), bedrock-runtime, bedrock-mantle, bedrock-agent, and bedrock-agent-runtime — plus FIPS variants bedrock-fips / bedrock-runtime-fips (FIPS endpoints exist in us-east-1, us-east-2, us-west-2, ca-central-1, and the GovCloud Regions). Attach an endpoint policy to scope access. (PrivateLink)
• Account-level monitoring (recommended): AWS Config (track configuration drift on your controls), Security Hub (aggregate compliance findings), GuardDuty (threat detection), and Amazon Macie (discover PHI sitting in S3, e.g. in logging buckets or knowledge-base sources).

S6 · Add a Guardrail to protect PHI ★

Amazon Bedrock Guardrails is a configurable safeguard layer you apply to inputs and responses. For HIPAA the key policy is the Sensitive information filter, which detects and blocks or masks PII in prompts and responses, supporting HIPAA's "minimum necessary" principle. (PII filter)

1. Create a guardrail in the Bedrock console (a working draft is created automatically; iterate in the built-in test window, then publish a version). Optionally encrypt the guardrail with your own KMS key.
2. Configure the Sensitive information filter: set each PII entity to Block or Mask (the API action is BLOCK / ANONYMIZE / NONE), and add custom regex for DOB, MRN, and any other health identifiers the built-in types miss.
3. Optionally add Content filters, Denied topics, Word filters, and Contextual grounding checks for RAG.
4. Apply the guardrail by passing its ID + version on each inference call, or evaluate text independently with the ApplyGuardrail API (works without invoking a model).

S7 · Lock down data residency (cross-Region inference) ★

Many models are invoked through cross-Region inference profiles, which can route your request — and therefore your PHI — to a different AWS Region for processing. There are two kinds, and the choice is a compliance decision: (CRIS)

• Cross-Region traffic stays on the AWS network and is encrypted in transit (it does not cross the public internet), and it can reach Regions you haven't manually enabled. (CRIS)
• Every cross-Region request is logged in CloudTrail in your source Region — check the additionalEventData.inferenceRegion field to confirm where processing actually happened. (CRIS)
• Enforce the boundary with an SCP. For Global, deny "aws:RequestedRegion": "unspecified" (optionally scoped with an ArnLike condition on the global.* inference-profile ARN — see the Global cross-Region inference page). For Geographic, your Region-exclusion SCPs must allow every destination Region in the profile, or inference fails.
• Even Geographic isn't fully single-Region for retained data: AWS states that "to the extent we store data for abuse detection, your input prompts and output results will be stored in the destination Region." So for models that retain (S3 / abuse detection), data can rest in another Region within the geography — pick a geography whose Regions all satisfy your residency rules. (Geo CRIS)

Choosing models safely for PHI

HIPAA-eligible service ≠ every model is safe for PHI. This is where most compliance mistakes happen.

• Each model declares which retention modes it allows (allowed_modes). If your effective mode (none) isn't allowed by a model, that model shows as unavailable and is blocked — which is the safe outcome. (Data retention)
• Models that share data with the provider (retained up to 30 days and shared): per AWS docs these currently require provider_data_share — Claude Mythos 5 and Claude Fable 5 (Fable 5 requires you to opt in to sharing with Anthropic to use it at all). These are unavailable under none. Don't use a share-required model for PHI unless you've arranged ZDR. (Data retention)
• Models that retain for abuse detection but do NOT share (a different, lesser regime): per AWS docs, OpenAI GPT-5.4 and GPT-5.5 retain classifier-flagged traffic up to 30 days, stored and processed by AWS and not shared with OpenAI unless you opt in. Eligible customers can request full ZDR via their account team. (Abuse detection)
• Always-on exception: regardless of retention mode, Bedrock may store and review image inputs flagged by CSAM detection and report them — a non-configurable path that applies even under none. (Abuse detection)
• Action: before sending PHI, check each model's effective mode and allowed_modes (via the models API) and confirm it supports none. Prefer models that retain nothing.

How to verify current eligibility yourself

Because the lists move, don't trust a static table — confirm at the moment you build:

• Service eligibility: check the model/service appears on the HIPAA Eligible Services Reference. HIPAA eligibility is service-wide once your BAA is executed — but a generally-available feature is only eligible "unless specifically excluded," so read the notes.
• Compliance scope & audit evidence: use AWS Services in Scope by Compliance Program and download the relevant SOC / audit reports from AWS Artifact.
• Per-model data handling: call the models API and read each model's allowed_modes — only use models for PHI whose modes include none (or that you've cleared for ZDR).
• Region availability: confirm the model is offered in your chosen, residency-appropriate Region before wiring it in.

PHI storage surfaces beyond the prompt

A single chat call isn't the only place PHI lands. If you use these Bedrock features, each is a store of PHI at rest you must encrypt and govern. (KMS support per resource type is documented on the AWS Data encryption page. (Encryption))

Your operational HIPAA duties

Configuration gets you ready; these are the ongoing obligations the BAA and HIPAA put on you, not AWS.

• Breach notification & incident response: the BAA imposes breach-notification obligations on you as the covered entity / business associate. Have an incident-response and notification plan before you go live — AWS securing the infrastructure does not discharge your duty to detect, investigate, and report. (AWS HIPAA)
• Minimum necessary & de-identification: send the least PHI required for the task, and de-identify where the use case allows. Pair this with the S6 Guardrail to strip identifiers automatically.
• Test with synthetic data first: validate prompts, RAG pipelines, and guardrails with non-PHI / synthetic data before any real PHI flows through.
• Keep account contact current & monitored: Bedrock abuse-detection and compliance requests go to your AWS account email; an unmonitored inbox can lead to suspended access. (Abuse detection)
• Re-verify over time: eligibility, models, Regions, and retention rules change — recheck the sources below periodically, not just at launch.

HIPAA-readiness checklist

For the implementer to complete and the compliance reviewer to verify. Every box maps to a step above. Boxes are interactive — tick them as you go (state isn't saved on refresh).

• AWS account exists; root user has MFA and no access keys. Path A2 / B1 — data-protection baseline.
• Day-to-day work is done as a least-privilege IAM / Identity Center user, not root, with MFA. Path A3 / B1.

• AWS BAA executed in AWS Artifact for this account (or org-wide from the management account). S1 — required before any PHI. Confirmed with legal/compliance.

• Working in a deliberately chosen, data-residency-appropriate Region. B2 / S2.
• Model access confirmed (Anthropic First-Time-Use form done if applicable). S2.

• Data-retention mode set to none at account/project level. S3 — the core PHI control. API only at launch.
• SCP/IAM enforces that retention can't be weakened below none (if org-managed). S3.
• Every model used with PHI has verified allowed_modes supporting none; no share-required model handles PHI without arranged ZDR. Choosing models safely.
• A Guardrail with a Sensitive-information filter is applied to inference / via ApplyGuardrail, with custom regex for DOB, MRN, and other health IDs (no built-in PII type covers them). S6 — minimum-necessary control.
• Masking blind spots handled: invocation logs and API traces protected separately (KMS + CloudWatch Logs data protection); raw response bodies/traces not logged in plaintext. S6 — guardrail masking doesn't reach logs/traces.

• Cross-Region inference uses a Geographic profile (not Global); SCP denies Global where residency is required. S7.
• Processing Region confirmed via CloudTrail inferenceRegion; retention destination Region accounted for. S7 / S3.

• Every feature in use (Knowledge Bases, Agents/AgentCore, fine-tuning, eval jobs, logs) has CMK encryption + access control on its data at rest. PHI storage surfaces.
• Macie (or equivalent) scans S3 buckets that could hold PHI (KB sources, log buckets). S5 / surfaces.

• Breach-notification / incident-response plan exists and owners are assigned. Operational duties.
• Minimum-necessary / de-identification practiced; pipelines tested with synthetic data before real PHI. Operational duties.
• AWS account contact email is current and actively monitored. Operational duties.

• CloudTrail trail recording account activity. S5.
• If invocation logging is on: destination encrypted with KMS, access-restricted, retention set, and the bedrock-mantle coverage gap acknowledged. S4.
• KMS customer-managed keys applied to Bedrock data resources (custom models, agents, knowledge bases, vector stores, eval jobs) and SSE-KMS on related S3 data. S5.
• TLS enforced; FIPS endpoints used if required; no PHI in tags/free-text fields. S5.

Sources

All facts in this guide were pulled from these official AWS pages on 2026-06-12. The inline links throughout the guide point to these same sources.

• AWS HIPAA Eligible Services Reference — Bedrock & Bedrock AgentCore listed; BAA required before PHI.
• Amazon Bedrock — Set up / prerequisites and Quickstart — account signup, admin user, Region.
• Amazon Bedrock — Request access to models — default access, Marketplace permissions, Anthropic First-Time-Use form.
• AWS Artifact — Managing agreements, Accept account agreement, Accept organization agreement — BAA acceptance steps.
• Amazon Bedrock — Data retention — retention modes, API config, SCP enforcement, ZDR.
• Amazon Bedrock — Abuse detection — Zero Operator Access, default Zero Data Retention, model-specific 30-day retention.
• Amazon Bedrock — Model invocation logging — off by default, S3/CloudWatch, KMS, bedrock-mantle coverage gap.
• Amazon Bedrock — Guardrails — sensitive-information filter (PII block/mask + custom regex), content/topic/word filters, contextual grounding, ApplyGuardrail API.
• Amazon Bedrock — Cross-Region inference and Geographic cross-Region inference — Geographic vs Global profiles, data residency, SCP/IAM control, CloudTrail inferenceRegion.
• Amazon Bedrock — Sensitive information filters and GuardrailPiiEntityConfig (API) — full built-in PII entity enum (no DOB / US health ID), BLOCK/ANONYMIZE/NONE actions, masking excludes logs & trace match.
• Amazon Bedrock — VPC interface endpoints (PrivateLink) — the five Bedrock endpoint services plus FIPS variants and their Regions.
• Amazon Bedrock — Data protection and Data encryption — shared responsibility, TLS, MFA, KMS/CMK, FIPS, tags warning.
• Amazon Bedrock — Compliance validation — audit reports via AWS Artifact, services-in-scope.
• Amazon Bedrock Security & Privacy and AWS blog: HIPAA compliance for generative AI on AWS — three-condition framing for HIPAA-eligible use.