Cloud & Enterprise IT
Landing Zones & Infrastructure as Code
Secure, repeatable cloud foundations built from code rather than clicks.
What this covers
A landing zone is the foundation an agency's cloud workloads sit on: account structure, identity integration, network topology, centralized logging, and guardrails that prevent common mistakes. Building it from code makes it reviewable, repeatable, and recoverable.
Typical activities
- Multi-account or multi-subscription design aligned to the agency's departments and data classifications
- Identity federation with the agency's directory and role design for least privilege
- Hub-and-spoke or transit networking with private connectivity back to agency sites
- Centralized logging, monitoring, and alerting
- Preventive guardrails, such as service control policies and policy-as-code
- Terraform, CloudFormation, Bicep, or Pulumi modules with version control and review workflows
What you receive
A documented reference architecture, the infrastructure code and pipelines that deploy it, an operations guide, and training for agency staff who will own it.
Why it matters
Agencies that start with a landing zone avoid the sprawl of ad hoc accounts, inconsistent security, and untraceable spending. It also makes later authorizations, such as StateRAMP alignment, far easier because the controls are already in place and evidenced by code.
Conditions that usually prompt this work
Agencies generally start this work after one of a few specific conditions appears:
- No one can produce a current list of the cloud accounts or subscriptions in use and the person accountable for each.
- Address ranges were chosen project by project and now overlap, which blocks private connectivity back to agency sites and between workloads.
- Rebuilding an environment depends on one engineer's memory, because the original was built by hand in the console.
- Privileged access is split, with some accounts federated to the agency directory and others still using local administrator logins that no one has reviewed.
A migration that is about to begin is the other common trigger. Account structure, network paths, and identity are harder to change underneath an application that is already serving the public than to settle before it lands.
What separates a sound build from a weak one
The working test is whether agency staff can point the code at an empty account or subscription and stand up the environment, and whether they have actually done that rather than assumed it. Supporting signs are state held in a shared backend with locking and access control, modules that are versioned and pinned rather than floating, a deployment pipeline with its own scoped identity instead of long-lived static keys, and log destinations that workload administrators cannot delete from. Guardrails belong in preventive form where the risk warrants a hard block, and in detective form where a block would stall legitimate work.
Weak builds are recognizable:
- Drift. The code was written once and then bypassed, so a later plan returns a long list of differences.
- One enormous state file. When a single state covers everything, routine changes carry the blast radius of the whole environment.
- A wrapper only the vendor can run. If agency staff cannot execute a plan and an apply themselves, the code has not really been transferred.
- Documentation that the repository does not match. The diagram shows one architecture and the code produces another.
What to require in the solicitation
Write requirements that can be tested at acceptance rather than described in a proposal:
- Code is committed to agency-owned version control from the first sprint, not delivered as an archive at closeout.
- The tool is named and conventional, such as Terraform, OpenTofu, CloudFormation, Bicep, or Pulumi, with license terms stated and no proprietary configuration language the agency cannot maintain.
- Acceptance includes a rebuild into a clean account or subscription, run by agency staff with the vendor observing.
- Implemented controls are mapped to a named baseline, such as NIST SP 800-53 or the CIS benchmark for the platform, with each control marked preventive or detective.
- Secrets handling, the state backend, and the break-glass procedure are documented and demonstrated on the agency's own environment.
- Data and intellectual property rights are settled before award, including whether reusable modules the vendor brings are licensed or assigned.
How to verify it worked after handover
Choose measures the agency can check without the vendor. Run a scheduled plan against production and see whether it comes back empty, since a persistently noisy plan means the environment is being changed outside the code. Review privileged console activity in the platform's audit log and watch whether manual changes decline. Track how long agency staff need, unassisted, to stand up a compliant environment for a new application, and compare that with what the same request used to take. Check what share of resources carries the tags the agency's cost allocation and grant reporting depend on. When the next audit request arrives, note whether evidence comes out of the repository and the log archive as routine work or becomes a project of its own.
Working with HQT on this
HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.
Frequently asked questions
How much of a landing zone should be in place before the first workload moves?
Enough that the first application does not have to invent its own account placement, network path, identity model, or logging destination. In practice that means the account or subscription structure, connectivity, directory federation, centralized log collection, and a first set of guardrails, with further modules added as later workloads require them. Building every module that might eventually be needed tends to produce code that is never exercised and that drifts before anything uses it.
Can we use AWS Control Tower or the Azure landing zone accelerators instead of a custom build?
They are reasonable starting points and are meant to be used that way rather than starting from an empty page. What they do not supply is the agency-specific part: how departments map to accounts or subscriptions, how the agency directory and multi-factor requirements integrate, which address ranges are free on the existing network, what the tagging scheme has to produce for cost allocation and grant reporting, and which controls auditors will ask about. Expect the platform baseline plus agency configuration expressed in code, rather than one or the other.
Who owns the infrastructure as code when the contract ends, and can agency staff maintain it?
That depends on what the contract says, which is why it is worth settling before award rather than at closeout. Ask for code in agency-owned version control from the beginning, conventional tooling rather than a proprietary layer on top of it, and explicit data and intellectual property terms covering any reusable modules the vendor brings. Maintainability is testable: have agency staff run a plan and apply a real change during acceptance, with the vendor observing rather than typing.
Does a landing zone make our agency compliant with programs such as StateRAMP, CJIS, or IRS Publication 1075?
No, and the three work differently from one another. StateRAMP assesses cloud service offerings against a NIST SP 800-53 baseline for state and local government buyers, the FBI CJIS Security Policy governs how agencies and their vendors handle criminal justice information, and IRS Publication 1075 sets safeguards for agencies that receive federal tax information. A landing zone can implement many of the underlying technical controls consistently and leave logs and code that serve as evidence, which reduces the collection work an assessment requires. Confirm what applies to a specific system with the authorizing body, such as the state CJIS systems agency, before relying on any mapping.
What happens when someone makes a change in the console instead of the code?
The environment drifts from what the code describes, and the next plan reports differences that someone has to reconcile by reverting the change, importing it, or updating the code to match. Agencies usually accept that urgent changes will sometimes be made by hand and handle them with a documented break-glass path: an identity that is normally unused, an alert when it is used, and a requirement to write the change back into code afterward. Preventive guardrails narrow what can be altered by hand at all, and the platform audit log shows when it happened.