We can size the kas default and az specific ingresscontroller routers differently - the default does not need the same cpu resources as the az specific, and we may actually need even more memory on the az specific now that we are only running 1 instance by default.

For the enterprise model it's not yet clear what the implications are for the demand expectations - it could be that we'll want to elevate the peak demand percentage property to the agent so that enterprise shards can specify something closer to 100%. If we instead switch to where the quota is effectively ignored we'll have to have some other mechanism for determining an appropriate number of (probably just 1) and resources for the replicas.

If we progress towards sharing ingresscontrollers across services, we need to consider introducing another cr / controller for that purpose. The cr could indicate an amount of demand [1] in terms of throughput and connections.

[1] this would be highly related to https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#extended-resources