Manage Your Service Limits
Understand the Default Service Limits of Your Tenancy
Enterprise Architect, Cloud Architect, Infrastructure Lead
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 OCI Console or API to view your service limits.
OCI 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, only one NAT Gateway resource is allowed per 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:
- Identify your Oracle Cloud Infrastructure regions based on your application, latency, and disaster recovery requirements.
- Identify the services that your applications require.
To determine your requirements, review the application architecture, infrastructure code, or on-premises deployment and follow these best practices:
- 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.
- Identify which default service limits require an increase.
- Understand the capacity that is required to run your application at peak load, and ensure your limits allow resiliency in the event of the failure of an availability domain.
- Allow you to protect yourself from unexpected consumption by ensuring your tenancy can only use the resources you want.
- Inform Oracle of the resources you need to run your workload so those resources are always available to you.
Monitor and Manage Your Service Limits
Cloud Architect, Infrastructure Lead
-
Use the OCI 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 OCI Console or Service Limits API to validate the service limit.
Set Compartment Quotas
Cloud Architect, Infrastructure Lead
- Identify services and their quota requirements for each compartment, based on your compartment structure. Quotas set at a parent compartment level, limit resource use for that compartment and all of its children. When setting quotas for a parent compartment, remember to include the usage in child compartments.
- Identify the scope of the compartment quotas as availability domain, regional, or global.
- Create compartment quota policies. When setting a quota that has a scope of availability domain (AD), the quota is allocated to each AD unless you specify an AD in the policy. Regional quotas apply to each region.
- Set an upper boundary to prevent errant configurations from creating request storms that create unlimited resources.
Be Aware of Fixed Service Limits
Cloud Architect, Infrastructure Lead
Identify those that might impact your applications and make appropriate adjustments to the architecture. For example, you can attach a maximum of 5 security lists 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
Cloud Architect, Infrastructure Lead
When a resource fails, it might still be counted against limits until it is successfully terminated. Ensure that 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.
- 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'.
- Understand your deployment patterns, such as Blue/Green, rollover, or canary.
- Have an appropriate buffer on your service limits for failover.
- Leave appropriate room for future growth and expansion.