What Is a Control Plane Dependency?
A Control Plane dependency exists when your system's ability to serve traffic requires making a configuration change to the infrastructure. In other words: your Data Plane cannot function without calling the Control Plane.
This is the most common architectural mistake in cloud-native systems, and it is almost always invisible until a real outage exposes it.
A Concrete Scenario
You have a fleet of servers processing video uploads. Your auto-scaling logic is reactive:
- The Dependency: Your code says: "If CPU > 80%, call the EC2
RunInstancesAPI to launch a new instance." - The Failure: A major AWS incident degrades the EC2 Control Plane.
RunInstancescalls start timing out or returning errors. - The Cascade: Your existing servers get overwhelmed. Request queues back up. Timeouts increase. Servers start crashing under load.
- The Result: Your entire video processing service goes down — not because EC2 instances stopped working, but because you couldn't launch new ones.
The cruel irony is that your existing instances are perfectly healthy. The Data Plane is fine. But because your scaling strategy depended on the Control Plane, a Control Plane degradation became a total service outage.
Other Common Control Plane Dependencies
| Pattern | Control Plane Call | Risk |
|---|---|---|
| Reading config from SSM Parameter Store on every request | GetParameter API |
SSM outage crashes your app |
| Fetching secrets from Secrets Manager per request | GetSecretValue API |
Secrets Manager throttling causes failures |
| Calling IAM to validate permissions at runtime | SimulatePrincipalPolicy |
IAM degradation blocks all requests |
| Updating a DNS record to trigger failover | Route 53 ChangeResourceRecordSets |
DNS change may not propagate during outage |
| Calling KMS to decrypt data on every read | Decrypt API |
KMS throttling causes read failures |
The pattern is always the same: a call that should be a one-time setup operation has leaked into the per-request hot path.