Landing Zones as Code: Guardrails, Vending and Evidence for Federal Cloud Environments

Most federal cloud environments were not designed. They accumulated. A program needed somewhere to deploy, an engineer built an account, and the next program copied what it could remember. The result is a set of environments that cannot be rebuilt, cannot be defended to an assessor, and cannot be handed to a new program without months of rework.

A landing zone replaces that with a foundation engineered once and issued on request. This article walks through what goes into one for a federal agency, layer by layer, and how it produces evidence as it is built.

Start With Discovery, Not Templates

Reference implementations are a starting point, not an answer. Before anything is built, a discovery phase of two to four weeks inventories the agency's existing accounts, subscriptions and tenants, interviews system owners and the ISSM, reviews configuration and posture with read-only access and open-source scanners, and takes a snapshot of cost and tagging. It also collects what documentation exists: SSPs, POA&Ms, network diagrams and prior assessments.

Discovery answers the questions that drive the design: which impact levels the data requires, how identity is managed today, where the network boundary sits, and which existing environments must be absorbed or retired.

Layer 1: Account and Subscription Structure

The account model is the skeleton everything else hangs on. A typical federal design uses organizational units or management groups by mission area, environment (production, test, development) and impact level, with dedicated accounts for:

• centralized logging, writable only by the logging pipeline;
• security tooling and audit access;
• shared network services;
• the workload accounts that programs receive.

Separating these keeps a compromised workload account from reaching the logs that would reveal it, and it gives the authorization boundary a clean shape an assessor can follow.

Layer 2: Network and Boundary

The network design sets the topology (hub-and-spoke or transit), segmentation between workloads and impact levels, and hybrid connectivity over Direct Connect or ExpressRoute where the agency needs it. Boundary protection follows CISA's TIC 3.0 cloud use cases (opens in a new tab) for civilian agencies, or DoD connection requirements under the Cloud Computing SRG.

New connectivity is usually the longest lead-time item in the schedule. Circuits and connection approvals sit with the agency, so the design names them early, with needed-by dates.

Layer 3: Identity

Workload accounts federate to the agency's enterprise ICAM rather than holding their own user stores. The design covers role structure, privileged access patterns, and break-glass procedures that are tested rather than assumed. This is where several zero trust capabilities actually get built: identity-based access, least privilege and per-request evaluation all live in this layer.

Layer 4: Logging, Keys and Recovery

Logs from every account flow to the central logging account, protected against modification by the workloads that produce them. Encryption at rest and in transit is set as a standard, with key management and key ownership decided explicitly. Backup and recovery architecture supports contingency planning from the start, rather than being added when the first program asks.

Layer 5: Guardrails as Policy-as-Code

Guardrails are what keep every future workload inside agency policy without a manual review of each change. They are written as code: service control policies, Azure Policy, AWS Config rules or Open Policy Agent, depending on the platform. Examples include blocking public storage, requiring encryption, restricting regions, and preventing anyone from disabling the logging pipeline.

The federal step is the mapping. Each guardrail is tied to the NIST SP 800-53 control it implements:

That mapping turns a guardrail set into control-implementation evidence. Hardened baselines use CIS Benchmarks or DISA STIGs, verified with scanners such as Prowler, ScoutSuite and Checkov.

Layer 6: Environment Vending

Vending is what turns a landing zone into a platform. A program requests an environment and receives an account or subscription already inside the guardrails, connected to the network and logging, and federated to identity. In planning terms, that changes the wait from months to weeks: in an illustrative three-year model (opens in a new tab), a program waits about 24 weeks for a bespoke environment and about 3 for a vended one once the landing zone exists.

The first workload enclave is built end to end as part of the engagement. It proves the pattern before any program depends on it.

Built as Code, Owned by the Agency

The whole environment is delivered as Terraform, CloudFormation or Bicep in the agency's own repository, with data rights set by the contract. Build tooling usually starts from AWS Control Tower and the Landing Zone Accelerator, or the Azure landing zone reference implementations, then adapts them to the agency's design.

Code makes the environment reviewable line by line, rebuildable after an incident, and repeatable for the next program. It also means changes go through review rather than through the console, which is what keeps the evidence true after the build team leaves.

Every significant design choice is recorded in an architecture decision record: the options considered, the choice made, and why. When an assessor or a new engineer asks why the network is shaped the way it is, the answer is written down.

Evidence as You Build

The validation and documentation phase, typically two to three weeks, runs compliance scans against the design and assembles:

• control-implementation statements for the environment-layer controls;
• authorization-boundary and data-flow diagrams;
• documentation of which controls are inherited from the cloud provider and which the agency implements;
• operations runbooks.

These are inputs to the agency's SSP, written so the ISSO can use them directly. They are not the SSP itself, and they are not an assessment. The builder of an environment should not be its assessor; testing evidence holds up (opens in a new tab) only when it comes from someone independent of the work being tested.

Impact Levels Change the Build

The same layers apply at every impact level, but the details shift. A DoD IL4 environment adds Cloud Computing SRG requirements for the provider offering, connection paths and STIG baselines. IL5 adds dedicated infrastructure requirements and, often, cleared personnel. Each added impact level or enclave adds weeks to the schedule and cost to the build.

Cloud offerings themselves are now "FedRAMP Certified" in classes A through D under the 2026 Consolidated Rules (opens in a new tab). That certification covers the provider's offering only. The agency's environment still needs the agency's own authorization, which is what the evidence above supports.

Cost-Aware by Design

Architecture is where most cloud waste starts, so cost controls belong in the foundation rather than in a later cleanup. Three are built in:

• A tagging standard enforced by guardrails. Every resource carries program, environment, owner and funding tags, and untagged resources are blocked or flagged at creation. Without that, no one can later say which program is paying for what.
• Budgets and alerts per account. Each vended environment gets a budget with alerts at defined thresholds, so a runaway workload is visible in days, not at the end of the quarter.
• An account strategy that matches funding. When accounts line up with programs and appropriations, cost reports line up with budgets without manual allocation.

None of this replaces financial operations, but it gives a FinOps practice clean data to work with from the first day.

Keeping the Evidence True: Drift

An environment that matched its documentation on the day of the build can drift within weeks. Someone changes a security group through the console during an outage; a new service is enabled without a guardrail; a baseline is patched in one account but not another.

Three practices keep the evidence true after handoff. First, changes go through the code repository and review, not the console, with console write access limited to break-glass roles. Second, configuration scanning runs on a schedule against the same baselines used at validation, and findings route to the platform team. Third, guardrails that detect rather than prevent are reviewed periodically to decide whether they should become preventive. This is the foundation for continuous monitoring, though running that monitoring program is the agency's responsibility, often with a separate operations service.

Common Failure Patterns

The same mistakes show up in most stalled federal cloud foundations:

Each one is cheaper to prevent in the design than to fix after programs depend on the environment.

Knowledge Transfer Is a Deliverable

A landing zone the agency cannot operate is a liability. The final phase runs working sessions with agency engineers and security staff on operating, extending and defending the environment, and hands over the backlog of work not in scope. A landing zone is a living platform; someone has to own it after the build.

What It Takes

A full design and build typically runs about 3.5 to 6 months: kickoff and discovery, three to five weeks of target architecture with ISSM design reviews, four to ten weeks of build, then validation and knowledge transfer. The agency provides a sponsor who can make architecture decisions quickly, ISSM time for design reviews, network and identity team participation, and the cloud accounts and consumption funding.

Avalon's Cloud Architecture & Engineering service designs and builds federal landing zones as code, maps every guardrail to NIST SP 800-53, and delivers the control-implementation evidence your ISSM needs, in unclassified environments through IL4, one engagement at a time.