Skip to content

CONCEPT Cited by 3 sources

Managed data plane

Managed data plane is the architectural primitive where the vendor operates the data-plane processes, not just the control plane. The customer still defines routes / policies / config through the control plane, but the processes that carry bytes — proxies, routers, gateways — are lifecycle-managed by the vendor: image updates, crash recovery, version policy, resource sizing.

The canonical modern example in this wiki is Amazon ECS Service Connect, which ships a managed systems/envoy proxy (the "Service Connect Proxy") per ECS Task. The contrast case is AWS App Mesh: same Envoy data plane, same xDS-shape config, but the sidecar container is customer-managed — the customer ships the image, sets resource limits, handles crash loops.

Why it matters

concepts/control-plane-data-plane-separation is a separation of concerns — who decides vs. who delivers. Managed data plane is a separation of operational ownership on the data-plane side. The two axes are orthogonal:

Customer-owned data plane Vendor-managed data plane
Customer-owned control plane DIY Envoy + custom xDS. Databricks' Robinhood-style proxyless meshes live near here. Rare — customer control over policy, vendor operates the proxies.
Vendor-managed control plane App Mesh classic, Istio. Customer still runs Envoy. Service Connect, VPC Lattice. Customer just declares intent.

The lower-right quadrant is where AWS is pushing its service-mesh story.

The operational-boundary tradeoff

What the vendor taking over gets you

  • No sidecar-image lifecycle. No version pinning, no CVE-patch rollouts, no "which Envoy build are we on?"
  • No crash-recovery code paths. The managed proxy's uptime/restart story is the vendor's problem.
  • No resource-tuning loop. Proxy memory/CPU sizing is a vendor-chosen default, not a customer operational knob.
  • Faster migration off. When the vendor sunsets the service (App Mesh EOL 2026-09-30), the EOL cutover is simpler because no customer code lived inside the data-plane container.

What it costs

  • Configurability narrows. Service Connect exposes only timeouts from the Envoy configuration surface; retry/outlier-detection/ health-check tuning are vendor defaults. App Mesh exposed the full Envoy knob-set.
  • Feature gaps lag. Service Connect does not (at 2025-01-18) support mTLS or weighted version routing, both of which App Mesh's customer-managed Envoy supported.
  • Vendor's roadmap = your feature set. You inherit the vendor's priorities and cadence; no dropping in a custom Envoy filter.
  • Observability is the vendor's shape. On the flip side: Service Connect gives you free CloudWatch application-level metrics — the vendor's shape, but for free.

Wider instances beyond service meshes

The managed-data-plane idea generalises beyond the sidecar/mesh context:

  • Managed databases (Aurora, RDS) are managed storage data planes — customer owns schema/queries (control surface), vendor operates the DB process.
  • API Gateway is a managed HTTP data plane in front of Lambda/ECS backends.
  • CloudFront is a managed edge CDN data plane with customer-declared behaviors.
  • EKS Auto Mode is the Kubernetes-layer instance — AWS operates the K8s data plane (nodes, OS, default add-ons, cluster upgrade cadence) while the customer retains the workload layer (Deployments, Services, HPA, custom add-ons). The same tradeoff applies at K8s scale: customer loses fine-grained control over when nodes are upgraded in exchange for not having to run that lifecycle themselves. The customer-retained-control surface becomes disruption budgets (see patterns/disruption-budget-guarded-upgrades) rather than timeout/retry knobs.

In each case the trade is the same: the customer gives up operational flexibility on the data path in exchange for not having to run it.

Seen in

  • sources/2025-01-18-aws-app-mesh-discontinuation-service-connect-migration — canonical write-up of the primitive. App Mesh's self-managed Envoy sidecar → Service Connect's AWS-managed Service Connect Proxy is framed explicitly: "Service Connect eliminates the undifferentiated heavy lifting associated with managing sidecar proxies." The five feature-delta cells in the comparison table are all instances of the configurability-vs-managed tradeoff above.
  • sources/2026-03-23-aws-generali-malaysia-eks-auto-mode — EKS Auto Mode as the Kubernetes-layer managed data plane: AWS operates the node fleet (Bottlerocket AMI, weekly replacement cadence, default add-on upgrades, cluster-version upgrades). Generali's customer-retained surface is the node-pool policy (instance types / zones / scale bounds) plus the disruption-budget- guarded-upgrades contract (PDBs + NDBs + off-peak maintenance window). The Kubernetes instance sits on the same spectrum as Service Connect's sidecar instance and Lambda's fully-serverless instance — same primitive, different layer.
  • sources/2026-04-06-aws-unlock-efficient-model-deployment-simplified-inference-operator-setup-on-amazon-sagemaker-hyperpod — EKS-add-on variant of the managed-data-plane primitive at the Kubernetes-operator layer. AWS's SageMaker HyperPod Inference Operator previously shipped as a Helm chart (customer owns Helm-release lifecycle + dependency-version management + IAM role scaffolding + S3/VPC-endpoint prereqs); as of 2026-04-06 it ships as a native EKS add-on with AWS operating the operator pod's lifecycle, dependency add-on provisioning (cert-manager / S3 CSI / FSx CSI / metrics-server), version-bumping, and rollback-on-failure. The customer declares intent via aws eks create-addon configuration; AWS runs the bytes. Canonical wiki instance of patterns/eks-add-on-as-lifecycle-packaging as a managed-data-plane delivery shape — same spectrum as App Mesh → Service Connect (sidecar layer) and EKS Auto Mode (node layer), now at the Kubernetes-operator layer.
Last updated · 200 distilled / 1,178 read