Case Study
HIPAA-Compliant Telehealth Platform on AWS: Zero-Trust Architecture in 8 Weeks
Built a HIPAA-compliant telehealth platform on AWS with zero-trust architecture, KMS encryption for all PHI, and automated compliance monitoring — from engagement to production in 8 weeks.
## Challenge: Rapid Telehealth Deployment Without Compliance Shortcuts
A regional healthcare network serving 340,000 patients across four states needed to launch a telehealth platform to extend specialist access to underserved rural communities. The clinical team had identified a critical care gap, executive leadership had committed to a launch date, and the board had approved budget. What they lacked was the cloud security architecture required to handle Protected Health Information (PHI) in compliance with HIPAA.
Three constraints defined the engagement:
**Speed without shortcuts.** The network's legal and compliance team had made clear that HIPAA compliance was non-negotiable — no "we'll fix it after launch" approach. Every architectural decision had to be made with HIPAA Security Rule requirements in place from day one.
**Existing AWS footprint.** The organization already ran administrative workloads in AWS with a basic landing zone — single account, limited IAM governance, no Security Hub baseline. The telehealth platform would be built in a new dedicated account, but it had to integrate with existing identity providers and share network infrastructure with legacy systems.
**No dedicated security team.** The network's IT team managed on-premises infrastructure competently but had no AWS security expertise. Whatever architecture was built had to be operable by a team that would learn as they went — automated where possible, with clear runbooks for the inevitable edge cases.
## Solution: HIPAA Reference Architecture with Automated Compliance
The engagement ran in two parallel tracks: security architecture design (weeks 1-3) and application infrastructure build (weeks 2-8). Both tracks converged in week 7 for integrated security validation before the week 8 production launch.
### Account and Identity Foundation
The telehealth platform runs in a dedicated AWS account within an AWS Organizations structure, isolated from administrative workloads. This separation is not bureaucratic overhead — it provides:
- **Blast radius containment.** A misconfiguration or compromise in the telehealth account cannot propagate to other accounts.
- **Independent billing.** PHI-related infrastructure costs are tracked separately for BAA compliance documentation.
- **SCPs for compliance guardrails.** AWS Organizations Service Control Policies prevent disabling of CloudTrail, deleting Security Hub findings, or creating unencrypted S3 buckets — at the organization level, not just the account level.
Identity federation uses existing Microsoft Azure AD as the identity provider, with AWS IAM Identity Center managing role assignments. Physicians, nurses, and administrative staff authenticate with their existing credentials. No separate AWS IAM users exist for human identities — only service roles for application components.
### PHI Data Architecture
PHI is stored in three locations, each with independent encryption and access controls:
**Amazon S3 (patient documents and consultation recordings):** SSE-KMS encryption with a customer-managed key. The KMS key policy grants access only to specific IAM roles — the telehealth application role, the clinical data engineering role, and the compliance team role. No human users have direct S3 access; all access flows through the application API.
**Amazon Aurora (patient records and appointment data):** RDS encryption at rest using a dedicated CMK. Encryption in transit enforced via SSL certificate validation in the application connection string. Database access is restricted to application Lambdas running in the same VPC — no direct database access from development machines or external networks.
**AWS Secrets Manager (database credentials and API keys):** Automatic rotation configured for all database credentials. Application code retrieves credentials at runtime via IAM-authenticated API calls — no credentials in environment variables, container images, or source code.
### Network Architecture: Zero-Trust VPC Design
The VPC design follows zero-trust principles — no network path is open by default, every connection is explicitly permitted:
```
Internet
│ (HTTPS only)
▼
AWS WAF + Shield Standard
│
Amazon CloudFront (HTTPS termination + WAF rules)
│
Application Load Balancer (private subnet)
│
AWS Lambda + ECS Fargate (private subnets, multiple AZs)
│
Amazon Aurora (isolated subnet, no internet route)
```
No EC2 instances have public IP addresses. No security groups permit inbound connections from 0.0.0.0/0. Lambda functions and ECS tasks communicate with AWS services (S3, Secrets Manager, KMS, SES) through VPC endpoints — no traffic leaves the AWS network.
The AWS WAF rule set includes: AWS Managed Rules (common rule group + known bad inputs), rate limiting (100 requests per minute per IP for API endpoints), and geographic restrictions. Every WAF request is logged to S3 for 7-year retention per HIPAA requirements.
### Automated Compliance Monitoring
The compliance automation layer runs continuously, not just at audit time:
**AWS Config rules** monitor 47 HIPAA-relevant configuration conditions: encryption-at-rest on all RDS instances, public access blocked on all S3 buckets, VPC flow logs enabled, CloudTrail multi-region enabled, root account MFA enabled, and more. Non-compliant resources trigger SNS alerts to the compliance team within 15 minutes.
**AWS Security Hub** aggregates findings from Config, GuardDuty, Inspector, and Macie into a single compliance view. The HIPAA standard in Security Hub is enabled, providing a scored assessment of controls. The baseline score at launch was 96/100 — the four unaddressed findings were known accepted risks documented in the risk register.
**Amazon Macie** scans S3 buckets for unintended PHI exposure — catching cases where development artifacts or test data containing real PHI (a common source of HIPAA violations) might have been uploaded to non-PHI buckets.
**AWS CloudTrail** logs all API calls, including management events and S3 data access events, to an immutable S3 bucket in a dedicated log archive account. CloudTrail logs cannot be deleted by the telehealth account administrators — only the security team account has deletion access.
### HIPAA BAA and Eligible Services
All services used in the PHI data path are HIPAA-eligible under the AWS Business Associate Agreement, signed before any PHI was processed. The BAA covers: EC2, Lambda, ECS Fargate, RDS/Aurora, S3, KMS, Secrets Manager, CloudTrail, WAF, CloudFront, API Gateway, and SES for appointment notification emails.
## Results: 8 Weeks from Kick-Off to HIPAA-Compliant Production
The telehealth platform launched on schedule with 340,000 enrolled patients able to book and attend video consultations with network specialists.
**Compliance automation eliminated audit preparation work.** The quarterly HIPAA audit, which previously required 2-3 weeks of evidence collection by the IT team, now takes 4 hours — Security Hub and Config provide automated evidence for 94% of control requirements. The compliance team downloads reports; they no longer scramble to reconstruct historical configuration states.
**Zero PHI incidents in production.** Macie, GuardDuty, and WAF have flagged and automatically remediated 3 potential incidents in the 6 months since launch — none resulted in PHI access or disclosure. GuardDuty detected one IAM credential that had been accidentally committed to a developer's public GitHub repository; the credential was automatically rotated within 8 minutes via a CloudWatch Events → Lambda → Secrets Manager rotation flow.
**The architecture scales without compliance rework.** Three additional service lines have been added since launch (behavioral health, diabetes management, cardiology remote monitoring) — each reuses the same VPC, encryption, and compliance automation foundation. Adding a new service line is configuration work, not architecture work.
The network's CISO described the outcome as "the first time we've deployed a new clinical system and felt confident in the security posture from day one, not six months after we discovered what we missed."
---
_This case study describes a composite engagement based on anonymized client work. All identifying details have been removed or modified._Challenge: Rapid Telehealth Deployment Without Compliance Shortcuts
A regional healthcare network serving 340,000 patients across four states needed to launch a telehealth platform to extend specialist access to underserved rural communities. The clinical team had identified a critical care gap, executive leadership had committed to a launch date, and the board had approved budget. What they lacked was the cloud security architecture required to handle Protected Health Information (PHI) in compliance with HIPAA.
Three constraints defined the engagement:
Speed without shortcuts. The network’s legal and compliance team had made clear that HIPAA compliance was non-negotiable — no “we’ll fix it after launch” approach. Every architectural decision had to be made with HIPAA Security Rule requirements in place from day one.
Existing AWS footprint. The organization already ran administrative workloads in AWS with a basic landing zone — single account, limited IAM governance, no Security Hub baseline. The telehealth platform would be built in a new dedicated account, but it had to integrate with existing identity providers and share network infrastructure with legacy systems.
No dedicated security team. The network’s IT team managed on-premises infrastructure competently but had no AWS security expertise. Whatever architecture was built had to be operable by a team that would learn as they went — automated where possible, with clear runbooks for the inevitable edge cases.
Solution: HIPAA Reference Architecture with Automated Compliance
The engagement ran in two parallel tracks: security architecture design (weeks 1-3) and application infrastructure build (weeks 2-8). Both tracks converged in week 7 for integrated security validation before the week 8 production launch.
Account and Identity Foundation
The telehealth platform runs in a dedicated AWS account within an AWS Organizations structure, isolated from administrative workloads. This separation is not bureaucratic overhead — it provides:
- Blast radius containment. A misconfiguration or compromise in the telehealth account cannot propagate to other accounts.
- Independent billing. PHI-related infrastructure costs are tracked separately for BAA compliance documentation.
- SCPs for compliance guardrails. AWS Organizations Service Control Policies prevent disabling of CloudTrail, deleting Security Hub findings, or creating unencrypted S3 buckets — at the organization level, not just the account level.
Identity federation uses existing Microsoft Azure AD as the identity provider, with AWS IAM Identity Center managing role assignments. Physicians, nurses, and administrative staff authenticate with their existing credentials. No separate AWS IAM users exist for human identities — only service roles for application components.
PHI Data Architecture
PHI is stored in three locations, each with independent encryption and access controls:
Amazon S3 (patient documents and consultation recordings): SSE-KMS encryption with a customer-managed key. The KMS key policy grants access only to specific IAM roles — the telehealth application role, the clinical data engineering role, and the compliance team role. No human users have direct S3 access; all access flows through the application API.
Amazon Aurora (patient records and appointment data): RDS encryption at rest using a dedicated CMK. Encryption in transit enforced via SSL certificate validation in the application connection string. Database access is restricted to application Lambdas running in the same VPC — no direct database access from development machines or external networks.
AWS Secrets Manager (database credentials and API keys): Automatic rotation configured for all database credentials. Application code retrieves credentials at runtime via IAM-authenticated API calls — no credentials in environment variables, container images, or source code.
Network Architecture: Zero-Trust VPC Design
The VPC design follows zero-trust principles — no network path is open by default, every connection is explicitly permitted:
Internet
│ (HTTPS only)
▼
AWS WAF + Shield Standard
│
Amazon CloudFront (HTTPS termination + WAF rules)
│
Application Load Balancer (private subnet)
│
AWS Lambda + ECS Fargate (private subnets, multiple AZs)
│
Amazon Aurora (isolated subnet, no internet route)No EC2 instances have public IP addresses. No security groups permit inbound connections from 0.0.0.0/0. Lambda functions and ECS tasks communicate with AWS services (S3, Secrets Manager, KMS, SES) through VPC endpoints — no traffic leaves the AWS network.
The AWS WAF rule set includes: AWS Managed Rules (common rule group + known bad inputs), rate limiting (100 requests per minute per IP for API endpoints), and geographic restrictions. Every WAF request is logged to S3 for 7-year retention per HIPAA requirements.
Automated Compliance Monitoring
The compliance automation layer runs continuously, not just at audit time:
AWS Config rules monitor 47 HIPAA-relevant configuration conditions: encryption-at-rest on all RDS instances, public access blocked on all S3 buckets, VPC flow logs enabled, CloudTrail multi-region enabled, root account MFA enabled, and more. Non-compliant resources trigger SNS alerts to the compliance team within 15 minutes.
AWS Security Hub aggregates findings from Config, GuardDuty, Inspector, and Macie into a single compliance view. The HIPAA standard in Security Hub is enabled, providing a scored assessment of controls. The baseline score at launch was 96/100 — the four unaddressed findings were known accepted risks documented in the risk register.
Amazon Macie scans S3 buckets for unintended PHI exposure — catching cases where development artifacts or test data containing real PHI (a common source of HIPAA violations) might have been uploaded to non-PHI buckets.
AWS CloudTrail logs all API calls, including management events and S3 data access events, to an immutable S3 bucket in a dedicated log archive account. CloudTrail logs cannot be deleted by the telehealth account administrators — only the security team account has deletion access.
HIPAA BAA and Eligible Services
All services used in the PHI data path are HIPAA-eligible under the AWS Business Associate Agreement, signed before any PHI was processed. The BAA covers: EC2, Lambda, ECS Fargate, RDS/Aurora, S3, KMS, Secrets Manager, CloudTrail, WAF, CloudFront, API Gateway, and SES for appointment notification emails.
Results: 8 Weeks from Kick-Off to HIPAA-Compliant Production
The telehealth platform launched on schedule with 340,000 enrolled patients able to book and attend video consultations with network specialists.
Compliance automation eliminated audit preparation work. The quarterly HIPAA audit, which previously required 2-3 weeks of evidence collection by the IT team, now takes 4 hours — Security Hub and Config provide automated evidence for 94% of control requirements. The compliance team downloads reports; they no longer scramble to reconstruct historical configuration states.
Zero PHI incidents in production. Macie, GuardDuty, and WAF have flagged and automatically remediated 3 potential incidents in the 6 months since launch — none resulted in PHI access or disclosure. GuardDuty detected one IAM credential that had been accidentally committed to a developer’s public GitHub repository; the credential was automatically rotated within 8 minutes via a CloudWatch Events → Lambda → Secrets Manager rotation flow.
The architecture scales without compliance rework. Three additional service lines have been added since launch (behavioral health, diabetes management, cardiology remote monitoring) — each reuses the same VPC, encryption, and compliance automation foundation. Adding a new service line is configuration work, not architecture work.
The network’s CISO described the outcome as “the first time we’ve deployed a new clinical system and felt confident in the security posture from day one, not six months after we discovered what we missed.”
This case study describes a composite engagement based on anonymized client work. All identifying details have been removed or modified.
Results
Build Your HIPAA-Compliant Platform on AWS
We design and deliver HIPAA-compliant AWS architectures with automated compliance monitoring — protecting PHI without slowing your product roadmap.