DevOps for Healthcare: The Infrastructure Checklist Before You Handle PHI

HIPAA compliance is often discussed as an application-layer concern — encryption in the database, audit logs in the application code, access controls in the API. These things matter, but they run on infrastructure, and infrastructure that was not designed for PHI cannot be made compliant retroactively just by adding application-layer controls. Before a single patient record is created, the infrastructure decisions that govern where PHI lives, who can access it, and how access is controlled need to be in place. Here is the checklist we follow on every healthcare project before we write a line of application code.

Cloud provider and BAA

AWS, Google Cloud, and Azure all offer Business Associate Agreements for healthcare workloads. The BAA must be signed before any PHI is stored on the platform — not after the system goes live. Each cloud provider has a list of services covered by their BAA; not every service is covered. AWS's HIPAA-eligible services include EC2, RDS, S3, Lambda, and most core services, but not every managed service. Before using any managed service (a logging platform, a third-party monitoring tool, a CDN), verify whether it is covered by your BAA or whether PHI can ever reach it. If PHI can reach a service that is not covered by a BAA, you have a compliance violation regardless of what your application code does.

Network architecture

PHI-handling systems must not be directly accessible from the public internet. This means a VPC with PHI resources in private subnets, a NAT gateway for outbound connectivity, and access to private resources only through a bastion host or VPN. Public-facing components (load balancers, API gateways) live in public subnets and communicate with private resources through security group rules. Security group rules should follow the principle of least privilege: each service is only permitted to communicate with the specific services it needs, on the specific ports it uses, nothing more.

TLS 1.2 minimum — preferably TLS 1.3 — is required for all data in transit between any two systems that handle PHI. This includes internal service-to-service communication inside the VPC, not just external-facing APIs. A patient record transmitted over HTTP between two internal services is still ePHI in transit, and the HIPAA Security Rule's transmission security requirement applies.

Encryption at rest

Every storage layer that can contain PHI must be encrypted at rest. For RDS: enable encryption at instance creation — you cannot enable encryption on an existing unencrypted RDS instance without a snapshot-and-restore. For S3: server-side encryption with AWS KMS keys, not the default S3 managed keys, so you control key rotation and can audit key usage. For EBS volumes on EC2 instances: encrypted at creation. For application-level backups: encrypted before they leave the application, not just during transit. The key management question — who can decrypt this data, under what circumstances, and how is that access logged — must be answered before you configure your KMS key policies.

Access control and identity

IAM roles, not IAM users with static credentials, for all service-to-service authentication. Static credentials get leaked in environment variables, log files, and code repositories. IAM roles with instance profiles or ECS task roles eliminate the credential management problem entirely. For human access to PHI-handling systems: MFA is required, session duration should be short (one to four hours for console sessions), and access should be granted through IAM Identity Center with approval workflows for privileged access. Log all API calls to AWS services handling PHI using CloudTrail — this is the infrastructure-level audit log that complements your application-level audit log.

Monitoring and incident response

CloudWatch alarms for anomalous PHI access patterns: a single user accessing an unusual number of patient records in a short time window, API error rates that suggest a data extraction attempt, authentication failures above a baseline threshold. GuardDuty for threat detection at the infrastructure level. A documented incident response plan that defines what constitutes a HIPAA breach, who is responsible for breach notification, and what the 60-day notification window requires. The Breach Notification Rule is not optional and the clock starts when you discover the breach — not when you finish investigating it. Know the procedure before you need it.