The service mesh conversation generates more architecture meetings per deployed feature than anything else in Kubernetes, so today is deliberately practical: what the AKS managed Istio addon gives you, what it costs, and a decision checklist that ends the meeting.

What the Addon Buys

The Istio based service mesh addon is Istio with the lifecycle problems removed: Microsoft manages the control plane, supports specific revision versions with a tested upgrade path (canary revision upgrades, run both, migrate namespaces, retire the old), and integrates the ingress and egress gateways with the AKS networking this series built. On top you get the mesh trinity. Security: automatic mutual TLS between every meshed pod, workload identity at the network layer with peer authentication policies to require it strictly, and authorization policies expressing “orders may call payments on POST /charge and nothing else”, which is the NetworkPolicy story from the hardening post upgraded from IP and port to service identity and method. Traffic management: virtual services and destination rules for canary weighting, header based routing, retries with budgets, timeouts, outlier ejection, circuit breaking, the reliability patterns applications otherwise implement inconsistently in fourteen libraries. Observability: uniform request metrics, and traces between every pair of services without touching application code, feeding the managed Prometheus stack coming later this week.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payments-ingress
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payments-api
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/orders/sa/orders-api"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/charge"]

What It Costs

The sidecar tax is real and threefold. Resources: an Envoy per pod, tens to a couple hundred MB of memory and real CPU under load, multiplied by every replica, which on a large cluster is nodes’ worth of overhead. Latency: single digit milliseconds per hop typically, which matters at the tail when a request fans across six services. And cognition: every incident now includes the question “is it the mesh”, every deployment interacts with injection labels, and the team needs Envoy literacy it did not need before. Upgrades, the historical Istio wound, are genuinely tamed by the managed revisions, but policy sprawl replaces them as the maintenance burden, authorization policies are code and belong in the GitOps repo from yesterday with review, or the mesh becomes an undocumented firewall.

The Checklist

Adopt a mesh when at least two of these are true: a compliance or zero trust mandate requires encryption and authenticated identity for every internal hop (the mesh does in configuration what would take months in libraries); the service count and polyglot spread make library based resilience and telemetry inconsistent in practice; you genuinely need progressive delivery with fine traffic control beyond what the revision and ingress tooling already gives; or multiple teams share clusters and service level authorization is the tenancy boundary you need. Skip it, without shame, when you run a modest number of services in one or two languages, Dapr from the Container Apps post already covers your service invocation with mTLS, or the honest driver is fashion. And size the middle path: the mesh can run on the critical namespaces only, injection is per namespace, which captures the compliance win where it pays without taxing the batch jobs that never needed it. The mesh is a tool with a bill; buy it the way this series buys everything, against a named requirement.

Cheers
Osama