Control Plane and Data Plane

Most infrastructure splits into two halves that are worth naming separately. The control plane is the management surface: the console, the configuration, the thing that decides how many workers exist, which keys are valid, and what the routing rules are. The data plane is the path a real request travels: the workers that answer, the network that carries the answer, the storage that holds what the answer was built from. The distinction is not academic, because the two halves fail independently and the difference decides what you say to customers. A control plane outage typically means nothing new can be provisioned or changed while everything already running continues to serve. That is a bad hour for your engineers and, if you handle it quietly, an ordinary hour for your users. A data plane outage is the opposite: nobody can be served, but you can still see and configure the system that is failing. Treating both as down is how a status update ends up wrong in a way customers remember. The split is also the shape behind several arrangements a buyer will be offered. A vendor can run the management surface while the workloads and the data stay in the customer's own account, which is what makes that model possible at all; the vendor sees configuration and metadata, the customer keeps the request path. That is a meaningful boundary and worth asking about precisely, because what crosses it varies: some designs send only configuration one way and health signals the other, and some quietly route the work itself. Two questions are enough to get started. If the vendor's management surface is unreachable, does our traffic keep flowing? And when we make a change, does the instruction travel to our systems, or does our data travel to theirs? Ask the same pair about your own product before an incident forces the question, because the answer determines whether a bad deploy in the console is a customer-visible event or an internal one.