Application Upstream

Now let’s look inside the Upstream page. Each upstream is a cluster of backend servers which can have more than one node (backend server). Here we only have one node for each stream cluster.

Our mail origin server is a Singapore node in AWS, Amazon EC2 services. The gateway only uses the SSL protocol to go back to the origin site (this is configurable though),

as we can see from here, the port number (used is) 443.

We can check out more details by clicking on the Edit upstream link.

We can control the protocol we use to go to the origin site, either “HTTP” or “HTTPS”.

And we can configure the origin server’s or the backend server’s IP address and port number. We have to use a public IP address here because it has to go through internet.

And also we can specify a weight number in case that you have multiple upstream nodes in the same upstream cluster.

We can specify an upstream name in whatever text.

Okay, let’s cancel this.

Once we defined the upstream clusters we can make use of them by actually routing traffic (received by the gateway) to the upstreams.

On the Filtering and Redirects page, we can define many rules, which are essentially routing rules. The default rule should be in the end of the list. Rules appeared first have higher priorities. So the order matters.

Each rule also have conditions. For example this rule is a non conditional rule.

We route the traffic to the AWS Singapore upstream previously defined.

We can choose a round-robin balancing policy, and the number of retries, and also the retry condition in case of bad response status codes, like 500, 502, and 504.