Pentest Tools

Published on April 20th, 2016 📆 | 7285 Views ⚑


Zuul — Gateway Edge Service

Zuul is a gateway service that provides dynamic routing, monitoring, resiliency, security, and more.


Zuul is the front door for all requests from devices and web sites to the backend of the Netflix streaming application. As an edge service application, Zuul is built to enable dynamic routing, monitoring, resiliency and security. It also has the ability to route requests to multiple Amazon Auto Scaling Groups as appropriate.


Why Netflix build Zuul?

The volume and diversity of Netflix API traffic sometimes results in production issues arising quickly and without warning. Neflix need a system that allows them to rapidly change behavior in order to react to these situations.

Zuul uses a range of different types of filters that enables them to quickly and nimbly apply functionality to their edge service. These filters help perform the following functions:

  • Authentication and Security – identifying authentication requirements for each resource and rejecting requests that do not satisfy them.
  • Insights and Monitoring – tracking meaningful data and statistics at the edge in order to give us an accurate view of production.
  • Dynamic Routing – dynamically routing requests to different backend clusters as needed.
  • Stress Testing – gradually increasing the traffic to a cluster in order to gauge performance.
  • Load Shedding – allocating capacity for each type of request and dropping requests that go over the limit.
  • Static Response handling – building some responses directly at the edge instead of forwarding them to an internal cluster
  • Multiregion Resiliency – routing requests across AWS regions in order to diversify our ELB usage and move our edge closer to our members

Zuul is an edge service originally designed to front the Netflix API, it is now being used in a variety of ways by a number of systems throughout Netflix.


Zuul Components

Zuul contains multiple components:

  • zuul-core – library which contains the core functionality of compiling and executing Filters
  • zuul-simple-webapp – webapp which shows a simple example of how to build an application with zuul-core
  • zuul-netflix – library which adds other NetflixOSS components to Zuul – using Ribbon for routing requests, for example.
  • zuul-netflix-webapp – webapp which packages zuul-core and zuul-netflix together into an easy to use package


Gateway Edge Service: Building Zuul

To checkout the source and build:

$ git clone
$ cd zuul/
$ ./gradlew build

To do a clean build:

$ ./gradlew clean build


How Does Zuul Work?

At the center of Zuul is a series of filters that are capable of performing a range of actions during the routing of HTTP requests and responses.  The following are the key characteristics of a Zuul filter:

  • Type: most often defines the stage during the routing flow when the filter will be applied (although it can be any custom string)
  • Execution Order: applied within the Type, defines the order of execution across multiple filters
  • Criteria: the conditions required in order for the filter to be executed
  • Action: the action to be executed if the Criteria are met


Zuul provides a framework to dynamically read, compile, and run these filters. Filters do not communicate with each other directly – instead they share state through a RequestContext which is unique to each request.

Filters are currently written in Groovy, although Zuul supports any JVM-based language. The source code for each filter is written to a specified set of directories on the Zuul server that are periodically polled for changes. Updated filters are read from disk, dynamically compiled into the running server, and are invoked by Zuul for each subsequent request.



There are several standard filter types that correspond to the typical lifecycle of a request:

  • PRE filters execute before routing to the origin. Examples include request authentication, choosing origin servers, and logging debug info.
  • ROUTING filters handle routing the request to an origin. This is where the origin HTTP request is built and sent using Apache HttpClient or Netflix Ribbon.
  • POST filters execute after the request has been routed to the origin.  Examples include adding standard HTTP headers to the response, gathering statistics and metrics, and streaming the response from the origin to the client.
  • ERROR filters execute when an error occurs during one of the other phases.

[adsense size='1']


Because Zuul can add, change, and compile filters at run-time, system behavior can be quickly altered. You can add new routes, assign authorization access rules, and categorize routes all by adding or modifying filters. And when unexpected conditions arise, Zuul has the ability to quickly intercept requests so you can explore, workaround, or fix the problem.

The dynamic filtering capability of Zuul allows you to find and isolate problems that would normally be difficult to locate among our large volume of requests.  A filter can be written to route a specific customer or device to a separate API cluster for debugging.  By isolating the traffic to a single instance, patterns and discrepancies in the requests could be seen in real time. Zuul has a “SurgicalDebugFilter”. This is a special “pre” filter that will route a request to an isolated cluster if the patternMatches() criteria is true.  Adding this filter to match your cases can help you quickly identify and analyze problems.




Source && Download

Leave a Reply

Your email address will not be published.