A Business Associate Agreement (BAA) from AWS is table stakes, not a compliance certificate. The BAA documents that AWS has agreed to protect PHI within their covered services — it says nothing about how you’ve configured those services.
HIPAA compliance is about your configuration, your access controls, your audit trails, and your incident response procedures. AWS provides the tools; you’re responsible for using them correctly.
Here’s what the actual implementation looks like.
First: the BAA and covered services
AWS signs BAAs for most services that can touch PHI, but not all AWS services are covered. You must use only HIPAA-eligible services for workloads that process or store PHI.
The covered service list includes the major ones — EC2, RDS, S3, Lambda, ECS, EKS, CloudTrail, KMS, Secrets Manager, Bedrock (Claude and other models), SQS, SNS (with caveats), and many more. Notably, some analytics and ML services are not covered.
Before building, check the current HIPAA-eligible services list. It’s updated regularly. Services not on the list cannot touch PHI.
To activate your BAA: AWS Management Console → AWS Artifact → Agreements → Business Associate Addendum. You must accept it before processing any PHI.
Encryption: at rest and in transit
HIPAA requires encryption of PHI, both at rest and in transit. AWS makes this achievable but you have to turn it on.
Encryption at rest
RDS: Enable encryption at creation time. Once you create an unencrypted RDS instance, you cannot encrypt it in place — you must snapshot, copy the snapshot with encryption enabled, and restore. The encryption key should be a customer-managed KMS key (CMK), not the default AWS-managed key. CMKs give you key rotation control and audit trail.
S3: Enable server-side encryption with a CMK (SSE-KMS) on all buckets that store PHI. Set a bucket policy that explicitly denies unencrypted uploads:
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your-phi-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
}
DynamoDB: Enable encryption at rest using a CMK. Default DynamoDB encryption uses AWS-owned keys which are not customer-managed — for HIPAA workloads, use CMKs.
EBS volumes: Encrypt all EBS volumes attached to instances processing PHI. Set the account-level default to encrypt new EBS volumes automatically: EC2 Console → Settings → EBS Encryption → Enable.
Backups: Automated RDS snapshots inherit the encryption of the source database. Manual snapshots can be configured independently — ensure they use CMKs.
Encryption in transit
All data moving between services and between your application and clients must be encrypted in transit.
ALB/API Gateway: Use HTTPS only. Enforce TLS 1.2 minimum using a security policy. Redirect HTTP to HTTPS at the load balancer level rather than relying on application code.
Internal service communication: If services communicate over a VPC (Lambda → RDS, ECS → RDS), encryption in transit depends on the service. RDS supports SSL connections — enforce this at the parameter group level (rds.force_ssl = 1 for PostgreSQL). Some applications skip SSL for internal connections assuming VPC isolation is sufficient; HIPAA requires encryption regardless.
S3 bucket policy: Enforce HTTPS-only access:
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::your-phi-bucket", "arn:aws:s3:::your-phi-bucket/*"],
"Condition": {
"Bool": {"aws:SecureTransport": "false"}
}
}
Access control: least privilege with full audit trail
HIPAA’s Minimum Necessary standard requires that access to PHI is limited to what’s required for the specific job function. AWS IAM is your implementation vehicle.
IAM design for HIPAA workloads
No direct human access to PHI data. Engineers should not have IAM permissions to query production RDS instances or read production S3 buckets that contain PHI. Data access should go through the application layer. If breakglass access is needed for incident response, it should require manual approval and generate an alert.
Application roles, not users. Lambda functions, ECS tasks, and EC2 instances should use IAM roles with policies scoped to exactly what they need. A Lambda that reads from one S3 bucket and writes to DynamoDB needs those four actions — not s3:* and dynamodb:*.
Separate roles for read vs. write. Where possible, use separate IAM roles for read operations (analytics, reporting) and write operations (application writes, backups). Limits the blast radius if credentials are compromised.
MFA on all human accounts. All IAM users must have MFA enabled. Consider AWS IAM Identity Center (SSO) for managing human access rather than long-lived IAM credentials.
VPC architecture
PHI data stores should be in private subnets with no direct internet access:
Public subnet: ALB → internet (HTTPS only)
Private subnet: Application (ECS/Lambda) → no direct internet
Isolated subnet: RDS, ElastiCache → no route to internet
Application resources in private subnets communicate with S3 through a VPC Gateway Endpoint (free, no NAT traversal). External API calls go through a NAT Gateway — log these for audit purposes.
Security groups: Default-deny approach. RDS security groups should only accept connections from the application security group on the database port. Application security groups should only accept from the ALB security group on the application port.
No public RDS. The “Publicly Accessible” option on RDS should be disabled for all HIPAA workloads.
Audit logging: the non-negotiable requirement
HIPAA requires maintaining records of who accessed PHI, when, from where, and what actions they took. AWS provides the tools; you must configure them.
CloudTrail
Enable CloudTrail for all regions, all accounts, with log file validation enabled. Store logs in a dedicated S3 bucket with:
- Object lock (WORM — write once, read many) to prevent tampering
- SSE-KMS encryption
- Access logging on the bucket itself
- A bucket policy preventing deletion by anyone including account admins
{
"Effect": "Deny",
"Principal": "*",
"Action": ["s3:DeleteObject", "s3:DeleteBucket"],
"Resource": ["arn:aws:s3:::cloudtrail-logs/*", "arn:aws:s3:::cloudtrail-logs"]
}
Log retention: HIPAA requires 6 years for audit logs. Configure S3 lifecycle to transition older logs to Glacier Deep Archive after 90 days (dramatically reduces cost while maintaining retention).
Enable data event logging for S3 operations on PHI buckets. By default, CloudTrail logs management events but not S3 object access. For HIPAA, you need a record of every GetObject, PutObject, and DeleteObject on PHI storage.
AWS Config
Config records configuration changes to AWS resources — what changed, who changed it, when. Enable it in all regions with a compliance rule set covering:
s3-bucket-ssl-requests-onlyrds-storage-encryptedencrypted-volumesroot-account-mfa-enabledcloudtrail-enabled
Config findings that indicate drift from your baseline should generate alerts in Security Hub.
RDS audit logging
Enable the database audit log to track query-level access to PHI tables. For PostgreSQL on RDS: enable the pgaudit extension. For MySQL: enable the audit plugin. Log to CloudWatch Logs, not just to the RDS instance.
Bedrock invocation logging
If using Amazon Bedrock for AI features that process PHI (clinical notes, medical records), enable model invocation logging. This captures what input went to the model and what response came back — essential for HIPAA audit trail of AI-assisted PHI access.
Backups and disaster recovery
HIPAA requires the ability to restore PHI data in the event of a disaster. This means documented, tested recovery procedures.
RDS automated backups: Enable with a retention period of at least 35 days. Store backups in a different region for disaster recovery. Enable point-in-time recovery.
AWS Backup: Use AWS Backup for centralized backup management across RDS, EFS, DynamoDB, and EBS. Create a backup vault with immutable settings so backups cannot be deleted within the retention period.
DR runbook: Document the recovery time objective (RTO) and recovery point objective (RPO). Test the restoration procedure annually at minimum — a backup that’s never been restored is not a backup.
Incident response
HIPAA requires policies for detecting, responding to, and reporting breaches. AWS services support this:
GuardDuty: Enable for threat detection across your account. GuardDuty detects unusual API activity, compromised credentials, and unusual data access patterns. Alerts go to Security Hub and EventBridge.
Security Hub: Aggregates findings from GuardDuty, Config, Inspector, and Macie. Enable HIPAA best practices compliance standard for an automated check against HIPAA security safeguards.
Macie: Automatically discovers PHI in S3 buckets using ML. Essential for detecting when PHI has ended up in unexpected locations (development buckets, log buckets, etc.).
CloudWatch alarms for access anomalies: Set alarms on unusual access patterns — high volume of RDS queries from an unexpected source, large S3 data transfers, IAM policy changes on PHI-related roles.
Breach notification: HIPAA requires notification within 60 days of discovering a breach. Your incident response plan should include contact trees, documentation procedures, and the HHS notification process.
Common gaps I find in healthcare AWS environments
Encryption enabled but with wrong key type. Default AWS-managed keys don’t give you the control and audit trail that CMKs do. Not a compliance violation per se, but industry practice is CMKs for HIPAA workloads.
CloudTrail enabled but no S3 data events. Management events log API calls; data events log actual PHI access. Without data events, you don’t have a complete audit trail.
Development environments touching production PHI. Dev accounts should use synthetic data, not copies of production PHI. Separate AWS accounts for dev/staging/prod with explicit PHI boundaries.
Manual breakglass access with no alerting. If engineers can access RDS directly “for emergencies,” that access needs to be logged, alerted on, and reviewed.
No documented restoration test. Backups exist but have never been tested. HIPAA auditors ask for evidence of successful restoration testing.
Getting to compliance
HIPAA compliance on AWS is a defined scope of work. The technical configuration takes 2-4 weeks for a greenfield environment; existing environments take longer depending on how much is already in place.
I work with healthcare-adjacent startups and scale-ups to establish and validate their HIPAA AWS posture. If you’re building on Bedrock, ECS, RDS, and Lambda and need to know what the compliance baseline looks like for your architecture, let’s talk.
Nick Allevato is an AWS Certified Solutions Architect Professional with 20 years of infrastructure experience. He runs Cold Smoke Consulting, an independent AWS consulting practice.