---
title: "Multi-account and multi-cluster platform"
chapter: "11"
---

# Multi-account and multi-cluster platform

A platform is a paved road: safe defaults, reusable services, and clear escape
hatches. It is not one giant cluster controlled by one team.

## Boundary choices

Use accounts for strong ownership, billing, quota, and policy separation. Use
clusters for regional, trust, lifecycle, or failure boundaries. Use namespaces
for lighter team and application separation. Keep production and
non-production blast radii intentional.

## Platform contract

Publish supported Kubernetes versions, compute models, ingress patterns,
identity method, base policies, SLOs, upgrade cadence, incident ownership,
backup expectations, and deprecation windows. Offer templates for Deployments,
autoscaling, observability, Pod Identity, and delivery.

## Reconciliation

Use infrastructure as code for accounts, VPCs, clusters, IAM, and add-ons. Use
GitOps such as Argo CD or Flux for governed Kubernetes configuration. Avoid two
controllers managing the same field. Roll global policy from audit to canary to
enforcement.

## Fleet operations

Standardize where sameness lowers risk; allow differences where region,
regulation, workload, or lifecycle requires them. Track cluster inventory,
versions, add-ons, policy exceptions, ownership, cost, and SLOs.

## Feynman check

The platform team builds roads, signs, and guardrails. Application teams drive
their cars. A paved road makes the safe path easy without taking away every
destination.