Cloud providers' reference architectures are written for large enterprises with platform teams. A small agency with two developers and a contractor does not need most of it, but it does need a few things done right at the start, because they are the things that are painful to fix later: how accounts are organised, how people get access, where logs go, and how changes get made.
This note is the short list. It applies to AWS GovCloud (US) and to Azure Government; the names differ, the shape does not.
Accounts and organisation
One organisation, a small number of accounts (or subscriptions) with a clear purpose each: a management account that runs nothing, a logging account that everyone writes to and few can read, a shared-services account for identity and networking, and then one account per environment per system (development, test, production). Workloads never share an account with each other or with the platform.
This costs nothing extra and it is the single decision that makes everything after it simpler: permissions, cost reporting, incident scope, and eventually giving a system to another team.
Identity
Nobody logs in with a long-lived key. Staff and contractors sign in through the agency's identity provider with multi-factor authentication, get a role for the time they need it, and lose it when they leave. Service accounts are roles, not users. Break-glass access exists, is logged, and is tested once so that it works when needed.
Guardrails, not gates
A short set of rules enforced by the platform: no public storage buckets, no resources outside the government regions, encryption on by default, required tags for cost and ownership, and a deny on the handful of actions nobody should ever take in production from a laptop. These are written as policy, applied at the organisation level, and they never block a developer who is doing ordinary work.
Logging that someone will read
Every account writes its audit trail, network flow logs, and application logs to the logging account, retained for the period the agency's records rules require. A small set of alerts on things that matter (a new user with administrative rights, a change to the guardrails, a spike in cost) goes to a place a person actually watches. Everything else is kept for when it is needed.
Infrastructure as code from the first day
The landing zone itself is code, in the agency's repository, applied through a pipeline with review. So is every workload deployed into it. The first time someone asks "what changed?" the answer is a commit, not a memory. This is also the deliverable that makes the platform transferable: another team, or another contractor, can read exactly what exists.
A path to authorisation
For federal systems the landing zone is where most of the inherited controls live. Building it with the control catalogue in view (NIST SP 800-53, and the provider's own inheritance for the government regions) means the system security plan for the first workload is mostly written by the time the workload arrives. For state and local agencies the same structure answers most of what a StateRAMP or an auditor's questionnaire asks.
What it is not
It is not a data centre in the cloud. Lifting virtual machines as they are, one for one, brings the old operating problems along and adds a bill. The landing zone is worth building because the first workload into it should be built to run there: managed databases, containers or serverless where they fit, and backups and patching handled by the platform rather than a person.
What to ask a contractor for
- A written account structure with the reason for each account.
- The guardrail policy set, in code, with a test that shows each one working.
- The logging design with retention periods tied to your records schedule.
- The pipeline that deploys the landing zone itself, and a runbook for the day-two tasks: adding a user, adding an account, responding to an alert.
- A first workload deployed through the same pipeline, as proof.
Working with us
We build landing zones, infrastructure as code, CI/CD, and observability on AWS, Azure, and Google Cloud, including the government regions, and we operate them under a published service level agreement. If your agency is about to put its first system in the cloud, or is living with one that was put there in a hurry, tell us what you're working on.