Best practices for ALB gateway routing - Serverless App Engine

By default, Serverless App Engine (SAE) applications cannot access the public network, and the public network cannot access the private network. To solve this problem, you can configure Application Load Balancer (ALB) gateway routing for your applications to enable normal access to SAE applications from the public network. This topic explains the important parameter configurations for ALB gateway routing.

Overview of forwarding rules

You can add multiple forwarding rules to a listener of an ALB instance from the SAE side. For a forwarding rule, from the perspective of data link direction, there are inbound forwarding rules and outbound forwarding rules. On the SAE side, you can only configure inbound forwarding rules for ALB instances. If you need to configure outbound forwarding rules, you need to do so on the SLB side.

A forwarding rule consists of two parts: forwarding conditions and forwarding actions. When a request matches the conditions specified in a forwarding rule, the actions specified in the forwarding rule are performed. You can specify one or more conditions and one or more actions in a forwarding rule.

For ALB instances of Standard Edition and WAF-Enabled Edition, when a client sends a request to the ALB, the ALB processes the request data through inbound forwarding rules and then sends it to the corresponding backend server. The response data from the backend server is processed through the ALB's outbound forwarding rules before being returned to the client.
- When you create an inbound forwarding rule, you can specify only inbound conditions and actions.
- When you create an outbound forwarding rule, you can specify both inbound and outbound conditions. However, you can specify only outbound actions in an outbound forwarding rule.
A forwarding rule must include one forwarding action of the type forward to, redirect to, or return fixed response to ensure that client requests are not interrupted.

Access path

Log on to the SAE console, click Namespaces in the left-side navigation pane, and then select the target region.
On the Namespace page, click the name of the target namespace.
On the Basic Information page of the target namespace, click Gateway Routing in the left-side navigation pane, and then click Create Gateway Route.
This topic only introduces the configuration of key parameters. For detailed instructions on creating gateway routing, see Configuring Route Rules by Application Load Balancer (ALB).

Forwarding conditions configuration

On the SAE side, you can configure forwarding conditions for Domain Name, Access Port, and Path.

Domain name configuration

Configuration rule	Description
Exact match and wildcard match	Matching description Exact match: The requested domain name must be the same as the specified domain name. Wildcard match: The requested domain name must match the wildcard pattern of the specified domain name. Input conditions The domain name length is limited to 3-128 characters. It can only contain uppercase and lowercase English letters, digits, and special characters `.-?=~_+\^!$&\|()[]`. It supports asterisk (``) and question mark (`?`) as wildcard characters. Example Requested domain name: www.example.com Exact match: Input `www.example.com` for a successful match. Wildcard match: Input `.example.com` or `www.example.` for a successful match.
Regular expression match	Matching description The requested domain name must match the specified regular expression. Input conditions The domain name length is limited to 3-128 characters. It can only contain uppercase and lowercase English letters, numbers, and special characters `.-?=~_-+\^!$&\|()[]`. Example* Requested domain name: www.example.com Case-insensitive: Input the regular expression `^www.example.com$` for a successful match.

Path configuration

Configuration rule	Description
Exact match and wildcard match	Matching description Exact match: The requested path must be the same as the specified path. Wildcard match: The requested path must match the wildcard pattern of the specified path. Input conditions Must start with `/` . It can only contain uppercase and lowercase English letters, numbers, and special characters `$-_.+/&~@:`. It supports asterisk (``) and question mark (`?`) as wildcard characters. Example* Requested path: /example/text Exact match: Input `/example/text` for a successful match. Wildcard match: Input `/example/` for a successful match. Note* The path matching rule of ALB is different from Nginx. ALB does not support the longest prefix match principle. For example, a common Nginx configuration is `location /abc`, where the location is matched using the longest prefix match. In ALB, the longest prefix match needs to be implemented using wildcards. You can configure `/abc/*` (exact match and wildcard) in ALB to achieve the same effect.
Regular expression match	Matching description The requested path matches the specified regular expression. Input conditions It can only contain uppercase and lowercase English letters, numbers, and special characters `.-_/=?~^$:()[]+\|`. Example* Requested path: `/sys/aaa/HOST` Case-sensitive: Regular expression input `^/sys/(.)/HOST$` results in a successful path match. Case-insensitive: Regular expression input `^/sys/(.)/host$` results in a successful path match.

Introduction to forwarding action configuration

In the forwarding action configuration, you can configure rewrite policies and redirection rules.

Rewrite policy configuration

Note

You can configure rewrite policies in forwarding actions.

When you select "Forward to", you can configure rewrite policies.
For domain name configuration in forwarding conditions, see Domain name configuration.
If the redirected domain name is the default ${host}, it means dynamically replacing it with the original request's domain name.

Path configuration

After configuring a regular expression for the path in forwarding conditions, the path in forwarding actions supports regular expression replacement. For information about how to add forwarding rules, see Configure routing rules for an application (ALB).

Notes
- The number of parentheses () in the regular expression in the forwarding condition must match the number of $variables in the rewritten path in the forwarding action.
- The rewritten path in the forwarding action must include one or more of ${1}, ${2}, and ${3}, and these three variables cannot be replaced with other characters.

Replacement principle

URL matching: The client sends a request and the request matches a regular expression that is specified in a forwarding rule.
Extraction and replacement: According to regular expression standards, the content extracted from the first three pairs of parentheses () is saved to ${1}, ${2}, and ${3} respectively, for replacement in the rewritten path of the forwarding action.
Concatenation: According to the configuration of the rewritten path in the forwarding action, replace the values of ${1}, ${2}, and ${3}, and finally concatenate them into the actual rewritten path.

Number	Step	Example
1	Configure the forwarding condition and the forwarding action in a forwarding rule.	Forwarding condition path: `/sys/(.)/(.)/aaa` Forwarding action rewrite path: `/${1}/${2}`
2	A client request matches the path in a forwarding rule.	Client request path: `/sys/ccc/bbb/aaa` Matched forwarding condition path: `/sys/(.)/(.)/aaa`
3	Extraction and replacement.	According to regular expression standards, the two `(.*)` in the forwarding condition path extract `ccc` and `bbb` respectively, and store them in `${1}` and `${2}` in the rewritten path of the forwarding action. `${1}` is replaced with `ccc` `${2}` is replaced with `bbb`
4	Path concatenation.	Path received by the backend server: `/ccc/bbb`

Note

If the redirected path is the default ${port}, it means dynamically replacing it with the original request path. For example, if the path in the forwarding condition is /test/aaa, then the path matched by the forwarding action is /test/aaa.

Query configuration

The query content refers to the part after the question mark in the URL. If the redirected query is the default ${query}, it means dynamically replacing it with the original request's query parameters.

Example:

If the client accesses the URL www.example.com/test/test1?x=1, the query content is x=1.

Redirection policy configuration

If you need to configure a redirection policy, you need to configure parameters such as protocol, domain name, access port, path, query, and status code.

Protocol introduction

An HTTP listener supports redirecting HTTP requests to another HTTP listener or an HTTPS listener.
An HTTPS listener supports redirecting HTTPS requests to another HTTPS listener.

Note

If the redirected protocol is the default $(protocol), it means dynamically replacing it with the original request's protocol.

Domain name introduction

The domain name configuration in forwarding actions is the same as in forwarding conditions. For specific configuration, see Domain name configuration.

Note

If the redirected domain name is the default ${host}, it means dynamically replacing it with the original request's domain name.

Access port introduction

Configure the listening port for the corresponding protocol. For example, when an HTTP request (access port: 80) is redirected to HTTPS (access port: 443).

Note

If the redirected access port is the default ${port}, it means dynamically replacing it with the original request's port.

Path introduction

Notes
- The number of parentheses () in the regular expression in the forwarding condition must match the number of $variables in the redirected path in the forwarding action.
- The redirected path in the forwarding action must include one or more of ${1}, ${2}, and ${3}, and these three variables cannot be replaced with other characters.

Replacement principle

URL matching: The client sends a request and the request matches a regular expression that is specified in a forwarding rule.
Extraction and replacement: According to regular expression standards, the content extracted from the first three pairs of parentheses () is saved to ${1}, ${2}, and ${3} respectively, for replacement in the redirected path of the forwarding action.
Concatenation: According to the configuration of the redirected path in the forwarding action, replace the values of ${1}, ${2}, and ${3}, and finally concatenate them into the actual rewritten path.

Number	Step	Example
1	Configure the forwarding condition and the forwarding action in a forwarding rule.	Forwarding condition path: `/sys/(.)/(.)/aaa` Forwarding action redirect path: `/${1}/${2}`
2	A client request matches the path in a forwarding rule.	Client request path: `/sys/ccc/bbb/aaa` Matched forwarding condition path: `/sys/(.)/(.)/aaa`
3	Extraction and replacement.	According to regular expression standards, the two `(.*)` in the forwarding condition path extract `ccc` and `bbb` respectively, and store them in `${1}` and `${2}` in the redirected path of the forwarding action. `${1}` is replaced with `ccc` `${2}` is replaced with `bbb`
4	Path concatenation.	Path received by the backend server: `/ccc/bbb`

Note

Query introduction

Example:

If the client accesses the URL www.example.com/test/test1?x=1, the query content is x=1.

Status code introduction

The default HTTP status code for ALB redirects is 301. You can specify an HTTP status code as needed. The following table describes the HTTP status codes supported by ALB:

Status code	Description
301	Indicates permanent redirect.
302	Indicates temporary redirect.
303	Indicates that the requested resource can be obtained through another URL (see other location).
307	Indicates that the requested resource has temporarily moved to another location (temporary redirect, method preserved).
308	Indicates that the requested resource has permanently moved to a new location (permanent redirect, method preserved).