A landing zone for regulated workloads

A landing zone is the foundation every workload lands on: accounts or subscriptions, identity, networking, logging and guardrails. In a regulated environment it is also the main control surface, so it has to satisfy auditors without becoming a queue that slows every team down.

The business problem

New products wait weeks for environments while security reviews each request by hand. Teams that bypass the process create shadow accounts with inconsistent controls. Audits then find gaps in logging, encryption or access that take months to close.

Constraints

• Regulatory requirements such as data residency, encryption, retention and segregation of duties.
• Multiple teams and products with different risk levels.
• Existing on-premises connectivity and identity provider.
• Evidence of control must be available at any time, not assembled for audits.

Architecture

Team requestNew product or environment, raised as a pull request

Landing zone controls

• Identity · single sign-on, roles per team, no long-lived keys
• Guardrails · organisation policies: regions, encryption, public access blocked
• Network · hub-and-spoke, private endpoints, inspected egress
• Logging · central, immutable audit and security logs
• Security · threat detection, posture checks, key management
• Baseline · tagging, budgets, backup policies applied on creation

• Production accountsOne per product, strict change control
• Non-production accountsSame guardrails, faster change
• Sandbox accountsIsolated, time-limited, no production data

Shared services

• Identity provider
• Central logging
• Security tooling
• Network hub
• Key management
• Backup vault

Account vendingFully automated after approval

1. RequestPull request with owner, data class and budget
2. Policy checkAutomated review against the data classification
3. ApproveRisk-based approval, not every request
4. CreateAccount, network, roles and baseline from code
5. Hand overPipeline, dashboards and cost view ready

Key decisions and trade-offs

• Preventive guardrails first: block what must never happen (public storage, unapproved regions, disabled logging) at the organisation level, rather than detecting it later.
• One account per product and environment: the account is the strongest isolation and the simplest cost and access boundary.
• Risk-based approval: low-risk requests are approved automatically; only high data classifications go to a human reviewer.
• Everything as code: accounts, policies and networks live in version control, so every change is reviewed and auditable.
• Central, immutable logs: workload teams cannot alter audit logs, which is what auditors look for first.