To control Kubernetes cost with quotas, apply a ResourceQuota to cap each namespace's total CPU, memory, storage, pod count, and LoadBalancer services, then add a LimitRange to set default and maximum requests and limits per container. The quota bounds the namespace total; the LimitRange ensures every pod is admitted with a request set, which the quota then counts. Convert each team's cost allowance into CPU, memory, and storage totals so the quota maps to real dollars, and cap services.loadbalancers low because each one provisions a billable cloud load balancer.
Last updated: June 2026. Written by Morten Andersen and reviewed by Fredrik Filipsson, built on our See, Cut, Lock, Run method.
This article sits in our complete guide to Kubernetes cost optimization, the cluster pillar it links up to, and connects to the broader cloud cost optimization playbook. Quotas are most useful once chargeback is in place, so pair this with our companion guide on how to set up Kubernetes cost anomaly alerts. Setting guardrails is a Govern step move, done so the savings you Cut do not creep back.
If you put a quota on requests.cpu or requests.memory, you must ship a LimitRange in the same namespace. A ResourceQuota that limits compute will reject any pod that does not declare those requests, so without default values from a LimitRange your developers' deployments simply fail to schedule. Add the LimitRange first, confirm pods are admitted with the defaults, then tighten the quota. That order keeps the guardrail from becoming an outage.
What is the difference between ResourceQuota and LimitRange?
A ResourceQuota is a namespace-scoped object that caps the aggregate resources a whole namespace can consume, while a LimitRange constrains and defaults each individual container or pod inside it. The quota controls totals: combined requests.cpu, requests.memory, requests.storage, the number of pods, and object counts such as services.loadbalancers and persistentvolumeclaims. The LimitRange controls the parts: the minimum, maximum, and default request and limit each container gets if it does not set its own. Both are stable objects in the core v1 API, documented in the Kubernetes resource quotas and limit range references. You use them together: the quota bounds the namespace, the LimitRange keeps each workload reasonable and ensures nothing slips in unsized.
How do I implement them, step by step?
Implement them by sizing a budget, applying the quota for totals, then adding a LimitRange for defaults so every pod is admitted. Six steps:
- Size a per-namespace budget. Convert each team's cost allowance into CPU, memory, and storage totals using your node price per core and per gibibyte. Result: a quota that maps to dollars, not abstract units.
- Apply a ResourceQuota for totals. Cap requests.cpu, requests.memory, requests.storage, pod count, and services.loadbalancers for the namespace. Result: a hard ceiling on what the team can reserve and bill.
- Add a LimitRange for container defaults. Set default requests and limits plus a max per container. Result: pods without explicit values still get sane sizing.
- Enforce requests on every pod. The LimitRange default means every pod is admitted with a request set, which the quota can then count. Result: no rejected deployments, no unbounded pods.
- Label namespaces for chargeback. Tag each namespace with team and cost-center labels. Result: OpenCost or Kubecost can attribute the quota-bounded spend to its owner.
- Review and adjust the quota. Watch utilization with kubectl describe quota and raise or lower caps as real demand becomes clear. Result: guardrails that fit actual usage with headroom above steady load.
How do ResourceQuotas actually reduce the bill?
ResourceQuotas reduce the bill by putting a hard ceiling on what a namespace can reserve, so waste is capped before it reaches the node pool. On managed Kubernetes you pay for the nodes that back requested capacity, so when a quota limits requests.cpu and requests.memory, the autoscaler can never grow the cluster beyond the sum of the quotas. The object-count limits matter just as much for cost: capping services.loadbalancers stops a team from accidentally standing up a dozen external load balancers that each bill hourly, and capping persistentvolumeclaims bounds storage spend. A quota does not optimize a workload the way right-sizing does, but it stops a single namespace from quietly consuming the whole cluster's budget.
Want quotas sized to real budgets across every namespace?
Our Kubernetes cost audit converts each team's allowance into a ResourceQuota and LimitRange, wires up chargeback so the caps map to owners, and validates that no workload is blocked. On the performance model, you pay only from realized savings. No savings, no fee.
Book a Kubernetes cost audit →Why does a ResourceQuota require pods to set requests?
A ResourceQuota requires pods to set requests because Kubernetes cannot count an unbounded pod against a budget. When the quota limits requests.cpu or requests.memory, any pod in that namespace that omits those values is rejected at admission, since the scheduler has no number to charge against the namespace total. This is the most common reason a freshly applied quota breaks deployments. The fix is a LimitRange that supplies default requests and limits, so pods that do not declare their own are admitted with the defaults rather than blocked. Ship the LimitRange before, or in the same change as, the compute quota, and confirm a test deployment without explicit requests still schedules.
Which limits give the most cost leverage?
The limits with the most cost leverage are services.loadbalancers, requests.cpu and requests.memory together, and requests.storage. Capping services.loadbalancers is the single highest-leverage guardrail because each LoadBalancer service provisions a real cloud load balancer on EKS, GKE, or AKS that bills by the hour regardless of traffic, so a low cap prevents duplicated or forgotten services from accumulating charges. Capping compute requests bounds the node pool the autoscaler can grow. Capping requests.storage and persistentvolumeclaims bounds block-storage spend, which pairs with disciplined storage classes covered in our guide on how to optimize persistent volume and storage class costs in Kubernetes. Set these four first; refine the rest later.
The Kubernetes Cost Optimization Handbook includes the per-namespace quota worksheet and the LimitRange default template referenced above. It is the downloadable companion to this guide.
Frequently asked questions
What is the difference between ResourceQuota and LimitRange?
A ResourceQuota caps the aggregate resources a whole namespace can consume, such as total CPU, total memory, total storage, pod count, and the number of LoadBalancer services. A LimitRange constrains and defaults individual objects, setting per-container minimum, maximum, and default request and limit values. ResourceQuota controls the namespace total; LimitRange controls each pod or container inside it. They are designed to work together.
How do ResourceQuotas reduce cloud cost?
ResourceQuotas reduce cost by putting a hard ceiling on what a namespace can reserve, so a single team cannot accidentally request hundreds of unused cores or spin up dozens of billable LoadBalancer services. On managed Kubernetes you pay for the nodes that back requested capacity and for each external load balancer, so capping requests.cpu, requests.memory, requests.storage, and services.loadbalancers directly bounds the bill per namespace.
Why does a ResourceQuota require pods to set requests?
When a ResourceQuota limits requests.cpu or requests.memory, Kubernetes rejects any pod in that namespace that does not declare those values, because it cannot count an unbounded pod against a budget. The fix is a LimitRange that supplies default requests, so pods without explicit values are admitted with sensible defaults instead of being blocked, while the quota still enforces the namespace ceiling.
Can I cap the number of LoadBalancers with a quota?
Yes. A ResourceQuota can limit object counts including services.loadbalancers, services.nodeports, persistentvolumeclaims, and pods. Capping services.loadbalancers is one of the highest-leverage cost guardrails on EKS, GKE, and AKS because every LoadBalancer service provisions a real cloud load balancer that bills hourly, so a low cap prevents surprise charges from accidental or duplicated services.
The short version
Apply a ResourceQuota to cap each namespace's compute, storage, pod count, and LoadBalancer services, then add a LimitRange so every container gets a sane default and the quota never blocks a deployment. Size the caps from real budgets, label for chargeback, and review utilization as demand settles. When you want every namespace bounded and mapped to an owner, that is what our rightsizing and waste elimination service delivers.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.