What is the Ambassador pattern and how does it proxy outbound traffic for a service?

The Ambassador pattern is a specialisation of the Sidecar pattern focused on outbound (egress) connections. The ambassador container acts as a local proxy for all traffic the main container sends to external services. Instead of the main application connecting directly to downstream services (with all the attendant concerns of retry logic, circuit breaking, timeouts, and connection pooling), it connects to localhost:<port> on the ambassador, which handles all of that transparently.

# Pod with an Envoy Ambassador for outbound calls
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: order-service
    image: myregistry/order-service:2.1
    env:
    - name: INVENTORY_URL
      value: http://localhost:9901/inventory  # ambassador port

  - name: envoy-ambassador
    image: envoyproxy/envoy:v1.29
    args: ["-c", "/etc/envoy/envoy.yaml"]
    volumeMounts:
    - name: envoy-config
      mountPath: /etc/envoy
# envoy.yaml configures upstream cluster, retries, circuit breaker, TLS

Ambassador responsibilities:

• Retry and circuit breaking — the ambassador retries transient failures with exponential backoff; opens the circuit when the upstream is unhealthy.
• Connection pooling — maintains a warm pool of HTTP/2 or gRPC connections to upstream services, avoiding per-request TCP handshake overhead.
• Protocol translation — a legacy service that only speaks HTTP/1.1 can be transparently proxied to an upstream that expects HTTP/2 or gRPC.
• mTLS to upstream — the ambassador terminates plaintext from the main app and re-establishes mTLS to the upstream, so the main app does not need TLS libraries.
• Telemetry — emits distributed trace spans and latency metrics for every outbound call.

The main application's code is simplified to a plain HTTP call to localhost. All network resilience logic lives in the ambassador configuration and can be changed without redeploying the application.