Federal cloud programs fail in predictable ways: compliance debt accumulated through manual configuration, security groups that became too permissive, logging disabled to save costs, accounts without spending controls. A well-designed federal cloud infrastructure — following established patterns for landing zones, network segmentation, and compliance-first IaC — prevents these failure modes from accumulating.
The Federal Cloud Landing Zone
A federal cloud landing zone is the pre-authorized, compliant foundation that all government workloads deploy into. It establishes guardrails that prevent non-compliant configurations before they occur.
Multi-Account Architecture
Federal cloud deployments should use separate AWS accounts for isolation — not separate VPCs in the same account:
Organization Root
├── Security OU
│ ├── Log Archive Account # CloudTrail, Config, VPC Flow Logs
│ └── Security Tooling Account # Security Hub, GuardDuty, Inspector
├── Infrastructure OU
│ ├── Network Account # Transit Gateway, Direct Connect, shared VPCs
│ └── Shared Services Account # DNS, patching, shared tooling
├── Workloads OU
│ ├── Production Account # Production mission workloads
│ ├── Development Account # Developer environments
│ └── Staging Account # Pre-production validation
└── Sandbox OU
└── Sandbox Account # Exploratory developmentAccount isolation provides:
- Blast radius limitation: A compromised production account doesn't grant access to the log archive
- Cost allocation: Billing per account makes cost attribution clear
- Policy enforcement: Service Control Policies (SCPs) apply at the OU level, enforcing organization-wide controls
Service Control Policies for Compliance
SCPs are the highest-level guardrails — they override any IAM policy, including administrator roles:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonGovCloudRegions",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"us-gov-east-1",
"us-gov-west-1"
]
}
}
},
{
"Sid": "DenyCloudTrailDisable",
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"cloudtrail:UpdateTrail"
],
"Resource": "*"
},
{
"Sid": "RequireIMDSv2",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws-us-gov:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:MetadataHttpTokens": "required"
}
}
}
]
}Network Architecture Patterns
Hub-and-Spoke with Transit Gateway
# Terraform: Transit Gateway hub for federal cloud
resource "aws_ec2_transit_gateway" "federal_hub" {
description = "Federal cloud hub TGW"
amazon_side_asn = 64512
auto_accept_shared_attachments = "disable"
default_route_table_association = "disable"
default_route_table_propagation = "disable"
dns_support = "enable"
vpn_ecmp_support = "enable"
tags = {
Name = "federal-cloud-hub"
Environment = "production"
Compliance = "FedRAMP-High"
}
}
# Separate route tables for different security tiers
resource "aws_ec2_transit_gateway_route_table" "production" {
transit_gateway_id = aws_ec2_transit_gateway.federal_hub.id
tags = { Name = "production-rtb" }
}
resource "aws_ec2_transit_gateway_route_table" "development" {
transit_gateway_id = aws_ec2_transit_gateway.federal_hub.id
tags = { Name = "development-rtb" }
}
# Production cannot route to development - enforce at TGW level
# (No route table propagation between prod and dev attached VPCs)Subnet Tiering Pattern
Every VPC in the federal cloud follows a consistent subnet tiering:
# Standard federal cloud VPC with 4 subnet tiers
locals {
subnet_tiers = {
public = { cidr_offset = 0, nat_gateway = true }
private = { cidr_offset = 32, nat_gateway = false }
data = { cidr_offset = 64, nat_gateway = false }
management = { cidr_offset = 96, nat_gateway = false }
}
}The data tier (RDS, ElasticSearch, DynamoDB VPC endpoints) has no route to the internet — not even through NAT. The management tier is for SSM, patching, and monitoring traffic only.
Shared Services Pattern
Shared services reduce duplication across accounts:
# Centralized secrets rotation Lambda (deployed in shared services account)
import boto3
import json
def rotate_rds_password(secret_arn: str,
target_account_id: str,
region: str = 'us-gov-east-1') -> None:
"""
Cross-account secret rotation: secrets manager in shared account,
RDS instances in workload accounts.
"""
sts = boto3.client('sts')
# Assume role in target account
assumed = sts.assume_role(
RoleArn=f'arn:aws-us-gov:iam::{target_account_id}:role/SecretsRotationRole',
RoleSessionName='SecretsRotation'
)
creds = assumed['Credentials']
rds = boto3.client(
'rds',
region_name=region,
aws_access_key_id=creds['AccessKeyId'],
aws_secret_access_key=creds['SecretAccessKey'],
aws_session_token=creds['SessionToken']
)
# Modify DB instance password
sm = boto3.client('secretsmanager', region_name=region)
new_password = sm.get_random_password(
PasswordLength=32,
ExcludeCharacters='/@"\''
)['RandomPassword']
# Implementation continues with RDS modify and secret updateSee Rutagon's NIST 800-53 cloud automation guide and Terraform module reuse in federal cloud for the compliance and IaC layers that build on this infrastructure pattern.
Explore Rutagon's cloud engineering capabilities.
FAQ
What is a cloud landing zone and why does a federal program need one?
A cloud landing zone is a pre-configured, compliant cloud environment that provides the account structure, networking, security controls, and logging infrastructure that all workloads deploy into. Federal programs need landing zones because starting from a blank AWS account leads to inconsistent, hard-to-audit configurations. A landing zone encodes the organization's security baseline into infrastructure that's enforced automatically rather than documented in a policy document.
What is the difference between AWS GovCloud and AWS standard regions for federal programs?
AWS GovCloud (US-East and US-West) regions are operated exclusively by US persons, support controlled unclassified information (CUI) and ITAR-regulated data, have FedRAMP High authorization, and have enhanced physical security. AWS standard regions (us-east-1, us-west-2) are not ITAR-compliant and are not appropriate for government data with CUI or higher classification requirements. IL4 and IL5 requirements generally mandate GovCloud.
How do Service Control Policies differ from IAM policies in federal cloud?
SCPs apply at the AWS Organization level and override any IAM policy — even an account's root user or administrator IAM roles cannot exceed SCP boundaries. IAM policies apply to specific users and roles within an account. SCPs are preventive controls that enforce what is possible; IAM policies are access controls that enforce what specific identities are permitted. Federal cloud uses both layers: SCPs for organization-wide guardrails, IAM policies for least-privilege role definitions.
Is AWS Control Tower sufficient for a federal cloud landing zone?
AWS Control Tower provides a good starting foundation — multi-account structure, organizational SCPs, and some logging. However, for FedRAMP High or IL4/IL5 environments, additional customization is required: enhanced logging configurations, tighter SCPs (Control Tower's defaults don't enforce FedRAMP controls), and custom Config rules for compliance controls beyond Control Tower's defaults. Rutagon recommends starting with Control Tower and customizing it for the program's authorization level rather than building from scratch.
What logging must be enabled by default in a federal cloud landing zone?
At minimum: CloudTrail (multi-region, all management events and S3/Lambda data events), AWS Config (all resource types, delivered to centralized log account), VPC Flow Logs (all VPCs), Security Hub (enabled with NIST 800-53 standard), and GuardDuty (all accounts and regions). These are the baseline controls for FedRAMP Moderate — FedRAMP High and IL5 require additional capabilities like CloudWatch anomaly detection and enhanced DNS logging.