Reference guide
145+ AWS services are HIPAA-eligible as of 2026. This is the current list — grouped by category, with BAA execution steps, the four configuration mistakes that void coverage, and deep-dive checks for EC2, S3, RDS, and Lambda.
AWS publishes the HIPAA-eligible services list at aws.amazon.com/compliance/hipaa-eligible-services-reference. A service appearing on that list means three specific things: AWS will sign a Business Associate Agreement covering its processing of PHI, AWS has implemented controls compatible with HIPAA's Security Rule for that service, and customers may process PHI through it under that BAA.
Eligibility does not mean compliant-by-default. An eligible S3 bucket left open to the public internet is still a violation — the same way an eligible RDS database without encryption at rest is still a violation. AWS provides the substrate; the practice configures the workload.
Equally important: any service not on the eligible list cannot be used to process PHI under the AWS BAA. The most common audit findings in this category involve general-purpose ML services (raw Polly, raw Translate before they became eligible), third-party Marketplace AMIs without explicit HIPAA disclosure, and CloudWatch dimensions containing patient identifiers.
The list
Grouped by category for navigability. The authoritative list lives on AWS's reference page and updates roughly monthly — re-verify before standing up a new workload.
All major compute primitives are eligible. Dedicated tenancy has not been required since 2017 — shared tenancy is permitted with HIPAA.
Encryption at rest is required for all storage holding PHI. Default encryption should be enabled at the account level via AWS Organizations.
All managed databases are eligible. Encryption at rest must be enabled at creation — it cannot be retroactively applied without a migration.
Purpose-built for clinical and life-sciences workloads. These services received HIPAA eligibility on launch and are the default choice for new PHI pipelines.
Foundation-model access via Bedrock became HIPAA-eligible in 2024. Customer-managed encryption keys (KMS) are recommended for fine-tuned model artifacts.
TLS 1.2 minimum is required for all PHI in transit. Public-IP exposure of PHI workloads must be blocked at the VPC level.
Encryption keys for PHI should be customer-managed CMKs in KMS, not AWS-managed keys, for full audit-trail control.
Analytics services that touch PHI must inherit encryption from the underlying datastore. Cross-account access to PHI buckets requires explicit BAA scope.
Message-bus services pass PHI in payloads. Encryption at rest must be enabled per-queue or per-topic — it is not on by default.
Container images that reference PHI build steps must use private ECR repositories — public images are not eligible.
Logs and metrics that include PHI must be encrypted. CloudWatch Logs encryption is opt-in per log group.
Bulk migration of PHI requires server-side encryption on transit. DataSync and DMS encrypt by default; manual transfers do not.
Virtual desktops and app-streaming for clinicians. PHI must be persisted to managed storage, never the local instance.
The traps
Each of these has produced OCR findings against cloud-hosted practices in the past 24 months. None require sophisticated attackers — all are misconfigurations the practice could have caught at setup.
Mistake 1
An AWS service being HIPAA-eligible does not mean your use of it is HIPAA-compliant. Eligibility means the service can be configured for HIPAA use — encryption enabled, BAA executed, access controlled, audit logs retained. A default S3 bucket with public access is still a violation, even though S3 is eligible.
Mistake 2
AWS publishes the eligible-service list precisely because there are non-eligible services in the catalog. Examples that have caught practices in audit: Amazon Polly text inputs, third-party AWS Marketplace AMIs without explicit HIPAA disclosure, and CloudWatch metric dimensions containing patient identifiers. Run a quarterly scan against the published list.
Mistake 3
The AWS BAA is self-service via AWS Artifact. It must be accepted by an authorized signer — and it must be in place before the first byte of PHI hits any eligible service. A BAA executed three months after the fact does not retroactively cover prior exposure. This is one of the most common findings in OCR investigations of cloud-hosted workloads.
Mistake 4
Multi-account architectures are standard at AWS, but PHI moving across accounts requires every account in the chain to be covered. If a development account reads from a production PHI bucket, that development account also needs to be on the BAA. The same applies to vendor accounts, contractor accounts, and analytics workspaces.
BAA execution
The BAA must be accepted before the first byte of PHI hits any eligible service. It is self-service, free, and takes about ten minutes — but it is account-scoped, so multi-account architectures need the step repeated per account.
1. Sign in to AWS Artifact
AWS Artifact is the self-service portal for downloading compliance reports and accepting agreements. Access requires an IAM user with artifact:* permissions or a root account. Path: AWS Console → AWS Artifact → Agreements → AWS Business Associate Addendum.
2. Accept on behalf of the covered entity
The BAA must be accepted by someone with legal authority to bind the practice — typically the owner, managing partner, or designated compliance officer. The accepting party's name and title is recorded.
3. Designate the accounts in scope
The BAA applies to specific AWS accounts. In a multi-account architecture (recommended for any practice with non-trivial scale), accept the BAA in each account that will touch PHI — production, staging, analytics, backup. Sandbox and developer accounts not touching real PHI do not need to be on the BAA.
4. Document the date and signer
Retain a record of when the BAA was executed, by whom, and which accounts it covers. OCR audits routinely request this. AWS Artifact exposes the acceptance history, but printing or exporting the record into your compliance file is recommended.
5. Re-verify after major account changes
If your practice consolidates accounts, brings in a new MSP, or migrates to AWS Control Tower, re-verify that the BAA still covers every account holding PHI. Account creation does not automatically inherit the BAA — it must be accepted in each new account.
Deep dives
EC2, S3, RDS, and Lambda account for the majority of cloud-era OCR findings against independent practices. Each gets a specific configuration checklist below.
All instance types are eligible except the smallest burstable tiers (T1.micro, T2.nano). Dedicated tenancy is not required — shared tenancy has been HIPAA-eligible since 2017. EBS volumes must have encryption at rest enabled. Snapshots inherit encryption from the source volume but must be retained per HIPAA's six-year minimum.
Configuration checks
Eligible and ubiquitous — most PHI exposure in OCR audits of cloud workloads traces to S3 misconfiguration. Public access is the dominant failure mode. Default encryption became a baseline in 2023, but bucket policies and ACLs still allow practices to open buckets unintentionally.
Configuration checks
Encryption at rest must be enabled at instance creation — it cannot be turned on later without snapshot/restore migration. Automated backups inherit encryption from the parent instance. Performance Insights and Enhanced Monitoring must be configured to redact PHI from query samples.
Configuration checks
Eligible, but every Lambda function touching PHI logs to CloudWatch by default — and those logs must be encrypted and retention-bounded. Lambda environment variables containing PHI or BAA-scoped secrets must be encrypted via KMS, not stored as plaintext.
Configuration checks
Where this work lives
The AWS BAA is the floor. The configuration work — encryption defaults, public-access blocks, KMS key rotation, log retention, account-boundary controls — is what determines whether your AWS environment is actually HIPAA-compliant or just nominally eligible.
Patient Protect maps your AWS environment against the configuration requirements above, identifies the specific services and accounts holding PHI, verifies your BAA scope covers them, and surfaces the drift that creates OCR exposure — daily, not at audit time.
For independent practices running on AWS without a dedicated cloud-security team, the platform turns a 145-service eligibility list into an operational checklist that maps to your actual workload.
Questions
AWS publishes the current list at aws.amazon.com/compliance/hipaa-eligible-services-reference. The list updates roughly monthly as new services and instance types become eligible. As of 2026, the list includes 145+ services across compute, storage, database, networking, security, analytics, AI/ML, and healthcare-specific categories.
Yes. Eligibility means a service can be used for PHI under a BAA. Without an executed BAA, no AWS service is HIPAA-compliant for PHI processing — regardless of how the service is configured. The BAA is self-service via AWS Artifact and applies to specific accounts.
No. AWS removed the dedicated-tenancy requirement for HIPAA workloads in 2017. Shared-tenancy EC2 instances are fully eligible. The lingering belief that dedicated tenancy is required adds material cost to practices migrating to AWS for no compliance benefit.
Yes — AWS Bedrock became HIPAA-eligible in 2024. PHI sent to Bedrock for inference is covered under the BAA. Fine-tuning artifacts should be encrypted with customer-managed KMS keys. Note that the model providers (Anthropic, Meta, Mistral, Cohere, Amazon) do not see your prompts or completions — Bedrock isolates them.
Marketplace products are a separate compliance domain. The AWS BAA covers AWS services; it does not cover third-party software running on or alongside them. Each Marketplace product must be evaluated independently — most require their own BAA from the vendor before processing PHI.
New AWS services typically become HIPAA-eligible within 6-18 months of general availability, but the timing varies. Healthcare-specific services (HealthLake, HealthImaging, HealthScribe) launched as eligible on day one. Generic services follow AWS's internal certification cadence. The published reference list is authoritative.
From eligibility list to running program
The AWS BAA covers what AWS does. Patient Protect covers what your practice does on top of AWS — daily configuration drift, BAA scope tracking, encryption verification, and the audit trail OCR will ask for.
14-day free trial · Credit card required · Cancel any time
