A quota sets the maximum usage of a resource or the maximum QPS of a service within a time period. Quotas are commonly used to manage resource allocation and consumption. How an ALB quota is calculated depends on the resource type and how ALB Ingresses are configured — in particular, how many listeners a single Ingress is associated with. This topic explains the calculation methods for ALB quotas related to standard ALB instances, backend server groups, listeners, and forwarding rules.
Scenario
ALB instances use Ingresses to manage and forward external requests. Ingresses define rules that forward requests to backend server groups (Service:port pairs), which route traffic to backend pods. The mappings between ALB instances, Ingresses, backend server groups, and pods form the routing system for request forwarding and load balancing.
When an ALB Ingress is associated with multiple listeners, all resources tied to that Ingress — forwarding rules, backend servers, and certificates — are counted once per listener. This multiplier effect applies across all quota types described below.
The following sections describe the calculation methods and reference the scenario in the preceding figure.
ALB quotas for standard ALB instances
| Quota | Name/ID | Calculation method | Scenario |
|---|
| Maximum number of additional certificates per ALB instance (excluding default certificates) | alb_quota_loadbalancer_certificates_num_standard_edition | Equals the total additional certificates across all listeners of the ALB instance. Per Ingress, the count depends on how certificates are configured: Auto discovery — count equals the total certificates associated with the domain in Certificate Management Service. Kubernetes Secrets — count equals the number of Secrets listed in the secretName field of spec.tls. Secrets in all namespaces are subject to the calculation; however, Secrets in the same namespace are counted only once. AlbConfig `CertificateId` — count equals the number of certificates listed in CertificateId. Multiple methods combined — count depends on compatibility between the methods. If the Ingress is associated with multiple listeners, its certificate count is multiplied by the number of listeners. | ALB Ingress 1 uses an HTTP listener — no additional certificates required, count is 0. ALB Ingress 2 uses an HTTP listener — count is 0. ALB Ingress 3 uses HTTPS Listener 3 and HTTPS Listener 4; each listener has 1 additional certificate, so the total is 2. |
| Maximum number of forwarding rules per ALB instance (excluding default forwarding rules) | alb_quota_loadbalancer_rules_num_standard_edition | Equals the total forwarding rules of all ALB Ingresses across all listeners. Per Ingress, the count equals the number of entries in the path field of the host parameter in spec.rules. If the Ingress is associated with multiple listeners, its forwarding rules are counted once per listener. | ALB Ingress 1 has 1 forwarding rule. ALB Ingress 2 has 1 forwarding rule. ALB Ingress 3 has 1 forwarding rule but is associated with 2 listeners, so its count is 2. |
| Maximum number of backend servers per ALB instance | alb_quota_loadbalancer_servers_num_standard_edition | Equals the total backend servers of all ALB Ingresses across all listeners. Per Ingress, the count equals the total backend pods across all forwarding rules. If the Ingress is associated with multiple listeners, its pod count is multiplied by the number of listeners. | ALB Ingress 1 has 3 backend pods. ALB Ingress 2 has 3 backend pods. ALB Ingress 3 has 2 backend pods and is associated with 2 listeners, so its backend server count is 4. |
| Maximum number of listeners per ALB instance | alb_quota_loadbalancer_listeners_num_standard_edition | Equals the number of port:protocol pairs in the Listeners parameter of the AlbConfig. The number of listeners associated with an ALB Ingress depends on the value of the alb.ingress.kubernetes.io/listen-ports annotation. | ALB Ingress 1 is associated with 1 listener. ALB Ingress 2 is associated with 1 listener. ALB Ingress 3 is associated with 2 listeners. |
Quotas related to server groups
| Quota | Name/ID | Calculation method | Scenario |
|---|
| Maximum number of ALB server groups a backend server (IP address) can be specified in | alb_quota_server_added_num | If a pod IP address is the backend server for a Service:port pair and that Service:port pair appears in multiple forwarding rules, the pod IP is counted once per forwarding rule. If each of those forwarding rules is associated with multiple listeners, the pod IP is additionally multiplied by the number of listeners. | Pod 1 is a backend for Service 1:port 80 and Service 2:port 80, each in a separate forwarding rule associated with 1 listener — Pod 1 is counted in 2 server groups. The same applies to Pod 2 and Pod 3. Pod 4 is a backend for Service 3:port 80, and that forwarding rule is associated with 2 listeners — Pod 4 is counted in 2 server groups. The same applies to Pod 5. |
| Maximum number of times an ALB server group can be associated with listeners and forwarding rules | alb_quota_servergroup_attached_num | Equals the number of forwarding rules that reference the server group (Service:port pair). If a referencing forwarding rule is associated with multiple listeners, the server group is counted once per listener for that rule. | Service 1:port 80 is referenced in 1 forwarding rule associated with 1 listener — associated 1 time. Service 2:port 80 is the same — associated 1 time. Service 3:port 80 is referenced in 1 forwarding rule associated with 2 listeners — associated 2 times. |
| Maximum number of backend servers (IP addresses and ports) in a server group | alb_quota_servergroup_servers_num | Equals the number of pod:port pairs in the server group (Service:port pair). | Service 1:port 80 has 3 backend pods — 3 backend servers. Service 2:port 80 has 3 backend pods — 3 backend servers. Service 3:port 80 has 2 backend pods — 2 backend servers. |
Quotas related to listeners
| Quota | Name/ID | Calculation method | Scenario |
|---|
| Maximum number of network access control lists (ACLs) that can be associated with a listener | — | Equals the total number of non-empty aclConfig entries across all port:protocol pairs in the Listeners parameter of the AlbConfig. | Listener 1 is associated with 1 network ACL. Listener 2 is associated with 1 network ACL. Listeners 3 and 4 are each associated with 0 network ACLs. |
| Maximum number of network ACL entries that can be associated with a listener | — | Equals the total number of entries in the non-empty aclConfig fields across all port:protocol pairs in the Listeners parameter of the AlbConfig. | The number of network ACL entries for Listener 1 depends on the entries specified in the aclId field. Listener 2 is associated with two network ACLs. Listeners 3 and 4 each have 0 network ACL entries. |
Quotas related to forwarding rules
| Quota | Name/ID | Calculation method | Scenario |
|---|
| Maximum number of actions in a forwarding rule | — | Depends on the servicePort field: if set to use-annotation, the count equals the total custom actions specified using annotations. If set to any other value, the count equals the custom annotation actions plus 1. | ALB Ingress 1 has 1 forwarding rule with servicePort set to 80 and no custom annotation actions — the action count is 1. ALB Ingress 2 and ALB Ingress 3 each have 1 forwarding rule with an action count of 1. |
| Maximum number of match conditions in a forwarding rule | alb_quota_rule_matchevaluations_num | Equals the sum of: the number of non-empty hosts in the rule, the number of path match conditions, and the number of custom conditions specified using annotations. If pathType is set to Prefix, each path counts as 2 match conditions. Any other pathType value counts as 1. | ALB Ingress 1 has 1 forwarding rule with 1 non-empty host, 1 path, and 1 custom annotation condition — the match condition count is 3. ALB Ingress 2 has 1 forwarding rule with 1 non-empty host and 1 path — the count is 2. ALB Ingress 3 has the same configuration as ALB Ingress 2 — the count is also 2. |
| Maximum number of wildcard characters in a forwarding rule | — | Equals the total number of wildcard characters used in all actions and match conditions of the forwarding rule. | ALB Ingress 2 has 1 forwarding rule with 1 wildcard character (asterisk, *) in the host match condition — the wildcard character count is 1. |