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.