Is AWS HIPAA Compliant? What Healthcare Practices Need to Know (2026)

AWS can be HIPAA compliant. Amazon Web Services signs a Business Associate Addendum (BAA), designates over 100 services as "HIPAA-eligible," and operates infrastructure that holds SOC 1/2/3, ISO 27001, and HITRUST CSF certifications. Patient Protect runs its entire platform on AWS — our PostgreSQL databases, application servers, encryption key management, and audit logging all sit on HIPAA-eligible AWS services inside a dedicated VPC.

But AWS being HIPAA-eligible does not make your practice HIPAA compliant. AWS provides the building blocks. You are responsible for how they are assembled, configured, and maintained. Default settings on most AWS services are not HIPAA-compliant out of the box. If you deploy an RDS database without enabling encryption at rest, or store PHI in an S3 bucket with public access, AWS will not stop you — and the compliance failure is entirely yours.

What AWS Provides for HIPAA Compliance

AWS offers a substantial set of tools, certifications, and contractual commitments that support HIPAA-compliant infrastructure. Here is what is included.

Business Associate Addendum (BAA). AWS calls its BAA a "Business Associate Addendum." You can review and accept it through AWS Artifact, a self-service compliance portal inside the AWS Management Console. The BAA must be signed before any protected health information touches any AWS service. This is not optional — it is a regulatory requirement.

100+ HIPAA-eligible services. AWS maintains a public list of services covered under the BAA. Major eligible services include EC2 (compute), S3 (storage), RDS (managed databases), Lambda (serverless compute), CloudWatch (monitoring), KMS (key management), ECS and EKS (container services), SNS (notifications), and SQS (message queuing). The list is updated regularly as AWS adds services.

AES-256 encryption at rest. S3, EBS (block storage), RDS, and other storage services support AES-256 encryption at rest. S3 now applies server-side encryption by default on new buckets, but older buckets and other services may still require manual configuration.

TLS encryption in transit. All AWS API endpoints enforce TLS. For your own applications, you are responsible for configuring TLS on load balancers, web servers, and any custom endpoints.

IAM for access control. AWS Identity and Access Management provides granular, policy-based access controls. You can define who has access to specific resources, under what conditions, and with what permissions — down to individual API actions on individual resources.

CloudTrail for audit logging. CloudTrail records API calls across your AWS account, providing the audit trail that HIPAA's administrative safeguards require. Logs can be stored in S3 and analyzed with Athena or fed into a SIEM.

VPC for network isolation. Amazon Virtual Private Cloud lets you create isolated network environments with private subnets, security groups, network ACLs, and VPN or Direct Connect for secure connectivity. PHI workloads should never sit in public subnets.

AWS Artifact for compliance documentation. Artifact provides on-demand access to AWS compliance reports, including SOC reports, ISO certifications, and the BAA itself.

Third-party certifications. AWS infrastructure is certified under SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, and HITRUST CSF. These certifications validate the physical and operational security of AWS data centers — they do not certify your application or your use of the services.

What AWS Does Not Do

AWS is infrastructure. It is not a compliance program. The distinction between "HIPAA-eligible infrastructure" and "HIPAA-compliant practice" is where most organizations create gaps that they do not discover until an audit or a breach.

AWS does not perform your risk assessment. The HIPAA Security Rule requires a thorough, current risk assessment of all systems that create, receive, maintain, or transmit ePHI. AWS covers its own infrastructure risk. Your risk assessment must cover your application architecture, your configurations, your access patterns, and your workforce.

AWS does not configure services for you. HIPAA-eligible does not mean HIPAA-configured. An S3 bucket is eligible for HIPAA workloads, but if you leave it with public read access, that is a breach waiting to happen. An RDS instance is eligible, but if you deploy it without encryption at rest or place it in a public subnet with an open security group, the eligibility is meaningless. Every service requires deliberate configuration.

AWS does not train your staff. Technical safeguards are one leg of HIPAA compliance. Administrative safeguards — including workforce training, security awareness, and documented procedures — are your responsibility. AWS has no visibility into how your staff handles PHI.

AWS does not track your BAAs with other vendors. Your practice uses more than AWS. Your EHR vendor, email provider, payment processor, scheduling software, and any other service that touches PHI each requires its own BAA. AWS tracks its BAA with you. It does not track your BAAs with anyone else.

AWS does not make non-eligible services compliant. Not every AWS service is covered by the BAA. Using a non-eligible service to process, store, or transmit PHI violates your BAA with Amazon and creates an unmitigated compliance exposure. AWS will not prevent you from sending PHI to a non-eligible service — there is no guardrail.

AWS does not monitor your application-level security. AWS secures the infrastructure layer — the physical data centers, the hypervisors, the network backbone. Everything above that is yours: your application code, your authentication logic, your session management, your input validation, your API security. A vulnerability in your application is your vulnerability, regardless of where it is hosted.

HIPAA-Eligible vs. Non-Eligible Services

This distinction matters more than most organizations realize. AWS maintains a list of HIPAA-eligible services that are explicitly covered under the BAA. Services not on that list are not covered — and using them with PHI violates the terms of your BAA.

HIPAA-eligible services include the core infrastructure most applications need: EC2, S3, RDS, Lambda, DynamoDB, API Gateway, CloudFront, ELB, Route 53, SES, SNS, SQS, CloudWatch, CloudTrail, KMS, Secrets Manager, and many others.

Non-eligible services include offerings like Amazon Mechanical Turk, some machine learning services, and various newer or experimental features that have not yet been evaluated for BAA coverage. The list changes as AWS adds services — always verify before deploying a new service in a PHI-handling workflow.

The practical rule: before any AWS service touches PHI, confirm it appears on the current HIPAA-eligible services list. If it does not, find an eligible alternative or architect around it.

Settings You Must Configure

Signing the BAA is step one. Configuring your environment is where the actual compliance work happens. These are the baseline settings, not suggestions.

• Sign the BAA in AWS Artifact — navigate to Artifact in the AWS Management Console, review the BAA, and accept it. Do this before any PHI enters your account. This is a contractual prerequisite.
• Enable encryption at rest on all storage — turn on server-side encryption for S3 buckets, enable encryption on EBS volumes, and require encryption on RDS instances. Use AWS KMS to manage encryption keys rather than relying on default AWS-managed keys when you need key rotation control and audit trails.
• Enable CloudTrail in all regions — create a trail that logs management events and data events across every region, not just the ones you are actively using. Store logs in a dedicated, encrypted S3 bucket with restricted access.
• Configure VPC with private subnets for PHI workloads — databases, application servers, and any service handling PHI should sit in private subnets with no direct internet access. Use NAT gateways for outbound traffic and load balancers in public subnets for inbound traffic.
• Enable AWS Config — AWS Config continuously evaluates your resource configurations against rules you define. Use managed rules for encryption checks, public access detection, and IAM policy validation. This gives you ongoing compliance monitoring, not just point-in-time checks.
• Use KMS for encryption key management — create customer-managed keys for PHI-related encryption. KMS provides automatic key rotation, usage logging via CloudTrail, and granular key policies that control which IAM principals can use each key.
• Set IAM policies following least privilege — no user, role, or service should have more permissions than required for its function. Avoid wildcard permissions. Use IAM Access Analyzer to identify overly permissive policies. Enforce MFA for all human users, especially those with console access.
• Enable GuardDuty for threat detection — GuardDuty analyzes CloudTrail logs, VPC Flow Logs, and DNS logs to identify malicious activity, unauthorized access attempts, and compromised instances. It runs continuously and requires no infrastructure to manage.

These settings form the technical baseline. Your compliance program must also address administrative and physical safeguards that AWS cannot provide.

How Patient Protect Uses AWS

Patient Protect runs its entire platform on AWS using HIPAA-eligible services, with a signed BAA in place. This is not theoretical architecture — it is what we operate in production every day.

Our infrastructure sits inside a dedicated VPC with private subnets. PostgreSQL databases run on RDS with AES-256 encryption at rest and TLS in transit. There are no public-facing database endpoints. Application servers run in private subnets behind an application load balancer. All encryption keys are managed through KMS with automatic rotation. CloudTrail captures every API call across the account. GuardDuty monitors for threats continuously.

We built Patient Protect this way because HIPAA compliance is not just what we sell — it is how we operate. When we tell independent practices that AWS can be configured for HIPAA compliance, it is because we have done it ourselves and maintain it every day.

Frequently Asked Questions

Is AWS HIPAA certified?

There is no such thing as "HIPAA certification" — not for AWS, not for any vendor. No government agency certifies organizations as HIPAA compliant. AWS holds third-party certifications including SOC 1/2/3, ISO 27001, and HITRUST CSF, and it aligns its HIPAA-eligible services with the requirements of the HIPAA Security Rule. But the compliance obligation ultimately falls on the covered entity — your practice.

Does AWS sign a BAA?

Yes. AWS offers a Business Associate Addendum (BAA) that you can review and accept through AWS Artifact. The BAA covers all HIPAA-eligible services and defines AWS's obligations for handling PHI on those services. You must accept the BAA before any PHI enters your AWS account.

Which AWS services are HIPAA eligible?

AWS currently designates over 100 services as HIPAA-eligible, including EC2, S3, RDS, Lambda, DynamoDB, API Gateway, CloudFront, ELB, CloudWatch, CloudTrail, KMS, SNS, SQS, SES, Secrets Manager, and many others. AWS maintains the current list at aws.amazon.com/compliance/hipaa-eligible-services-reference. Always verify before using a new service with PHI.

Is S3 HIPAA compliant?

S3 is HIPAA-eligible and covered under the AWS BAA, but it is not HIPAA-compliant by default. You must enable server-side encryption (AES-256 via SSE-S3 or SSE-KMS), block public access at the account and bucket level, configure access logging, apply least-privilege bucket policies, and enable versioning for data integrity. An S3 bucket with default settings and no access restrictions is a compliance violation, not a compliant storage solution.

Do I need AWS for HIPAA compliance?

No. HIPAA does not mandate any specific cloud provider or technology platform. You can achieve compliance on AWS, Azure, Google Cloud, or on-premises infrastructure. What matters is that your infrastructure meets the technical safeguard requirements of the Security Rule — encryption, access controls, audit logging, transmission security — and that you have a BAA with any vendor handling PHI. Patient Protect chose AWS for the depth of its HIPAA-eligible services, its certification portfolio, and the maturity of its security tooling.

---

Patient Protect runs on AWS and monitors your full compliance posture — infrastructure, policies, training, and vendor management — starting at $39/month.