The distinction between HIPAA-compliant and HIPAA-native is the difference between a legal position and an architecture. A HIPAA-compliant system is one where someone has assessed each safeguard requirement and concluded that the existing implementation satisfies it. A HIPAA-native system is one where the architecture encodes the safeguards as structural properties — where it would require deliberate effort to violate them. The OCR enforcement pattern consistently finds that HIPAA-compliant systems have gaps that HIPAA-native systems do not, and that retrofit costs three times more than native design.
The architectural decisions that determine this are made in the first two weeks of a cloud migration or greenfield build — not in the compliance review that happens six months later. This article covers the decisions that matter and the failure modes that appear when they are made incorrectly.
VPC Design: The Foundation of PHI Isolation
HIPAA Technical Safeguards (§164.312) require access controls, audit controls, integrity controls, and transmission security. The VPC architecture is the technical substrate for all four. The HIPAA-native VPC design: PHI-handling services in a private subnet with no direct internet routing, a separate subnet for bastion/jump access with MFA-enforced authentication, an isolated subnet for audit log storage with write-once configuration (S3 Object Lock or equivalent), and network flow logs enabled on all VPCs that touch PHI. VPC flow logs alone do not satisfy the audit control requirement — they capture network metadata, not application-level PHI access events — but they are necessary for the transmission security audit trail.
Encryption Architecture: KMS Key Hierarchy
§164.312(a)(2)(iv) and §164.312(e)(2)(ii) require encryption of PHI at rest and in transit. A HIPAA-native key architecture uses AWS KMS or Azure Key Vault customer-managed keys (not provider-managed), separate key hierarchies for PHI data versus application secrets, key rotation policies at annual minimum, and key access policies implementing least privilege at the key level, not just at the IAM level. The failure mode: using default AWS-managed keys because they are easier to configure, creating a key management architecture where AWS can access PHI without a BAA obligation for the key service.
BAA-covered services are not the same as HIPAA-eligible services, and HIPAA-eligible services are not the same as services configured to be HIPAA-compliant. AWS publishes a list of HIPAA-eligible services — services for which AWS will execute a BAA. Using a HIPAA-eligible service without the HIPAA-required configuration (encryption, logging, access control) does not create HIPAA compliance. It creates the legal precondition for compliance.
Audit Trail Architecture: §164.312(b)
The HIPAA Security Rule Audit Controls standard (§164.312(b)) requires systems to implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. "Record and examine" is the operative phrase — the audit trail must be queryable, not just written. The HIPAA-native audit architecture: a centralized audit log service separate from application logs, receiving structured events from every service that accesses PHI, stored with tamper-evident integrity, retained for six years per HIPAA retention requirements, with a query interface that allows identification of all PHI access by a given user within a given time window.
BAA-Covered Service Selection
The architectural discipline is to build the system using only HIPAA-eligible services for any component that touches PHI — and to make this constraint explicit in infrastructure-as-code through AWS SCPs or Azure Policy definitions that deny deployment of non-eligible services in PHI environments. The failure mode: a HIPAA-eligible architecture that uses a non-eligible service for logging, monitoring, or deployment automation, creating PHI exposure through the operational toolchain rather than the application.
- Design PHI-handling services into private subnets with no direct internet egress — NAT gateway for outbound, ALB for inbound
- Implement customer-managed KMS keys with explicit rotation policies and least-privilege access policies
- Deploy write-once audit log storage with S3 Object Lock or equivalent — separate from application logs
- Use AWS Config or Azure Policy to enforce HIPAA-eligible service usage in PHI environments
- Implement structured PHI access events at the application layer — VPC flow logs are not a substitute
- Document the BAA chain before the first PHI-handling service is deployed — not after
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.