RFD 52
Quota Policies

Oxide racks enforce quotas on resource usage for a variety of reasons. For example, quotas protect the community of users by preventing unforeseen spikes in usage. This way no single user can accidentally consume all the resources in a rack or fleet of racks, such that no other users can deploy resources. Although the API supports an arbitrary number of objects, operators or the system itself may place limits on the number of resources that users can create. These are known as quotas.

In [rfd43], we went over Identity and Access Management (IAM) policies. This RFD is going to be focused on Quotas. While IAM policies focus on who is allowed to access what, and are attached to different resources. Quota policies focus on the number of resources a project is allowed to consume. Although, different from [rfd43], the mechanics of attaching a policy to a project or organization are similar.

Quota policies can only be attached to an organization or project, not individual resources. This is where Quota policies differ from IAM policies.

Eventually, when users have more than one rack and different regions, you can imagine they might want to set different quota policies per region. This will be possible. Initially, we will set the policies "globally" (their first rack), from there once more regions are defined for the fleet, users can set specific policies per region. The API should allow for a different parameter to be set when accessing policies per region.

When a user goes to create a resource in a project, IAM will check if they are authorized to do so, quota policies are then checked to make sure the project has the quota to create the additional resource. If the project does not have enough quota we should return a specific error response in the API as covered in [rfd4] error responses.

Policy inheritance

Please refer to [rfd44] to understand the hierarchy of resources.

Child resources of a parent resource automatically inherit the policies from the parent resource by default. This is the same behavior as [rfd43] as well.

For example, if an organization has a specific quota granted to it for various resources, projects in that organization will inherit those quotas.

For example, if an organization has a quota of 100 instances, all projects in the organization inherit the quota of 100 instances. This way you can set quota policies at the organization level that can be inherited by projects in that organization.

Regional policies versus global

Regional policies inherit from the global policy. Unless the quotas are explicitly modified for a region, the quota will be taken from the global quota policy.

Requesting more quota

When a project is out of quota for a particular resource and needs more, they will need to send an alert to their administrator. This should be easy someone to do from the UI, CLI, or API. Refer to [rfd55] for more on alerts.

The administrator (aka person with the IAM permission capable of changing quotas) can then modify the specific projects quota for that resource.

Not all projects have the same quotas. As your use of Oxide expands over time, your quotas may increase accordingly. If you expect a notable upcoming increase in usage, you can proactively request quota adjustments from the UI, CLI, or API.

Alerting when quota is about to run out

We should periodically check and alert project owners when their quota is about to run out. We can do this through the UI and through other alerting mechanisms as outlined in [rfd55].

Understanding VM, CPU, and IP address quotas

When planning your virtual machine (VM) instance needs, there are a number of quotas to consider that affect how many VM instances you can create.

VM quotas are managed at the regional level. VM instance, CPU, and Disk quotas can be consumed by any VM in the region, regardless of zone. For example, CPU quota is a regional quota, so there is a different limit and usage count for each region. To launch an 16 core instance in any zone in X region, you need enough quota for at least 16 CPUs in X region.

VPC and load balancing quotas are required to create firewalls, load balancers, subnets, and VPNs.


CPU quota is the total number of virtual CPUs across all of your VM instances in a region. CPU quotas apply to running instances and instance reservations. Both standard and spot instances consume this quota. The differentiation between the two is covered in [rfd4].

Virtual machine types

Quotas can be placed on machine types to limit the number of each specific machine type projects or organizations can deploy.

Quotas for spot instances

To use spot CPUs attached to spot VM instances, or to use disks attached to spot VM instances, you must have available quota in your project for the respective resource.

Disk quotas

This is the total size of disks that can be created in a region. Disks that are not attached to an instance still count against quota.

IP addresses

You must have enough public IP addresses for every VM that needs to be reachable from the public internet. Regional IP quota is for assigning IP addresses to VMs in that region.

In-use IP address. Includes both ephemeral and floating IP addresses that are currently being used by a resource.

Floating IP addresses that are not in use by a resource but are still reserved count against the quota.

Example policy

The syntax for quota policies is the following: "resource_type": integer. This applies for all resources. There is an example below:

    "ncpus": 96,
    "nmemory": 256,
    "ndisks": 2500,
    "nvpcs": 100,
    "nsubnets": 100,
    "nrouters": 100,
    "nroutes": 1000,
    "nfirewallRules": 10000,
    "nephemeralIPAddresses": 300,
    "nfloatingIPAddresses": 20,
    "nsnapshots": 5000,
    "nimages": 5000,
    "vms": {
        "{type/size}": 10, (1)
        "{type/size}": 20, (1)
1You can add quotas per type of VM machine as well.
Update this example once we have defined the types of virtual machines.

External References