HIPAA-Compliant Cloud Architecture: AWS vs Azure vs GCP for Healthcare

Key Takeaways:

• AWS, Azure, and GCP all offer HIPAA-eligible services — but the cloud provider does not make your architecture HIPAA compliant, your implementation does
• A signed Business Associate Agreement (BAA) with your cloud provider is the mandatory first step before storing any PHI
• Encryption, audit logging, access control, and network segmentation must be configured explicitly — none are enabled by default
• AWS has the deepest HIPAA-eligible service catalog in healthcare; Azure dominates in enterprise health systems running Microsoft stacks; GCP leads in healthcare AI and BigQuery analytics
• Architecture mistakes at the infrastructure level are the most expensive HIPAA failures to fix — get it right from day one

What Makes Cloud Architecture HIPAA Compliant?

This is the most important thing to understand before anything else: no cloud platform is HIPAA compliant out of the box. AWS, Azure, and GCP provide the infrastructure and tools to build HIPAA-compliant systems. Whether your actual deployment is compliant depends entirely on how you configure and use that infrastructure.

HIPAA compliance in cloud architecture comes down to three things working together. First, your cloud provider must be willing to sign a Business Associate Agreement with you, accepting shared responsibility for PHI protection. Second, you must use only HIPAA-eligible services — not every service on every cloud platform qualifies. Third, you must configure those services correctly — encryption, access controls, audit logging, network segmentation — according to HIPAA’s technical safeguard requirements.

A healthcare organization that stores patient records on AWS with no encryption, no audit logging, and public S3 buckets is not HIPAA compliant despite running on AWS. A properly architected deployment on any of the three major clouds can absolutely be HIPAA compliant.

This distinction matters enormously for healthcare software development teams who are moving workloads to the cloud for the first time.

The BAA: Your First Non-Negotiable Step

Before you store a single byte of PHI in any cloud environment, you need a signed Business Associate Agreement with your cloud provider. This is not optional. Under HIPAA, any vendor that creates, receives, maintains, or transmits PHI on your behalf is a Business Associate, and a BAA is legally required.

All three major cloud providers offer BAAs:

AWS covers HIPAA-eligible services under their standard BAA, which is available through the AWS console without requiring a custom agreement for most use cases. The BAA is account-wide but only covers designated HIPAA-eligible services — workloads using non-eligible services require separation.

Azure provides a HIPAA BAA as part of its standard online service terms for enterprise customers. Microsoft’s BAA covers a broad set of Azure services and is generally considered one of the more comprehensive in the industry.

GCP offers a HIPAA BAA through Google Cloud’s standard terms for covered services. Google also provides a BAA for Google Workspace (formerly G Suite) separately, which is relevant for healthcare organizations using Google’s productivity tools alongside GCP infrastructure.

Getting the BAA signed is the start, not the finish. Everything that follows — encryption, network design, access control, monitoring — is where the actual compliance work happens.

AWS HIPAA-Compliant Architecture

AWS has the largest catalog of HIPAA-eligible services of any cloud provider, making it the most flexible choice for healthcare workloads. It is the dominant cloud platform in US healthcare infrastructure.

Core HIPAA-eligible services on AWS:

Amazon EC2, ECS, and EKS handle compute workloads. Amazon RDS (PostgreSQL, MySQL, Aurora) and DynamoDB handle database workloads. S3 handles object storage. Lambda handles serverless compute. API Gateway manages API endpoints. CloudTrail provides audit logging. CloudWatch handles monitoring and alerting. KMS manages encryption keys. VPC provides network isolation. IAM handles identity and access management. Cognito handles user authentication.

Reference architecture for a HIPAA workload on AWS:

The foundation is a VPC with public and private subnets across multiple Availability Zones. Application load balancers live in the public subnet. Application servers (EC2 or ECS containers) run in private subnets with no direct internet access. Databases run in isolated private subnets with no route to the internet at all. All traffic between tiers flows through security groups that implement least-privilege network access.

Encryption is applied at every layer. S3 buckets use server-side encryption with KMS-managed keys (SSE-KMS). RDS instances are encrypted at rest using KMS. All data in transit uses TLS 1.2 minimum — this is enforced at the load balancer and at the application layer. EBS volumes attached to EC2 instances are encrypted.

CloudTrail is enabled in all regions with log file validation and logs shipped to a dedicated, write-protected S3 bucket. CloudWatch Logs captures application logs. AWS Config monitors for configuration drift — any change to a security group rule or S3 bucket policy triggers an alert.

IAM policies follow least-privilege principles. No user or service has more permissions than required for their specific function. MFA is enforced for all console access. Service accounts use IAM roles, never long-lived access keys.

AWS Macie can be enabled to automatically discover and classify PHI stored in S3 — useful for large organizations where data sprawl is a real risk. AWS Security Hub aggregates findings from GuardDuty, Inspector, and Macie into a single compliance dashboard.

For healthcare applications integrating with EHRs via HL7 or FHIR, AWS HealthLake provides a FHIR R4-compatible data store that is itself a HIPAA-eligible service — removing the need to build your own FHIR persistence layer from scratch.

Azure HIPAA-Compliant Architecture

Azure is the preferred cloud for healthcare organizations that are already deep in the Microsoft ecosystem — running Epic on Azure, using Microsoft 365, or leveraging Azure Active Directory for identity management. Microsoft has invested heavily in healthcare-specific services and compliance tooling.

Core HIPAA-eligible services on Azure:

Azure Virtual Machines and AKS handle compute. Azure SQL Database, Cosmos DB, and Azure Database for PostgreSQL handle data storage. Azure Blob Storage handles object storage. Azure Functions handles serverless compute. Azure API Management manages APIs. Azure Monitor and Log Analytics handle observability. Azure Key Vault manages encryption keys. Virtual Network provides network isolation. Azure Active Directory handles identity.

Reference architecture for a HIPAA workload on Azure:

Azure’s compliance advantage is its integration with Azure Policy and Microsoft Defender for Cloud (formerly Azure Security Center), which can continuously assess your environment against HIPAA controls and flag violations automatically. This is operationally significant — it reduces the manual effort of maintaining compliance posture.

Azure Virtual Networks segment workloads into tiers. Application Gateway with WAF (Web Application Firewall) handles ingress. Application services run in private subnets. Azure SQL Managed Instance or Azure Database for PostgreSQL Flexible Server handles relational data with encryption at rest enabled by default using Azure-managed or customer-managed keys in Key Vault.

Azure Active Directory provides enterprise-grade identity with conditional access policies, MFA enforcement, and Privileged Identity Management (PIM) for just-in-time admin access. For healthcare organizations, this integrates directly with existing on-premise Active Directory environments — a major operational advantage during EHR modernization projects.

Azure Monitor captures all control plane and data plane activity. Diagnostic settings on every resource ship logs to a Log Analytics workspace. Azure Sentinel (now Microsoft Sentinel) provides SIEM capabilities for detecting and responding to security incidents involving PHI.

Azure Health Data Services is Microsoft’s purpose-built healthcare data platform — it combines a FHIR service, a DICOM service, and MedTech service (for IoT/device data ingestion) into a single HIPAA-eligible managed service. For organizations building remote patient monitoring systems or FHIR-based patient data platforms, this is a significant architectural accelerator.

GCP HIPAA-Compliant Architecture

GCP is the strongest choice for healthcare organizations with significant data analytics, machine learning, or AI workloads. Google’s data infrastructure — BigQuery, Vertex AI, Cloud Healthcare API — is genuinely ahead of AWS and Azure for large-scale healthcare analytics use cases.

Core HIPAA-eligible services on GCP:

Compute Engine and GKE handle compute. Cloud SQL and Firestore handle database workloads. Cloud Storage handles object storage. Cloud Functions and Cloud Run handle serverless workloads. Cloud Healthcare API provides a purpose-built FHIR, HL7v2, and DICOM service. BigQuery handles analytical workloads. Cloud KMS manages encryption. VPC provides network isolation. Cloud IAM handles access control. Cloud Audit Logs provides audit trails.

Reference architecture for a HIPAA workload on GCP:

GCP’s standout feature for healthcare is the Cloud Healthcare API — a managed service that natively supports HL7 v2 message ingestion, FHIR R4 data stores, and DICOM image stores, all within a HIPAA-eligible, fully managed service. For teams building healthcare interoperability solutions, this removes substantial infrastructure work.

VPC Service Controls create a security perimeter around GCP resources containing PHI, preventing data exfiltration even if credentials are compromised. This is a differentiated security capability that AWS and Azure don’t have a direct equivalent for.

BigQuery with column-level security and dynamic data masking enables analytics teams to query PHI-containing datasets while enforcing access controls at the field level — so a data analyst can run population health queries without seeing individual patient identifiers. This capability is extremely valuable for healthcare AI and analytics workloads.

Cloud Audit Logs captures Admin Activity, Data Access, and System Event logs. These logs are immutable and can be exported to Cloud Storage for long-term retention. Cloud Security Command Center provides a unified view of security findings across the GCP environment.

For organizations building healthcare AI applications — clinical NLP, medical imaging analysis, predictive analytics — Vertex AI on GCP with its deep BigQuery integration and HIPAA eligibility makes GCP the strongest platform choice.

AWS vs Azure vs GCP: Side-by-Side Comparison

Core Architecture Patterns for HIPAA Workloads

Regardless of which cloud platform you choose, these architecture patterns apply to every HIPAA-compliant deployment:

Multi-tier network segmentation. Public tier (load balancers, API gateways), application tier (app servers, containers — private, no direct internet), data tier (databases — isolated, no internet route whatsoever). PHI never lives in the public tier.

Encryption everywhere, always. Encryption at rest for every storage resource. TLS 1.2 minimum in transit for every connection — internal service-to-service included, not just external traffic. Customer-managed encryption keys (CMEK) for regulated workloads where you need key rotation control.

Centralized, immutable audit logging. Every API call, every data access, every configuration change logged. Logs shipped to write-protected, separate storage. Log retention minimum 6 years for HIPAA. Automated alerting on suspicious access patterns.

Zero-trust access model. No implicit trust based on network location. Every service authenticates. Every user authenticates with MFA. Permissions follow least-privilege — grant exactly what is needed, nothing more. Service accounts use short-lived credentials, never permanent keys.

Automated compliance monitoring. Configuration drift detection — any change to a security group, bucket policy, or IAM policy triggers automated review. Continuous compliance scoring against HIPAA controls. Vulnerability scanning of compute workloads.

Disaster recovery with tested RTO/RPO. Multi-AZ deployments for high availability. Cross-region backups for disaster recovery. Documented and tested recovery procedures — HIPAA’s contingency planning requirement is not just about having backups, it’s about proving you can recover from them.

These patterns apply whether you are building a patient portal, an HMS platform, or a remote patient monitoring system.

What HIPAA Actually Requires at the Infrastructure Level

HIPAA’s Security Rule has three categories of safeguards. Here is what each means at the cloud infrastructure level specifically:

Administrative Safeguards — These are the policies and procedures: documented risk analysis, workforce training, access management procedures, incident response plan, disaster recovery plan, and business associate management. At the cloud level, this means having documented runbooks for how PHI environments are managed, who has access and why, and what happens when there is a breach.

Physical Safeguards — In cloud environments, your cloud provider’s data center physical security satisfies the facility access controls requirement. This is one area where cloud providers genuinely simplify HIPAA compliance — AWS, Azure, and GCP data centers are certified to standards far beyond what most healthcare organizations could achieve on-premise.

Technical Safeguards — This is where cloud architecture directly maps to HIPAA requirements. Access controls (IAM, RBAC, MFA), audit controls (CloudTrail, Azure Monitor, Cloud Audit Logs), integrity controls (checksums, log validation, change detection), transmission security (TLS everywhere). Every one of these is an architectural decision that must be deliberately implemented.

The most important thing to understand is that HIPAA does not specify exact technical implementations — it specifies required outcomes. You must demonstrate that PHI is protected, access is controlled, and activity is logged. How you achieve that with cloud-native tools is up to you, which is both the flexibility and the complexity of HIPAA compliant software development.

Common Cloud Architecture Mistakes in Healthcare

These are the mistakes we see most frequently when auditing healthcare cloud environments:

Public S3 buckets or Blob Storage containers containing PHI. This is still happening in 2026. Default storage bucket configurations are often public or overly permissive. Every bucket containing PHI must be explicitly private with public access blocked at the account level.

Unencrypted databases. RDS encryption at rest is not enabled by default on older instance types. Azure SQL transparent data encryption is on by default now, but older deployments may predate this. Always verify encryption is actually enabled, not assumed.

CloudTrail or audit logging disabled in some regions. Organizations enable logging in their primary region and forget that workloads running in other regions are unlogged. CloudTrail must be enabled globally.

Overly permissive IAM roles. Developers create IAM roles with AdministratorAccess or wildcard permissions during development and forget to tighten them before production. Every service should have a purpose-built role with only the permissions it actually needs.

No separation between PHI and non-PHI workloads. Running HIPAA workloads and non-regulated workloads in the same account or subscription with shared IAM roles creates compliance exposure. PHI environments should be in dedicated accounts or subscriptions with strict separation.

Skipping VPC Service Controls or equivalent. Network perimeters stop lateral movement. Organizations that deploy resources without proper network segmentation create environments where a single compromised credential can access all PHI.

Treating the BAA as the finish line. Signing the BAA with AWS, Azure, or GCP does not make your environment compliant. It is the prerequisite. Everything described in this guide is what comes after.

The Bottom Line

The cloud has made HIPAA-compliant infrastructure more accessible than ever. The tools are mature, the documentation is extensive, and all three major platforms have purpose-built healthcare services that accelerate compliant architecture significantly.

But accessible does not mean automatic. Every misconfigured S3 bucket, every unencrypted database, every overpermissioned IAM role is a compliance failure waiting to happen — and in healthcare, those failures have consequences that go well beyond technical remediation.

The organizations that get this right treat cloud architecture as a clinical risk question, not just a technical one. PHI protection is not a feature to add later. It is a design constraint that shapes every infrastructure decision from day one.

If you are building or migrating a healthcare application to the cloud and need a team that has architected HIPAA-compliant environments on AWS, Azure, and GCP in production, talk to Taction Software.

Related Reading:

• HIPAA Compliant Healthcare Software Development
• How to Build Secure Healthcare Apps That Pass HIPAA Audits
• How to Develop a HIPAA Compliant App
• EHR Integration Services
• Healthcare Interoperability Solutions
• Healthcare Software AI Development
• Remote Patient Monitoring App Development