Overview

Compare L4 ztunnel-native and L7 waypoint egress options for your ambient mesh.

Egress approaches

Egress control in an ambient mesh determines how outbound traffic from your workloads reaches external services and what policies are enforced before traffic leaves the cluster. In an ambient mesh, ztunnel captures outbound traffic from every pod on the node. For traffic destined for external services, you configure an egress gateway that ztunnel routes matched traffic through before releasing connections from the cluster.

Three egress approaches are available, differentiated by the gateway type and the enforcement layer:

Components

L4 ztunnel-native egress

• Gateway: A single cluster-wide resource in istio-system using the solo-ztunnel-egress GatewayClass. Backed by the existing ztunnel DaemonSet. Creating this resource does not deploy any new pods.
• ServiceEntry: Registers the external destination and binds it to the Gateway via istio.io/use-waypoint and istio.io/use-waypoint-namespace labels. Ztunnel routes matched traffic through the Gateway before it exits the cluster.
• AuthorizationPolicy: Controls which namespaces and service accounts can reach a given ServiceEntry. Because ztunnel operates at L4, rules match on source identity only and do not support HTTP-level attributes.
• ztunnel egressPolicies (optional): A Helm value that configures ztunnel to deny traffic to any destination not recognized in the service registry (populated from both Kubernetes Services and Istio ServiceEntries). Adds a default-deny backstop for unknown external destinations.
• NetworkPolicy (optional): A Kubernetes NetworkPolicy that blocks workload pods from reaching external IPs directly. Because traffic exits from the ztunnel pod’s network namespace, the CNI can enforce that application pods cannot bypass the mesh.

L7 waypoint egress

• Gateway: Deployed per namespace (or shared across namespaces) using the istio-waypoint GatewayClass. Runs as an Envoy-based proxy pod.
• ServiceEntry: Registers the external destination and binds it to the waypoint using the same istio.io/use-waypoint label as L4.
• AuthorizationPolicy: Supports both source identity rules and HTTP-level rules such as methods, paths, and hosts.
• DestinationRule (optional): Configures TLS origination so the waypoint upgrades internal HTTP connections to HTTPS before they exit the cluster.
• VirtualService (optional): Adds L7 routing behavior such as header manipulation and request rewrites.

L7 agentgateway waypoint egress

• Gateway: Deployed per namespace using the enterprise-agentgateway-waypoint GatewayClass. Runs as an agentgateway-based proxy pod. Requires a Solo Enterprise for agentgateway license in addition to the Solo distribution of Istio Enterprise license.
• ServiceEntry: Registers the external destination with resolution: DNS and location: MESH_EXTERNAL. Must use istio.io/waypoint-for: all instead of istio.io/waypoint-for: service, because ServiceEntries are not Kubernetes-native services.
• EnterpriseAgentgatewayPolicy: Controls access using CEL expressions that match on source identity and HTTP attributes. When an Allow policy is applied, all unmatched traffic is denied by default.

When to use each approach

Use L4 ztunnel-native egress when:

• Workloads connect to external services over TCP or TLS. HTTP is also supported only when you do not need to enforce policy based on the content of HTTP requests (methods, paths, or headers).
• Authorization requirements are based on source identity (namespace or service account) or destination port and address.
• You want to minimize operational overhead with no dedicated proxy pods.

Use L7 waypoint egress when:

• You need to enforce rules based on HTTP methods, URL paths, or request headers.
• You need TLS origination. The application sends plain HTTP internally and the proxy upgrades the connection to HTTPS before it exits the cluster.
• You need rate limiting on egress traffic.

Use L7 agentgateway waypoint egress when:

• You need CEL-based authorization that combines source identity and HTTP method or path attributes in a single expression, without writing EnvoyFilters.
• Your workloads call external AI APIs and you want to control which service accounts are allowed to make outbound calls.
• You are already using agentgateway as a waypoint for in-mesh services and want consistent policy enforcement for egress traffic.

L4 ztunnel-native and L7 community waypoint egress can coexist in the same cluster. Each ServiceEntry independently chooses its gateway via the istio.io/use-waypoint label, so a namespace can use ztunnel-native egress for most services and a community waypoint for services that require L7 features. Coexistence of agentgateway waypoints alongside community istio-waypoint deployments or L4 ztunnel-native egress in the same cluster has not yet been verified.

Next steps

To get started with egress, check out one of the following guides.

• L4 ztunnel-native egress (alpha): Set up the ztunnel-egress Gateway and enforce identity-based egress policy with no dedicated proxy pods.
• L7 waypoint egress: Deploy a waypoint proxy and apply HTTP-level routing and authorization policies.
• Agentgateway waypoint egress (alpha): Use agentgateway as an egress waypoint to enforce CEL-based policies on outbound traffic to external AI APIs.
• Advanced mTLS egress: Route egress traffic using per-workload mTLS identities.