ALB quotas define the maximum resource usage for standard ALB instances, backend server groups, listeners, and forwarding rules. Understanding how each quota is calculated lets you predict quota consumption before deployment and avoid hitting limits unexpectedly.
How quotas are calculated
ALB instances use Ingresses to manage and forward external requests. An Ingress defines rules that route requests to backend server groups (Service:port pairs), which distribute traffic to backend pods. Quotas are counted across this routing hierarchy: ALB instance -> Ingresses -> backend server groups -> pods.
The examples in the following sections reference this diagram.
Key multiplier rule: When an Ingress is associated with multiple listeners, its forwarding rules, backend pods, and certificates are each counted once per listener.
ALB instance quotas
Additional certificates per ALB instance
Quota ID: alb_quota_loadbalancer_certificates_num_standard_edition
The certificate count for an ALB instance is the sum of additional certificates across all its listeners.
The certificate count for a single Ingress depends on the certificate configuration method:
| Configuration method | How certificates are counted |
|---|---|
| Automatic certificate discovery | Number of certificates associated with the domain name in Certificate Management Service |
| Kubernetes Secrets | Number of Secrets in the secretName field of spec.tls. Secrets across all namespaces are included; Secrets in the same namespace are counted once. |
AlbConfig CertificateId field | Number of certificates listed in the CertificateId field |
| Multiple methods combined | Depends on compatibility between the methods used |
| Multiple listeners | Certificates are counted once per associated listener |
Scenario example:
| Ingress | Listeners | Certificate count |
|---|---|---|
| ALB Ingress 1 | HTTP Listener 1 | 0 (HTTP requires no certificates) |
| ALB Ingress 2 | HTTP Listener 2 | 0 (HTTP requires no certificates) |
| ALB Ingress 3 | HTTPS Listener 3, HTTPS Listener 4 (1 cert each) | 2 (1 cert x 2 listeners) |
Forwarding rules per ALB instance
Quota ID: alb_quota_loadbalancer_rules_num_standard_edition
The forwarding rule count for an ALB instance is the sum of forwarding rules across all Ingresses on all listeners.
The rule count for a single Ingress equals the number of entries in the path field of host in the spec.rules section of the Ingress configuration. If the Ingress is associated with multiple listeners, its rules are counted once per listener.
Scenario example:
| Ingress | Rules | Listeners | Total rules counted |
|---|---|---|---|
| ALB Ingress 1 | 1 | 1 | 1 |
| ALB Ingress 2 | 1 | 1 | 1 |
| ALB Ingress 3 | 1 | 2 | 2 (1 rule x 2 listeners) |
Backend servers per ALB instance
Quota ID: alb_quota_loadbalancer_servers_num_standard_edition
The backend server count for an ALB instance is the sum of backend pods across all Ingresses on all listeners.
The backend server count for a single Ingress equals the total number of backend pods across all its forwarding rules. If the Ingress is associated with multiple listeners, its pods are counted once per listener.
Scenario example:
| Ingress | Pods | Listeners | Total servers counted |
|---|---|---|---|
| ALB Ingress 1 | 3 | 1 | 3 |
| ALB Ingress 2 | 3 | 1 | 3 |
| ALB Ingress 3 | 2 | 2 | 4 (2 pods x 2 listeners) |
Listeners per ALB instance
Quota ID: alb_quota_loadbalancer_listeners_num_standard_edition
The listener count for an ALB instance equals the number of port:protocol pairs in the Listeners parameter of the AlbConfig. The number of listeners associated with a specific Ingress depends on the value of the alb.ingress.kubernetes.io/listen-ports annotation.
Scenario example:
| Ingress | Listener count |
|---|---|
| ALB Ingress 1 | 1 |
| ALB Ingress 2 | 1 |
| ALB Ingress 3 | 2 |
Server group quotas
Server groups per backend server
Quota ID: alb_quota_server_added_num
This quota tracks how many ALB server groups a single pod IP address appears in.
If a pod IP is the backend of a Service:port pair that is referenced in multiple forwarding rules, the pod is counted once per forwarding rule. If any of those rules are associated with multiple listeners, the pod is counted once per listener for each rule.
Scenario example:
| Pod | Service:port pairs | Forwarding rules | Listeners | Server group count |
|---|---|---|---|---|
| Pod 1 | Service 1:80, Service 2:80 | 1 rule per Service | 1 per rule | 2 |
| Pod 2 | Service 1:80, Service 2:80 | 1 rule per Service | 1 per rule | 2 |
| Pod 3 | Service 1:80, Service 2:80 | 1 rule per Service | 1 per rule | 2 |
| Pod 4 | Service 3:80 | 1 rule | 2 listeners | 2 |
| Pod 5 | Service 3:80 | 1 rule | 2 listeners | 2 |
Listener and rule associations per server group
Quota ID: alb_quota_servergroup_attached_num
This quota tracks how many times a server group (Service:port pair) is associated with listeners and forwarding rules.
The count equals the number of forwarding rules that reference the Service:port pair. If a forwarding rule is associated with multiple listeners, the server group is counted once per listener.
Scenario example:
| Service:port | Forwarding rules | Listeners | Association count |
|---|---|---|---|
| Service 1:80 | 1 | 1 | 1 |
| Service 2:80 | 1 | 1 | 1 |
| Service 3:80 | 1 | 2 | 2 (1 rule x 2 listeners) |
Backend servers per server group
Quota ID: alb_quota_servergroup_servers_num
The backend server count for a server group (Service:port pair) equals the number of pod:port pairs in that server group.
Scenario example:
| Service:port | Backend servers |
|---|---|
| Service 1:80 | 3 |
| Service 2:80 | 3 |
| Service 3:80 | 2 |
Listener quotas
Network ACLs per listener
The network access control list (ACL) count for a listener equals the number of entries in the non-empty aclConfig fields across all port:protocol pairs in the AlbConfig Listeners parameter.
Scenario example:
| Listener | Network ACL count |
|---|---|
| Listener 1 | 1 |
| Listener 2 | 1 |
| Listener 3 | 0 |
| Listener 4 | 0 |
Network ACL entries per listener
The network ACL entry count for a listener equals the total number of entries in the non-empty aclConfig fields across all port:protocol pairs in the AlbConfig Listeners parameter.
Scenario example:
| Listener | ACL entry count |
|---|---|
| Listener 1 | Depends on the number of ACL IDs in the aclId field |
| Listener 2 | 2 |
| Listener 3 | 0 |
| Listener 4 | 0 |
Forwarding rule quotas
Actions per forwarding rule
The action count for a forwarding rule depends on the value of the servicePort field:
servicePort value | Action count |
|---|---|
use-annotation | Total number of custom actions specified by annotations |
| Any other value | Total number of custom annotation actions plus 1 |
Scenario example: ALB Ingress 1 has one forwarding rule with servicePort set to 80 and no custom annotation actions. The action count is 1.
Match conditions per forwarding rule
Quota ID: alb_quota_rule_matchevaluations_num
Match condition count = non-empty hosts + path conditions + custom annotation conditions
Path conditions are counted as follows based on pathType:
pathType value | Conditions per path |
|---|---|
Prefix | 2 |
| Any other value | 1 |
Scenario example:
| Ingress | Hosts | Paths | Custom conditions | Match condition count |
|---|---|---|---|---|
| ALB Ingress 1 | 1 | 1 | 1 | 3 |
| ALB Ingress 2 | 1 | 1 | 0 | 2 |
| ALB Ingress 3 | 1 | 1 | 0 | 2 |
Wildcard characters per forwarding rule
The wildcard character count for a forwarding rule equals the total number of wildcard characters used across its actions and match conditions.
Scenario example: ALB Ingress 2 has one forwarding rule with one wildcard character (*) in the host match condition. The wildcard count is 1.