AWS HIPAA Compliance: Practical Guide for 2025
Healthcare organizations moving workloads to AWS often assume that using a major cloud provider handles most of the compliance heavy lifting. It doesn't. AWS provides a platform that can be used in a HIPAA-compliant way, but the configuration decisions that determine whether your environment actually meets the Security Rule are almost entirely yours to make. AWS HIPAA compliance is ultimately a partnership between you and the cloud.
This matters because most HIPAA failures on AWS aren't caused by AWS. They're caused by misconfigured environments: an S3 bucket left public, an EBS volume without encryption, a Lambda function writing PHI to unencrypted logs, IAM permissions that grew unchecked over two years of fast hiring. A cloud audit routinely surfaces these issues in environments that passed an internal review.
Understanding where the line sits between AWS's responsibility and yours is the starting point for building something genuinely audit-ready.
The shared responsibility model, applied to HIPAA
AWS operates under a shared responsibility model. On the infrastructure side, AWS handles physical data center security, the underlying hardware, the hypervisor layer, and the compliance certifications that cover the platform itself. When you sign the Business Associate Addendum (BAA) with AWS through AWS Artifact, you're establishing the legal foundation that allows PHI to be processed on the platform at all. That step is non-negotiable and has to happen before any PHI touches the environment.
Everything above the infrastructure layer is your responsibility. Access controls, encryption configuration, audit logging, network segmentation, backup procedures, IAM policy design, and how your application code handles PHI: all of it falls on your team to implement correctly. AWS provides the tools; you determine how they're configured.
The BAA also only covers services on AWS's HIPAA-eligible list. The list is extensive and covers most common services including EC2, S3, Lambda, RDS (including Aurora), DynamoDB, API Gateway, CloudWatch, Systems Manager, VPC, EBS, SNS, SQS, Secrets Manager, Shield, and WAF. But if PHI ends up in a service that isn't on that list, you're outside the terms of the BAA regardless of what else you have in place. Building guardrails that prevent developers from inadvertently routing PHI through unapproved services is a practical necessity, not an optional hardening measure.
Encryption: the baseline requirement
HIPAA's technical safeguards require PHI to be protected both at rest and in transit. On AWS, that means a few concrete things.
For data at rest, every storage resource touching PHI needs KMS encryption: S3 buckets, EBS volumes, RDS instances, DynamoDB tables. AWS-managed KMS keys with automatic rotation are sufficient for most healthcare workloads. Customer-managed keys add operational complexity and are worth the tradeoff only when your security program or auditors specifically require them.
For data in transit, TLS 1.2 is the floor. Communications between services within your VPC should use VPC endpoints or AWS PrivateLink rather than traversing the public internet, both for security posture and to support network segmentation requirements.
The gaps we see most often: EBS volumes attached to EC2 instances that were provisioned before encryption was enforced as a default, Lambda functions logging request payloads (which may contain PHI) to CloudWatch without log encryption, and RDS snapshots not covered by the same encryption policy as the live database.
IAM and access controls
HIPAA requires that access to PHI be limited to people and systems that actually need it. In practice, IAM is where healthcare environments accumulate the most risk over time. Permissions get granted during a fast sprint, the project ends, and nobody revisits the policy. A developer gets broad access to troubleshoot something in production and it never gets narrowed back down. A service account that started with read access gets write permissions added and they never come off.
The structural fixes are straightforward, though enforcing them consistently requires discipline or automation. IAM roles rather than long-lived access keys for all workloads. MFA required for every human user without exception. IAM Access Analyzer running continuously to surface policies that grant broader access than intended. AWS SSO or an identity provider like Okta or Azure AD handling authentication rather than managing credentials directly in IAM.
Least privilege sounds simple until you're looking at a 200-line IAM policy that nobody on the current team wrote. A systematic permissions audit, either as part of a broader cloud audit or as a standalone exercise, is usually the fastest way to understand the actual exposure.
Network segmentation
HIPAA auditors expect to see PHI workloads isolated from general traffic. On AWS, that means PHI should live in private subnets within dedicated VPCs. Security groups should be configured to the minimum required access, not left open to broad CIDR ranges because it was easier during development. NACLs add a second layer of traffic control at the subnet boundary.
EC2 instances handling PHI should not have public IP addresses unless there's a specific requirement that can't be met any other way. VPC endpoints for S3, DynamoDB, and Secrets Manager keep that traffic on AWS's private network rather than routing it out and back through the internet.
The network segmentation requirement isn't purely about preventing external attackers. It's also about limiting the blast radius if something else in your environment is compromised. A well-segmented network means a breach in one area doesn't automatically mean access to PHI.
Logging, monitoring, and the six-year retention requirement
HIPAA requires audit logs covering access to PHI, and those logs need to be retained for six years. On AWS, the foundation is CloudTrail enabled across every region (not just the regions you think you're using), with logs shipped to an S3 bucket in a separate account where they can't be modified or deleted by the same principals who might want to cover their tracks.
CloudWatch handles application and infrastructure logs. GuardDuty provides continuous threat detection against your CloudTrail and VPC flow logs. AWS Config tracks configuration changes and can alert when resources drift from compliant states. Security Hub aggregates findings across these tools into a single view.
Six years of log retention is longer than most teams plan for. The practical implication is that log storage costs need to be accounted for from the beginning, and S3 lifecycle policies need to be set up to transition older logs to cheaper storage tiers rather than deleting them.
Backups and disaster recovery
PHI availability is a HIPAA requirement, not just a reliability concern. Your backup strategy needs to cover RDS automated backups, EBS snapshots, S3 versioning, and cross-region replication for anything critical. Multi-AZ deployment for databases is the baseline for production workloads.
The part that gets skipped most often is testing. A backup that has never been restored is an untested hypothesis. Recovery time objectives documented in a DR plan that was never exercised are aspirational, not verified. HIPAA auditors will ask how you know your backups work. "We set them up" is not a complete answer.
Documentation
HIPAA compliance requires both implementation and documentation. Architecture diagrams, data flow diagrams that show where PHI moves through your systems, access control policies, incident response procedures, backup and DR plans, risk assessments: all of it needs to exist, be current, and be reviewed at least annually.
The documentation requirement is where engineering teams often underinvest. Building a compliant environment without maintaining the documentation to support it creates a compliance gap that shows up during audits even when the technical controls are solid.
Common mistakes worth knowing about
Across the HIPAA environments we've reviewed, a few issues come up repeatedly regardless of team size or how long the organization has been on AWS:
S3 buckets that were public at some point and never locked down. EBS volumes attached to instances that predate the account's encryption policy. Lambda functions writing full request payloads, including PHI, to unencrypted CloudWatch log groups. IAM permissions that accumulated over years of growth and were never audited. DR plans that exist in a document somewhere but have never been tested against real infrastructure.
None of these reflect carelessness. They reflect the reality that compliance work competes with product work, and the gaps accumulate when there's no structured process for finding them.
Getting your environment audit-ready
If you're preparing for a HIPAA audit or HITRUST certification, or if you simply haven't had a thorough security review of your AWS environment recently, a free cloud audit is a practical starting point. We review your environment against common risk areas including security posture, IAM configuration, encryption coverage, logging completeness, and backup and DR posture, and produce a prioritized action plan covering where PHI is at risk and what to address first.
Get in touch to get started.
