HIPAA-Compliant Cloud Architecture on AWS

HIPAA compliance is not a feature. It’s an architectural constraint.

If you’re a Series A–C health tech founder or CTO, you’re juggling speed, runway, and enterprise sales cycles. Meanwhile, every provider prospect asks the same question: “Walk me through your security architecture.” If the answer is “we’re on AWS and everything is encrypted,” you will lose credibility fast.

We’ve seen this repeatedly. Teams ship fast on a default AWS account, then scramble when the first enterprise prospect sends a 200-question security questionnaire. Refactoring IAM, network design, logging, and key management after production traffic is painful—and expensive.

This is the architecture we recommend, the tradeoffs you’ll face, and how our team at AST builds HIPAA-compliant environments that don’t collapse under real audit pressure.

The Core Problem: Speed vs. Audit-Ready Security

From the buyer’s perspective, the tension is simple:

• You need to ship features weekly.
• You need to pass SOC 2 and handle PHI.
• You need to answer security reviews from hospital IT teams.

The technical risk isn’t a single misconfigured S3 bucket. It’s architectural sprawl: shared environments, over-permissioned IAM roles, no separation between dev and prod, weak logging, ad-hoc secrets management.

When AST builds cloud foundations for clinical software companies—including systems currently serving 160+ respiratory care facilities—the goal is simple: no architectural regrets at Series B.

Four HIPAA-Ready AWS Architecture Patterns

There is no single “HIPAA architecture.” There are patterns, each with different blast-radius and operational tradeoffs.

1. Hardened Single-Account VPC

This is the minimum viable serious setup:

• Private subnets for app and database tiers
• Public subnets only for load balancers
• KMS-backed encryption for RDS, EBS, S3
• Strict security groups and NACLs
• IAM roles with least privilege
• CloudTrail + centralized CloudWatch logs

This can be HIPAA-compliant if you sign a BAA, restrict access, and maintain audit logs. But blast radius is shared across environments. One IAM mistake can affect production.

2. Multi-Account Architecture (Recommended by Series B)

Separate AWS accounts for:

• Production
• Staging
• Development
• Security/Logging

Use AWS Organizations with SCPs (Service Control Policies) to enforce guardrails globally. Centralize logs into a dedicated security account. Enforce MFA and SSO federation for all human access.

We’ve migrated multiple startups from single-account to multi-account setups mid-flight. The common issue: undocumented IAM sprawl and hardcoded secrets. If you think you’ll need this later, build it early.

3. Control Tower Landing Zone

For companies targeting large health systems, start with AWS Control Tower:

• Automated account vending
• Preconfigured guardrails
• Centralized logging
• Built-in compliance alignment

Pair this with infrastructure as code (Terraform or CloudFormation) to ensure environments are reproducible. This is heavier operationally but pays off when you pursue HITRUST or large enterprise contracts.

4. Containerized + Zero Trust Access

For teams running EKS or ECS:

• Private cluster endpoints
• Network policies between services
• Secrets via AWS Secrets Manager
• Pod-level IAM roles (IRSA)

Do not rely solely on perimeter-based VPC security. In multi-tenant clinical applications, service-to-service controls matter as much as external firewalls.

Core Controls You Cannot Skip

Regardless of pattern, your HIPAA-compliant AWS architecture must include:

• Encryption at rest and in transit: KMS-managed keys, enforced TLS 1.2+
• Audit logging: CloudTrail (all regions), immutable log storage
• Centralized secrets: No environment variables committed anywhere
• Backup + disaster recovery: Cross-region replication for critical PHI
• Access governance: SSO, enforced MFA, short-lived credentials
• Continuous compliance scanning: AWS Config, Security Hub

On one recent engagement, we re-architected a clinical platform that had grown organically over three years. Within eight weeks, we moved them to multi-account isolation, centralized logs, enforced encryption everywhere, and automated security checks—without interrupting customer traffic.

How AST Designs HIPAA-Ready AWS Foundations

We don’t treat cloud architecture as a ticket queue. Our pod model means your DevOps engineer, backend developers, QA lead, and product owner operate as a single delivery unit.

Practically, that means:

• Infrastructure as code reviewed like application code
• Environment parity between staging and production
• Automated security regression testing
• Documented threat models alongside system diagrams

In one revenue cycle platform we built, early investment in segmentation and IAM design reduced enterprise security review turnaround time from weeks to days. That’s not theoretical benefit—that’s faster revenue.

Decision Framework: What Should You Implement Now?

1. Assess PHI Exposure Are you storing, transmitting, or processing PHI directly? If yes, assume full HIPAA scope.
2. Map Customer Targets Selling to small practices differs from selling to integrated delivery networks with formal security audits.
3. Model Growth Will customer isolation or multi-tenancy create blast-radius risk later?
4. Choose Account Strategy Single-account now with migration plan, or multi-account from day one.
5. Codify Everything Use infrastructure as code and enforce peer review for all changes.

If you’re heading toward enterprise contracts within 12–18 months, start with multi-account. Retrofitting is almost always more expensive than building it right.

Frequently Asked Questions