Skip to content

PATTERN Cited by 1 source

Managed sidecar

Managed sidecar is the pattern where the vendor owns the sidecar container's lifecycle — image, version, crash recovery, resource sizing — on behalf of the customer. Same physical patterns/sidecar-agent deployment shape (one auxiliary process per workload pod/task intercepting that workload's traffic or fetching its config), but the customer does not ship or operate the sidecar image. It's the sidecar-specific instance of the broader concepts/managed-data-plane primitive.

The canonical modern example is Amazon ECS Service Connect's Service Connect Proxy, an systems/envoy container AWS deploys into every ECS Task in a Service Connect Namespace. Customers declare intent (Client / Server / Client-Server role, namespace membership, timeouts) — AWS runs the proxy.

The classic counterpoint in the same family tree is AWS App Mesh, which ships the Envoy sidecar as a container image the customer runs inside each Task.

Shape

A managed sidecar differs from a customer-managed sidecar on four axes, all on the ops side — the in-pod architecture is identical:

Axis Customer-managed sidecar Managed sidecar
Image build / update Customer pulls/builds, pins version Vendor ships, updates continuously
Crash recovery Customer's orchestrator policy Vendor's managed restart loop
Resource sizing Customer-tuned limits Vendor default, sometimes adjustable
Config surface exposed Full (e.g. all Envoy knobs) Narrowed (e.g. only timeouts)

Benefits

  • No sidecar-image CVE treadmill. Patching the proxy data plane is the vendor's problem; customers don't track upstream Envoy security bulletins.
  • No customer-side version skew between control plane and data plane; vendor coordinates both.
  • Simpler EOL story. When the service is sunset (App Mesh EOL 2026-09-30 is the canonical case), customers don't have to migrate any code inside the data-plane container — just the declared configuration.
  • Reduced surface for operator errors (misconfigured sidecar resources, stale proxy versions, forgotten sidecar on a new Task Definition).

Tradeoffs

  • Narrowed configurability. Service Connect exposes only timeouts from the Envoy config surface; retry policies, outlier-detection thresholds, and health-check intervals are vendor defaults. App Mesh exposed the full set.
  • Feature gap risk. The managed variant often lags its customer-managed sibling on advanced features. At 2025-01-18, Service Connect lacked mTLS and version-weighted routing (two App Mesh features) — real blockers for some customers.
  • Vendor's roadmap is your feature set. No dropping in a custom Envoy filter, extension, or WASM plugin.
  • Vendor discretion on discontinuation. If the vendor sunsets the managed service (App Mesh itself!), you are forced onto a different managed service (Service Connect / VPC Lattice) or back onto a self-managed Envoy. Sovereignty tradeoff.
  • Observability in the vendor's shape. On the plus side: free and pre-wired (Service Connect → free CloudWatch app-level metrics). On the minus side: you can't reshape the metric surface if it doesn't match your observability stack.

When managed sidecar wins

  • Small team, standard requirements. The managed defaults are fine and operating Envoy yourself is pure overhead.
  • Traffic mostly RPC-ish, no exotic routing needs. You don't need the knobs the vendor hid.
  • Regulatory posture allows it. mTLS / data-residency / BYOK gaps don't apply to your workload.
  • Cost of operator headcount > cost of vendor's managed tier. Usually true for smaller orgs.

When customer-managed sidecar (or proxyless) wins

  • Need a specific Envoy filter / extension / WASM plugin.
  • Need configurability the vendor didn't expose (retry budgets, custom health-check logic, outlier-detection tuning).
  • Need mTLS / advanced routing / cross-account sharing today — see the App Mesh → Service Connect feature deltas.
  • Need to avoid vendor lock-in on the data-plane layer specifically. Alternative is patterns/proxyless-service-mesh: in-library mesh, no sidecar at all.

Seen in

  • sources/2025-01-18-aws-app-mesh-discontinuation-service-connect-migration — canonical articulation of the tradeoff. AWS framing: "Service Connect eliminates the undifferentiated heavy lifting associated with managing sidecar proxies." The five feature-delta cells (retry tuning, version routing, observability, mTLS, cross-account sharing) enumerate what customers trade away for the managed tier.
Last updated · 200 distilled / 1,178 read