Reference · built on requestOperator by FibricIT & reliability

Quota Headroom

Reads cloud service quotas against usage and its trend. Proposes an increase request before a limit is reached.

Request accessPricing ↗

About

A service quota fails quietly. An Auto Scaling group stops adding instances, an API starts returning throttling errors, and nothing in the pipeline says why. Quota Headroom reads each quota's applied value and its usage metric, fits the trend of recent weeks, and works out the day usage crosses the value. For AWS it reads the AWS/Usage metrics that Service Quotas publishes to CloudWatch. For Azure it reads quotas and usages per subscription and location through the Microsoft.Quota provider.

When the crossing date lands inside your lead time, it proposes an increase request with the service code, quota code, applied value, and desired value filled in. A cloud owner approves in Jira, Slack, or Microsoft Teams. The request is submitted once, and the provider's own change history shows who asked, for what, and when.

This is a reference listing. It documents what Fibric would read from Quota Headroom and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Quotas per service through ListServiceQuotas: QuotaCode, Value, Unit, Adjustable, GlobalQuota, and the UsageMetric each quota publishes
  • Usage in the AWS/Usage namespace in CloudWatch: ResourceCount and CallCount by Service, Resource, Type, and Class, collected every minute
  • Utilization as CloudWatch metric math, m1/SERVICE_QUOTA(m1)*100, for the services that integrate usage metrics with Service Quotas
  • Open and past requests through ListRequestedServiceQuotaChangeHistory, with Status and CaseId, so a pending request is not filed twice
  • Azure quotas, usages, and quota request status per subscription and location through the Microsoft.Quota resource provider
  • Grafana alert rules on usage series, delivered to a webhook with status firing or resolved, labels, annotations, and values
  • Approval responses on the messages it posts in Slack or Microsoft Teams

Proposed actions

  • Target capability: propose a quota increase through RequestServiceQuotaIncrease with ServiceCode, QuotaCode, and DesiredValue, once a cloud owner approves
  • Target capability: propose an Azure quota update through a PUT on Microsoft.Quota/quotas at the subscription and location scope
  • Target capability: propose a Jira issue through POST /rest/api/3/issue with the quota, usage, trend, and requested value, for quotas that need a support case
  • Target capability: propose a message in Slack or Microsoft Teams to the owning team, one per quota, with the crossing date and the desired value

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Raise the vCPU quota before autoscaling stalls

    CloudWatch shows ResourceCount for Service EC2, Resource vCPU, Class Standard/OnDemand climbing toward SERVICE_QUOTA. The operator proposes a DesiredValue and posts it to Slack. The cloud owner approves. One request is filed.

    With Amazon CloudWatch, Slack

  • Turn a Grafana alert into a filed request

    A Grafana alert rule on an API CallCount series fires to the operator's webhook. It reads the quota behind the series and proposes a Jira issue with the codes and values filled in, for the platform team to approve.

    With Grafana, Jira

  • Track an Azure VM family in one region

    Usage for a VM family in a location approaches its quota. The operator proposes a PUT on Microsoft.Quota/quotas for that scope, posts the proposal to Microsoft Teams, and records the request status once submitted.

    With Microsoft Teams, Jira

Requirements

  • An AWS account with Service Quotas, and CloudWatch usage metrics for the services you care about
  • For Azure, the Microsoft.Quota resource provider registered on each subscription, and the Quota Request Operator role on the identity
  • A Grafana service account token when the trend comes from your own dashboards rather than from CloudWatch
  • A Jira project, or a Slack or Microsoft Teams channel, where the cloud owner approves
  • A lead time per quota, in days, so the operator knows how early to ask
Authentication
Runs on the cloud, monitoring, and ticketing credentials you attach. For AWS, a role allowed to call ListServiceQuotas, RequestServiceQuotaIncrease, and CloudWatch GetMetricData. For Azure, an identity holding the Quota Request Operator role.

Limits

  • Only some AWS services publish usage metrics to CloudWatch. A quota without a UsageMetric has no trend and is not watched
  • A quota with Adjustable false cannot be raised through the API. The operator lists it and stops there
  • AWS may open a support case for some requests. With SupportCaseAllowed false, the request is marked Not approved instead
  • Azure does not reduce a quota through the API, and subscription-level requests can be throttled

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Quota Headroom ↗

Questions and answers

What does a cloud owner approve?
One request per quota: the service, the quota code, the applied value, the usage trend, the crossing date, and the desired value. The owner can change the desired value or decline. Approval submits the request once. Nothing is filed before that.
What record is left after a request is filed?
The request id and status from the cloud provider, kept with the proposal: who approved, when, the usage that decided it, and the value asked for. In AWS the same request appears in ListRequestedServiceQuotaChangeHistory, with a CaseId when a support case was opened.
Does it file quota increases on its own?
No. It proposes. A person approves each request in Jira, Slack, or Microsoft Teams. A quota that is already pending, or that is not adjustable, is reported and left alone. If nobody approves, usage keeps climbing and the operator says so again at the next check.
Ask about Quota Headroom

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy