Protecting Protected Health Information (PHI) in the cloud requires more than encrypting databases and restricting user permissions. Healthcare workloads often contain highly sensitive information that must be isolated from unrelated applications, development environments, experimental systems, and administrative workloads. In AWS, one of the most effective ways to establish this separation is through a multi-account architecture.

A multi-account AWS architecture creates strong boundaries between workloads by placing systems, data, identities, and infrastructure into separate AWS accounts. Rather than treating an AWS account as merely a billing container, organizations can use it as a foundational security and governance boundary. When PHI workloads are placed in dedicated accounts, the organization gains clearer isolation, more precise access control, reduced blast radius, and stronger auditability.

This article explains how multi-account AWS architecture can enforce PHI workload isolation at the boundary level. It also demonstrates practical implementation approaches using AWS Organizations, Service Control Policies (SCPs), IAM policies, VPC architecture, resource policies, encryption controls, and Infrastructure as Code examples.

Understanding PHI Workload Isolation

PHI workload isolation is the practice of separating systems that process, store, or transmit Protected Health Information from systems that do not require access to that information.

For example, an organization might operate:

• A production patient management platform.
• A healthcare analytics environment.
• A public-facing marketing website.
• Development and testing environments.
• Internal corporate applications.
• Security and logging systems.
• Machine learning experimentation workloads.

Not all of these systems need access to patient information. If they are placed inside a single AWS account with broadly shared IAM roles, networks, and services, an error in one workload may potentially affect another.

A multi-account design reduces this risk by establishing account-level boundaries.

A simplified structure might look like this:

AWS Organization
│
├── Security OU
│   ├── Security Account
│   └── Log Archive Account
│
├── Production OU
│   ├── PHI Production Account
│   └── Non-PHI Production Account
│
├── Development OU
│   ├── PHI Development Account
│   └── General Development Account
│
└── Shared Services OU
    ├── Identity Account
    └── Networking Account

The important architectural decision is that the PHI production workload does not simply coexist with every other workload. It has its own AWS account boundary.

This means that access into the PHI environment must cross an explicitly controlled boundary.

Why the AWS Account Is an Important Security Boundary

An AWS account provides a natural separation point for identities, resource ownership, quotas, billing, and many administrative operations.

Even if an organization uses a single centralized identity provider, access to a resource in another account generally requires explicit authorization. This creates opportunities to enforce least privilege.

For example, a developer who has administrator-like permissions in a development account should not automatically receive access to a PHI production account.

Instead, the organization can require a separate role assumption process.

Developer Identity
       │
       ▼
Development Account
       │
       │ Explicit Role Assumption
       ▼
PHI Production Account
       │
       ▼
Restricted PHI Resources

This distinction is critical. Isolation should not depend entirely on users remembering which resources they are allowed to access. The architecture itself should enforce separation.

A compromised development credential, for example, should not automatically provide access to PHI resources simply because both environments exist within the same AWS organization.

Using AWS Organizations to Establish Structural Boundaries

AWS Organizations provides a hierarchical way to manage multiple AWS accounts.

Accounts can be grouped into Organizational Units, commonly referred to as OUs.

A healthcare organization might create an OU specifically for regulated workloads:

Root
├── Security
├── Infrastructure
├── Regulated-Workloads
│   ├── PHI-Production
│   ├── PHI-Development
│   └── PHI-Analytics
└── General-Workloads
    ├── Marketing
    ├── Corporate-IT
    └── Sandbox

The advantage of this approach is that governance policies can be applied to the entire regulated environment.

For example, an organization can apply restrictive Service Control Policies to the Regulated-Workloads OU.

This creates a governance model where PHI-specific restrictions are inherited by accounts in that organizational structure.

Enforcing Guardrails with Service Control Policies

Service Control Policies are especially useful because they establish maximum permission boundaries for accounts.

An SCP does not grant permissions. Instead, it limits what permissions can ultimately be exercised, even when an IAM policy might otherwise allow an action.

For PHI workloads, organizations can use SCPs to prevent risky actions.

For example, an organization may want to prevent PHI resources from being created outside approved AWS Regions.

A simplified SCP might look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "cloudfront:*",
        "route53:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    }
  ]
}

This policy can be attached to the regulated workloads OU.

As a result, even if an administrator inside a PHI account attempts to deploy infrastructure into an unapproved region, the SCP can block the action.

Another example is preventing the deletion or modification of critical logging resources.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectSecurityLogging",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "logs:DeleteLogGroup"
      ],
      "Resource": "*"
    }
  ]
}

This demonstrates an important architectural principle: controls should exist outside the workload administrator’s immediate authority whenever possible.

If the same administrator who manages PHI infrastructure can also disable the organization’s security controls without restriction, the isolation model is weaker.

Separating PHI and Non-PHI Networks

Account boundaries should be reinforced by network boundaries.

A PHI account can contain dedicated VPCs that are separate from general application environments.

For example:

PHI Account
└── PHI VPC
    ├── Private Application Subnet
    ├── Private Database Subnet
    └── Restricted Integration Subnet

General Application Account
└── General VPC
    ├── Web Application Subnet
    ├── Development Subnet
    └── Public Services

The key principle is to avoid unrestricted network connectivity between these environments.

Instead of allowing broad network peering, connectivity should be explicitly designed around required communication paths.

For example, if a non-PHI application requires access to a specific healthcare API, it should access that API rather than receiving unrestricted access to the entire PHI VPC.

This creates a narrower security boundary:

Non-PHI Application
       │
       │ HTTPS API Request
       ▼
Controlled API Endpoint
       │
       ▼
PHI Application
       │
       ▼
PHI Data Store

The non-PHI environment does not need direct database connectivity.

This reduces unnecessary exposure.

Using IAM Roles for Cross-Account Access

Cross-account access should be explicit and tightly scoped.

Suppose a centralized security account needs permission to read security information from a PHI account.

Instead of creating a shared administrator account, the PHI account can define a dedicated IAM role.

Here is an example trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

The associated permissions policy can restrict what the security account is allowed to do:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudtrail:LookupEvents",
        "config:GetResourceConfigHistory",
        "config:ListDiscoveredResources"
      ],
      "Resource": "*"
    }
  ]
}

The security account can assume the role, but it cannot automatically modify databases, delete application resources, or retrieve PHI.

This is an example of separating administrative responsibilities.

Cross-account access should answer a simple question:

What exact capability does this external account require?

The permissions should be built around that capability rather than around broad convenience.

Enforcing Encryption Boundaries with AWS KMS

Encryption is another important component of PHI isolation.

However, encryption alone does not create workload isolation. The key management architecture is equally important.

A PHI account can use dedicated AWS KMS keys for regulated data.

For example, an S3 bucket storing PHI can use a customer-managed KMS key.

A simplified Terraform example might look like this:

resource "aws_kms_key" "phi_key" {
  description             = "Encryption key for PHI workloads"
  deletion_window_in_days = 30
  enable_key_rotation     = true
}

resource "aws_s3_bucket" "phi_data" {
  bucket = "organization-phi-data"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "phi_data" {
  bucket = aws_s3_bucket.phi_data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.phi_key.arn
    }
  }
}

The KMS key policy can further restrict which principals are allowed to decrypt data.

For example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPHIApplicationRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::444455556666:role/PHIApplicationRole"
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "*"
    }
  ]
}

A workload outside the PHI account should not automatically gain decryption rights.

This creates an additional boundary: even if encrypted data is accidentally copied elsewhere, access to the encryption key remains independently controlled.

Controlling Data Egress at the Boundary

PHI isolation should also consider where data can leave the protected environment.

A PHI account should not necessarily have unrestricted outbound access to the internet or arbitrary AWS services.

Organizations can implement controlled egress using:

• Dedicated NAT gateways.
• Centralized inspection.
• AWS Network Firewall.
• Proxy services.
• VPC endpoints.
• Private connectivity.
• DNS controls.
• Network access control mechanisms.

For example, applications accessing Amazon S3 can use a VPC endpoint rather than sending traffic through public internet paths.

A VPC endpoint policy can limit which buckets are accessible.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::organization-phi-data",
        "arn:aws:s3:::organization-phi-data/*"
      ]
    }
  ]
}

This helps define exactly which data destinations the PHI workload can interact with.

The same concept can be applied to outbound integrations. Instead of allowing unrestricted communication, approved services should be explicitly defined.

Resource Policies as Additional Isolation Controls

Identity-based permissions are not the only mechanism available.

Resource-based policies can provide another enforcement layer.

Consider an S3 bucket containing PHI. The bucket policy can explicitly deny insecure transport:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::organization-phi-data",
        "arn:aws:s3:::organization-phi-data/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

A resource policy can also restrict access to specific AWS accounts or roles.

This is valuable because it creates defense in depth.

An IAM policy might accidentally become too broad, but a restrictive resource policy can still prevent unauthorized access.

Infrastructure as Code and Repeatable Isolation

Manual account configuration can create inconsistencies.

For regulated environments, Infrastructure as Code can help ensure that PHI account controls are deployed consistently.

For example, an AWS CloudFormation template might enforce block public access settings for an S3 bucket:

Resources:
  PHIBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: aws:kms

      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        IgnorePublicAcls: true
        BlockPublicPolicy: true
        RestrictPublicBuckets: true

Organizations can standardize these patterns into reusable modules.

For example:

terraform/
├── modules/
│   ├── phi-vpc/
│   ├── phi-s3/
│   ├── phi-kms/
│   └── phi-logging/
│
└── environments/
    ├── phi-production/
    └── phi-development/

The PHI account architecture then becomes a repeatable implementation rather than a collection of manually configured settings.

This is particularly useful when an organization must create multiple regulated environments.

Centralized Logging Without Breaking Isolation

Isolation should not mean invisibility.

A PHI workload should generate logs and audit information that can be monitored by an independent security function.

A common pattern is:

PHI Account
    │
    │ CloudTrail / Security Logs
    ▼
Log Archive Account
    │
    ▼
Security Analytics Account

The PHI workload generates the events, but the logs are stored in a separate account.

This reduces the risk that a compromised workload administrator could simply delete evidence of suspicious activity.

Access to the centralized logging environment should also be tightly controlled. Security personnel may need access to metadata and audit information without requiring broad access to the underlying PHI application.

The logging architecture should therefore distinguish between operational observability and unnecessary access to sensitive application data.

Reducing the Blast Radius of Security Incidents

One of the strongest benefits of multi-account architecture is blast-radius reduction.

Imagine that a developer credential is compromised in a general development account.

In a single-account environment, the attacker might discover that the same account contains development resources, production infrastructure, PHI databases, and logging systems.

In a properly designed multi-account architecture, the compromised identity starts within a much narrower environment.

The attacker must overcome additional boundaries to reach the PHI workload.

Those boundaries may include:

• Cross-account IAM restrictions.
• Explicit role trust relationships.
• MFA and identity controls.
• SCPs.
• Network segmentation.
• Resource-based policies.
• KMS key policies.
• Centralized monitoring.
• Dedicated administrative roles.

No single control should be considered sufficient.

The goal is to create multiple independent enforcement points.

Designing for Administrative Separation

PHI workload isolation also requires separation of administrative responsibilities.

For example, these functions do not necessarily need to be controlled by the same people:

Security Team
    └── Organization-wide security monitoring

Platform Team
    └── Shared infrastructure

Application Team
    └── PHI application deployment

Database Team
    └── Controlled data operations

Audit Team
    └── Read-only compliance visibility

AWS accounts and IAM roles can be used to implement these responsibilities.

An application administrator may be allowed to deploy an ECS service but not modify the organization-level SCP.

A security engineer may be allowed to investigate logs but not change patient records.

A database administrator may have controlled operational access without unrestricted access to application infrastructure.

This separation helps reduce excessive privilege accumulation.

Example Boundary-Level Architecture

A practical PHI architecture could be represented as follows:

                         AWS Organization
                                │
          ┌─────────────────────┴─────────────────────┐
          │                                           │
     Security OU                                  Workloads OU
          │                                           │
 ┌────────┴────────┐                    ┌─────────────┴─────────────┐
 │                 │                    │                           │
Security       Log Archive          PHI Production              Non-PHI
Account          Account              Account                  Account
                                      │
                               ┌──────┴──────┐
                               │             │
                            PHI VPC       KMS Keys
                               │
                    ┌──────────┴──────────┐
                    │                     │
              Application Tier      Database Tier
                    │                     │
                    └──────────┬──────────┘
                               │
                        Controlled APIs
                               │
                        Approved Consumers

This architecture establishes several distinct boundaries.

The PHI workload is separated structurally through its own account.

It is separated organizationally through OU-level controls.

It is separated logically through IAM and cross-account role assumptions.

It is separated cryptographically through dedicated encryption keys and key policies.

It is separated at the network level through dedicated VPCs and controlled communication paths.

It is separated operationally through centralized logging and security monitoring.

Together, these controls create a layered isolation model.

Conclusion

A secure PHI environment should not rely on a single security mechanism, a single administrator, or a single IAM policy. The strongest cloud architectures assume that credentials can be compromised, permissions can be misconfigured, applications can contain vulnerabilities, and operational mistakes can occur.

Multi-account AWS architecture addresses this reality by introducing meaningful boundaries into the cloud environment.

The AWS account becomes a foundational isolation layer. PHI workloads can be placed in dedicated accounts that are structurally separated from development systems, corporate applications, public websites, experimental workloads, and other non-regulated environments. Access into those accounts becomes an explicit decision rather than an accidental consequence of broad permissions.

AWS Organizations can then reinforce this structure through Organizational Units and Service Control Policies. SCPs can prevent accounts from operating outside approved governance boundaries, even when powerful IAM permissions are granted within an account. This makes governance less dependent on individual configuration decisions.

IAM roles and cross-account trust relationships further narrow access. Instead of sharing credentials or granting broad organization-wide permissions, workloads and administrators can assume narrowly defined roles for specific purposes. Security teams, application teams, auditors, and infrastructure teams can each receive the permissions necessary for their responsibilities without automatically receiving access to PHI.

Network architecture adds another layer of separation. Dedicated VPCs, private subnets, controlled APIs, VPC endpoints, and restricted egress paths help ensure that PHI systems communicate only with approved services. A non-PHI application should not need unrestricted network access simply because it needs to request information from a controlled healthcare service.

Encryption provides an additional boundary when implemented with carefully managed KMS keys and restrictive key policies. The ability to obtain encrypted data should not automatically imply the ability to decrypt it. Separating cryptographic permissions from general infrastructure permissions strengthens the overall isolation model.

Centralized logging and independent security accounts are equally important. A protected workload should be isolated, but it should not be allowed to operate without oversight. Audit logs, configuration records, and security events should be collected in a way that supports investigation and reduces the ability of a compromised workload administrator to erase evidence.

Ultimately, PHI isolation is most effective when security is embedded into the architecture itself. Instead of asking administrators to remember where PHI belongs, the environment should establish clear boundaries around it. Instead of assuming that broad administrative access will always be used correctly, the architecture should limit unnecessary authority. Instead of allowing every workload to communicate freely, connections should be intentional and narrowly defined.

A mature multi-account AWS strategy therefore transforms isolation from a documentation requirement into an enforceable technical property. Account boundaries, organizational guardrails, identity controls, network segmentation, resource policies, encryption boundaries, centralized monitoring, and automated infrastructure work together to reduce risk.

For organizations handling PHI, the objective is not simply to create more AWS accounts. The objective is to create meaningful boundaries that constrain how identities, data, infrastructure, and network traffic interact. When designed correctly, a multi-account architecture limits the blast radius of incidents, simplifies governance, improves auditability, and provides a stronger foundation for protecting sensitive healthcare workloads.

The most effective implementation is one in which PHI isolation is continuously enforced at multiple layers. If one control fails, another boundary remains in place. That defense-in-depth approach is what turns multi-account architecture from an organizational convenience into a powerful security design strategy for regulated healthcare workloads.