Cloud control plane
A cloud control plane is the layer of interfaces, APIs, and services that let you provision, configure, and manage infrastructure — separate from the data plane, which actually runs your workloads and moves your traffic. Every provider ships its own; the term also covers systems that manage several providers as one plane.
Every piece of infrastructure has two separate layers. The data plane is the infrastructure itself: the virtual machines running your application, the network moving packets between them, the disk serving reads and writes. The control plane is everything you use to decide what that infrastructure should look like and to change it — the API, the console, the CLI, the permission system that decides who is allowed to make a change. When you create a VM in a cloud console, resize a disk, or open a firewall port, you are operating the control plane. The instance that boots, the extra gigabytes that become available, the traffic that starts flowing — that is the data plane responding to what the control plane told it to do.
The distinction gets more useful once a team runs more than one provider. AWS has a control plane. So does Google Cloud, Azure, Hetzner, and every other provider — each with its own console, its own API shape, its own credentials, its own idea of what a 'security group' or a 'firewall rule' is called. A team running three clouds and twenty bare-metal servers is really operating three or four separate control planes side by side, plus whatever they use to manage the servers that aren't in any cloud at all. Nothing forces those control planes to agree with each other, and nothing outside your own process keeps a change made in one of them visible to someone looking at another.
'Cloud control plane' is also used more narrowly — inside Kubernetes, the control plane is the API server, scheduler, and controller-manager that decide where pods run, as distinct from the kubelets and containers actually running them on nodes. A 'multi-cloud' or 'unified' control plane extends the same idea across providers: one place to see and act on infrastructure that physically lives in several different accounts, regions, and vendors, instead of one interface per provider. It does not replace the underlying provider control planes — a request still ends up as an API call to AWS, or Hetzner, or the fleet agent on a bare-metal box — it sits in front of them so the person making the change only has to learn one system.
Why the distinction matters operationally
Most infrastructure incidents and audit gaps trace back to control-plane problems, not data-plane ones: a change nobody logged, a permission nobody revoked, a firewall rule opened in one provider's console that nobody else on the team can see. When each cloud has its own control plane and its own audit trail, "who changed this, and when" becomes a question you answer by logging into three or four different consoles and comparing timestamps by hand — or by not answering it at all. For teams under compliance frameworks such as NIS2, that gap is not just inconvenient: change history, access control, and incident evidence are exactly what an auditor or a regulator asks for first, and a fragmented control plane is the reason that evidence often does not exist in one place.
How Sencai fits in
Sencai is a control plane that sits above the native ones: it connects to accounts across eleven cloud providers plus on-premise and bare-metal servers through a lightweight fleet agent, and inventories what is already running the moment an account is connected — no migration required. From there, provisioning, starting, stopping, resizing, and destroying instances works the same way regardless of provider. You can connect existing accounts (nothing moves, credentials stay revocable at the provider) or let Sencai provision and bill capacity directly, and mix both in one organisation. Every action across every connected provider lands in a single append-only, hash-chained audit log, so "who changed this, and when" is a query, not an investigation.
See inventory and provisioning →