Multi-Classification Cloud Environment Architecture

Many DoD programs operate workloads at multiple classification levels simultaneously. A web presence might be unclassified (IL2). Operational data might be CUI (IL4). Mission-critical systems touching NSS data might require IL5. Managing these workloads as separate, disconnected environments produces operational overhead and eliminates the cost and integration benefits of cloud. Managing them in a unified environment without proper boundary enforcement creates unacceptable security risk.

The solution is a multi-classification cloud environment: a single managed landing zone architecture that hosts workloads at IL2, IL4, and IL5 in properly segmented accounts, with controlled data paths between levels and unified operational visibility across all tiers.

The Account Boundary Model

The foundational design decision: each impact level gets its own AWS account (or set of accounts for large programs). Accounts are the hardest isolation boundary in AWS — IAM, VPCs, and resource policies cannot accidentally cross account boundaries without explicit configuration.

AWS Organizations (GovCloud)
├── Management Account (SCPs, billing, audit)
├── Security OU
│   └── Security Account (CloudTrail aggregation, Security Hub, GuardDuty)
├── Network OU
│   └── Network Account (Transit Gateway, Direct Connect)
├── IL2 OU
│   ├── IL2-Workload-Prod
│   └── IL2-Workload-Dev
├── IL4 OU
│   ├── IL4-Workload-Prod
│   └── IL4-Workload-Dev
└── IL5 OU
    ├── IL5-Workload-Prod
    └── IL5-Workload-Dev

Service Control Policies (SCPs) on each OU enforce the constraints specific to that classification level. IL5 OUs, for example, carry SCPs requiring US-person-only access controls and physical GovCloud region isolation. IL2 OUs have less restrictive SCPs but still enforce baseline security requirements (encryption, logging, no public resources).

# SCP: IL5 US-person access enforcement (simplified)
data "aws_iam_policy_document" "il5_us_person_scp" {
  statement {
    effect = "Deny"
    actions = ["*"]
    resources = ["*"]
    condition {
      test     = "StringNotEquals"
      variable = "aws:RequestedRegion"
      values   = ["us-gov-east-1", "us-gov-west-1"]
    }
  }
}

Network Architecture: Segmented Transit Gateway

A shared Transit Gateway in the network account connects workload VPCs across classification levels. The critical design constraint: routing tables must enforce that IL2 traffic cannot reach IL4 or IL5 VPCs, and IL4 traffic cannot reach IL5 VPCs, through any misconfiguration of routing.

Separate route tables per classification. Each classification level has a dedicated Transit Gateway route table. Associations and propagations are configured so that:

IL2 VPCs associate with and propagate to the IL2 route table only
IL4 VPCs associate with and propagate to the IL4 route table only
IL5 VPCs associate with and propagate to the IL5 route table only
Shared services (DNS, patch management, logging) live in a shared services VPC accessible from all levels via tightly controlled route table entries

On-premise connectivity. Direct Connect or VPN connections from on-premise environments terminate in the network account. Each connection lands in the appropriate classification-level Transit Gateway attachment — on-premise IL4 systems connect to the IL4 Transit Gateway attachment, not to a shared attachment.

No "downflow" routing. Lower classification workloads must never have network paths to higher classification resources. Downflow (IL4 to IL5) is as dangerous as upflow — it creates channels for exfiltration of higher-classified data to less-controlled environments.

Cross-Domain Data Movement

Some programs legitimately need to move data between classification levels — downgrading sanitized data from IL4 to IL2 for publication, for example. This movement must go through a controlled, audited cross-domain solution (CDS), never through application-layer logic.

CDS architecture principles:

Dedicated account for the CDS, accessible from both source and destination classification levels via tightly scoped Transit Gateway rules
Every data transfer is logged to CloudTrail in the Security account with full metadata (source, destination, data product, approving system)
Data transformation at the CDS applies sanitization rules (stripping classified metadata, applying classification markings)
No bidirectional data flows — a CDS is unidirectional (IL4→IL2 or IL2→IL4), not a two-way pipe

Shared Services Architecture

Some services must be accessible from all classification levels: DNS resolution, patch management, container image registries, and security tooling. These live in a shared services account with tightly controlled access from all workload accounts.

Design principle: Shared services data flows upward only. A shared patch server can push to IL2, IL4, and IL5 workloads. IL4 workloads cannot reach shared services that also serve IL2 systems — that would create an indirect IL4→IL2 path.

Key shared services in a multi-classification environment:

Private DNS (Route 53 Resolver) — resolves internal names across all VPCs via forwarding rules
Patch management (Systems Manager Patch Manager) — patches instances across all accounts without direct internet access from workload accounts
Container registry (ECR) — a single hardened image registry pulls from the shared account into workload accounts using cross-account IAM roles
Security aggregation — CloudTrail, Security Hub, and GuardDuty findings from all accounts aggregate to the Security account for unified visibility

Operational Visibility Across Classification Levels

Security operations teams need unified visibility across all classification levels without flattening the boundaries. The solution: aggregation without access flattening.

CloudTrail logs from all accounts ship to a centralized S3 bucket in the Security account. Security Hub aggregates findings. GuardDuty delivers findings to a central delegated admin. Security team members access the Security account with appropriate clearances — they see all findings from all classification levels within their clearance scope. Workload account teams only see their own accounts.

This design satisfies both operational effectiveness (SOC team has full visibility) and least-privilege security (workload owners cannot access other classification levels through shared tooling).

Working With Rutagon

Rutagon designs and operates multi-classification cloud environments for defense programs — from IL2 public web presence through IL5 NSS workloads in a single managed landing zone.

Contact Rutagon →

Frequently Asked Questions

What is a multi-classification cloud environment?

A multi-classification cloud environment hosts workloads at multiple DoD impact levels (IL2, IL4, IL5) within a single managed cloud landing zone architecture. Each classification level is isolated in dedicated AWS accounts with separate network segments, distinct SCPs, and controlled cross-domain data paths. This architecture enables program offices to consolidate cloud operations while maintaining the security boundaries required at each classification level.

How are IL2, IL4, and IL5 workloads isolated in AWS?

Account boundaries provide the primary isolation. Each impact level operates in dedicated AWS accounts within the AWS Organizations hierarchy. Service Control Policies on each Organizational Unit enforce classification-specific constraints. Network isolation uses separate Transit Gateway route tables per classification level, preventing routing between levels. Cross-domain data movement (when legitimately needed) goes through a dedicated cross-domain solution with full audit logging — never through application-layer or ad-hoc network paths.

What is the difference between IL4 and IL5 in AWS GovCloud?

IL4 supports Controlled Unclassified Information (CUI) and requires FedRAMP High equivalency, US-citizen-operated support, and physical US datacenter location. IL5 supports National Security Systems (NSS) data and controlled unclassified information requiring higher-level protection, adding requirements for US-person access controls, physical isolation from non-government tenants, and DISA authorization through the DoD SRG. Both impact levels require AWS GovCloud regions; IL5 adds additional access and isolation constraints beyond IL4.

Can shared services be used across classification levels?

Yes, with strict unidirectional flow controls. Shared services (patch management, DNS, container registries) can serve workloads at multiple classification levels when data flows only upward (from lower to higher classification) through tightly scoped IAM roles and Transit Gateway routing rules. Bidirectional access from higher-classification workloads back to shared services that also serve lower-classification environments is prohibited — it creates indirect cross-domain paths. Each shared service design must be analyzed for potential cross-domain data flow risks.

How does multi-classification cloud affect ATO?

Each classification level boundary typically requires a separate ATO or distinct Authorization Package, because the system boundary definition changes between levels. A multi-classification environment often results in three ATOs: IL2, IL4, and IL5. The landing zone (Management, Security, Network accounts) may carry its own authorization or be included within one of the level-specific packages. Rutagon's SSP-as-code approach generates level-specific documentation from Terraform state, reducing the overhead of maintaining multiple synchronized SSPs.