Feature Request — Route Groups for Shared Filters

[Svetliox]

Is your feature request related to a problem? Please describe.

Yes.
Currently, Spring Cloud Gateway supports only global filters (apply to all routes) and per-route filters (apply individually).
There’s no built-in way to group multiple related routes (for example /users/** or /products/**) and apply a common set of filters only to that group.

This makes configuration repetitive and harder to maintain in larger projects where routes are logically grouped by domain.
For example, when several /users/** routes all need the same filter, we must copy-paste the filter configuration into each route.
This duplication increases the chance of inconsistency and makes YAML configurations verbose and error-prone.

Describe the solution you'd like
I propose adding a route group concept that allows defining shared filters (and optionally URIs or predicates) for multiple routes matching a pattern.

Example syntax:

spring:
  cloud:
    gateway:
      route-groups:
        - id: users
          path: /users/**
          filters:
            - GlobalUserFilter
        - id: products
          path: /products/**
          filters:
            - GlobalProductsFilter

Spring Cloud Gateway could internally expand each route group into standard RouteDefinitions, automatically attaching the group-level filters to all matching routes.

Even further this will allows multi-application, multi-domain, and multi-tenant setups, for example:

spring:
  cloud:
    gateway:
      route-groups:
        - id: group-app1
          path: /app1/**
          filters:
            - App1AuthFilter
            - App1LoggingFilter
        - id: group-app2
          path: /app2/**
          filters:
            - App2AuthFilter
            - App2MetricsFilter
        - id: group-tenant1
          path: /tenant1/**
          filters:
            - Tenant1SecurityFilter
        - id: group-tenant2
          path: /tenant2/**
          filters:
            - Tenant2SecurityFilter

Benefits:

• Avoids repetitive filter definitions.
• Keeps configuration cleaner and more readable.
• Makes maintenance easier for large APIs with domain-based route structures.
• Provides a middle layer between global and per-route filters, which currently doesn’t exist.
• Fully backward-compatible (existing route definitions remain unchanged).
• Supports multi-application, multi-domain, and multi-tenant setups, allowing each application or tenant to have its own group-level filters.

Describe alternatives you've considered

1.Use a single GlobalFilter and branch logic manually based on path prefixes (e.g., if path.startsWith("/users/")) — works, but it mixes unrelated concerns in one filter and reduces modularity.
2.Repeat filter configurations on each route individually — works but is verbose, harder to maintain, and easy to forget when new routes are added.
3.Programmatically register routes using RouteLocatorBuilder and apply shared filters in code — flexible but less declarative and not ideal for YAML-based configuration management.

Additional context
This concept aligns with how other gateway systems (e.g., Kong, NGINX, Traefik) allow applying shared policies or middlewares to groups of routes or path prefixes.

It fits Spring Cloud Gateway’s design philosophy (predicate + filter layering) but introduces a helpful configuration abstraction layer.

Implementation could be achieved via a new configuration property (spring.cloud.gateway.route-groups) and a supporting RouteDefinitionLocator that expands groups into regular routes.

In many real-world setups, Spring Cloud Gateway is used to route traffic for multiple applications or microservices. Each application may need its own custom filters (for authentication, logging, metrics, or headers).

Currently, you either:

• Apply a global filter to all routes, which is often unnecessary for unrelated applications.
• Repeat per-route filters, which is verbose and error-prone.

Introducing route-groups allows defining a group per application (e.g., group-app1, group-app2) so that:

All routes in a group automatically inherit the group’s filters.

Adding a new route to an application automatically applies the correct filters.

Configuration becomes cleaner, easier to maintain, and more modular.

This approach supports multi-application, multi-domain, or multi-tenant use cases, reflecting how Spring Cloud Gateway is commonly used in production environments.

Submitted by @Svetliox
I’d be happy to discuss or prototype the implementation if this idea is accepted.