AWS for Health is the AWS portfolio of services and partner solutions for healthcare, biopharma, and genomics workloads. For public-sector health entities (state Medicaid agencies, public hospitals, academic medical centers, federal health programs), the platform capability is real but the operational discipline is what makes it production-grade. This post is the practical guide for those workloads.
We covered the broader public-sector AWS pattern in AWS for Government and AWS for Higher Education Institutions. This post focuses on what is different for healthcare workloads.
What AWS for Health Actually Is
AWS for Health is not a single service. It is a curated set of AWS services, AWS Partner Network solutions, and reference architectures organized around healthcare-specific use cases: clinical data, genomics, biopharma research, payer operations, and health-tech applications. The healthcare-specific services include Amazon HealthLake (HIPAA-eligible health data lake), Amazon Comprehend Medical (clinical NLP), Amazon Transcribe Medical (clinical speech-to-text), and Amazon Omics (genomic and biological data analysis).
For institutional health workloads, the service catalog is meaningful but secondary. The primary question is whether the institution has the operational discipline to run HIPAA-eligible workloads on AWS in a way that holds up to audit.
What Public-Sector Health Workloads Actually Need
For state Medicaid agencies, public hospitals, academic medical centers, and federal health programs, the AWS deployment pattern is shaped by overlapping compliance frameworks.
HIPAA. Protected Health Information (PHI) handling is the table-stakes requirement. AWS publishes a list of HIPAA-eligible services, and institutional workloads must use only those services for PHI processing. The institution executes a Business Associate Addendum (BAA) with AWS as part of the AWS Enterprise Agreement.
HITRUST. Many public-sector health institutions inherit HITRUST CSF requirements from their payer or partner relationships. HITRUST overlaps with HIPAA but adds specific control requirements that shape AWS configuration choices.
FedRAMP. Federal health programs (HHS, CMS, VA, IHS) and many state Medicaid programs require FedRAMP-authorized environments. AWS GovCloud (US) hosts many of the FedRAMP High services that federal health programs need.
State data residency. Some state health programs have data residency requirements that constrain region choice. AWS US-East and US-West regions are typically acceptable; ex-US regions are typically not.
42 CFR Part 2. For substance use disorder treatment data, additional federal protections apply beyond HIPAA. Workloads handling this data class need additional access control and audit discipline.
The combination of these frameworks is what shapes the AWS architecture for public-sector health, not the service catalog alone.
What Operational Discipline Public-Sector Health on AWS Requires
The operational pattern that holds for institutional health workloads on AWS:
Account structure as the boundary. PHI workloads run in dedicated AWS accounts within an AWS Organization. The account structure itself becomes the authorization boundary. AWS Service Control Policies enforce baseline guardrails (no PHI services launched in non-PHI accounts, no resources created in non-approved regions, no encryption keys stored outside KMS).
Encryption everywhere. PHI is encrypted in transit (TLS 1.2 minimum) and at rest (AWS KMS with customer-managed keys). For some workloads, customer-managed key material in CloudHSM. The encryption posture is documented and the keys are rotated on cadence.
Identity through institutional IdP. Administrative access to PHI workloads flows through the institutional identity provider via AWS IAM Identity Center. Long-lived access keys are prohibited. Break-glass accounts are documented and audited.
Logging that meets audit retention. CloudTrail (management and data events), VPC Flow Logs, AWS Config, and service-specific audit logs (HealthLake audit logs, S3 access logs for any S3 holding PHI) flow to a separate logging account. Retention meets HIPAA requirements (six years minimum for many record types).
Vulnerability management on documented cadence. Amazon Inspector for vulnerability assessment, GuardDuty for threat detection, Security Hub for compliance posture monitoring. Findings are reviewed on documented cadence with response procedures that have been exercised.
Backup and disaster recovery validated. Backups are not just configured. They are tested by restore exercise on documented cadence. For PHI workloads, the recovery point objective and recovery time objective are documented in the system security plan.
BAA in place before workload launch. The AWS Business Associate Addendum is executed before any PHI is processed on AWS. For public-sector institutions, the BAA execution path goes through institutional procurement and legal.
We covered the broader compliance posture in AWS Shared Responsibility for Government and Cloud Computing Security.
Where Public-Sector Health Workloads Actually Land on AWS
The architectural pattern that holds for public-sector health workloads:
Compute. EC2 for traditional applications and EHR adjacencies, ECS or EKS for containerized health-tech applications, Lambda for event-driven integrations (claims processing, eligibility checks, appointment reminders).
Data. RDS (HIPAA-eligible engines) for transactional health data, Aurora for higher-throughput workloads, S3 for clinical data archives with lifecycle policies aligned to retention requirements, HealthLake for FHIR-based clinical data lakes.
Analytics and ML. SageMaker for predictive analytics on de-identified data sets, Comprehend Medical for clinical NLP, Athena and Redshift for analytics over claims and clinical data lakes.
Patient-facing. CloudFront for content delivery, WAF for application-layer protection, Cognito for patient identity (where federation with institutional identity is appropriate), Connect for contact center workloads.
The architectural pattern is similar to other regulated industries, with healthcare-specific services layered in where they reduce institutional operational burden.
What Mature Public-Sector Health on AWS Looks Like
Institutions running mature public-sector health workloads on AWS share visible characteristics: dedicated accounts for PHI workloads, identity through the institutional IdP, encryption with customer-managed keys, logging that meets audit retention, vulnerability management on documented cadence, BAAs in place, and incident response procedures that have been exercised in the past 12 months.
The maturity comes from operational discipline applied consistently, not from service selection. For cloud operations engagements supporting public-sector health entities, this discipline is the engagement scope.
Frequently Asked Questions
Do all AWS services support HIPAA-eligible workloads?
No. AWS publishes a current list of HIPAA-eligible services. Institutional workloads must use only those services for PHI processing. Using a non-HIPAA-eligible service for PHI is a BAA violation and an audit finding.
Should public-sector health workloads run in AWS commercial regions or AWS GovCloud?
It depends on the institution. Federal health programs (HHS, CMS, VA, IHS) typically require AWS GovCloud (US). State Medicaid programs and public hospitals are usually acceptable in AWS US commercial regions with the BAA executed. Academic medical centers generally run in commercial regions. The decision is driven by the specific compliance frameworks the institution inherits.
What is the typical cost difference between AWS for Health workloads and on-premises healthcare infrastructure?
The total cost of ownership comparison is workload-specific. For workloads with variable demand (analytics, genomic processing, patient-facing applications during enrollment seasons), AWS is typically less expensive than on-premises capacity sized for peak. For workloads with steady-state demand and existing on-premises capacity already paid for, the cost case is closer.
How do public-sector health workloads coordinate with EHR systems on AWS?
The pattern depends on the EHR. Cloud-native EHRs (some Epic deployments, Cerner, Athena) are increasingly hosted on AWS by the EHR vendor with institutional integration via API. On-premises EHRs (legacy Epic, MEDITECH, others) integrate via VPN or AWS Direct Connect with HL7/FHIR interfaces. The integration is part of the institutional architecture, and the security boundary between the EHR and AWS-hosted institutional applications is documented.
What is the typical AWS for Health adoption pattern for public-sector institutions?
The pattern that holds: start with non-PHI workloads (research analytics, public-facing patient education, internal applications) to build operational maturity. Add de-identified data analytics workloads as the second wave. Add PHI workloads with full operational discipline once the BAA is in place and the operational posture has been audited. Genomic and biopharma workloads follow when the institution has those use cases.