Manage Your Service Limits

Understand, monitor, and manage your tenancy's service limits and compartment quotas. Service limits are resource allowances that are established when you create your tenancy. Compartment quotas are policies that allow administrators to allocate resources with a high level of flexibility.

Understand the Default Service Limits of Your Tenancy

Typically, the service limits associated with your tenancy are established when you sign up for Oracle Cloud Infrastructure.

If you didn't establish limits with your Oracle sales representative or if you signed up through the Oracle Store, then default or trial limits are set for your tenancy. Use the Oracle Cloud Infrastructure Console or API to view your service limits.

Oracle Cloud Infrastructure is hosted in regions and availability domains. Regions are localized geographic areas, and availability domains are one or more data centers within a region. Each resource has a defined limit and scope. The scope of service limits is either regional or availability domain specific. In some cases, the scope is defined by another service. For example, one NAT Gateway resource is allowed in a virtual cloud network. The scope of service limits for a NAT Gateway is virtual cloud network.

Follow these best practices to determine the service limits of your tenancy:

  1. Identify your Oracle Cloud Infrastructure regions based on your application, latency, and disaster recovery requirements.
  2. Identify the services that your applications require.

    To determine your requirements, review the application architecture, infrastructure code, or on-premises deployment.

  3. Review the default limits and scope for your required services. For example, per availability domain, per region, or per tenant. Some services have additional limits.
  4. Identify which default service limits require an increase.

Monitor and Manage Your Service Limits

Evaluate the use of Oracle Cloud Infrastructure services based on your application. Leave room for growth and expansion. Keep a track of your current usage and monitor growth.

  • Use the Console or Service Limits API to capture your current resource utilization and total service limits for your tenancy. For example, how many compute instances you're using per availability domain and how much room you have to grow in that availability domain and region.

  • Request an increase in the service limit for a resource, if required. Keep a record and track the request. After receiving confirmation, go to the Console or Service Limits API to validate the service limit.

Track Your Compartment Quotas

Administrators use policy statements to create compartment quotas. The quotas control how resources are consumed in your cloud compartments.

  1. Based on your compartment structure, identify services and their quota requirements for each compartment.
  2. Identify the scope of the compartment quotas as availability domain, regional or global.
  3. Create compartment quota policies. When setting a quota at the availability domain (AD) level, the quota is allocated to each AD unless you specify an AD. Regional quotas apply to each region.
  4. Add usage for sub-compartments. Usage for sub-compartments counts towards usage for the main compartment.

Be Aware of Fixed Service Limits

Be aware that some resources have fixed, unchangeable service limits.

Identify those that might impact your applications and make appropriate adjustments to the architecture. For example, a maximum of 5 security lists can be attached to a single subnet. To overcome this limit, you can adjust your architecture to use network security groups in addition to security lists.

Factor Failover Usage in Your Service Limits

Ensure that you factor in a sufficient gap between the current service limit and the maximum usage to accommodate failover.

When a resource fails, it might still be counted against limits until it is successfully terminated. Ensure your limits cover the overlap of all failed resources with replacements before the failed resources are terminated. You should consider an availability domain failure when calculating this gap.

  1. Understand your reliability and availability scenario, and how you are making your architecture resilient enough to accommodate that. Typically, availability is in the form of 'number of 9s'.
  2. Understand your deployment patterns, such as Blue/Green, rollover, or canary.
  3. Have an appropriate buffer on your service limits for failover.
  4. Leave appropriate room for future growth and expansion.