HIPAA Compliance on AWS: What You Actually Need

If you work in healthcare IT, you have almost certainly spent hours wading through vague compliance guidance that reads like it was written by committee. And it was. HIPAA regulations are notoriously dense, and when you layer AWS infrastructure on top, the confusion multiplies. Which services can you actually use? What does the Business Associate Agreement really cover? Is encryption alone enough?

This guide strips away the legalese and gives you the practical, technical answers. Whether you are a startup building a telehealth platform or an established health system migrating to the cloud, this is what you actually need to know.

What HIPAA Actually Requires

Before diving into AWS specifics, let us level-set on what HIPAA mandates. The Health Insurance Portability and Accountability Act has two rules that matter most for technology teams: the Privacy Rule and the Security Rule.

The Privacy Rule governs who can access Protected Health Information (PHI) and under what circumstances. The Security Rule is more prescriptive: it defines administrative, physical, and technical safeguards specifically for electronic PHI (ePHI). When people talk about "HIPAA compliance on AWS," they are primarily talking about the Security Rule.

Understanding PHI

Protected Health Information is any individually identifiable health information. This includes the obvious things like medical records, lab results, and diagnoses. But it also includes less obvious data: billing records, appointment schedules, health plan enrollment data, and even IP addresses or device identifiers if they can be linked back to a patient. There are 18 specific identifiers defined by the Department of Health and Human Services (HHS). If your system touches any of them in a healthcare context, you are dealing with PHI.

Covered Entities vs. Business Associates

A Covered Entity is the organization that directly handles PHI: hospitals, clinics, insurance companies, healthcare clearinghouses. A Business Associate is any company or person that performs services for a covered entity and encounters PHI in the process. This is critical: if you are building software that processes PHI for a hospital, you are a business associate. If you host PHI on AWS, then AWS is also a business associate. Each relationship requires a Business Associate Agreement (BAA).

The AWS Shared Responsibility Model for HIPAA

AWS operates on a shared responsibility model, and understanding it is non-negotiable for HIPAA compliance. In simple terms: AWS is responsible for the security of the cloud, and you are responsible for security in the cloud.

What AWS Handles

AWS manages the physical data centers, the hypervisor layer, the global network infrastructure, and the hardware. They maintain SOC 2 reports, undergo third-party audits, and meet a wide array of compliance frameworks. Their infrastructure has been validated to support HIPAA workloads.

What You Handle

Everything above the infrastructure is your responsibility. That includes operating system patches, application-level security, network configuration (security groups, NACLs), data encryption, access control, and audit logging. If you misconfigure an S3 bucket and PHI leaks, that is on you, not AWS. If you fail to enable encryption on an RDS instance storing patient data, AWS will not stop you or alert you.

This is where many organizations get into trouble. They assume that because AWS "supports HIPAA," their workloads are automatically compliant. They are not. Having a BAA in place is step one of about fifty.

The Business Associate Agreement (BAA) with AWS

To use AWS for HIPAA workloads, you must have a signed BAA with AWS. You can configure this through the AWS Artifact console. It is a self-service process and does not require contacting an AWS sales representative, though you may want to for large-scale deployments.

What the BAA Covers

The AWS BAA specifically covers the HIPAA-eligible services listed by AWS. When you sign the BAA, AWS agrees to handle PHI processed through those eligible services in compliance with HIPAA requirements. This means AWS will apply appropriate safeguards, report security incidents, and maintain the confidentiality of PHI within those services.

What the BAA Does Not Cover

The BAA does not cover services that are not on the HIPAA-eligible list. If you use a non-eligible service to process PHI, you are on your own, legally. The BAA also does not cover your application logic, your access control decisions, or your encryption implementation. It does not replace the need for your own risk assessment. AWS is not auditing your application layer or verifying that your IAM policies are properly scoped. The BAA protects AWS. Your policies and configurations protect you.

HIPAA-Eligible AWS Services

AWS maintains an official list of HIPAA-eligible services, and it grows regularly. As of this writing, there are over 100 eligible services. Here are the ones that matter most for typical healthcare workloads:

Always verify the current eligible services list directly on the AWS HIPAA Eligible Services Reference page. Services are added regularly, and relying on outdated information is a common compliance gap.

Encryption Requirements: At Rest and In Transit

HIPAA does not technically mandate encryption. The Security Rule lists encryption as an "addressable" specification, meaning you need to either implement it or document why an equivalent alternative is in place. In practice, there is no reasonable alternative. Encryption is a baseline expectation for any auditor or regulatory body. If you are not encrypting PHI at rest and in transit, you are asking for trouble.

Encryption at Rest

Every AWS service that stores PHI should have encryption enabled. This means:

• -S3 buckets: Enable default encryption using SSE-S3, SSE-KMS, or SSE-C. For HIPAA workloads, SSE-KMS with customer-managed keys gives you the most control and the best audit trail.
• -RDS and Aurora: Enable encryption at instance creation. You cannot retroactively encrypt an unencrypted RDS instance. You would have to create an encrypted snapshot and restore from it.
• -EBS volumes: Enable default EBS encryption at the account level. This ensures every new volume is automatically encrypted.
• -DynamoDB: Encryption at rest is enabled by default using AWS-owned keys. For HIPAA workloads, switch to customer-managed KMS keys for audit visibility.

Use AWS Key Management Service (KMS) for centralized key management. Customer-managed keys (CMKs) give you control over key rotation policies, access policies, and usage auditing through CloudTrail. This is important during audits when you need to demonstrate who accessed encryption keys and when.

Encryption in Transit

All data containing PHI must be encrypted in transit. This means:

• -TLS 1.2 or higher for all API endpoints and web traffic. Terminate TLS at your load balancer at minimum, but consider end-to-end encryption to the application layer.
• -Enforce HTTPS-only on S3 bucket policies. Add a condition that denies any request where "aws:SecureTransport" is false.
• -Enforce SSL connections on RDS instances by setting the "rds.force_ssl" parameter to 1 in your parameter group.
• -Use VPC endpoints for AWS service traffic that never needs to traverse the public internet.

Access Control and IAM Best Practices for HIPAA

The HIPAA Security Rule requires that access to ePHI be limited to authorized personnel with a legitimate need. On AWS, this translates directly to IAM policy design.

Principle of Least Privilege

Every IAM user, role, and policy should grant the minimum permissions needed. This sounds obvious, but in practice most organizations we audit have at least a few overly permissive policies. Common problems include:

• -Developers with full AdministratorAccess when they only need access to specific services.
• -Lambda execution roles with "s3:*" permissions instead of access to specific buckets and actions.
• -Service accounts with long-lived access keys instead of using IAM roles with temporary credentials.

Multi-Factor Authentication

MFA should be required for all human users, with no exceptions. Use hardware tokens or virtual MFA devices. For privileged operations (account-level changes, IAM modifications, access to sensitive data stores), consider requiring MFA as a condition in IAM policies. The root account must have MFA enabled and its credentials should be locked in a physical safe. If you are using the root account for day-to-day operations, stop immediately.

Centralized Identity Management

Use AWS IAM Identity Center (formerly AWS SSO) to federate access through your organization's identity provider. This gives you centralized user lifecycle management, consistent MFA enforcement, and the ability to revoke access from a single place. Avoid creating individual IAM users wherever possible. When employees leave or change roles, access should be updated in your IdP, not manually in each AWS account.

Logging and Audit Trail Requirements

HIPAA requires you to record and examine activity in information systems that contain or use ePHI. This is one of the areas where AWS actually makes compliance easier than on-premises infrastructure, if you configure it correctly.

AWS CloudTrail

CloudTrail is the backbone of your HIPAA audit trail. Enable it in every region, even regions you do not use, because an attacker might spin up resources in an unused region. Configure a multi-region trail that delivers logs to a centralized, encrypted S3 bucket with object-level logging enabled. Enable CloudTrail Insights to detect unusual API activity patterns. Set up log file validation so you can prove that logs have not been tampered with. This is essential during audits and investigations.

Amazon CloudWatch

CloudWatch should be configured with alarms for security-relevant events: unauthorized API calls, console sign-ins without MFA, changes to security groups, changes to IAM policies, and root account usage. Create a CloudWatch dashboard for your security team that shows these events in near-real-time. Use CloudWatch Logs to aggregate application logs from your EC2 instances, containers, and Lambda functions into a searchable, centralized location.

AWS Config

AWS Config records configuration changes to your AWS resources over time. Use Config Rules to enforce compliance policies continuously. For HIPAA, you should have rules checking that S3 buckets are encrypted, EBS volumes are encrypted, security groups do not allow unrestricted inbound access, RDS instances are encrypted, and CloudTrail is enabled. When a resource drifts out of compliance, Config flags it immediately. This turns compliance from a periodic audit exercise into a continuous process.

Log Retention and Protection

HIPAA requires a six-year retention period for compliance documentation. Your audit logs should be retained for at least that long. Use S3 lifecycle policies to transition older logs to S3 Glacier for cost-effective long-term storage. Apply S3 Object Lock with a compliance retention mode to prevent anyone, including root, from deleting audit logs before the retention period expires. This is your strongest defense against log tampering.

Common HIPAA Mistakes on AWS

After years of performing compliance assessments, these are the mistakes we see most frequently. Each one can result in a violation, and several have led to significant fines in real enforcement actions.

Practical HIPAA Compliance Checklist for AWS

Use this checklist as a starting point for your compliance efforts. It is not exhaustive, but it covers the most critical technical controls.

When to Hire a Compliance Consultant

Not every organization needs outside help, but many benefit from it. Here are the situations where bringing in a consultant pays for itself:

• -First-time compliance: If this is your first time building HIPAA-compliant infrastructure on AWS, a consultant can save you months of trial and error and help you avoid costly architectural mistakes.
• -Pre-audit preparation: Before a formal compliance audit or assessment, a consultant can identify and remediate gaps that your internal team may be too close to see.
• -Complex architectures: Multi-account AWS setups, hybrid cloud environments, or architectures involving multiple third-party integrations add complexity that benefits from expert review.
• -After a security incident: If you have experienced a breach or near-miss, a consultant can help you assess the damage, meet notification requirements, and strengthen your defenses.
• -Staff limitations: If your team does not include someone with deep HIPAA and AWS expertise, a consultant bridges the gap without requiring a full-time hire.

The cost of a compliance consultant is a fraction of the cost of a HIPAA violation, which can range from $100 to $50,000 per violation (with an annual maximum of $1.5 million per violation category) under the HITECH Act. And those are just the regulatory fines. The reputational damage and operational disruption from a breach can be far more expensive.

The Bottom Line

HIPAA compliance on AWS is not a single checkbox. It is an ongoing practice that spans your technology, your processes, and your people. AWS provides the infrastructure and a solid set of tools, but the responsibility for configuring them correctly and maintaining compliance over time rests with you.

Start with the fundamentals: sign the BAA, complete your risk assessment, encrypt everything, lock down access, and log every action. Then build on that foundation with continuous monitoring, regular reviews, and a culture that treats compliance as an operational requirement rather than a periodic audit exercise.

The organizations that do this well are not the ones with the biggest budgets. They are the ones that treat compliance as inseparable from good engineering.