AWS Infrastructure Controls That Satisfy HIPAA Requirements

AWS builds the vault. HIPAA compliance is what happens inside it, and that part is entirely on the customer. AWS secures the physical data centers, the hardware, and the hypervisor layer beneath every EC2 instance and every RDS database. Everything above that line, meaning configuration, access control, encryption, logging, and the audit evidence to prove all of it, falls to whoever runs the workload. A signed vendor compliance agreement doesn't hand you compliance. It hands you eligibility to build compliance on top of AWS's infrastructure, and that distinction is where a lot of healthcare IT teams get into trouble.

The stakes aren't abstract. Healthcare breaches now average $7.42 million each and take 279 days on average to identify and contain, which is nearly nine months of exposure before anyone even knows the extent of the damage. In 2024 alone, more than 700 healthcare breaches exposed 186 million records. And the industry's starkest case study is Change Healthcare: a breach attributed in part to a Citrix portal that didn't require multi-factor authentication, affecting an estimated 192.7 million people and standing as the largest healthcare data breach on record. That breach wasn't a failure of clinical judgment or provider negligence. It was an infrastructure misconfiguration, one missing control on one login portal, and it should reframe how every covered entity thinks about where its real risk sits.

What teams should do before finalization of the proposed 2026 Security Rule changes

HHS published a proposed update to the Security Rule in the Federal Register on January 6, 2025, and the comment period closed on March 7, 2025. A final rule was once expected around May 2026, but as of June 2026 it still hasn't been published. It remains a proposal, not law, and the timeline has since slipped further, with the final rule now expected around July 2027.

Worth understanding what's actually in it, though, because the direction is clear even if the date keeps moving. The NPRM would eliminate the current split between "Addressable" and "Required" implementation specifications. Encryption, MFA, and asset inventory would become mandatory for every covered entity, full stop, no more case-by-case judgment calls. It would also require annual verification that business associates still meet security standards: BAAs would carry stronger security expectations for business associates. The estimated compliance costs across regulated entities are substantial, which gives some sense of how many organizations are currently leaning on the addressable designation to avoid controls they'd otherwise have to build.

AWS's own guidance already tells customers to treat every specification as Required for new workloads, regardless of where the rule lands. That's the sound posture. The controls that satisfy MFA and encryption requirements don't get worse if the rule doesn't finalize on schedule. And to be precise about where things stand: "addressable" is still the current legal designation today, even though best practice, and AWS's own recommendation, already points the other way.

Executing the BAA through AWS Artifact before any PHI touches the environment

The BAA itself is self-service. It's available through AWS Artifact right inside the AWS Management Console, and for standard terms, no custom negotiation is needed. Click, accept, done. But it's account-specific: each AWS account that will touch PHI must be covered under an executed BAA. Any account in a multi-account setup that lacks that coverage has no legal basis to process PHI.

The BAA covers the entire account, but only for HIPAA-eligible services. Any workload in that same account using a non-eligible service needs architectural separation from the PHI data flows; it can't just sit next to protected data and hope proximity doesn't count.

Without an executed BAA, no AWS service is HIPAA-permissible for PHI, no matter how well it's configured. Perfect encryption, airtight IAM policies, six years of clean audit logs, none of it matters if the BAA was never accepted. It's the single non-technical requirement in a domain otherwise dominated by technical ones.

And given where the 2026 NPRM is headed, with stronger security expectations for business associates baked into BAA requirements, teams should start documenting their verification process now. Build it as a routine practice today, so there's no scramble later when the rule finalizes and everyone needs evidence overnight.

Which AWS services the BAA covers, and the exclusions that create exposure

More than 200 AWS services are HIPAA-eligible today. The reference list was updated February 10, 2026, adding Amazon Bedrock and Amazon Bedrock AgentCore, and the roster keeps growing as AWS rolls out new services.

The core eligible services span compute (Amazon EC2, Amazon ECS, Amazon EKS), databases (Amazon RDS across its Aurora, PostgreSQL, MySQL, SQL Server, MariaDB, and Oracle engines, plus Amazon DynamoDB), object storage (Amazon S3), serverless compute (AWS Lambda), API management (Amazon API Gateway), logging and monitoring (AWS CloudTrail, Amazon CloudWatch), healthcare-specific tools (Amazon HealthLake, Amazon Comprehend Medical, Amazon HealthImaging), messaging (Amazon SQS, Amazon SNS), and now AI and ML (Amazon Bedrock, Amazon Bedrock AgentCore).

Eligibility isn't always all-or-nothing at the service level. Some services are eligible with specific features carved out, and those carve-outs are exactly where audit failures happen. Amazon CloudFront is eligible, but excludes a specific edge delivery feature. AWS Directory Service is eligible, but excludes Simple AD. Amazon Augmented AI excludes Public Workforce and Vendor Workforce. Amazon WorkDocs excludes its Adding Controls for Deleting Previous File Version feature. A team that reads "CloudFront is HIPAA-eligible" and stops there, without checking which delivery method they're using, has already created an audit gap without realizing it.

The most common failures showing up in this category: general-purpose machine learning services getting used for PHI processing without checking eligibility first, third-party Marketplace AMIs deployed without confirming HIPAA disclosure, and CloudWatch dimensions that end up holding patient identifiers in what was supposed to be metadata.

How KMS delivers the encryption at rest and in transit that 45 CFR §164.312 requires

The regulatory anchor here splits in two. 45 CFR §164.312(a)(2)(iv) covers encryption at rest, and §164.312(e) covers encryption in transit. Both are technically "addressable" under current rules, but given the breach numbers above and the direction the 2026 NPRM is heading, treating either as optional is a bet not worth making.

NIST SP 800-111 recommends AES encryption at 128, 192, or 256-bit key lengths, using FIPS-approved cryptographic modules. One NIST guidance document on TLS configuration. 2 requires TLS 1.2 at minimum, configured with FIPS-based cipher suites, and also requires support for TLS 1.3.

For data at rest, the requirements differ service by service, and this is where configuration choices actually matter:

Amazon S3: use SSE-KMS, server-side encryption with KMS-managed keys, rather than SSE-S3. SSE-S3 encrypts, sure, but it doesn't give you the key management controls or audit capability that SSE-KMS does, and that audit trail is what a HIPAA reviewer wants to see. For Amazon RDS and Amazon EBS, encryption must be turned on when the volume or instance is created. There's no encrypting an existing unencrypted volume in place. Skipping it at launch means the fix requires migrating data to a new encrypted resource. Amazon DynamoDB: encrypts new tables at rest by default, one less thing to configure manually. Amazon EFS: needs encryption turned on explicitly. That's not automatic, since EFS requires an explicit step that RDS, EBS, and DynamoDB don't in the same way.

For data in transit: enforce TLS 1.2 as the floor at both the load balancer and the application layer. Configure S3 bucket policies to reject any request that isn't over HTTPS. Use AWS Certificate Manager to issue and manage SSL/TLS certificates on load balancers. And use VPC endpoints for S3, DynamoDB, and Secrets Manager so that traffic stays on AWS's private network instead of crossing the open internet.

VPC network architecture: isolating PHI data flows from the rest of the environment

A sound reference architecture splits into three tiers, and the logic behind the split is simple: nothing that touches PHI should be reachable from the public internet.

Public subnets, spread across multiple Availability Zones, hold the Application Load Balancers that terminate external HTTPS traffic. Private application subnets sit behind that, running EC2 instances or ECS/EKS containers with no direct route to the internet. And isolated database subnets hold RDS, Aurora, and DynamoDB, with no internet route whatsoever, reachable only from the application tier through security group rules.

Security groups enforce least-privilege access between these tiers. No wildcard ingress rules, anywhere. Each tier only talks to the tier immediately above or below it, so a compromised web server can't reach the database directly even if an attacker gets a foothold there.

VPC endpoints for S3, DynamoDB, and Secrets Manager keep that service traffic on AWS's private backbone, cutting out public internet exposure for anything PHI-adjacent. And VPC Flow Logs should be turned on across the board: they capture network traffic metadata for security analysis, and they're often the exact evidence an auditor asks for when verifying that network controls actually exist rather than just being described in a policy document somewhere.

IAM access controls: translating the minimum necessary standard into policy configuration

HIPAA's access control standard, 45 CFR §164.312(a), requires unique user identification and emergency access procedures, both of which are Required. Each of these maps cleanly onto a specific IAM or AWS Organizations construct, so there's no ambiguity about how to satisfy them technically.

The baseline posture: never use the root account for daily operations, full stop. Every human gets an individual IAM user or a federated identity, and every application or service gets an IAM role, never embedded credentials sitting in a config file somewhere. Permission boundaries cap the maximum privileges any user or role can hold. Wildcard permissions have no place in any policy touching PHI resources. And IAM Access Analyzer should run on a regular schedule, not just once during initial setup, since permissions tend to accumulate over time as people change roles and nobody goes back to clean up the old grants.

MFA is non-negotiable. Every IAM user with console access needs it enabled, and administrative privileges shouldn't be reachable without it under any circumstance. The Change Healthcare breach is the clearest illustration available of what skipping this one control actually costs: a Citrix portal without MFA became the entry point for a breach touching a substantial share of the country's population. And under the 2026 NPRM, MFA moves from addressable to explicitly mandatory, so the direction of travel is already set regardless of the final rule's timeline.

AWS Organizations Service Control Policies add a layer above all of this. SCPs can enforce guardrails that even administrators cannot override, preventing configuration changes that would undermine compliance controls. The reason this matters: SCPs sit above IAM and constrain what even an administrator can do. That's precisely the kind of guardrail auditors look for, because it removes the single point of human error or bad judgment that IAM policies alone can't fully close off.

CloudTrail, CloudWatch, and the six-year audit log requirement

45 CFR §164.312(b) requires audit controls capable of recording and examining activity in any system that touches ePHI, and HIPAA's records retention standard runs six years. Six years is a long time to keep logs intact and untampered, and the architecture has to account for that from day one.

CloudTrail needs to run in every AWS region, including ones a team doesn't believe it's actively using. A resource accidentally spun up in an unused region is one of the most common gaps auditors find, because nobody thought to check a region that "shouldn't" have anything in it. Logs should ship to a centralized S3 bucket sitting in a separate, dedicated AWS account, since that separation means the account under audit can't modify or delete its own trail. Versioning should be turned on for that log destination bucket, and retention configuration should enforce the six-year minimum automatically rather than relying on someone to remember.

CloudWatch Logs captures application-level activity from EC2, from ECS/EKS containers, and from Lambda functions. And here's a gap that occurs constantly, regardless of team size or maturity: Lambda functions that log full request payloads straight into an unencrypted CloudWatch log group expose PHI in what everyone assumed was just operational logging. CloudWatch alarms can route into SNS notifications, feeding a Slack channel or an on-call rotation the moment suspicious activity or an unexpected configuration change is detected.

VPC Flow Logs round this out, giving network-level evidence to sit alongside the API-level record CloudTrail provides. Between the two, there's a full picture of who did what and what traveled where.

AWS Config and GuardDuty: continuous compliance monitoring versus point-in-time audits

HIPAA compliance isn't a box checked once and filed away. New resources get deployed without encryption turned on. IAM policies pick up extra permissions over months of small requests nobody circles back to revoke. Logging configurations get changed, sometimes by accident, sometimes by someone troubleshooting at 2 a.m. who forgets to revert the change afterward.

A point-in-time audit catches none of that drift between review cycles. AWS Config and GuardDuty exist precisely to close that gap: Config tracks resource configuration against defined rules continuously, flagging the moment something drifts out of compliance, while GuardDuty watches for the threat activity that a static audit was never built to catch in real time. Together, they turn compliance from a once-a-year fire drill into something closer to a running measurement, which is the only version of HIPAA compliance that actually survives contact with a live, constantly changing AWS environment.