Fixing Load Balancer Rule Limits in Kubernetes

As multi-tenant Kubernetes platforms grow, most teams watch CPU, memory, storage, and cloud spend. Far fewer watch the number of routing rules accumulating in front of the platform. That blind spot can become a real deployment blocker.

In a recent customer environment, Shakudo traced an urgent upgrade risk to a deceptively simple pattern: each new project was adding roughly six domains, and each subdomain was creating two load balancer rules. Nothing was failing because traffic volume was too high. The bottleneck was control-plane sprawl.

That matters well beyond one customer. AWS documents a default quota of 100 rules per Application Load Balancer excluding the default rule. Quotas can be adjusted, but the bigger lesson is architectural: if your platform automatically creates hosts, environments, and routes, rule growth can silently become a scaling constraint.

The bottleneck was rule growth not traffic

The useful lesson from this case is that the failure mode was not obvious from normal platform dashboards. There was no single dramatic CPU spike, no sudden storage event, and no classic “the cluster is down” signal. Instead, the team noticed that routing complexity was growing linearly with every new project.

In this environment, the growth math looked something like this:

• each new project introduced multiple domains
• each subdomain introduced multiple load balancer rules
• non-production and production environments multiplied the rule count further
• ingress and mesh behavior added more operational complexity on top

That combination turned a normal production upgrade into a blocker.

This is exactly the kind of issue that platform teams building an enterprise AI agent infrastructure stack or trying to deploy AI agents on Kubernetes should pay attention to early. Rule growth often hides inside “just one more hostname” decisions until the platform reaches enough tenant and environment density for those decisions to compound.

Why teams miss this until late

There are a few reasons this problem shows up late:

Routing rules feel cheap

Adding one more hostname or path looks harmless in isolation. The problem is that self-service platforms rarely add just one. They add many, and they keep adding them.

The platform looks healthy right up until it does not

Teams usually monitor traffic, latency, cost, and pod health. Fewer teams actively monitor listener rule growth, ingress object sprawl, or the number of host-based routes generated per tenant.

Quota increases feel like a fix

They can buy time, but they do not simplify the architecture. If the routing pattern itself is inefficient, raising the ceiling just delays the next incident.

Why multi tenant Kubernetes platforms hit this wall

Subdomain multiplication is normal

Many platform teams create separate subdomains for:

• each customer or tenant
• each project or workspace
• each environment such as dev, staging, and prod
• APIs, apps, dashboards, notebooks, and internal services

That is a reasonable pattern. The problem is not the naming convention itself. The problem is what happens when each of those names turns into separate routing entries.

Environment multiplication changes the math fast

A platform may feel manageable at 10 projects. It becomes very different at 50 or 100 projects when every service pattern is repeated across multiple environments.

This is especially true in self-service environments with provisioning flows, ephemeral deployments, or workflow automation that creates routes as part of standard operations.

Mesh and ingress layers can add complexity

Many enterprise platforms do not stop at raw ingress. They also add a service mesh or gateway layer for policy, security, and traffic management.

That is often the right call. But it means your routing model now spans:

• cloud load balancer behavior
• Kubernetes ingress behavior
• controller-specific behavior
• service mesh gateway and routing behavior

In this case, the team also had Istio-related behavior to consider. That matters because wildcard design has to be correct across layers, not just in one place.

The fix was to change the routing pattern

The breakthrough in this case was not “optimize the cluster harder.” It was much simpler:

collapse many explicit host rules into wildcard host patterns wherever the domain model allows it.

Instead of creating one routing rule per subdomain, the team used wildcard-style routing to consolidate many hosts under fewer load balancer entries.

Why wildcard rules help

Wildcard host rules reduce the rate at which rule count grows.

Instead of handling routes like this:

• tenant-a.dev.platform.example.com
• tenant-b.dev.platform.example.com
• tenant-c.dev.platform.example.com

you can often handle a whole family of related subdomains with a pattern like:

• *.dev.platform.example.com

That does not solve every routing problem, but it dramatically improves the scaling characteristics of the ingress layer.

AWS ALB supports host-based wildcard matching

AWS documents host-based routing and wildcard matching in listener rule conditions for Application Load Balancers. In practical terms, ALB can match wildcard host-header patterns such as *.example.com, which makes it possible to consolidate many related subdomains behind fewer rules.

That is the key architectural move here: reduce per-host explicit routing where the naming scheme is predictable.

Kubernetes ingress supports wildcard hosts too

Kubernetes also supports wildcard hostnames in Ingress. The official Ingress documentation shows that wildcard hosts work for a single DNS label.

That nuance matters:

• *.example.com matches app.example.com
• *.example.com does not match api.app.example.com

So if your platform naming hierarchy goes deeper than one label, you need to design the wildcard pattern carefully instead of assuming one wildcard catches everything.

Kubernetes also introduced and documented this more clearly in its Ingress API improvements around wildcard hostnames.

Istio supports wildcard matching at the gateway layer

If you are using Istio, its Gateway documentation also supports wildcard hosts in the left-most component. Istio further documents that matching can work via exact or suffix-based relationships between the gateway host and the VirtualService host.

That makes wildcard consolidation viable even in more policy-heavy environments, as long as the gateway and service naming model are designed together.

‍

What wildcard routing solves and what it does not

Wildcard routing is powerful, but it is not magic.

What it solves

• slower rule-count growth
• less repetitive routing configuration
• fewer deployment blockers caused by ingress sprawl
• a cleaner model for predictable subdomain families

What it does not solve

• poor tenant or namespace design
• weak security boundaries
• certificate management complexity
• bad observability
• uncontrolled naming conventions

This is why wildcard routing should be treated as an architectural simplification, not just a quota workaround.

For example, if you widen host patterns without keeping clear auth, namespace, and policy boundaries, you can make the platform harder to govern. Teams building secure scalable AI agents or enterprise-grade internal platforms should treat wildcard adoption as a design review item, not just an ops tweak.

A practical rollout checklist before you adopt wildcard rules

If your team sees similar rule growth, this is the checklist worth following.

1. Map the full hostname taxonomy

Document every hostname family by:

• tenant
• environment
• service type
• internal vs external exposure
• certificate boundary

Do this before changing any routing.

2. Find the natural wildcard boundaries

Look for hostname families where a single wildcard is actually correct. Do not force wildcards where the domain structure is inconsistent.

3. Validate single-label behavior

This is where many teams get tripped up. Kubernetes wildcard hosts only cover one DNS label. If your pattern is deeper than that, you may need multiple wildcard levels or a different naming model.

4. Review mesh and ingress interactions together

If you use ALB, Kubernetes Ingress, and Istio, review all three layers at once. A wildcard plan that works at the cloud load balancer layer but not at the gateway layer will not reduce operational pain.

5. Review TLS and certificate strategy

Wildcard routing usually implies wildcard certificate planning too. Make sure certificate issuance, renewal, and boundary ownership are explicit.

6. Improve observability before rollout

You should be able to answer:

• which hosts are matched by which rule
• which backends receive wildcard traffic
• which environments are adding routes fastest
• which changes increase routing complexity over time

If you are standardizing platform observability, Shakudo’s broader integrations ecosystem and support for tools like Prometheus and Grafana are highly relevant here.

7. Roll out in stages

Start with non-critical environments. Confirm that host matching, certificates, redirects, and service ownership all behave as expected before production cutover.

The broader lesson for platform teams

The real takeaway from this case is not just “wildcards are useful.”

It is this:

Ingress design is part of platform scalability.

Teams often treat routing as a thin layer in front of the real system. But in multi-tenant platforms, routing rules are part of the system. They shape how fast environments can be provisioned, how safely services can be exposed, and how easily production upgrades can happen.

In this customer case, the team moved from identifying the rule-growth pattern to removing the blocker within days. That is a good outcome. But the more useful lesson is that platform teams should design for this class of problem before it appears.

If your architecture assumes the platform will keep adding tenants, services, and environments, your ingress model should scale at the same rate.

FAQ

How many rules can an AWS Application Load Balancer have

AWS documents a default quota of 100 rules per Application Load Balancer excluding the default rule, and that quota can be adjusted. The exact number in your environment may vary if quotas have already been increased, but the key point is that ALB rule growth is finite and worth tracking.

Can I solve this by just requesting a quota increase

Sometimes, yes in the short term. But if each new tenant or subdomain keeps adding more explicit rules, the underlying architecture will still create operational drag later.

Do wildcard hosts work for every hostname structure

No. In Kubernetes Ingress, wildcard matching covers a single DNS label. That means *.example.com matches app.example.com but not api.app.example.com.

Does this pattern work with Istio

Yes, if the gateway and VirtualService host model are designed correctly. Istio documents wildcard support at the gateway layer, but teams should still validate the exact host patterns they use.

When should I start worrying about this

As soon as your platform automatically provisions routes for tenants, projects, or environments. If hostname creation is part of your product or platform workflow, you should review routing growth before it becomes urgent.

What is the strongest early warning signal

A simple one is this: if every new project, workspace, or environment creates several more domains and each of those creates more routing rules, you already have the ingredients for rule sprawl.

Talk to Shakudo

If your team is building a multi-tenant data or AI platform on Kubernetes, this is exactly the kind of scaling issue that is easier to fix early than under production pressure.

The Shakudo Platform helps teams simplify the infrastructure behind modern data and AI systems, including the layers around orchestration, deployment, governance, and operational scale.

If you want help reviewing your ingress model, wildcard strategy, or broader platform design, contact Shakudo.