The control plane is the machinery that creates, changes and deletes resources. The data plane is what the resources do day to day. Data planes are usually simpler, so they often keep working when the control plane is impaired, which is why you should know which of your actions depend on which.
Definitions
AWS documentation draws the line like this. Control planes provide the administrative APIs used to create, read, update, delete and list resources. Launching a virtual machine, creating a storage bucket and describing a queue are control plane actions. The data plane provides the service's primary function: the running machine, reading and writing a volume, getting and putting objects, answering DNS queries.
The terms come from networking, where a router's data plane moves packets by rules and the control plane creates and distributes those rules.
Why the two fail differently
The AWS fault isolation whitepaper notes that control planes tend to be complicated orchestration and aggregation systems, while data planes are intentionally less complicated, with fewer moving parts. That makes failure events statistically less likely in the data plane.
The static stability article adds a practical consequence. During a control plane impairment, a running server may not see updates such as a new instance or a new firewall rule, but traffic it was already handling continues to flow.
| Action | Plane | Likely to work during a control plane problem? |
|---|---|---|
| Serve a web page from a running server | Data | Usually yes |
| Read an object that already exists | Data | Usually yes |
| Launch a new server | Control | Possibly not |
| Change a security group rule | Control | Possibly not |
| Rotate a credential | Control | Possibly not |
"Usually" and "possibly" matter here. These are design tendencies described by the provider, not guarantees for every incident.
Mapping the idea onto your own product
Your product has the same split even if you never use those words.
- Data plane: handling a login with an existing session, serving a request, processing a queued job.
- Control plane: creating an account, deploying a release, changing a setting, issuing a new key.
Ask which of your actions must work during an incident. Often it is a surprise. A rollback is a control plane action. So is rotating a leaked secret. If your deployment system or identity provider is the thing that is down, the emergency fix you need most may be the one you cannot perform.
What to do with this
- Write two columns for your top three services: what keeps users working, and what lets you change things.
- Mark every item in the second column that you would need during an incident, such as rollback, key rotation, feature flag changes and scaling.
- For each marked item, decide on a fallback. That might be a break-glass credential held offline, a local copy of the last release artifact, or a documented manual step.
- Keep the data plane free of calls to the control plane in the request path. A request that needs a fresh configuration fetch to succeed has quietly joined the two.
- Rehearse one control plane failure in a game day and see whether the fallback works.
If a fallback needs a credential, store and test it in the way you would for any break-glass access, and keep a record of when it was last used.
A worked example: the emergency you cannot perform
This scenario is hypothetical. A team runs a customer facing application. One afternoon its deployment service becomes unreachable. Customers are unaffected, because the running application is the data plane and it does not call the deployment service. Then the team discovers a vulnerable component in the application and decides to ship a fix. Now the control plane matters.
| Task during the incident | Plane | Depends on | Fallback written down? |
|---|---|---|---|
| Customers keep using the app | Data | Running instances, database | Not needed |
| Ship a patched build | Control | Deployment service, registry | No |
| Roll back to last release | Control | Deployment service, previous artifact | No |
| Rotate an exposed key | Control | Secrets manager, identity provider | Partly |
| Turn off a risky feature | Control | Feature flag service | Yes, local override |
| Add capacity | Control | Orchestrator | No |
Four of the six rows have no fallback. That is the useful result. The team did not need a deep redesign to learn it, just a table and half an hour.
Step by step: building fallbacks for control plane actions
- Pick the three control plane actions you would most need in a bad hour. For most teams these are rollback, key rotation and a way to switch something off.
- For rollback, keep the last two known good release artifacts somewhere that does not depend on the deployment service. Document the manual command to start one.
- For key rotation, write the order of steps and make sure the person who does it can reach every system involved. Practice in staging.
- For switching a feature off, support a local override such as an environment variable or file that the application reads, in addition to a hosted flag service. Our post on kill switch design lists what to include.
- For capacity, decide the highest load you can carry without adding anything and monitor how close you run to it.
- Review the table each quarter. New services and vendors change it.
Why simplicity of the data plane is a design goal
The AWS material says data planes are intentionally less complicated than control planes. You can borrow the idea. Keep the request path short and free of calls to orchestration, configuration fetches and approval systems. Anything complicated that must sit in the path deserves its own failure plan. When you review a new feature, ask whether it adds a control plane call to the data plane. If it does, that is a design cost, and the review is the cheapest moment to reconsider.
Security controls and the two planes
Security tooling has both planes as well. Enforcement, such as a check that blocks a bad request or a gate that stops a vulnerable version from deploying, is closer to the data plane of your delivery process. Configuration of those rules is the control plane. If a policy service is unreachable, decide in advance whether enforcement continues with the last known rules, which is the statically stable choice, or stops. Our post on whether a scanner outage should block pull requests walks through the trade-off.
Try it yourself
Open the vulnerability management demo and look at how findings are tracked and acted on over time. Notice which steps are about viewing the current state and which change it, and think about which you would need during an incident.
Click through it at your own pace, or open it full screen.
Quick check
Is the data plane always safe from outages?
No. It is usually simpler and so less likely to fail, but it can fail, and a control plane change can break it. The point is to know which dependencies each plane has.
Where does a CI/CD pipeline fit?
Mostly the control plane of your product. It changes what runs; it does not serve users. That is why a pipeline outage often blocks fixes without affecting current customers.
Can a single system be both planes?
Yes, and that is a risk. When the same service handles requests and also accepts configuration changes, a problem in one can disturb the other. Separating them lets each be scaled and protected on its own terms.
Sources
- Control planes and data planes (AWS Fault Isolation Boundaries)
- Static stability using Availability Zones (AWS Builders Library)
Last reviewed: 19 October 2026.
