Work that applies to every request
The strongest argument for a gateway is not routing at all.
It is that some work applies to every request no matter which service handles it, and doing that work in twenty services means twenty implementations, twenty config files, and twenty chances to get it wrong. Your security review finds the one service that skipped checking token expiry. Attackers find it faster.
Put authentication here, the headline case. Your gateway validates the token, rejects garbage before it touches a backend, and forwards a verified identity inwards in a trusted header.
Keep authorization in your services, deciding whether this particular user may cancel that particular order, because that is business logic and it belongs to the domain.
Remember the split as one sentence. The gateway proves who you are, and the service decides what you may do.
Put rate limiting here too, since the gateway sees all your traffic and can throttle per key, per address or per pricing tier before an abusive client eats backend capacity. Same for stamping a correlation identifier on entry, compressing responses, handling cross-origin rules, and rejecting anything over a size limit.
Notice why platform teams choose the products they do. Adding one of those concerns is configuration, not a code rollout across a fleet.
Aggregation, the dangerous one
Treat aggregation as the most tempting and most dangerous capability. Your gateway can fan one client request out to three services and merge the answers, saving a mobile client three round trips on a bad network.
Watch what each merge rule teaches it, though: response shapes, which are business logic. A little aggregation is fine. A lot means you started building a service inside your proxy, and it should either move out or become an explicit backend for one frontend, which the next lesson covers.
Worked example
A fintech with 14 services fails a security audit in March: the auditor finds three services accepting expired JWTs because their auth middleware pinned an old library version. Ines, the platform lead, moves token validation to their Envoy gateway over two sprints. The gateway now verifies signature and expiry against a shared JWKS endpoint and forwards a signed internal header with the user ID; services delete their own validation code, about 200 lines each. The follow-up audit in September tests all 14 services with expired tokens and gets 14 identical 401s in under 5 ms, because none of the requests ever reached a service. The finding closes, and the next auth upgrade (rotating signing keys) is one config change instead of 14 pull requests.