Organising cloud at scale: autonomy without loss of control

1. Start with the domain model, not with accounts

In many enterprises, accounts or subscriptions are created per project. This seems pragmatic, but at scale, it becomes a structural problem. Accounts should not stem from project planning, but from an explicit domain model.

Before creating new accounts, it must be clear how the organization structures its business capabilities, what isolation requirements apply per domain, and which compliance or data classification rules require architectural separation. Account structure arises from responsibility and risk management, not from temporary needs.

Too many accounts increase governance complexity and IAM overhead. Too few accounts increase blast radius and compliance risk. The right balance is coherent, not maximum or minimum.

2. Landing zones as an enforceable standard

Landing zones are not technical templates but the translation of your governance model into infrastructure. They determine how logging, network segmentation, identity structure, tagging, and security settings are to be configured by default.

It is crucial that landing zones are not optional. Every new account must be automatically rolled out with the same baseline for audit logging, network configuration, identity principles, and mandatory tagging. This baseline must be version controlled and technically enforced via policy engines, not through guidelines in documents.

Overly strict baselines can delay innovation. Too lenient baselines lead to drift. The right choice is to make infrastructure standards rigid, while allowing differentiation at the workload level.

3. Design identity centrally, apply locally

In complex cloud environments, identity is the primary control mechanism. When IAM grows organically, the organization loses oversight. Roles are copied, privileges are expanded out of pragmatism, and temporary accesses remain.

A scalable model centralizes identity architecture but decentralizes usage. This means one central source for identities, no local identity stores per account, and a strict separation between human and machine identities. Rights are granted through role-based structures with predefined privilege categories.

Product teams can grant access within those boundaries, but defining new privilege classes remains a central responsibility. This way, speed is achieved without privilege creep.

4. Governance through code, not through discussion

Governance that relies on approval meetings does not scale. Governance that is built into provisioning and deployment flows does.

Policy-as-code should therefore form the primary governance layer. Resource creation is automatically checked against encryption requirements, network standards, and tagging obligations. Deviations are not audited afterwards, but blocked or flagged immediately.

This requires a conscious trade-off. Too many policies create frustration and stimulate shadow IT. Too few policies create fragmentation. Mature organizations measure policy violations and refine guardrails based on actual usage instead of theoretical risks.

5. Costs as an architectural design variable

FinOps at scale means that costs are not a reporting dimension but a design variable. Budget responsibility lies explicitly with the domain owners, who have real-time visibility into their consumption. Tagging standards are not optional but enforceable, so costs can be allocated correctly.

Additionally, lifecycle mechanisms must automatically shut down or archive resources when no longer required. Reserved capacity and savings plans are optimized centrally, but usage is made locally visible.

Transparency is not optional here. Without transparency, invisible inefficiency arises; without accountability, budget shifts occur without behavioral effects.

6. Explicitly define the platform mandate

Cloud at scale requires a platform organization with a clear mandate. This organization is responsible for landing zones, identity governance, policy-as-code, network architecture, platform observability, and cost governance tooling.

What the platform should NOT do is take over application management or workload ownership. The platform designs the playing field but does not play the game.

Success is measured in the adoption of standards and the reduction of variation, not in the number of approved requests. Too little mandate leads to fragmentation, too much mandate to bureaucracy. The balance lies in enforceable frameworks combined with self-service.

7. Platform-wide observability

Manageability requires visibility across accounts and regions. Logging and audit data must be centrally aggregated and normalized. Security events, IAM anomalies, and policy violations must be correlatable platform-wide.

Without central correlation, each incident becomes a forensic exercise. With central observability, behavior becomes predictable and manageable.

8. Systematically prevent shadow platform formation

When central platform capacity is insufficiently mature, domains build their own infrastructure layers. This seems efficient but undermines coherence.

You do not prevent this through prohibition, but through attractiveness. A clear service catalog, rapid iteration on platform capabilities, versionable modules, and short feedback loops make the platform more attractive than self-build.

Shadow platform formation is not rebellion but a symptom of organizational delay.

9. Cloud architecture as part of enterprise architecture

Cloud at scale cannot be disconnected from enterprise architecture. Cloud principles must be integrated into the architecture governance. New domains follow the existing account model, integrations respect identity and network standards, and deviations are explicit and temporary.

Cloud architecture is not an operational detail but an infrastructure strategy.