AWS's HIPAA-eligible services list is not a compliance checklist. Here is what auditors actually examine, and the gaps we find most often in healthcare AWS environments.
AWS publishes a list of HIPAA-eligible services and a shared responsibility model. Healthcare IT teams often read this and conclude that using eligible services means they are HIPAA compliant. It doesn't. The HIPAA Security Rule requires specific technical safeguards regardless of which cloud provider you use. What auditors check is whether those safeguards are actually implemented, not whether you're using the right services. Here are the areas where we find gaps most frequently.
AWS CloudTrail logs API calls across your account. HIPAA requires audit controls, specifically the ability to record and examine activity in systems containing PHI. CloudTrail is how you satisfy this requirement in AWS.
The gap we find most often: CloudTrail is enabled in us-east-1 because that's where the application runs, but not in other regions. An auditor will check CloudTrail configuration account-wide. If a resource is created in eu-west-1, even temporarily, even by a developer who 'was just testing' and CloudTrail isn't enabled there, that's a finding.
Enable CloudTrail with multi-region logging and log file validation enabled. Store logs in a dedicated S3 bucket with a bucket policy that prevents deletion, and enable S3 Object Lock if your retention requirements call for it. Set retention to at least six years to meet HIPAA's record retention requirements.
Most teams encrypt their RDS database. Auditors check RDS, and also S3 buckets, EBS volumes, ElastiCache clusters, SQS queues, SNS topics, CloudWatch Logs groups, and Secrets Manager. PHI has a way of appearing in unexpected places: application logs, temporary processing queues, cached query results.
The fastest way to audit your own environment: run AWS Config with the managed rules for encryption at rest across all resource types. Review the findings. You will almost certainly find unencrypted resources you didn't know existed.
Use AWS KMS with customer-managed keys (CMKs) for resources containing PHI. This gives you key rotation control and the ability to produce key usage logs during an audit. CMK rotation should be enabled on all keys used for PHI storage.
HIPAA requires access controls that limit PHI access to the minimum necessary. In AWS, this maps to IAM policies. In practice, most healthcare AWS environments accumulate overly permissive IAM roles over time: roles with broad s3:* permissions, EC2 instance profiles with AdministratorAccess, and service accounts that were granted full access during initial setup and never tightened.
Auditors will request IAM policy documentation and review it for over-permissive access. They pay particular attention to who has access to S3 buckets and databases containing PHI.
Run IAM Access Analyzer regularly. Review the IAM Access Advisor tab for each role to see which permissions have actually been used in the last 90 days and remove the ones that haven't. For new roles, start with the minimum necessary permissions and expand only when needed. Document the rationale for sensitive permissions.
HIPAA doesn't prescribe specific network architecture, but it requires access controls that prevent unauthorized access to PHI. In AWS, VPC design is how you implement network-level access control.
Common gap: everything runs in the default VPC with no security group restrictions beyond basic port filtering. PHI workloads share network segments with development environments. There's no network ACL separation between tiers.
PHI workloads should run in private subnets with no direct internet access. Data flows to and from PHI storage should be explicitly defined in security group rules, not implicitly allowed. Development and production environments should be in separate VPCs with no peering. Document your network architecture. Auditors will ask for it.
The HIPAA Security Rule requires a documented security incident response process. Many healthcare teams interpret this as 'we will respond to incidents if they happen' rather than 'we have written procedures that define how we respond, who is responsible, and what we do about notification requirements.'
Auditors will ask to see your incident response plan. They will ask whether your team has tested it. They will look for evidence of tabletop exercises or incident simulations in the last twelve months.
Your incident response plan should cover: how you detect security incidents in your AWS environment (CloudWatch alarms, GuardDuty findings, CloudTrail alerts), how you assess whether a breach occurred, the notification timeline under HIPAA's Breach Notification Rule (60 days to notify affected individuals), and who is responsible for each step. It doesn't need to be long. It needs to be specific and practiced.
AWS requires you to sign a BAA before using HIPAA-eligible services. Most healthcare teams do this. The gap is the other vendors: analytics tools, logging services, monitoring platforms, and error tracking services that receive data from your AWS environment and may receive PHI.
Audit your vendor list against your data flows. If PHI can reach a vendor's systems, you need a BAA with them. If they don't offer a BAA, PHI cannot flow to their systems. This is non-negotiable and it's a finding auditors flag consistently.
In summary
HIPAA compliance in AWS is not a one-time project. It's a continuous state that requires regular review as your infrastructure changes. The teams that pass audits cleanly are the ones that treat compliance controls as part of their infrastructure, automated, monitored, and documented, rather than a checklist they revisit before an audit.
See it in production
HIPAA-compliant AWS infrastructure rebuilt from a standing start
Read case study →Talk to us. We will scope an engagement before any work begins.