Hosted control plane: when it simplifies operations and when it adds complexity

A  hosted control plane  moves Kubernetes control-plane components off your worker fleet either into a provider-managed boundary (EKS) or onto a separate hosting cluster as pods (HyperShift). It simplifies ops when you want predictable upgrades, less per-cluster snowflake work, and cleaner separation between “management” and “workloads.” It adds complexity when control-plane connectivity, IAM, and shared blast radius become your new failure modes especially with private clusters. Define hosted control plane in concrete terms If you can’t say where the API server and etcd live, you can’t model risk. “Hosted control plane” is a placement decision. EKS: hosted by AWS in an EKS-managed VPC AWS owns the masters; you own nodes and workloads. AWS documents that the EKS- managed control plane runs inside an AWS-managed VPC and includes Kubernetes API server nodes and an etcd cluster. API server nodes run in an Auto Scaling group across at least two AZs; etcd nodes span three AZs. What that mea