Build a cloud foundation teams can actually use

Start with the first real workload

A cloud foundation can become an impressive collection of policies and networks while application teams still cannot deploy a useful service. Choose a representative workload early and use it to test the foundation's decisions.

For example, an internal document assistant needs identity, private data access, model connectivity, logs and a deployment path. Following that workload from source code to a supported environment exposes gaps that an account hierarchy alone does not reveal.

Do not treat the pilot as an exception to every rule. Its purpose is to show whether the intended defaults work for a realistic service.

Separate shared responsibilities from workload ownership

Platform capabilities may include central identity integration, audit collection and common connectivity. Workload teams still need clear responsibility for their application data, runtime behaviour and recovery procedures.

Provider landing-zone approaches offer structures for this separation. Azure describes platform and application landing zones, while AWS Control Tower supports governance of a multi-account environment. These are useful starting points, not proof that a particular organisation's operating model is complete.

Choose boundaries for a reason

Accounts or subscriptions can help separate environments, ownership and access. Decide which differences justify a boundary rather than reproducing the organisation chart mechanically.

A production workload may need stricter change authority than a sandbox. A shared network service may need a different operator from the application team. Document those reasons so future teams can choose the appropriate placement.

Too little separation creates broad access and unclear cost ownership. Too much separation can create unnecessary connectivity and administration work. Use the actual workload and support model to balance them.

Keep shared services deliberately small

Centralising a capability can improve consistency, but it also creates a dependency. A shared DNS or deployment service outage may affect many workloads at once.

For each shared component, name its owner, support expectations and recovery path. Ask whether the benefit of centralisation justifies that dependency. Do not add a central service merely because a reference diagram includes one.

Test the operating path end to end

Have a workload team provision an environment, deploy a service, inspect a denied action, retrieve logs and perform a recovery exercise. Measure the manual interventions required.

The foundation is useful when teams can repeat that path with understandable controls. A completed infrastructure deployment is only the beginning. The real result is a service that can be changed and supported without relying on undocumented administrator access.