On this page
Building healthcare software on AWS means protecting electronic protected health information (ePHI) to a standard auditors — and patients — can trust. AWS offers HIPAA-eligible services and a Business Associate Addendum (BAA), but compliance is a shared responsibility: AWS secures the cloud; you secure what you build and run in it. There is no such thing as a "HIPAA-certified" cloud or application. Here's the reference approach our cloud & infrastructure and HIPAA compliance teams use.
Start with the risk analysis, the BAA and eligible services
The HIPAA Security Rule requires a documented risk analysis of where ePHI lives and what threatens it, so start there. Then:
- Accept the AWS BAA (available through AWS Artifact) for every account that will store or process ePHI.
- Restrict ePHI to services on AWS's list of HIPAA-eligible services, and check that list when you adopt something new.
- Draw a data-flow diagram showing exactly where PHI enters, is stored, processed and leaves. It is the foundation of everything below — and the first thing an auditor will ask for.
Remember that the BAA chain extends beyond AWS: email, support desks, analytics, error tracking and any other vendor that might see PHI need their own BAA, or must be kept away from PHI entirely.
Separate accounts and environments
Use AWS Organizations to put ePHI workloads in dedicated production accounts, separate from development and test. Apply service control policies (SCPs) as guardrails — for example, denying the disabling of CloudTrail or restricting which regions can be used. Never copy production PHI into lower environments; use synthetic or properly de-identified data instead.
Encrypt everywhere
Under the Security Rule, encryption is an "addressable" specification — but in practice, on AWS, there is rarely a good reason not to encrypt, and doing so simplifies breach analysis.
- Encryption at rest with AWS KMS keys for RDS/Aurora, DynamoDB, S3, EBS and backups
- TLS for every connection, internal and external, with old protocol versions disabled
- Key rotation and tightly scoped key policies, so access to data also requires access to the key
Least-privilege access
Use IAM roles and IAM Identity Center (single sign-on) rather than long-lived access keys. Grant the minimum permissions needed, enforce MFA, require just-in-time elevation for production access, and review access regularly — every identity, human or machine, should be able to justify each permission it holds. Application-level access to patient records needs the same discipline, with role-based access and break-glass procedures that are logged.
Log everything, immutably
The Security Rule requires audit controls that record activity in systems containing ePHI. On AWS that typically means:
- An organisation-wide CloudTrail trail with log file validation enabled
- VPC Flow Logs, load balancer access logs and database audit logs
- Application audit logs of who viewed or changed which patient record
- Central storage in a separate log-archive account, with S3 Object Lock to prevent tampering
Auditors will ask who accessed what and when; you want that answer to be one query away. HIPAA also requires its documentation (policies, procedures, risk analyses and similar records) to be retained for six years, so plan retention deliberately.
Isolate and segment
Put ePHI workloads in private subnets with no direct internet exposure, reach AWS services through VPC endpoints, segment by function, and control traffic with security groups and network ACLs. Put a web application firewall in front of public endpoints. Defence in depth means a single misconfiguration doesn't expose data.
Back up, and prove you can restore
A contingency plan — data backup, disaster recovery and emergency-mode operation — is part of the Security Rule. Use AWS Backup with encrypted, cross-account (and ideally cross-region) copies, and run restore tests on a schedule. A backup you've never restored is a hope, not a control.
Prove it continuously
HIPAA isn't a one-time checkbox. AWS Config rules, Security Hub and GuardDuty give you continuous configuration and threat monitoring; our CloudMonitor adds CIS-style compliance scoring across accounts. Add regular vulnerability scanning and penetration testing, a documented and rehearsed incident response plan, and keep policies, risk decisions and evidence together — our GRC Platform is built for exactly that.
A HIPAA-aligned architecture protects patients first. The compliance evidence is a natural by-product of doing that well.
Moving patient data between systems as well? Our guide to HL7 vs FHIR covers the integration side, and our HL7, FHIR & EDI integration team builds interfaces that run inside the same HIPAA-aligned boundary.
Want help putting this into practice?
Talk to a senior engineer about your specific situation — no sales script.






Compliance-first delivery