Signing a Business Associate Agreement with AWS is step one of HIPAA compliance, not the finish line. The BAA covers AWS's obligations as a business associate. What you build on top of AWS is your responsibility entirely.
The AWS shared responsibility model divides security into two parts: AWS secures the infrastructure (hardware, physical facilities, hypervisor). You secure everything else: operating systems, network configuration, application code, access controls, and encryption. HIPAA compliance lives almost entirely in your half of this model.
Here are the specific architectural configurations that matter.
Encryption at rest: everywhere
HIPAA requires encryption for all protected health information (PHI) at rest. On AWS, this means:
RDS: Enable encryption at rest when creating the instance (it cannot be added later without a snapshot/restore). Use AWS KMS for key management. Enable automated backups and verify that backup snapshots are also encrypted. They inherit encryption from the source instance.
S3: Enable default server-side encryption on every bucket that may contain PHI. Use SSE-KMS (not SSE-S3) so you control the encryption keys. Enable bucket versioning so you can recover from accidental deletion. Block all public access at the account level. No HIPAA-covered bucket should ever be public.
EBS volumes: Encrypt all EBS volumes attached to instances that process or store PHI. Configure your AWS account to encrypt new EBS volumes by default in Account Settings.
ElastiCache (Redis/Memcached): If you cache PHI, enable encryption at rest and in transit. Redis supports both; Memcached supports neither. Do not cache PHI in Memcached.
Encryption in transit
All PHI must be encrypted during transmission. Enforce HTTPS on all application load balancers using an SSL certificate from AWS Certificate Manager. Configure your ALB listener to redirect HTTP → HTTPS and reject any non-TLS traffic. Set a minimum TLS version of 1.2 (1.3 preferred) on your listener policy.
For internal service-to-service communication within your VPC, use TLS even if the traffic does not leave AWS's network. Force SSL on RDS connections by setting the `rds.force_ssl` parameter to 1. For services that communicate over internal APIs, use HTTPS between them.
Access controls and IAM
HIPAA requires access controls that limit PHI access to authorized users and systems. On AWS, this translates to several specific practices:
Principle of least privilege: IAM roles for your application should have permission to access only the specific resources they need. An ECS task role that needs to read from one S3 bucket should have s3:GetObject on that specific bucket ARN, not s3:* on all buckets.
No long-lived credentials: Do not use IAM access keys with secrets stored in environment variables or code. Use IAM roles for EC2 and ECS tasks instead. Credentials are rotated automatically and never leave AWS infrastructure.
MFA on all human accounts: Every IAM user and the root account must have MFA enabled. Enforce this with an IAM policy that denies all actions except enabling MFA until MFA is configured.
No root account usage: The root account should have MFA enabled and then be locked away. Daily operations use IAM users with appropriate permissions. Create a break-glass procedure for root account access.
Audit logging with CloudTrail
HIPAA requires audit controls that record and examine activity in systems containing PHI. AWS CloudTrail logs every API call in your account: who made it, when, from where, and what the result was. This is your audit log.
Configure CloudTrail with the following settings: enable in all regions (not just your primary region), enable log file validation (detects tampering), deliver logs to an S3 bucket with a separate AWS account as the owner if possible (prevents deletion by a compromised primary account), and enable CloudWatch Logs integration for real-time monitoring and alerting.
Retain CloudTrail logs for at least 6 years (HIPAA requires 6 years for documentation of required activities). S3 lifecycle policies can move logs to Glacier Instant Retrieval after 90 days to reduce storage costs while meeting retention requirements.
Network isolation
PHI should never be reachable from the public internet directly. Your architecture should have at minimum:
Public subnets: Only load balancers and NAT gateways. Nothing else should have a public IP address.
Private subnets: Application servers (ECS tasks, EC2 instances), databases, and caches. These have no inbound internet access. Outbound access goes through NAT Gateway.
Security groups: Application servers should only accept traffic from the load balancer security group. Databases should only accept traffic from application server security groups on the specific database port. No security group should have an inbound rule of 0.0.0.0/0 except load balancers on port 443.
Backup and disaster recovery
HIPAA requires contingency planning: procedures for responding to emergencies that damage systems containing PHI. On AWS, this means: automated RDS backups with a retention period of at least 35 days, EBS snapshots via AWS Backup with a defined schedule and retention policy, and S3 versioning with lifecycle rules that retain previous versions for a meaningful period.
Test restores periodically. A backup procedure that has never been verified by actually restoring from it is not a backup procedure you can depend on.
What AWS handles vs. what you handle
AWS HIPAA-eligible services include RDS, S3, EC2, ECS, Lambda, CloudWatch, CloudTrail, KMS, and others listed in the AWS HIPAA compliance documentation. Using these services under a signed BAA means AWS is responsible for the physical security, hardware maintenance, and infrastructure-level controls.
What AWS does not handle: your application's security, your IAM configuration, your encryption settings, your network architecture, your access logging, your vulnerability patching schedule, or your incident response procedures. All of these are in your half of the shared responsibility model.
A HIPAA-compliant AWS architecture is achievable for any team. It requires deliberate configuration choices at every layer, not specialized hardware or enterprise software. The work is in getting all of the details right and maintaining that configuration as the system evolves.