System and method for tag based resource limits or quotas in cloud infrastructure environment

Abstract

To provide a system and a method for supporting tag based resource limits or quotas in an associated cloud infrastructure environment.SOLUTION: A method is for restricting handling of resources or allocating quotas thereto, or, for example, provisioning resources based on request context in a cloud infrastructure environment. The method includes receiving a request for provisioning a resource, inspecting the request, determining the context of the request to the requested resource, determining a privilege level classification associated with the requested resource, allocating the resource request to a specific container according to the determined group of the request, comparing the request context with a plurality of necessary credential gate levels, and dropping a request for handling of a first resource when the request context information is determined not to match the necessary credential gate level.SELECTED DRAWING: Figure 10

Description

[Technical field]

[0001] Copyright Notice A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of this patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0002] Priority claims and cross-references to related applications: This application is a joint venture of U.S. Provisional Patent Application No. 2019 / 08 / 09 entitled “SYSTEM AND METHOD FOR TAG BASED RESOURCE LIMITS OR QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT,” filed on August 9, 2019. Application No. 62 / 884,931, and the application "SYSTEM AND METHOD FOR TAG BASED REQUEST CONTEXT IN A CLOUD INFRASTRUCTURE ENVIRONMENT” No. 62 / 884,933, filed on Oct. 13, 2007, which claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 884,933, entitled "Compounding a Polymer for a Medical Device," each of which is incorporated herein by reference in its entirety.

[0003] This application is a joint venture with U.S. Patent No. 6,369,633, filed on August 5, 2020, entitled “SYSTEM AND METHOD FOR TAG BASED RESOURCE LIMITS OR QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT.” Application No. 16 / 986,158, and entitled “SYSTEM AND METHOD FOR TAG BASED REQUEST CONTEXT IN A CLOUD INFRASTRUCTURE ENVIRONMENT,” filed on August 5, 2020. This application also claims the benefit of priority to U.S. patent application Ser. No. 16 / 986,160, filed on Mar. 23, 2007, each of which is incorporated herein by reference in its entirety.

[0004] Technical Field The embodiments described herein generally relate to a cloud infrastructure environment, such as Infrastructure as a Service (IaaS). The present invention relates to a cloud infrastructure environment, and more particularly to a system and method for providing resource constraints within such a cloud infrastructure environment. [Background technology]

[0005] background: A cloud infrastructure environment can comprise a set of complementary cloud services that enable users and clients (throughout this specification the terms "clients" and "customers" can be used interchangeably) to build and run a wide range of applications and services in a highly available hosted environment.

[0006] Every year, more and more businesses and organizations are migrating their mission-critical applications and systems to cloud infrastructure environments. The reasons for this shift are manifold. For example, many businesses are moving to the cloud to reduce the cost and complexity of operating, maintaining, and building out on-premise infrastructure. Similarly, cloud infrastructure also enables a more agile information technology (IT) delivery mechanism. Some businesses and organizations also see cloud infrastructure environments as a means to gain a competitive advantage by adopting more agile systems.

[0007] In the Infrastructure as a Service (IaaS) model, cloud providers In a traditional setup, the infrastructure would be on-premise at each customer / client location. Such infrastructure components, which are traditionally provided on-premise, can include hardware, e.g., data warehouses and data centers, servers, storage, networking hardware, and software, such as virtualization software.

[0008] In addition to providing hardware and software that would traditionally be on-premise, IaaS providers can also provide services to their clients and customers. As an example, clients and customers can be enabled to tailor their IaaS subscriptions to fit their needs, which in turn allows for detailed and decomposed billing and invoicing. IaaS can also support features such as load balancing, redundancy, replication, recovery, etc. Because such services are provided and supported by the IaaS provider (rather than the customer), this allows clients and customers to focus more on improving their business by pushing further into automation and orchestration for their services.

[0009] Cloud infrastructure allows users and clients to seamlessly run traditional enterprise applications alongside cloud-native apps, all on the same platform, reducing operational overhead and enabling direct connectivity between both types of workloads. Summary of the Invention [Means for solving the problem]

[0010] overview: Described herein are systems and methods for providing tag-based resource limits or quotas in a cloud infrastructure environment. The systems and methods described herein support tag-based resource limits / quotas in a cloud infrastructure environment. A fine-grained approach can provide resource limits based on tags across multiple containers. Tags are a mechanism used primarily in resource management, and cloud providers also use them for cost management. The systems and methods can create a mechanism to control costs at a group level through tags. The systems and methods provide compartment quotas for a cloud infrastructure environment.

[0011] Cloud administrators have the ability to limit resource usage in existing clouds, but only at a high level and do not consider resources at the level of a particular user, particular resource and resource type, or container hierarchy. In accordance with an embodiment, resources are associated with tags so that their usage can be controlled, tracked, and / or otherwise handled at the resource level, as needed or desired. By establishing resource quotas and / or limits, administrators and others can limit users' resource usage to appropriate levels, allowing for fine-tuned cost control.

[0012] According to an embodiment, customers can be assigned service level limits defined by the cloud infrastructure environment upon account creation. These service level limits limit the total number of resources a customer can create across the entire tenancy (e.g., across multiple regions with multiple compartments, spanning multiple containers). Tenancy and compartment administrators can utilize tag-based resource allocations to set resource-specific limits. Without such limits based on tags associated with resources, a user authorized to launch an instance could consume all available capacity across the entire tenancy. Tag-based resource limits solve this problem and, unlike service limits, can be easily configured through, e.g., the Console, S Tag-based resource limits are configured and customized by clients and customers via the DK, or APIs. Tag-based resource limits are applied on top of service limits and can be inherited through nested compartment hierarchies. This allows compartment administrators to restrict resource consumption and set boundaries around acceptable resource usage. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 illustrates a system for providing a cloud infrastructure environment according to an embodiment. [Diagram 2] FIG. 1 illustrates a system for providing a cloud infrastructure region within a cloud infrastructure environment according to an embodiment. [Diagram 3] FIG. 2 illustrates a cloud infrastructure environment system illustrating relationships between compartments, compartment policies, subcompartments, and subcompartment policies for policy management and control across cloud infrastructure regions according to an embodiment. [Figure 4]4 is a diagram illustrating a cloud infrastructure environment 400 illustrating the relationships between compartments, compartment policies, subcompartments, and subcompartment policies when moving a compartment. [Diagram 5] FIG. 5 illustrates a cloud infrastructure environment 500 illustrating policy implications when moving compartments. [Figure 6] FIG. 13 illustrates predefined tag pairs according to an example embodiment. [Figure 7] 1 illustrates an architecture of a system for enforcing quotas or limits on resources in a cloud infrastructure environment based on tags, including, for example, resource tags and resource request context tags, in accordance with an exemplary embodiment. [Figure 8] FIG. 1 illustrates a system that uses request context tags and / or resource tags to restrict usage, such as provisioning, of resources in a cloud infrastructure environment. [Figure 9] 1 is a functional schematic diagram of a system for providing resource request context tag-based limits / quotas in a cloud infrastructure environment, according to one embodiment. [Figure 10] 1 is a flow diagram illustrating a method for limiting or imposing quotas on resource provisioning in a cloud infrastructure environment based on a request context, according to an example embodiment. [Figure 11] FIG. 1 is a functional schematic diagram of a system for providing tag-based resource limitations / quotas in a cloud infrastructure environment, according to one embodiment. [Figure 12] 1 is a flow diagram illustrating a method for limiting or imposing quotas on resource provisioning in a cloud infrastructure environment based on resource tags, according to an example embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Detailed Description: According to embodiments herein, the terms "bare metal host," "bare metal instance," or "bare metal compute instance" may refer to a physical host ("bare metal") machine provided for use by a cloud infrastructure environment. A bare metal compute instance runs directly on a bare metal server without a hypervisor. Once a bare metal instance is provisioned, the user / client can maintain sole control of the physical CPU, memory, and network interface card (NIC). The user / client can configure and utilize the full capabilities of each physical machine as if it were hardware running in their own data center. The user / client does not share the physical machine with other tenants.

[0015] According to embodiments herein, a cloud infrastructure environment is a A region may be physically hosted in a region and an availability domain. The term "region" may refer to a localized geographic area. The term "availability domain" may mean one or more data centers located within a region. A region is composed of one or more availability domains. Cloud infrastructure can be region-specific, such as a virtual cloud network, or availability domain-specific, such as a compute instance. Availability domains are isolated from each other, fault-tolerant, and unlikely to fail simultaneously or be affected by the failure of another availability domain. When a user / client configures his / her cloud service, the user / client can use multiple availability domains to ensure high availability and protect against resource failures. Some resources must be created in the same availability domain, such as an instance and its associated storage volume.

[0016] According to embodiments herein, the term "realm" may refer to a logical collection of regions. Realms are isolated from each other and do not share any data. A client tenancy may exist within a single realm and have access to each of the regions that belong to that realm. Realms may be provided, for example, for commercial and government cloud regions.

[0017] According to embodiments herein, the term "console" may refer to a (e.g., web-based) user interface that a user / client may use to access and manage a cloud infrastructure environment.

[0018] According to embodiments herein, the term "tenancy" may refer to a secure and isolated partition within a cloud infrastructure environment. When a client / user signs up for a cloud infrastructure environment, the cloud infrastructure environment may create a tenancy for that user / client (or their company). A tenancy may be where a user / client creates, organizes, and manages their cloud resources.

[0019] According to embodiments herein, the term "compartment" may refer to a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that may only be accessed by a specific group that has been granted permission by an administrator. Compartments allow clients / users to organize their cloud resources and control access to them. When a client / user begins working with resources in the console, compartments may provide a filter for what the client / user is looking at.

[0020] According to embodiments herein, the term "tenancy" may refer to a root compartment that contains all of a tenant's cloud resources. Additional compartments may be created within the tenancy (root compartment) and corresponding policies to control access to resources within each compartment. When a user / client creates a cloud resource, such as an instance, block volume, or cloud network, the user / client may specify which compartment the resource should belong to.

[0021] According to embodiments herein, the term "virtual cloud network" may refer to a virtual version of a traditional network, including subnets, route tables, and gateways, in which instances operate. A cloud network exists within a single region but includes all availability domains of that region. Each subnet defined in a cloud network may be in or across a single availability domain. At least one cloud network may be set up before an instance can be launched, and may span all availability domains in a region.

[0022] According to embodiments herein, the term "instance" may refer to a computing host operating within a cloud. A cloud infrastructure environment instance allows users / clients to utilize hosted physical hardware as opposed to traditional software-based virtual machines, which may provide increased security and performance.

[0023] According to embodiments herein, the term "image" may refer to a template of a virtual hard drive that defines an operating system and other software for an instance, such as, for example, LINUX. When an instance is launched, its characteristics can be defined by selecting its image. A set of images may be provided, and an image may be used from an existing instance that is already configured (e.g., as a template) to use an instance with the same software and customizations.

[0024] According to embodiments herein, the term "shape" may refer to the specification of the number of CPUs and the amount of memory allocated to an instance. In load balancing, the shape may determine the load balancer's pre-provisioned total maximum capacity (bandwidth) for ingress + egress traffic. Available shapes may include, for example, 100 Mbps, 400 Mbps, and 8000 Mbps.

[0025] According to an embodiment of the present specification, the term "key pair" may refer to an authentication mechanism used in a cloud infrastructure environment. A key pair consists of a private key file and a public key file. The public key can be uploaded while the private key is kept on the user / client's device. The private key is secret to the user / client, like a password. Key pairs may be generated according to different specifications, such as an instance SSH key pair and an API signing key pair. The instance SSH key pair is used to establish a secure shell (SSH) connection to the instance. When the instance is provisioned, a public key may be provided, which is stored in the instance's authorized key file. To log on to the instance, a private key is provided, which is verified with the public key. The API signing key pair is in PEM (Privacy Enhanced Mail) format and is used to authenticate the user / client when submitting an API request.

[0026] According to embodiments herein, the term "block volume" may refer to a virtual disk that provides persistent block storage for a cloud infrastructure environment instance. A block volume may be used, for example, in a manner similar to a physical hard drive on a computer, for example, to store data and applications. A volume may be detached from one instance and attached to another instance without data loss.

[0027] According to embodiments herein, the term "object storage" may refer to a storage architecture that may be used to store and manage data as objects. Data files may be of any type. Once data is uploaded to object storage, it may be accessed from any location. Object storage may be used when there is a need to store large amounts of data and the data does not change very frequently. A typical use for object storage is to store data This includes, but is not limited to, data backup, file sharing, and storage of unstructured data (e.g., logs and sensor-generated data).

[0028] According to embodiments herein, the term "bucket" may refer to a logical container for storing data and files. A bucket may contain an unlimited number of objects.

[0029] As described above, a cloud infrastructure environment can comprise a set of complementary cloud services that enable users and clients to build and run a wide range of applications and services in a highly available hosted environment.

[0030] FIG. 1 illustrates a system for providing a cloud infrastructure environment, according to one embodiment.

[0031] According to an embodiment, a cloud infrastructure environment 100, which may run on a number of hardware and software resources 112, may comprise a console interface 102 and an API 104. In addition, the cloud infrastructure environment 100 may support a number of governance services 110, an identity and access management (IAM) service 120, and a provisioning service 130. The cloud infrastructure environment 100 may also support a number of resources 140, for example, in layers such as a computer resource layer 150, a network resource layer 160, and a storage resource layer 170. The cloud infrastructure environment 100 may also support a number of tags associated with each of the resources, including, for example, a resource tag 140a generally associated with the resource 140, a computer resource tag 150a associated with the computer resource 150, a network resource tag 160a associated with the network resource 160, and a storage resource tag 170a associated with the storage resource 170.

[0032] According to an embodiment, a client device, such as a computing device 10 having device hardware (processor, memory, etc.) 12, can communicate with a cloud infrastructure environment over a network, such as, for example, a wide area network (WAN), a local area network (LAN), or the Internet. The client device can include an administrator application 14, which can include a user interface 16.

[0033] According to an embodiment, tenancies may be supported within the cloud infrastructure environment. Upon registration and deployment, a tenancy may be created for each client / customer, which may provide a secure and isolated partition within the cloud infrastructure where the client can create, organize, and manage their cloud resources.

[0034] According to one embodiment, the console interface 102 and API 104 provide clients with access and control over their respective portions of the infrastructure environment. According to one embodiment, the console interface may include an intuitive graphical interface that allows clients to create and manage resources, instances, cloud networks, and storage volumes, as well as manage users associated with the client and set permissions within the client. Similarly, the API 104 may communicate over a variety of protocols, such as HTTPS (HyperText Transfer Protocol Secure) and / or HTTP (HTTPS) protocols. This may include a REST API that utilizes the

[0035] According to one embodiment, an example of a console interface or API may be a configuration management tool (e.g., Ansible). The configuration management tool may be a cloud infrastructure Configuration management tools can be used for infrastructure provisioning, orchestration, and configuration management. Configuration management tools can enable clients to automate the configuration and provisioning of cloud infrastructure, the deployment and updates of software assets, and the orchestration of complex operational processes.

[0036] According to an embodiment, the governance service 110 of the cloud infrastructure environment provides clients with tools that enable simple resource management, help clients manage costs, and control access to the cloud infrastructure. As an example, the governance service can provide tagging, which allows clients to apply tags to their resources for informational or operational reasons. Predefined tags can be controlled to avoid incorrect tags being applied to resources. Tags can also provide a flexible targeting mechanism for management scripts. Similarly, the governance service can enable budget management, tracking actual and forecasted expenses all from one place. This allows clients to stay on top of usage with a cost analysis dashboard, filtering by compartment and tags to analyze spending by department, team, and project. Such data can also be exported for detailed resource utilization reporting and integration with existing cloud management and business intelligence tools. The governance service can also log events that can be later searched, stored, and analyzed for security, compliance, and resource optimization across cloud infrastructure entitlements and compartments.

[0037] According to an exemplary embodiment, the governance service provides tagging that allows clients, administrators, and the like to apply tags to their resources for informational or operational reasons when the resources are instantiated. According to a further exemplary embodiment, the governance service also provides tagging that allows clients and others to apply tags to their resources for informational or operational reasons after the resources are instantiated, thereby enabling retroactive enforcement of resource quotas or limits in the system using the tags.

[0038] According to an embodiment, the Identity and Access Management (IAM) service 120 can create a user profile for each client / customer / user in the IAM service, associated with user credentials (e.g., username and password). Clients can also be granted administrative privileges in the cloud infrastructure via the IAM service.

[0039] According to an embodiment, the identity and access management service can be integrated with a cloud infrastructure environment: upon client registration, the IAM service can create separate user credentials in the identity service, which can then enable single sign-on to the cloud infrastructure service and access to additional cloud services.

[0040] According to one embodiment, a provisioning service 130 can provision a tenancy within a cloud infrastructure service, such as within resources 140. The provisioning service can be accessed and controlled, for example, through a console interface or via one or more APIs, such as API 104. A provisioning service may enable clients to provision and manage compute hosts, which may be referred to as instances. Clients may launch instances as needed to meet computational and application requirements. After a client launches an instance, the provisioned instance may be accessed, for example, from a client device. A provisioning service may also provide for rebooting an instance, attaching and detaching volumes from an instance, and terminating an instance.

[0041] According to an embodiment, resources 140 provided by a cloud infrastructure environment may be divided into multiple tiers, such as a computational resource tier 150 , a network resource tier 160 , and a storage resource tier 170 .

[0042] According to an embodiment, the computing resource layer 150 may include several resources, such as, for example, bare metal instances 152, virtual machines 154, edge services 156, and containers 158. The computing resource layer may be used, for example, to provision and manage bare metal computing instances and provision instances as needed to deploy and run applications, similar to an on-premise data center. The cloud infrastructure environment 100 according to an example embodiment supports several tags 140a associated with each of the resources, including, for example, a computing resource tag 150a associated with the computing resources 150 including the bare metal instances 152, virtual machines 154, edge services 156, and containers 158.

[0043] According to an embodiment, a cloud infrastructure environment can provide control of one or more physical host ("bare metal") machines in a compute resource tier. Bare metal compute instances run directly on bare metal servers without a hypervisor. Once a bare metal compute instance is provisioned, the client can maintain sole control of the physical CPU, memory, and network interface cards (NICs). Bare metal compute instances can be configured to utilize the full power of each physical machine as if it were hardware running in their own on-premise data center. Thus, bare metal compute instances are generally not shared between tenants.

[0044] According to certain embodiments, bare metal computing instances can provide a high level of security and performance through associated physical hardware, as opposed to software-based virtual environments.

[0045] According to an embodiment, a cloud infrastructure environment can provide control of a number of virtual machines within a computing resource layer. A virtual machine computing host can be booted from an image that can determine, for example, a virtual machine operating system and other software. The type and amount of resources available to a virtual machine instance can be determined based on, for example, the image from which the virtual machine was booted.

[0046] According to an embodiment, a virtual machine (VM) computing instance may include an independent computing environment that runs on top of physical bare metal hardware. Virtualization allows multiple VMs to run that are isolated from each other. VMs can be used, for example, to run applications that do not require the performance and resources (CPU, memory, network bandwidth, storage) of an entire physical machine.

[0047] In some embodiments, a virtual machine instance is the same as a bare metal instance. It can run on the same cloud-optimized hardware, firmware, software stack, and networking infrastructure.

[0048] According to an embodiment, a cloud infrastructure environment can provide several Graphical Processing Unit (GPU) computing instances in the computing resource layer. Accelerated computing requires consistently fast infrastructure across all services. With GPU instances, clients can more efficiently process and analyze large data sets, making them useful for complex machine learning (ML), artificial intelligence (AI) algorithms, and many industrial HPC applications. GPU computing instances can be provisioned as virtualized computing instances (where multiple GPU computing instances share the same bare metal hardware) or as bare metal instances that provide dedicated hardware for each GPU computing instance.

[0049] According to an embodiment, the cloud infrastructure environment can provide several containerized compute instances in a compute resource layer. A standalone container engine service can be used to build and launch containerized applications in the cloud. The container service can be used, for example, to build, deploy, and manage cloud native applications. The container service can specify the compute resources required by the containerized application, and the container engine, via a provisioning service, can then provision the required compute resources for use in the cloud infrastructure environment (e.g., in the context of a tenancy).

[0050] According to one embodiment, one such container service engine that can be used is Kubernetes, an open source system for automating the deployment, scaling, and management of containerized applications across a cluster of hosts. Such container services can group the containers that make up an application into logical units for easy management and discovery.

[0051] According to an embodiment, network resource layer 160 may include several resources, such as, for example, virtual cloud networks (VCNs) 162, load balancers 164, edge services 166, and connectivity services 168. Cloud infrastructure environment 100 according to an example embodiment supports several tags associated with each of the resources, including, for example, resource tag 140a associated generally with resource 140, and network resource tag 160a associated with virtual cloud networks (VCNs) 162, load balancers 164, edge services 166, and connectivity services 168.

[0052] According to an embodiment, the cloud infrastructure environment can provide several virtual cloud networks 162 at the networking resource layer. A virtual cloud network can include a virtual version of a traditional network, including subnets, route tables, and gateways in which client instances can operate. A cloud network exists within a single region but includes all availability domains of that region. Each subnet defined in a cloud network can either be within a single availability domain or span all availability domains in that region (recommended). At least one cloud network can be configured before launching an instance. In an embodiment, a VCN can handle public traffic, VPN connections, or high-speed connection services to provide a secure, secure, and secure network connection to an on-premises network. It can be configured through an Internet gateway to securely extend the network.

[0053] According to an embodiment, the cloud infrastructure environment can provide several load balancers 164 at the networking resource layer. The load balancing service can provide automated traffic distribution from one entry point to multiple servers reachable from a virtual cloud network (VCN). The various load balancers can provide public or private IP addresses and provisioned bandwidth.

[0054] According to an embodiment, the load balancer can help improve resource utilization, scaling, and ensure high availability. Multiple load balancing policies can be configured and application-specific health checks can be provided to ensure that the load balancer directs traffic only to healthy instances. The load balancer can reduce maintenance windows by draining traffic from unhealthy application servers before they are removed from service for maintenance.

[0055] According to an embodiment, the load balancing service allows for the creation of public or private load balancers associated with a VCN. A public load balancer has a public IP address accessible from the Internet. A private load balancer has an IP address from a hosting subnet that is only visible within the VCN. Multiple listeners can be configured to load balance different tiers of traffic (e.g., tier 4 and tier 7 (TCP and HTTP) traffic) for an IP address. Both public and private load balancers can route data traffic to any backend server reachable from the VCN.

[0056] According to an embodiment, a public load balancer can be created that can accept traffic from the Internet and is assigned a public address that serves as an entry point for incoming traffic.

[0057] According to an embodiment, the public load balancer is regional in scope. If the region includes multiple availability domains, the public load balancer can have, for example, a regional subnet or two availability domain-specific (AD-specific) subnets, each in a separate availability domain. In a regional subnet, the load balancer can create a primary load balancer and a standby load balancer, each in a different availability domain, to ensure accessibility even during an availability domain outage. When the load balancer is formed in multiple AD-specific subnets, one subnet can host the primary load balancer and the other subnet can host the standby load balancer. If the primary load balancer fails, the public IP address can switch to the secondary load balancer. The service treats the two load balancers as equivalent.

[0058] According to one embodiment, if a region contains only one availability domain, the service requires only one subnet, whether regional or AD-specific, to host both the primary and standby load balancers. The primary and standby load balancers each have a private IP address from the host subnet in addition to an assigned floating public IP address. If there is an availability domain outage, the load balancer does not have failover.

[0059] According to an embodiment, private load balancing may also be provided to isolate the load balancer from the Internet and simplify the security posture. The load balancer service may assign the load balancer a private address that serves as an entry point for incoming traffic.

[0060] According to an embodiment, a private load balancer can be created by a service to serve only one subnet and host both a primary and a standby load balancer. The load balancer can be regional or AD-specific, depending on the scope of the host subnet. The load balancer is accessible only from within the VCN that contains the host subnet, or as further restricted by security rules.

[0061] According to one embodiment, the assigned floating private IP addresses are local to the host subnet. The primary and standby load balancers each require an additional private IP address from the host subnet.

[0062] According to one embodiment, a private load balancer created in a regional subnet in a multi-AD region provides failover capability when there is an availability domain outage. A private load balancer created in an AD-specific subnet or in a regional subnet in a single availability domain region does not have failover capability in response to an availability domain outage.

[0063] According to an embodiment, the cloud infrastructure environment can provide several edge services 166 at the networking resource layer. Generally, the edge services comprise several services that enable clients to manage, secure, and maintain domains and endpoints. These include, for example, DNS (Domain Name System), DDoS (Distributed Denial of Service) protection, email delivery, etc. These services enable clients to optimize performance, thwart cyber attacks, and scale communications.

[0064] According to an embodiment, the cloud infrastructure environment can provide several connectivity services 168 at the networking resource layer. Such connectivity services can provide an easy way to create dedicated, private connections between client data centers or existing networks and the cloud infrastructure environment. The connectivity services can provide high bandwidth and reliable, consistent networks.

[0065] According to an embodiment, storage resource tier 170 may include several resources, such as, for example, block volumes 172, file storage 174, object storage 176, and local storage 178. Cloud infrastructure environment 100 according to an example embodiment supports several tags associated with each of the resources, including, for example, resource tag 140a associated with resource 140 generally, and storage resource tags 170a associated with block volumes 172, file storage 174, object storage 176, and local storage 178.

[0066] According to one embodiment, block volumes 172 provide high-performance network storage capacity that supports a wide range of I / O intensive workloads. Clients can use block volumes to extend the storage capacity of their compute instances, provide durable, persistent data storage that can be migrated across compute instances, and host large databases.

[0067] According to one embodiment, file storage 174 enables clients to create scalable, distributed, enterprise-grade network file systems. File storage supports semantics, snapshot capabilities, and encryption at rest.

[0068] According to one embodiment, object storage provides high-throughput storage for unstructured data. Object storage services allow for nearly unlimited storage capacity for large amounts of analytical data or rich content such as images and videos. Block volumes can be backed up to object storage for additional durability.

[0069] According to an embodiment, local storage 178 can provide fast and reliable storage, for example in the form of solid state drives for I / O intensive applications. These can be provided, for example, within bare metal instances. The local storage provides high storage performance for VMs and bare metal compute instances. Some examples include relational databases, data warehouses, big data, analytics, AI, and HPC applications.

[0070] FIG. 2 illustrates a system for providing a cloud infrastructure region within a cloud infrastructure environment according to an embodiment.

[0071] According to an embodiment, instances of the cloud infrastructure environment described above in Figure 1 may be hosted in different regions, referred to as cloud infrastructure regions 220. They may be accessed by customer networks 200 over a network, such as the Internet 210, via a console, SDK, or API, as described above. Each cloud infrastructure region may include management services 222, compute services 224, storage services 226, edge services 228, network services 230, and physical infrastructure 232.

[0072] According to an embodiment, cloud infrastructure can be hosted in regions and availability domains. A region can be a localized geographic area, and an availability domain can be one or more data centers located within a region. A region is composed of one or more availability domains. Most cloud infrastructure resources can be either region-specific, such as a virtual cloud network, or availability domain-specific, such as a compute instance. Traffic between availability domains and between regions is encrypted.

[0073] According to one embodiment, availability domains are isolated from each other, fault tolerant, and highly unlikely to fail simultaneously: Because availability domains do not share infrastructure such as power or cooling, or internal availability domain networks, a failure in one availability domain within a region is unlikely to affect the availability of others in the same region.

[0074] According to one embodiment, availability domains within the same region can be connected to each other by low-latency, high-bandwidth networks, providing highly available connectivity to the Internet and on-premises, and enabling the creation of replicated systems in multiple availability domains for both high availability and disaster recovery.

[0075] According to one embodiment, regions are independent of other regions and can be geographically separated (e.g., across countries or continents), which then leads to the deployment of an application in the region where it is most likely to be used most frequently.

[0076] However, according to an embodiment, applications may also be deployed in different regions for a variety of reasons, including, for example, risk mitigation when an event such as a weather system takes a region offline. In addition, applications may be deployed to other regions for strategic reasons, such as tax domains or other business or social criteria.

[0077] According to one embodiment, there are several services available across the region, including, for example, management services 222, computational services 224, storage services 226, edge services 228, and network services 230.

[0078] According to an embodiment, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that can only be accessed by a particular group that has been granted permission by an administrator. For example, one compartment may contain all the servers and storage volumes that make up the composition of a company's Human Resources (HR) system, as an example, while another compartment may be separately dedicated to the company's legal, marketing, accounting, sales, and information technology (IT) systems, respectively, as a further example. In an example, only users with permission to that compartment can manage and / or access those servers and volumes. In a further example, a compartment may contain all the servers and storage volumes that make up the composition of a company's Human Resources (HR) system and its collection of legal, marketing, accounting, sales, and information technology (IT) systems. In an example, only users with permission to those portions of resources can manage and / or access those portions on the servers and volumes.

[0079] A compartment in an exemplary embodiment comprises one or more logical groupings and is not necessarily a physical memory container, but may be, as desired or necessary. When working within the console, a compartment can act as a filter for what is allowed to be seen. Compartments are the main building block that can be used for cloud resources; they can be used to organize and isolate resources to make it easier to manage and secure access to those resources.

[0080] According to an embodiment, a compartment can have several tiers. For example, a tenancy can be considered the root compartment that holds all of a client's cloud resources. Additional compartments can be created within the root compartment (tenancy) and corresponding policies can be created to control access to resources within each compartment. A client can have compute, storage, VCNs, IP addresses and / or DNS instances, block volumes, or When you create a cloud resource, such as a cloud network, you can target such a resource to a specific compartment or compartments. Compartments can span regions.

[0081] Fault Domain According to an embodiment, a fault domain can include a grouping of hardware and infrastructure within an availability domain. Each availability domain can include three fault domains. Fault domains allow instances to be distributed such that they are not on the same physical hardware within a single availability domain. A hardware failure or compute hardware maintenance that affects one fault domain does not affect instances in other fault domains.

[0082] According to an embodiment, placement of a resource, such as a compute, bare metal DB system, or virtual machine DB system instance, can optionally specify a failure domain or a new instance at launch time. After placement, the resource can additionally change its failure domain by terminating the resource in its current failure domain and launching a new instance of the resource in a different failure domain.

[0083] According to an embodiment, fault domains can be utilized for a number of reasons, such as protection from unexpected hardware failures and protection from planned outages due to maintenance.

[0084] availability According to an embodiment, service availability can be provided. Regions within a cloud infrastructure environment can provide core infrastructure services and resources, including: Compute: Compute (bare metal and VM, DenseIO and Standard), container engine for Kubernetes, registry... Storage: Block volumes, file storage, object storage, archive storage Networking: Virtual cloud network, load balancing, high speed connection Database: Database, Exadata cloud services, autonomous data warehouse, Autonomous Transactions ·process Edge: DNS Platform: Identity and access management, tagging, auditing According to an embodiment, the above services and resources may be generally available, but other services and resources may be additionally available (e.g., based on regional demand or customer request). By way of example, new cloud services may be made available as quickly as possible in a region based on various considerations, including regional customer demand, the ability to achieve regulatory compliance where applicable, resource availability, and other factors. Because of the low-latency interconnection backbone, customers can use cloud services with efficient results in other geographic regions when they are not available in their home region, provided that data residency requirements do not prevent them from doing so.

[0085] According to an embodiment, resource availability can be considered in the context of global availability, regional availability, single region availability, and domain availability. Generally, IAM resources are globally available, while DB systems, instances, and volumes are specific to a viability domain. Most other resources are regional.

[0086] According to an embodiment, examples of globally available resources may include API signing keys, compartments, dynamic groups, federated resources, groups, policies, tag namespaces, tag keys, and users.

[0087] According to one embodiment, examples of regionally available resources include alarms, applications, buckets (buckets are regional resources, but buckets can be accessed from any location with the correct region-specific object storage URL for the API call), clusters, cloud event rules, customer premises equipment (CPE), DHCP option sets, dynamic routing gateways (DRGs), encryption keys, functions, images, internet gateways, jobs, key vaults, load balancers, local peering gateways (LPGs), metrics, NAT gateways, network security groups, node pools, ons-subscriptions, ons-topics. These can include repositories, reserved public IPs, route tables, security lists, service gateways, stacks, subnets (when a subnet is created, it can be declared to be regional or availability domain specific), virtual cloud networks (VCNs), and volume backups (volume backups can be restored as new volumes to any availability domain within the same region in which they are stored).

[0088] According to an embodiment, examples of availability domain-specific resources may include DB systems, ephemeral public IPs, instances (an instance can be attached to a volume in the same availability domain), subnets (when a subnet is created, it can be declared as regional or availability domain specific), and volumes (a volume can be attached to an instance in the same availability domain).

[0089] compartment According to one embodiment, an administrator can manage compartments within a cloud infrastructure environment.

[0090] According to an embodiment, tags can be applied to resources within a compartment. Tags can be used to organize resources according to a schema, such as, for example, a business needs schema. Tags can be applied to resources at the time of their creation or tags can be updated on existing resources. Tags associated with each of the resources may include, for example, resource tag 140a (FIG. 1) generally associated with resource 140, computer resource tag 150a associated with computer resource 150, network resource tag 160a associated with network resource 160, and storage resource tag 170a associated with storage resource 170.

[0091] According to an embodiment, compartments are important for building and organizing a cloud infrastructure. Resources can be moved between compartments, viewed (e.g., via a user interface), and organized by compartment within the current region. When working with and managing resources, a compartment can be selected first.

[0092] According to one embodiment, compartments are tenancy-wide and can span regions: when a compartment is created, it can be made available in any region to which the tenancy is subscribed.

[0093] According to an embodiment, a compartment can be deleted: To delete a compartment, the compartment can have all resources therein removed prior to deletion.

[0094] According to one embodiment, the action of deleting a compartment can be asynchronous and initiates a work request. The compartment's state changes to "deleting" while the work request is running. If the work request fails, the compartment is not deleted and returns to the active state.

[0095] According to an embodiment, each compartment created in the cloud infrastructure environment can have certain properties. For example, each compartment can be assigned a unique identifier (ID) and, optionally, can be provided with a configurable description and name. According to an embodiment, subcompartments can be hierarchically defined under a base compartment.

[0096] According to an embodiment, access to and control over compartments and subcompartments can be limited to administrators or other users with sufficient credentials. Credentials can be associated with different levels of compartment access. For example, an administrator can have permission to view and access all compartments and work with resources in any compartment of the tenancy, while a user with more limited access does not have such a level of access and control.

[0097] FIG. 3 illustrates a cloud infrastructure environment 300 illustrating relationships between compartments 360, compartment policies 365, subcompartments 370, and subcompartment policies 375 for policy management and control across cloud infrastructure regions, according to one embodiment.

[0098] According to an embodiment, as discussed above, instances of the cloud infrastructure environment described above in Figure 1 may be hosted in different regions, such as cloud infrastructure regions 320, 330, 340, 350. They may be accessed by customer network 301 over network 302, such as the Internet, via consoles, SDKs, or APIs, as discussed above.

[0099] According to an embodiment, customer network 301 may include, for example, a single computer, a network of customer computers, or other such networks.

[0100] According to one embodiment, although not shown in the figure, each cloud infrastructure region may include several services, each of which includes several resources such as management services, computational services, storage services, edge services, network services, and physical infrastructure.

[0101] According to an embodiment, cloud infrastructure can be hosted in regions and availability domains. A region can be a localized geographic area, and an availability domain can be one or more data centers located within a region. A region is composed of one or more availability domains. Most cloud infrastructure resources can be either region-specific, such as a virtual cloud network, or availability domain-specific, such as a compute instance. Traffic between availability domains and between regions is encrypted.

[0102] According to one embodiment, availability domains are isolated from each other, fault tolerant, and highly unlikely to fail simultaneously: Because availability domains do not share infrastructure such as power or cooling, or internal availability domain networks, a failure in one availability domain within a region is unlikely to affect the availability of others in the same region.

[0103] According to one embodiment, availability domains within the same region can be connected to each other by low-latency, high-bandwidth networks, providing highly available connectivity to the Internet and on-premises, and enabling the creation of replicated systems in multiple availability domains for both high availability and disaster recovery.

[0104] According to one embodiment, regions are independent of other regions and can be geographically separated (e.g., across countries or continents), which then leads to the deployment of an application in the region where it is most likely to be used most frequently.

[0105] However, according to an embodiment, applications may also be deployed in different regions for a variety of reasons, including, for example, risk mitigation when an event such as a weather system takes a region offline. In addition, applications may be deployed to other regions for strategic reasons, such as tax domains or other business or social criteria.

[0106] According to one embodiment, there are several services available across a region, including, for example, management services, compute services, storage services, edge services, and network services.

[0107] According to an embodiment, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that can only be accessed by specific groups that have been given permission by an administrator. Compartments can be thought of as logical groupings, rather than physical containers. When working within the console, compartments can act as a filter for what you are allowed to see.

[0108] According to an embodiment, compartments can have several tiers. For example, tenancy 305 can be considered the root compartment that holds all of a client's cloud resources. Compartments can be organized in a hierarchical manner, such that compartment 360 is a level below the tenancy compartment, and subcompartment 370 is an additional tier below compartment 360. According to an embodiment, each compartment can be associated with one or more compartment policies, such as compartment policy 365 and subcompartment policy 375. Tenant compartment policies are not shown in the figure.

[0109] According to an embodiment, during, at, or after the creation of a compartment or subcompartment, e.g., compartment 360 and subcompartment 370, policies, such as compartment policy 365 and subcompartment policy 375, can be written / created for each compartment and subcompartment. Without policies in place, access to the compartment and / or subcompartment may be restricted to users with permissions at the tenancy 305 level.

[0110] According to one embodiment, upon creation of a compartment within a compartment (ie, a subcompartment), the subcompartment inherits access permissions from the compartment above it in the hierarchy.

[0111] According to an embodiment, when a compartment or subcompartment policy is created, the policy may include a specification that indicates which compartment it is attached to. Such a specification may include controls that limit access for subsequence control, modification, or deletion of the policy. In some embodiments, a policy may be attached to the tenancy, a parent compartment, or the specific compartment to which the policy is directed.

[0112] According to one embodiment, new resources can be placed into a compartment. This can be accomplished by specifying the targeted compartment when creating a new resource (the compartment is one of the pieces of information required to create a resource). This can be accomplished via the console interface.

[0113] According to an embodiment, existing resources can also be moved to a different compartment. Most resources can be moved after they are created. There are a few resources that cannot be moved from one compartment to another.

[0114] According to an embodiment, some resources have attached resource dependencies and some do not, and when a parent resource moves, not all attached dependencies behave the same.

[0115] According to one embodiment, for some resources, attached dependencies are moved to the new compartment along with the parent resource: the parent resource moves immediately, but in some cases, the attached dependencies move asynchronously and are not visible in the new compartment until the move is complete.

[0116] According to one embodiment, for other resources, attached resource dependencies are not moved to the new compartment: such attached resources may be moved independently.

[0117] According to one embodiment, after a resource is moved to a new compartment, the policies governing the new compartment are immediately applied and affect access to the resource. Depending on the compartment organization structure, metering, billing, and alerting may also be affected.

[0118] According to an embodiment, after creation, a compartment can be moved, for example to a different parent compartment within the same tenancy. When a compartment is moved, all of the compartment's contents (including subcompartments and resources) move with it.

[0119] FIG. 4 illustrates a system for compartment migration within a cloud infrastructure environment according to an embodiment.

[0120] According to one embodiment, as mentioned above, instances of the cloud infrastructure environment 400 described above in FIG. 1 may be hosted in different regions. Compartments, such as compartment 405, compartment A 460, and compartment B 470, can be defined within the cloud infrastructure environment, and these compartments can span regions. Such compartments can be accessed by customer network 401 over a network 402, such as the Internet, via a console, SDK, or API, as described above.

[0121] According to an embodiment, customer network 401 may include, for example, a single computer, a network of customer computers, or other such networks.

[0122] According to an embodiment, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that can only be accessed by specific groups that have been given permission by an administrator. Compartments can be thought of as logical groupings, rather than physical containers. When working within the console, compartments can act as a filter for what you are allowed to see.

[0123] According to an embodiment, compartments can have several tiers. For example, tenancy 405 can be considered the root compartment that holds all of a client's cloud resources. Compartments can be organized in a hierarchical manner such that compartment A 460 and compartment B 470 are levels below the tenancy compartment, subcompartment A 465 is defined below compartment A, and subcompartment B 475 is defined below compartment B. According to an embodiment, each compartment can be associated with one or more compartment policies (not shown).

[0124] According to an embodiment, for example, a compartment defined within a tenancy may be moved, for example, by redefining the compartment or a subcompartment.

[0125] According to one embodiment, a request with sufficient permissions to move a compartment can be received, i.e., from a user belonging to a group that has "all resource management" permissions for the current compartment and the lowest tier shared parent compartment for the destination compartment of the moved compartment.

[0126] That is, for example, a request to move subcompartment A 465 from compartment A 460 to compartment B 470 (moving 465 to 476) must be received with sufficient permissions from a user. Because tenancy 405 is the lowest-level shared parent compartment of both the source compartment, compartment A 460, and the destination compartment, compartment B 470, as shown in the figure, the request to move subcompartment A must be received from a user with "manage all resources" permission in the compartments of tenancy 405.

[0127] In another example, according to an embodiment, if a request to move subcompartment A465 from compartment A to compartment B is received from a user who only has permission to “manage all resources” in compartment A, the request may fail because the request from the user cannot manage resources in the destination compartment, i.e., compartment B.

[0128] According to an embodiment, when a compartment is moved to a new parent compartment, the access policies of the new parent compartment take effect and the policies of the previous parent compartment no longer apply. In some cases, when moving nested compartments with policies that specify a hierarchy, those policies may be automatically updated to ensure consistency.

[0129] Thus, according to one embodiment, the compartment policy of compartment A 460 that was previously applied to subcompartment A will no longer apply to the movement of subcompartment A to compartment B. The compartment policy of compartment B will then be applied to subcompartment A instead. This is further explained in the following figure.

[0130] FIG. 5 illustrates a system for policy management and enforcement during compartment movement within a cloud infrastructure environment.

[0131] More specifically, FIG. 5 illustrates a compartment hierarchy through which compartments may be moved and the consequences for different policies, according to one embodiment.

[0132] According to an embodiment, as described above, instances of cloud infrastructure environment 500 as described above in FIG. 1 may be hosted in different regions. Compartments, such as tenancy 505, compartment A 560 and compartment B 565, and compartment D 566, may be defined within the cloud infrastructure environment, and these compartments may span regions. Such compartments may be accessed by customer network 501 over network 502, such as the Internet, via a console, SDK, or API, as described above.

[0133] According to an embodiment, customer network 501 may include, for example, a single computer, a network of customer computers, or other such networks.

[0134] According to an embodiment, compartments can have several tiers. For example, tenancy 505 can be considered the root compartment that holds all of a client's cloud resources. Compartments can be organized hierarchically, with compartment A 560 being a level below the tenancy. Compartment B 565 and compartment D 566 are then organized as yet another level below compartment A 560, while subcompartment C 570 is initially shown as a level below compartment B. According to an embodiment, each compartment can be associated with one or more compartment policies, such as compartment B policy 582, compartment A policy 580, and compartment D policy 583. Such policies can, for example, govern user / client permissions for access to the compartment, as well as permissions for access to and control of resources within any given compartment. As described above, compartment policies can be added to one another (i.e., “stacked”) such that a user accessing compartment B 565 has their interaction with compartment B 565 governed / restricted by compartment B policy 582 in addition to compartment A policy 580.

[0135] According to one embodiment, assume, for example, that compartment B policy 582 allows a group, group 1, to manage instance families in compartment AB (the compartment hierarchy may be a subcompartment of compartment A). (including compartment B, which is the endothelial compartment).

[0136] According to one embodiment, assume that compartment D policy 583 also allows another group, group 2, to manage instance families within compartment AD (the compartment hierarchy includes compartment D, which is a subcompartment of compartment A).

[0137] According to one embodiment, when compartment C is moved from compartment B to compartment D, members of group 1 can no longer manage the instance families in compartment C, and members of group 2 can now manage the instance families in compartment C.

[0138] According to certain embodiments, in certain circumstances, moving a compartment can automatically update certain policies. For example, policies that specify the compartment hierarchy up to the compartment being moved can be automatically updated when policies are attached to a shared ancestor of the current target parent.

[0139] Referring again to Figure 5, for example, according to one embodiment, assume that compartment A policy allows members of a group, group X, to manage buckets in compartment B:C. If compartment C is moved to compartment D, because of the shared ancestor between compartment B and compartment D (compartment A), compartment A policy may be automatically updated to allow members of group X to manage buckets in compartment D:C.

[0140] According to an embodiment, policies attached to a tenancy can also be automatically updated when a compartment is moved within the tenancy.

[0141] However, according to an embodiment, moving a compartment does not automatically update all policies. For example, referring to FIG. 5, in a situation where compartment C is moved from compartment B to compartment D, assume that compartment B policy allows management of buckets in compartment C (prior to the move). When compartment C is moved, compartment B policy is not automatically updated. Instead, the policy is no longer valid and may be removed (e.g., manually or automatically).

[0142] Tag-based resource limits / quotas According to an embodiment, cloud administrators generally do not have the ability to limit resource usage in existing clouds. Giving a user permission to create resources allows the user to create any number of resources up to a predefined account limit. Tag-based resource limits or quotas allow for restrictions to be imposed on the ability to create or use resources within a compartment to an appropriate level that allows fine-tuned cost control.

[0143] According to an embodiment, a customer can be assigned service level limits defined by the cloud infrastructure environment upon account creation. These service level limits limit the total number of resources a customer can create across the entire tenancy (e.g., across multiple regions with multiple compartments). Tenancy and compartment administrators can utilize tag-based resource limits or quotas to set hard resource-specific limits. Without such compartment limits on individual resources, users authorized to launch instances may be limited in number. Users may consume all available capacity across the entire tenancy. Tag-based resource limits or quotas solve this problem and, unlike service limits, are set and customized by clients and customers, for example, via the console, SDK, or API. Tag-based resource limits or quotas are applied on top of service limits and can be inherited through nested compartment hierarchies. This allows cloud administrators to limit resource consumption and set boundaries around acceptable resource usage.

[0144] According to an embodiment, tag-based resource limits or quotas give tenant and compartment administrators better control over how resources are consumed in a cloud infrastructure environment and allow administrators to easily allocate resources to users or groups of users, for example, using the console, SDK, or API. Compartment quotas are a powerful toolset for managing client spending within a tenant.

[0145] According to an embodiment, when a client has resources (e.g., instances, VCNs, load balancers, and block volumes) across multiple compartments in a tenancy, it can be difficult to track resources used for a particular purpose or to aggregate, report on, or take bulk actions on them. Tagging allows a client to define keys and values ​​and associate them with resources. Tags can be used to help organize and list resources. There are generally two kinds of tags: free-form tags and predefined tags, although other types of tags are possible according to an exemplary embodiment.

[0146] According to one embodiment, a free-form tag can consist of a key and a value. For example, "environment:production" is an example of a free-form tag, where "environment" is the key and "production" is the value. Multiple free-form tags can apply to a single resource.

[0147] According to an embodiment, predefined tags offer more features and control than free-form tags. A tag namespace can be set for a predefined tag before a client creates a predefined tag key. A namespace can be thought of as a container for a set of tag keys. Predefined tags support policies that allow control over who can apply your defined tags. A tag namespace is an entity to which a client can apply policies.

[0148] According to an embodiment, to apply a predefined tag to a resource, a user first selects a tag namespace, then selects a tag key within the namespace, and the user can then assign a value. Administrators can control which groups of users are allowed to use each namespace. According to an exemplary embodiment, tags may be applied to resources when the resources are created. In another embodiment, tags may be applied to resources after the resources are provisioned, thereby enabling retroactive enforcement of resource quotas or limits in a system that uses tags. According to an embodiment, tags may be used to enable cost management and / or resource management. In this manner, tags may be used to track costs.

[0149] Figure 6 shows two predefined tags according to one embodiment. Two tag namespaces are established, namespace1 600 and namespace2 620 (e.g., namespace1 could be "sales" and namespace2 could be "human resources"). Tag keys 605, 610, 625, and 630 are defined in the namespaces. Within each namespace, tag keys can be unique, but , tag key names may be repeated across namespaces. For example, both namespaces may contain a key named "environment."

[0150] According to an embodiment, many cloud providers provide service limits to protect against running out of capacity. However, often clients also want to set limits to ensure they do not over-resource themselves. One such approach is to specify limits at a group level. A group can contain a set of users, resources, or anything a user wants to specify. Group level limits are set by an administrator / user for a particular tenancy / account.

[0151] According to an embodiment, as an example, a tenancy administrator or group administrator can configure limits at the group level to control their cloud costs. This gives a customer / company an assurance that when cloud resources emit usage data that is converted into dollar costs associated with resources created within a particular group, the group will not exceed the usage limits set by the tenancy or account administrator. In this sense, a group can be thought of as a cost center group because all of the cloud costs of resources created by members of that group are allocated to the customer / company as a single aggregated lump sum, aggregated to a single group account, etc.

[0152] However, according to certain embodiments, a problem exists because there are very simple mechanisms for administrators to control costs. As an example, an administrator can include or exclude certain groups from resource overages, or an administrator can exclude certain users from creating resources by denying them access. However, these are coarse-grained mechanisms, and customers generally do not have the ability to specify fine-grained mechanisms that give them the flexibility and better control to manage their cloud resources.

[0153] According to an embodiment, a fine-grained approach can provide resource restrictions based on tags, where all of the resources that can be provisioned by one or more members of a particular group are associated or otherwise provided with a cost center tag that represents that group. Cost center tags of this nature provide a mechanism for use in resource management, and cloud providers also use them for cost management. The system and method can create a mechanism for controlling costs at a group level through tags. As an example, a user can specify fine-grained rules / policies such as: Set limits<resource type> to 10 in group A where target.resource.tag = “finance” (Limit <resource type> set to 10 in Group A and target resource tag = "Finance") According to an embodiment, tags can be associated with resources and using the above approach, tags can protect customers from resource overages at a group level. In the above example, if the tag value is "finance" in group A, then user members will not be able to create more than 10 instances of <resource type>. This approach of limiting costs at a group level provides clients with a fine-grained mechanism to better manage costs and resource usage.

[0154] According to an embodiment, a system provides resource request context tag-based limits / quotas in a cloud infrastructure environment. The system provisions resources in the cloud infrastructure environment based on the request context. The present invention implements methods for limiting or imposing quotas on the use of certain resources.

[0155] According to an embodiment, a system provides tag-based resource limitations / quotas in a cloud infrastructure environment. The system executes a method for restricting or imposing quotas on resource provisioning in a cloud infrastructure environment based on resource tags.

[0156] According to an embodiment, in a highly secure environment, customers want to secure access to resources and their data. As an example, customers protect their resources by classifying them as highly sensitive, sensitive, restricted, public, etc., and grant access to users based on their clearance according to the constraints. Users with access to classified resources / data need to be extremely careful when accessing the data to ensure there is no information leakage and to avoid inadvertent changes to resources across data classifications within a shared context. The embodiments herein provide improved systems and methods for allowing users to restrict access or modify resources within data classification boundaries for a given session / context, while the user may otherwise have higher access.

[0157] According to one embodiment, the cloud architecture can use rule (role) based access control techniques to restrict / allow access to specific security perimeters by casting users into roles. However, these techniques are coarse-grained. The onus is on users to be diligent and careful about what they are accessing, modifying, or doing.

[0158] According to an embodiment, the system and method of the present disclosure protects a user from accessing resources to perform certain actions when the user does not intend. One example is accessing data of other classifications when the user has access to highly classified resources. For example, assume that the user has a script that only needs to access unclassified resources by filtering out highly classified resources. Now the user / script must know which data / resources are classified and which are not.

[0159] Another example, according to an embodiment, is when a user is only interested in shutting down non-business-critical infrastructure after the end of the business day, but wants to keep other resources running that are business-critical, where the user must know exactly which instances to turn off.

[0160] According to an embodiment, the system and method herein provide a solution to such a problem via tags attached to one or more requests for resources. Requests from scripts perform operations on behalf of the user, such as, for example, shutting down an instance, retrieving resource details, updating resources, accessing classified resources, etc. The user sends these requests with one or more tags attached to the request context. When the request performs an action on the resource, these tags from the request context can be inspected, and then access to perform the operation can be denied or allowed, even if the user initially has access to perform the operation the user wants to perform. This avoids unintended access to highly classified data or resources by the user performing unintended operations on that particular resource. This can fall under tag-based automation. It can address a wide variety of use cases, not just security-related fields.

[0161] According to one embodiment, a tag representing a resource request context can be used to create a security boundary via the tag when accessing a resource by sending a request.

[0162] According to an embodiment, when a user wants to access a resource to perform an operation, the user can generally make a call via a software development kit or will make an API call directly. The user can pass one or more tags that will be added to the request sent to the resource. While authorizing a user, the resource implementation can check the tag associated with the request, and if the tag matches the user tag, the request is allowed, otherwise the request is rejected / rejected.

[0163] FIG. 7 illustrates an architectural flow for a user launching an instance in a system that enforces allocations or limits on resources in a cloud infrastructure environment based on tags, including, for example, resource tags and / or resource request context tags, in accordance with an example embodiment.

[0164] According to one embodiment, in step 1, a user 701 makes a request to launch an instance in region 700, and the request is associated with one or more tags (e.g., free-form tags or predefined tags) that are defined within region 700. In an exemplary embodiment, the tags represent the context of the user's request for a resource.

[0165] According to one embodiment, in step 2, the load balancer 720 forwards the request to an API, such as a public proxy API 725.

[0166] According to one embodiment, in step 3, the API performs authentication in the identity data plane 735.

[0167] According to an embodiment, in step 4, the request to launch the instance may be forwarded to a Computation Control Plane (CCP) 730. The CCP may then further authenticate the request in the Identity Data Plane in step 5.

[0168] According to an embodiment, in step 6, the computation control plane can fetch from the restriction service data plane 740 all tag-based restrictions / quotas 750 associated with the tags that are part of the request from the user 701 (alternatively, the fetching operation can be performed in the resource control plane). Such tag-based quotas can be applied, for example, tenancy-wide and do not need to be compartment-specific.

[0169] According to one embodiment, in step 7, the compute control plane can check 750 whether the requested usage violates any of the tag-based restrictions / quotas for any. If the requested usage does not violate any compartment quotas, the request can be processed, for example, to database 745. If the requested usage violates any of the tag-based restrictions / quotas along the compartment tree, the request can be dropped and a message can be sent to inform the user.

[0170] According to one embodiment, tag-based limits / quotas are applied across the entire tenancy, including, for example, all regions where the tenancy is an enabled compartment within the tenancy. If a requested instance violates a tag-based limit / quota, When determining whether a new request is allowed, the CCP can ensure, for example via a service developer kit (SDK), that the new request does not violate any of the quotas. If the request would exceed the quotas, the CCP can drop the request.

[0171] According to one embodiment, the CCP's SDK may reside on all control planes of a cloud infrastructure environment.

[0172] According to one embodiment, the CCP can cooperate with the restriction service data plane to check new requests against tag-based restrictions / quotas.

[0173] According to an embodiment, when a client triggers an operation to create a cloud resource, the request goes to the resource control plane, which asks from the limits service to know if the resource can be safely spun up, taking into account the limits configured at the group level. If the limits server returns a negative / failure response to the resource control plane, the resource is not created.

[0174] Internally, when the limits service receives a request, it checks the tag associated with the resource creation and consults a store or database or memory to see the current usage of resources with that particular tag. If the tag value exceeds the limit set at the group level, it sends a failure / negative response to the resource control plane so that the resource creation fails.

[0175] Using tags for resource limits / quotas FIG. 8 illustrates a system that uses request context tags and / or resource tags to restrict usage, such as provisioning, of resources in a cloud infrastructure environment.

[0176] According to an embodiment, a client device 810 can submit a request 811 to the cloud infrastructure environment, where the request is associated with a tag 812, e.g., a tag that represents the context of the request. The client device can submit the request to the cloud infrastructure environment 800 (running on device hardware 801) via one of an interface, such as a console 802, an API 804, or an SDK 806.

[0177] According to one embodiment, the request may be forwarded to resources 840, which may include several tiers (as described above), such as a computational resource tier 850 including tagged resources 851-854, a network resource tier 860 including tagged resources 861-864, and a storage resource tier 870 including tagged resources 871-874.

[0178] According to an embodiment, if a client device enjoys high security / priority privileges (e.g., tamper protection, or intelligence), the client device may utilize a wide range of tags for the request. As an example, the tags associated with the request may be used to help the user from accidentally touching protected resources. For example, assume that to save costs, certain computing resources can be shut down after 6pm every day. Such computing resources have a low secure tag. However, the same system also has other computing resources that cannot be shut down (must run 24 / 7). Such computing resources have a high secure tag. To shut down low privilege computing resources, the user goes to each resource without having a tagged request and selects the resource to be shut down. One would have to select only those resources that need to be running, or write a script to do so, to avoid shutting down highly privileged resources that need to run 24 / 7, which is difficult to maintain as computing resources may be added and removed daily.

[0179] According to an embodiment, a user can instead provide a tagged request to shut down less privileged resources. That is, the tag associated with the request would share a less secure tag with the computing resources that may be shut down at 6pm. The tag would then be allowed to proceed to all resources in the network, but would bypass highly protected resources that do not have the tag that the request has. In this way, a tagged request to shut down computing resources would only shut down those computing resources with a matching less secure tag, and bypass the highly secure tagged computing resources.

[0180] As another example, according to an embodiment, assume that a client 810 wishes to attach a highly secure compute instance to a block volume. In such a situation, the request to attach the highly secure compute instance may be tagged with a highly secure tag. By doing so, this can then ensure that the highly secure compute instance is not attached to a block volume with a less secure tag; instead, the request can only attach the highly secure compute instance to a similarly tagged (highly secure) block volume. In other words, the request will not attach the highly secure compute to a less secure block volume (the tag check would fail).

[0181] Request Context Tag-Based Limits / Allocations 9 is a functional schematic diagram of a system 900 for providing resource request tag-based limits / quotas in a cloud infrastructure environment, according to one embodiment. Generally, a client device 810 (FIG. 8) can submit a request 911 to a cloud infrastructure environment for provisioning a new resource among a plurality of tagged resources 940. The plurality of tagged resources 940 can be, for example, any of tagged computational resources 851-854 of a computational resource layer 850, tagged network resources 861-864 of a network resource layer 860, and / or tagged storage resources 871-874 of a storage resource layer 870.

[0182] According to exemplary embodiments, resources are items that are provisioned in a cloud infrastructure environment and may be of various types, which may include, for example, a compute resource type, a storage service resource type, a VCN service type, an IP address service type, a DNS service type, a DDoS service protection type, and an email delivery service type, to name a few. The exemplary embodiments herein are not limited to these particular resource types and may include other types, and further examples of resource types are mentioned below by way of example.

[0183] [Table 1]

[0184] According to an exemplary embodiment, provisioned resources and services are taggable. In an exemplary embodiment, requests for resources and resources are associated with one or more tags. Additionally, resources may be grouped based on their tag values. Essentially, in an exemplary embodiment, a resource tag associated with each provisioned resource is a key-value pair that may be attached to or otherwise associated with the provisioned resource in the cloud infrastructure environment. The tag key-value pairs may be used for many purposes, including, for example, various accounting purposes. In one example, the resource key-value pair tags associated with the provisioned resources are used to group the resources, and the grouping provided by the resource tags enables all cost management and / or resource management of values ​​in the cloud infrastructure environment.

[0185] Resources provisioned in the cloud infrastructure environment may be grouped into containers 942, 944, 946 based on tag values ​​assigned to each resource or based on other criteria as needed or desired. By way of example, a first container 942 may store computing and storage resources provisioned in the cloud and associated with an accounting group of client user 701 (FIG. 7), a second container 944 may hold computing resources provisioned in the cloud and associated with a sales group of client user 701, and a third container 946 may hold computing resources provisioned in the cloud and associated with a human resources group of client user 701. Example embodiments herein are not limited to these groups, as other groups may be used as well, and further example groups are provided below by way of example.

[0186] [Table 2]

[0187] According to one example, resource instances are logically placed into different containers 942, 944, 946, thereby providing separate cost centers, each of which is assigned a tag value, end users can be charged for access to the various cost centers, and the cost center tags are used for cost management and billing purposes. Some customers may model multiple cost centers within their end group pricing. There may be a separate tag for each cost center, and the cloud may allocate a limited set of resources for each tag.

[0188] In an exemplary embodiment, one or more policies 920 provide a mechanism for end users to protect themselves from accessing more resources than their standard contract allows for access, where a substantial overage may result from an end user accessing more resources than is permitted under the standard contractual conditions of the standard contract. For example, a customer may send a request for resources via resource control plane 930 that activates the provisioning of multiple computing resources, such as, for example, 100 computing resources, where the contractual terms only allow for the provisioning of 90 computing resources at the standard rate, and the overage, 10 in this example, incurs additional costs to the customer end user.

[0189] As mentioned above, and according to one embodiment, a fine-grained approach can provide resource restrictions based on tags. Tags are a mechanism used primarily in resource management, and cloud providers also use them for cost management. The system and method can create a mechanism to control costs at a group level through tags. As an example, a user can specify fine-grained rules / policies such as: Set limits<resource type> to 10 in group A where target.resource.tag = “finance” (Limit <resource type> set to 10 in Group A and target resource tag = "Finance") According to an embodiment, tags can be associated with resources and / or resource requests, and using the above approach, tags can protect customers from resource overages at one or more selected levels, such as at the group level. In the above example, if the tag value is "finance" in group A, then user members would not be able to create more than 10 instances of <resource type>. This approach of limiting costs at the group level provides clients with a fine-grained mechanism to better manage costs and resource usage.

[0190] According to an example embodiment, a first policy 922 protects customers from resource overload at a group level for resources grouped in a first container 942. Similarly, a second policy 924 protects customers from resource overload at a group level for resources grouped in a second container 944, and a third policy 926 protects customers from resource overload at a group level for resources grouped in a third container 946.

[0191] According to an example, each of the resource requests 911a-911d includes fields having data representative of a type of resource instance being requested (resource type), data representative of a group of resource instances being requested (resource group), and data representative of the context of the resource request (context tag). In this regard, each of the resource requests 911a-911d includes a resource type field 912a-912d having data representative of a type of resource instance being requested (resource type). In addition, each of the resource requests 911a-911d includes a resource group field 913a-913d representing a group of resource instances being requested (resource group). Additionally, each of the resource requests 911a-911d includes a request context field 914a-914d including request context data (context tag) representative of the context of the resource request.

[0192] Pursuant to one example, the computation control plane can fetch from the restriction service data plane 740 (FIG. 7) all tag-based restrictions / quotas 950 associated with the tags that are part of the request from the user 701. (Alternatively, the fetching operation can be performed in the resource control plane 930.) Such tag-based quotas can be applied, for example, tenancy-wide and do not need to be compartment-specific.

[0193] According to an embodiment, the compute control plane can check whether the requested usage violates any of the tag-based restrictions / quotas for any quota or limit rules in memory 950. If the requested usage does not violate any compartment quotas, the request can be processed, for example to a database. If the requested usage violates any of the tag-based restrictions / quotas along the compartment tree, the request can be dropped and a message can be sent to inform the user.

[0194] According to an example embodiment, the tag-based limits / quotas are applied to compartments within a tenancy. According to an example embodiment described below, the tag-based limits / quotas are applied across the entire tenancy, including, for example, all regions across the inherent compartments in which the tenancy is enabled. When determining whether a requested instance would violate a tag-based limit / quota, the compute control plane can ensure that the new request does not violate any of the quotas, for example, via a service developer kit (SDK). If the request would exceed the quota, the compute control plane can drop the request.

[0195] According to an embodiment, a compute control plane SDK may be present in all control planes of a cloud infrastructure environment. According to an embodiment, the compute control plane may cooperate with a limit service data plane to check new requests against tag-based limits / quotas.

[0196] According to one embodiment, tags can be associated with resources and / or requests for resources; in this manner, tags can protect resources from inadvertent access and can also protect customer users from inadvertent resource overages.

[0197] In this regard, the system 900 is provided with request context tags 914a-914d to control handling of resources 940 in an associated cloud infrastructure environment. The system may include one or more computers with one or more microprocessors that define a tenancy in the associated cloud infrastructure environment. In an exemplary embodiment, a memory device 940 operatively coupled to the computer stores computer executable logic to provide control of handling of resources in the tenancy. The memory device may also store access control data 950 representing a number of required credential gate levels for enabling handling of resources in the tenancy. A request 911a-911d to handle a first resource in the tenancy may be received, the request 911a-911d including request context tag data 914a-914d representing request context information of the request. A first privilege level classification associated with the requested first resource is determined, and request context information of the request is compared to a first required credential gate level of a plurality of required credential gate levels to enable handling of the resource in the tenancy having the first privilege level classification. According to an example embodiment, the request to handle the first resource is selectively permitted based on the request context information matching the first required credential gate level.

[0198] The request to handle the first resource may include a request to provision the first resource in a tenancy. According to an example embodiment, the first resource is selectively provisioned in the tenancy based on request context information that matches a first required credential gate level.

[0199] According to an exemplary embodiment, a request to provision a first resource in a tenancy may include a request from a user of the system to provision a bare metal computing instance in the tenancy to give the user control over one or more physical host machines in a computing resource tier in an associated cloud infrastructure environment. In this example, the request context tag data of the request includes user context tag data 913a-913d representing a user identity of the user. The access control data stored in the memory device includes user access control data representing a plurality of user required credential gate levels for enabling handling of resources in the tenancy, and the user identity of the user is compared to a first user required credential gate level of the plurality of user required credential gate levels for enabling handling of resources in the tenancy having a first privilege classification. In this example, a bare metal computing instance is selectively provisioned to the user in the tenancy based on the user identity of the user that matches the first user required credential gate level.

[0200] According to an example embodiment, the request to provision a first resource in a tenancy may include a request to provision a plurality of resources in the tenancy having a first privilege level classification, where the plurality of resources in the tenancy are selectively provisioned based on request context information that matches a first required credential gate level.

[0201] According to an example embodiment, the request context tag data of the request may include user context tag data 913a-913d representing a user identity of the user, and the request to handle the first resource may include a request to handle all resources provisioned in the tenancy and associated with a second privilege level classification. The system 900 operates to compare the user identity of the request to a second required request credential gate level of the plurality of required credential gate levels to enable handling of resources in the tenancy having the second privilege level classification. The system 900 selectively grants the request to handle all of the provisioned resources in the tenancy associated with the second privilege level classification based on the user identity matching the second required credential gate level.

[0202] According to an example embodiment, the tenancy can include a plurality of compartments 942, 944, 946 that store resources associated with a second privilege level classification, with each compartment of the plurality of compartments providing isolation of a set of resources associated with the second privilege level classification in each compartment relative to one or more other sets of resources associated with the second privilege level classification in the other compartments. The system 900 selectively authorizes requests to address all of the resources provisioned in the tenancy associated with the second privilege level classification across the plurality of compartments based on a user identity that matches a second required credential gate level.

[0203] The request context data for a request received by a system to handle a first resource in a tenancy includes a resource type that represents the type of resource instance being requested. The requested resource instance may include one or more of type data 912a-912d and / or resource group data 913a-913d representing a group of resource instances being requested.

[0204] According to an embodiment, when a client triggers an operation to create a cloud resource, the request goes to the resource control plane, which asks from the limits service to know if the resource can be safely spun up, taking into account the limits configured at the group level. If the limits server returns a negative / failure response to the resource control plane, the resource is not created.

[0205] Internally, when the limits service receives a request, it checks the tag associated with the resource creation and consults a store or database or memory to see the current usage of resources with that particular tag. If the tag value exceeds the limit set at the group level, it sends a failure / negative response to the resource control plane so that the resource creation fails.

[0206] For purposes of illustrating the functionality of the example embodiment only and not for purposes of limiting it, the first policy 922 may protect customers from resource overages at a financial group level for resources grouped in the first container 942 according to fine-grained rules / policies such as: Set limits <compute>to 10 in Container #1 (642) where target.resource.tag = "Finance" (Set limit <calculation> to 10 on container #1 (642) and target resource tag = "finance") In the particular example above, a user cannot create more than 10 instances of a computing resource in financial container 942. Thus, a request 911d to provision a resource in container 942 is processed by policy 922 to determine whether the request can be fulfilled or otherwise performed without incurring any excess.

[0207] Similarly, the second policy 924 can protect customers from resource overages at the sales group level for resources grouped in the second container 644 according to fine-grained rules / policies such as: Set limits<db storage> to 100 in Container #2 (644) where target.resource.tag = "Operations" (limit<dbストレージ> is set to 100 in container #2 (644) and the target resource tag = "Sales") In the above example, a user cannot create more than 100 instances of a storage resource in sales container 644. Thus, a request 911c to provision a resource in container 944 is processed by policy 924 to determine whether the request can be fulfilled or otherwise performed without incurring any excess.

[0208] Similarly, a third policy 926 can protect customers from resource overages at the personnel group level for resources grouped in a third container 946 according to fine-grained rules / policies such as: Set limits <compute>to 10 and<db storage> to 100 in Container #3 (646) where target.resource.tag = "Human Resources" (In container #3 (646), set the limit <calculation> to 10, and<dbストレージ> 100, and the target resource tag is "HR") In the above example, a user cannot create more than 10 instances of a computing resource or more than 100 instances of a storage resource in the personnel container 946. In this manner, requests 911a, 911b to provision resources in the container 946 are processed by the policy 926 to determine whether the request can be fulfilled or otherwise performed without incurring any excess.

[0209] 10 is a flow diagram illustrating a method 1000 for restricting or imposing quotas on handling resources, such as, for example, provisioning resources in a cloud infrastructure environment based on a request context, according to an example embodiment. Referring now to that figure, a request for provisioning a resource in a cloud infrastructure environment is received in step 1010. The request may be, for example, the first request 911a described above. The request may include, for example, request context tag data 914a representing request context information of the request.

[0210] In step 1020, the request 911a is examined to determine the context of the request for the requested resource. The determined resource type may be, for example, a request to provision a computational resource type or a request to provision a storage resource type.

[0211] In step 1030, a privilege level classification associated with the requested resource is determined. According to an exemplary embodiment, the resource may be stored in association with an indicia reflecting a privilege level required to access the resource. The privilege level may be stored within or as one or more privilege level tags, such as, for example, 851-854, 861-864, 871-874 in FIG. 8 and 140a, 16a, 170a in FIG. 1. The determined resource group may be, for example, a request to provision resources grouped into a personnel group.

[0212] In step 1040, the resource request 911a may be assigned to a particular container according to the determined group of requests. In this example, the resource request 911a may be assigned to the third container 946, for example, according to this example. A policy corresponding to the assigned compartment may be selectively applied to the resource request. In the illustrated example, the third policy 926 may be selectively applied to the resource request 911a. If in step 1040 it is determined that the provisioning of additional resources according to the content of the resource request 911a will not exceed the limits and / or allocations specified in the policy 926 assigned to the compartment 946, the instance requested in the request 911a may be created in the compartment 946.

[0213] In step 1050, the request context information 914a of the request 911a is compared to a first required credential gate level of a plurality of required credential gate levels to enable handling of resources in the tenancy having a first privilege level classification.

[0214] If, in step 1060, it is determined that the request context information matches the first required credential gate level, then, in step 1070, the request to handle the first resource is allowed and the resource may be handled, e.g., an instance of the requested resource may be created, the requested resource may be provisioned, the requested resource may be terminated, or otherwise de-provisioned.

[0215] In step 1060, the request context information is If it is determined that the rule level does not match, then in step 1080 the request handling the first resource is dropped.

[0216] Resource tag-based limits / quotas FIG. 11 is a functional schematic diagram of a system 1100 for providing tag-based resource limits / quotas in a cloud infrastructure environment, according to one embodiment.

[0217] Generally, a client device 810 (FIG. 8) can submit a request 1111 to a cloud infrastructure environment to provision a new resource among the plurality of tagged resources 1040. The plurality of tagged resources 1140 can be, for example, any of the tagged computational resources 851-854 of a computational resource tier 850, the tagged network resources 861-864 of a network resource tier 860, and / or the tagged storage resources 871-874 of a storage resource tier 870.

[0218] In accordance with an exemplary embodiment, provisioned resources and services are taggable. In an exemplary embodiment, resources are associated with one or more tags. Additionally, resources may be grouped based on their tag values. Essentially, in an exemplary embodiment, resource tags associated with each provisioned resource are key-value pairs that may be attached to or otherwise associated with the provisioned resources in the cloud infrastructure environment. Tag key-value pairs may be used for many purposes, including, for example, various accounting purposes. In one example, resource key-value pair tags associated with provisioned resources are used to group resources, and the grouping provided by resource tags enables all cost management and / or resource management of values ​​in the cloud infrastructure environment.

[0219] Resources provisioned in the cloud infrastructure environment may be grouped into containers 1142, 1144, 1146 based on tag values ​​assigned to each resource.

[0220] According to one example, resource instances are logically placed into different containers 1142, 1144, 1146, thereby providing separate cost centers, each cost center is assigned a tag value, end users can be charged for access to the various cost centers, and the cost center tags are used for cost management and billing. Some customers may model multiple cost centers within their end group pricing. There may be a separate tag for each cost center, and the cloud may allocate a limited set of resources for each tag.

[0221] In an exemplary embodiment, one or more policies 1120 provide a mechanism for end users to protect themselves from accessing more resources than their standard contract allows for access, where a substantial overage may result from an end user accessing more resources than is permitted under the standard contractual conditions of the standard contract. For example, a customer may send a request for resources via the resource control plane 1130 that activates the provisioning of multiple computing resources, such as, for example, 100 computing resources, where the contractual terms only allow for the provisioning of 90 computing resources at the standard rate, and the overage, 10 in this example, incurs additional costs to the customer end user.

[0222] As discussed above, and in accordance with an embodiment, a fine-grained approach can provide resource restrictions based on tags, particularly tags associated with resources. Tags associated with resources provide a mechanism that can be used in resource management 110 (FIG. 1), and cloud providers may also use them for cost management. Through tags, the system and method can create a mechanism for controlling costs at levels, including the group level. As an example, a user can specify fine-grained rules / policies such as: Set limits<resource type> to 10 in group A where target.resource.tag = "finance" (Limit <resource type> set to 10 in Group A and target resource tag = "Finance") According to an embodiment, tags can be associated with resources and using the above approach, tags can protect customers from resource overages at one or more selected levels, such as at the group level. In the above example, if the tag value is "finance" in group A, then no user member of would be able to create more than 10 instances of <resource type>. This approach of limiting costs at the group level provides clients with a fine-grained mechanism to better manage costs and resource usage.

[0223] According to an example embodiment, the first policy 1120a protects customers from over-use of resources associated with a first tag and that may be grouped into any of the containers 1142, 1144, 1146. Similarly, the second policy 1120b protects customers from over-use of resources associated with a second tag and that may be grouped into any of the containers 1142, 1144, 1146. Similarly, the third and fourth policies 1120c, 1120d protect customers from over-use of resources associated with the third and fourth tags and that may also be grouped into any of the containers 1142, 1144, 1146.

[0224] According to an example, each of the resource requests 1111a-1111d includes fields having data representative of a type of resource instance being requested (resource type), data representative of a group of resource instances being requested (resource group), data representative of characteristics of the resource request (resource characteristics), and data representative of the context of the resource request (context tag). In this regard, each of the resource requests 1111a-1111d includes a resource type field 1112a-1112d having data representative of a type of resource instance being requested (resource type). In addition, each of the resource requests 1111a-1111d includes a resource group field 1113a-1113d representing a group of resource instances being requested (resource group). Additionally, each of the resource requests 1111a-1111d includes a request context field 1114a-1114d including request context data (context tag) representative of the context of the resource request. Additionally, each of the resource requests 1111a-1111d includes a request characteristic field 1115a-1115d that contains request characteristic data (characteristic tag) that represents a characteristic of the resource request. Although the request characteristic field 1115a-1115d is shown and described separately for ease of explanation, it should be understood that it may be derived from resource type information, from resource group information, or from any other information forming the resource request.

[0225] According to one example, the computation control plane can fetch all tag-based restrictions / quotas 1150 associated with the tags that are part of the request from the user 701 from the restrictions service data plane 740 (FIG. 7) (alternatively, the fetching operation can be performed in the resource control plane 1130). Such tag-based quotas can be applied, for example, tenancy-wide and do not need to be compartment-specific.

[0226] According to an embodiment, the compute control plane can check whether the requested usage violates any of the tag-based limits / quotas for any allocation or limit rules in memory 1150. If the requested usage does not violate any resource tag-based limits / quotas, the request can be processed, for example, against a database. If the requested usage violates any of the resource tag-based limits / quotas along the compartment tree, the request can be dropped and a message can be sent to inform the user.

[0227] According to an example embodiment, the resource tag-based limits / quotas are applied to compartments within a tenancy. According to an example embodiment described below, the resource tag-based limits / quotas are applied across the entire tenancy, including, for example, all regions across compartments in which the tenancy is enabled. When determining whether a requested instance would violate a resource tag-based limit / quota, the compute control plane can ensure that the new request does not violate any of the quotas, for example, via a service developer kit (SDK). If the request exceeds the quota, the compute control plane can drop the request.

[0228] According to an embodiment, a compute control plane SDK may be present in all control planes of a cloud infrastructure environment. According to an embodiment, the compute control plane may interface with a limiting service data plane to check new requests against resource tag-based limits / quotas.

[0229] According to an embodiment, when a client triggers an operation to create a cloud resource, the request goes to the resource control plane, which asks from the limits service to know if the resource can be safely spun up, taking into account the limits configured at a selected level, e.g., at the group level. If the limits server returns a negative / failure response to the resource control plane, the resource is not created and the request is dropped.

[0230] Internally, when the limiting service receives a request, it checks the tag associated with the resource creation and consults a store or database or memory to see the current usage of resources with that particular tag. A resource may be associated with multiple tags, and a resource may be associated with multiple different tags. If the tag value exceeds the limit configured at a selected level, e.g., at the group level, it sends a failure / negative response to the resource control plane so that the resource creation fails.

[0231] According to an embodiment, the memory device 1140 stores tag-based allocation data 1150 representing a plurality of tag-based allocations for resource provisioning in the tenancy 305 (FIG. 3). Requests 1111a-1111d to provision resources in the tenancy are received. The requests 1111a-1111d may include request characteristic data 1115a-1115d representing request characteristics of the requests. According to an embodiment, usage of resources in the tenancy associated with resource tags 150a, 160a, 170a (FIG. 1) corresponding to the request characteristics of the requests is determined and compared to the plurality of tag-based allocations and / or limits 1150. The request to provision the resource is dropped based on the determined usage exceeding one of the plurality of tag-based allocations.

[0232] According to an example embodiment, tenancy 305 includes a number of compartments 1142, 1144, 1146 for storing resources, each of which provides isolation of a set of resources within each compartment relative to one or more other sets of resources within other compartments. Usage of resources in the tenancy associated with a tag-based quota is determined collectively across the compartments, and the usage determined collectively across the compartments is compared to the tenancy's tag-based quotas. Requests 1111a-1111d to provision resources are dropped based on usage determined collectively across the compartments exceeding one of the tag-based quotas.

[0233] According to an example embodiment, tag-based allocation data 1150 stored in memory device 1140 represents a plurality of tag-based allocations of resource provisioning in the tenancy for a corresponding plurality of resource types of the tenancy. Additionally, request characteristic data 1115a-1115d of requests 1111a-1111d to provision resources in the tenancies includes resource type data representing first resource types 1112a-1112d of the requested resources. In an example embodiment, resource usage in the tenancy associated with a resource tag corresponding to the first resource type 1112a is determined and compared to the first tag-based allocation 1120a of resource provisioning in the tenancy for the first resource type. A request 1111a to provision a resource of a first resource type 1112a is dropped based on a determined resource usage in the tenancy associated with a resource tag corresponding to the first resource type exceeding a first tag-based allocation, stored as, for example, a policy 1120a, of resource provisioning in the tenancy for the first resource type.

[0234] According to an example embodiment, tag-based allocation data 1150 stored in memory device 1140 represents a plurality of tag-based allocations of resource provisioning in the tenancy assigned to a corresponding plurality of user groups of the tenancy. Request characteristic data 1115a-1115d of requests 1111a-1111d to provision resources in the tenancy includes user group data 1113a-1113d representing user group categories assigned to users of the system requesting the resources. Resource usage in the tenancy associated with resource tags corresponding to the user group categories is determined and compared to a first tag-based allocation of resource provisioning in the tenancy assigned to the user group categories 1120b. The request to provision resources is dropped based on the determined resource usage in the tenancy associated with resource tags corresponding to the user group categories exceeding the first tag-based allocation of resource provisioning in the tenancy assigned to the user group categories.

[0235] According to an example embodiment, the tag-based allocation data stored in the memory device represents a tag-based allocation of resource provisioning in the tenancy of a plurality of resource types of the tenancy assigned to a plurality of user groups of the tenancy. The request characteristic data of the request to provision a resource in the tenancy may include, for example, i) resource type data representing a first resource type of the requested resource, and / or ii) user group data representing a user group category assigned to a user of the system requesting the resource. In this example, usage of resources in the tenancy associated with a resource tag corresponding to the first resource type to be provisioned to the first user group category is determined and compared to a first tag-based allocation of resource provisioning in the tenancy of the first resource type assigned to the first user group category. Additionally, the request to provision a resource includes determining whether the determined usage of resources in the tenancy associated with a resource tag corresponding to the first resource type to be provisioned to the first user group category is a tag-based allocation of resource provisioning in the tenancy of the first resource type assigned to the first user group category. The resource provisioning is dropped based on exceeding a first tag-based allocation in the

[0236] According to an example embodiment, tag-based allocation data 1150 stored in memory device 1140 represents tag-based allocations of resource provisioning in a tenancy for multiple resource types of the tenancy assigned to multiple user groups of the tenancy. A first request to track resource usage of the tenancy may be received from a user 701, the first request including request characteristic data 1115a-1115d representing a first user group category 1113a-1113d and a first resource type 1112a-1112d.

[0237] A first usage of resources in the tenancy associated with a resource tag corresponding to a first resource type provisioned by a first user group category is determined, and resource usage tracking data is generated based on the determined first usage of resources in the tenancy of the first resource type provisioned by the first user group.

[0238] According to an example embodiment, a request to provision a resource is dropped based on the determined usage exceeding one of a plurality of tag-based allocations. However, an override request to provision a resource in the tenancy may be received from a user 701. The resource is selectively provisioned based on the system receiving the override request according to an example embodiment. Additionally, resource overutilization data is generated based on the resource being selectively provisioned in response to the system receiving the override request.

[0239] FIG. 12 is a flow diagram illustrating a method 1200 for restricting or imposing quotas on resource provisioning in a cloud infrastructure environment based on resource tags, according to an example embodiment.

[0240] According to method 1200, at step 1210, a tenancy is provided and tag-based limit / allocation data is stored in memory. In its preferred form, the tenancy is provided by a computer in an associated cloud infrastructure environment, the computer including one or more processors and a memory device operatively coupled to the computer. The memory device stores tag-based control logic executable by the computer to provide tag-based control of resource usage in the associated cloud infrastructure environment. In an exemplary embodiment, the tag-based allocation data stored in the memory device represents a plurality of tag-based allocations of resource provisioning in the tenancy.

[0241] At step 1220, a request to provision a resource in a tenancy is received. The request includes request characteristics data that describes request characteristics of the request.

[0242] In step 1230, the resource type of the requested resource is determined. In step 1240, resource usage in the tenancy associated with a resource tag corresponding to the request characteristic of the request is determined by one or more processors executing tag-based control logic.

[0243] The request is assigned, in step 1250, to one or more of the compartments based on the group of resources requested.

[0244] One or more processors executing the tag-based control logic determine usage of the resource associated with the tag, and the determined usage is compared to a plurality of tag-based allocations in step 1260 .

[0245] The resource request is dropped in step 1290 by one or more processors executing tag-based control logic to provision the resource based on a determination in step 1270 that the usage exceeds one of the multiple tag-based allocations.

[0246] An instance of the requested resource is created in step 1280 by one or more processors executing the tag-based control logic to request provisioning of the resource based on a determination in step 1270 that the usage does not exceed one of the multiple tag-based allocations.

[0247] According to an example embodiment, a tenancy is provided by providing a plurality of compartments for storing resources, each compartment of the plurality of compartments providing isolation of a set of resources in each compartment relative to one or more other sets of resources in other compartments. Additionally, determining the usage includes determining usage of resources in the tenancy associated with a resource tag corresponding to the request characteristic of the request, collectively across the plurality of compartments, and comparing includes comparing the determined usage to a plurality of tag-based quotas of the tenancy, collectively across the plurality of compartments. Additionally, dropping the request includes dropping the request to provision the resource based on the collectively determined usage across the plurality of compartments exceeding one of the plurality of tag-based quotas.

[0248] According to an example embodiment, storing the tag-based allocation data includes storing in a memory device tag-based allocation data representative of a plurality of tag-based allocations of resource provisioning in the tenancy for a corresponding plurality of resource types of the tenancy. Additionally, receiving the request includes receiving a request including resource type data representative of a first resource type of the requested resource, and determining includes determining that usage of resources in the tenancy associated with a resource tag corresponding to the first resource type is determined. Additionally, comparing includes comparing the determined usage to a first tag-based allocation of resource provisioning in the tenancy of the first resource type, and dropping the request includes dropping the request based on the determined usage of resources in the tenancy associated with a resource tag corresponding to the first resource type exceeding the first tag-based allocation of resource provisioning in the tenancy of the first resource type.

[0249] According to an example embodiment, storing the tag-based allocation data includes storing in a memory device tag-based allocation data representative of a plurality of tag-based allocations of resource provisioning in the tenancy assigned to a corresponding plurality of user groups of the tenancy, and receiving the request includes receiving a request including resource type data representative of a user group category assigned to a user of the system requesting the resource. Additionally, determining includes determining usage of resources in the tenancy associated with a resource tag corresponding to the user group category, and comparing includes comparing the determined usage to a first tag-based allocation of resource provisioning in the tenancy assigned to the user group category. Additionally, dropping the request includes receiving a request including resource type data representative of a user group category assigned to a corresponding user group category. and dropping the request based on a determined resource usage in the tenancy associated with the tag exceeding a first tag-based allocation of resource provisioning in the tenancy assigned to the user group category.

[0250] According to an example embodiment, storing the tag-based allocation data includes storing in a memory device tag-based allocation data representative of a tag-based allocation of resource provisioning in the tenancy for a plurality of resource types of the tenancy assigned to a plurality of user groups of the tenancy, and receiving the request includes receiving a request including resource type data including i) resource type data representative of a first resource type of the requested resource and ii) user group data representative of a user group category assigned to a user of the system requesting the resource. Additionally, determining includes determining usage of resources in the tenancy associated with a resource tag corresponding to the first resource type provisioned to the first user group category, and comparing includes comparing the determined usage to the first tag-based allocation of resource provisioning in the tenancy for the first resource type assigned to the first user group category. Additionally, dropping the request includes dropping the request based on determined resource usage in the tenancy associated with a resource tag corresponding to a first resource type provisioned to the first user group category exceeding a first tag-based allocation of resource provisioning in the tenancy of the first resource type assigned to the first user group category.

[0251] According to an example embodiment, the method stores in a memory device tag-based allocation data representing tag-based allocation of resource provisioning in the tenancy for a plurality of resource types of the tenancy allocated to a plurality of user groups of the tenancy. The method further includes receiving a first request to track resource usage of the tenancy, the first request including request characteristic data representing a first user group category and the first resource type. In addition, determining a first usage of resources in the tenancy associated with a resource tag corresponding to the first resource type provisioned by the first user group category, and generating resource usage tracking data based on the determined first usage of resources in the tenancy of the first resource type provisioned by the first user group.

[0252] The method further includes receiving an override request to provision resources of the tenancy, selectively provisioning the resources based on the system receiving the override request, and generating resource overutilization data based on the resources being selectively provisioned in response to the system receiving the override request.

[0253] According to various embodiments, the teachings herein may be conveniently implemented using one or more conventional general purpose or special purpose digital computers, computing devices, machines, or microprocessors, including one or more processors, memories, and / or computer-readable storage media programmed according to the teachings of the present disclosure. Appropriate software coding can be readily prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software arts.

[0254] In some embodiments, the teachings of the present disclosure may include a computer program product using a computer-readable medium that can communicate (e.g., store or carry) instructions for one or more programmable processors or computers to perform any of the processes of the present teachings. A non-transitory computer-readable storage medium having stored thereon instructions that can be used to program a computer to execute any of the processes described above. Examples of such storage media may include, but are not limited to, hard disk drives, hard disks, hard drives, fixed disks, or other electromechanical data storage devices, floppy disks, optical disks, DVDs, CD-ROMs, microdrives, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems, or other types of storage media or devices suitable for non-transitory storage of instructions and / or data. Another example of a computer-readable medium is a transient medium that conveys such instructions between computer systems or between components of a given computer system. Examples of transient media may include, but are not limited to, carrier waves and transmission signals.

[0255] Thus, from one perspective, a system and method for supporting tag-based resource limitations or quotas in a cloud infrastructure environment has been described. Cloud administrators generally do not have the ability to limit resource usage in existing clouds. Giving a user permission to create resources allows the user to create any number of resources up to a predefined account limit. Tags are associated with the resources to allow administrators to limit the user's resource usage to an appropriate level by enabling fine-tuned cost control. Usage of resources in a tenancy associated with a resource tag corresponding to a request characteristic of a request to provision the resource is determined and compared to a plurality of tag-based quotas, and the request to provision the resource is dropped based on the determined usage exceeding one of the plurality of tag-based quotas.

[0256] The foregoing description has been provided for purposes of illustration and explanation. It is not intended to be exhaustive or to limit the scope of protection to the precise form disclosed. Many modifications and variations will be apparent to those skilled in the art. For example, although some of the examples provided in this disclosure illustrate use with enterprise software application components such as Oracle Fusion Applications, cloud environments such as Oracle Cloud Infrastructure, and cloud services such as Oracle Fusion Analytics, according to various embodiments, the systems and methods described in this disclosure can be used with other types of enterprise software applications, cloud environments, cloud services, cloud computing, or other computing environments.

[0257] The embodiments have been chosen and described in order to best explain the principles of the present teachings and their practical application, so that those skilled in the art will recognize various embodiments and various modifications suited to the particular use contemplated, the scope of which is intended to be defined by the claims and their equivalents.< / compute> < / compute>

Claims

1. 1. A system for tag-based control of resource usage in an associated cloud infrastructure environment, comprising: a computer including one or more microprocessors; a tenancy defined in the associated cloud infrastructure environment; and a memory device operatively coupled to the computer, the memory device storing logic executable by the computer for providing the tag-based control of resource usage in the tenancy, the memory storing tag-based allocation data representing a plurality of tag-based allocations of resource provisioning in the tenancy; A request to provision a resource in the tenancy is received, the request including request characteristics data representing request characteristics of the request; resource usage in the tenancy associated with a resource tag corresponding to the request characteristic of the request is determined and compared to the plurality of tag-based allocations; The request to provision the resource is dropped based on the determined usage exceeding one of the plurality of tag-based allocations.

2. the tenancy comprises a plurality of compartments for storing the resources, each compartment of the plurality of compartments providing isolation of a set of resources within the compartment relative to one or more other sets of resources within other compartments; the usage of the resources in the tenancy associated with the resource tags corresponding to the request characteristics of the request is determined collectively across the compartments, and the usage determined collectively across the compartments is compared to the tag-based quotas of the tenancy; 2. The system of claim 1, wherein the request to provision the resource is dropped based on the usage determined collectively across the compartments exceeding one of the tag-based quotas.

3. the tag-based allocation data stored in the memory device represents a plurality of tag-based allocations of resource provisioning in the tenancy for a corresponding plurality of resource types of the tenancy; the request characteristics data of the request to provision the resource in the tenancy includes resource type data representing a first resource type of the requested resource; resource usage in the tenancy associated with a resource tag corresponding to the first resource type is determined and compared to a first tag-based allocation of resource provisioning in the tenancy of the first resource type; 3. The system of claim 1 or 2, wherein the request to provision the resource of the first resource type is dropped based on the determined resource usage in the tenancy associated with the resource tag corresponding to the first resource type exceeding the first tag-based allocation of resource provisioning in the tenancy of the first resource type.

4. the tag-based allocation data stored in the memory device represents a plurality of tag-based allocations of resource provisioning in the tenancy assigned to a corresponding plurality of user groups of the tenancy; The request characteristics of the request to provision the resource in the tenancy the data includes user group data representing a user group category assigned to a user of the system requesting the resource; resource usage in the tenancy associated with a resource tag corresponding to the user group category is determined and compared to a first tag-based allocation of resource provisioning in the tenancy assigned the user group category; 4. The system of claim 1, 2, or 3, wherein the request to provision the resource is dropped based on the determined resource usage in the tenancy associated with the resource tag corresponding to the user group category exceeding the first tag-based allocation of resource provisioning in the tenancy assigned to the user group category.

5. the tag-based allocation data stored in the memory device represents tag-based allocations of resource provisioning in the tenancy for a plurality of resource types of the tenancy assigned to a plurality of user groups of the tenancy; the request characteristic data of the request to provision the resource in the tenancy includes: i) resource type data representing a first resource type of the requested resource; and ii) user group data representing a user group category assigned to a user of the system requesting the resource; resource usage in the tenancy associated with a resource tag corresponding to the first resource type provisioned to the first user group category is determined and compared to a first tag-based allocation of resource provisioning in the tenancy of the first resource type assigned to the first user group category; 5. The system of claim 1, wherein the request to provision the resource is dropped based on the determined resource usage in the tenancy associated with the resource tag corresponding to the first resource type to be provisioned to the first user group category exceeding the first tag-based allocation of the resource provisioning in the tenancy of the first resource type assigned to the first user group category.

6. the tag-based allocation data stored in the memory device represents tag-based allocations of resource provisioning in the tenancy for a plurality of resource types of the tenancy assigned to a plurality of user groups of the tenancy; a first request to track resource usage of the tenancy is received, the first request including request characteristic data representative of a first user group category and a first resource type; A first use of a resource in the tenancy associated with a resource tag corresponding to the first resource type provisioned by the first user group category is determined; 6. The system of claim 1, wherein resource usage tracking data is generated based on a first usage of the determined resources in the tenancy of the first resource type provisioned by the first user group.

7. the request to provision the resource is dropped based on the determined usage exceeding one of the tag-based allocations; an override request to provision the resource in the tenancy is received; the resources are selectively provisioned based on the system receiving the override request; resource overutilization data is generated based on the resource being selectively provisioned in response to the system receiving the override request. The system according to any one of claims 1 to 6.

8. 1. A method for tag-based control of resource usage in an associated cloud infrastructure environment, comprising: The method further includes providing a tenancy in the associated cloud infrastructure environment, the computer comprising one or more processors and a memory device operatively coupled to the computer, the memory device storing tag-based control logic, the method further comprising: storing tag-based allocation data in the memory device, the tag-based allocation data representing a plurality of tag-based allocations of resource provisioning in the tenancy, the method further comprising: receiving a request to provision a resource in the tenancy, the request including request characteristic data representing request characteristics of the request, the method further comprising: determining resource usage in the tenancy associated with a resource tag corresponding to the request characteristic of the request by the one or more processors executing the tag-based control logic; comparing the determined usage to the plurality of tag-based allocations by the one or more processors executing the tag-based control logic; and dropping the request to provision the resource based on the determined usage exceeding one of the plurality of tag-based allocations by the one or more processors executing the tag-based control logic.

9. providing the tenancy includes providing a plurality of compartments for storing the resources, each compartment of the plurality of compartments providing isolation of a set of resources in the respective compartment relative to one or more other sets of resources in other compartments; determining the usage includes determining usage of the resources in the tenancy associated with the resource tags corresponding to the request characteristics of the request, collectively across the compartments; the comparing includes comparing the usage determined collectively across the compartments to the tag-based allocations of the tenancy; 10. The method of claim 8, wherein the dropping comprises dropping the request to provision the resource based on the usage determined collectively across the multiple compartments exceeding one of the multiple tag-based allocations.

10. storing the tag-based allocation data includes storing in the memory device tag-based allocation data representing a plurality of tag-based allocations of resource provisioning in the tenancy for a corresponding plurality of resource types of the tenancy; Receiving the request includes receiving a request including resource type data representing a first resource type of the requested resource; The determining includes determining that usage of a resource in the tenancy associated with a resource tag corresponding to the first resource type is determined; The comparing includes comparing the determined usage to a first tag-based allocation of resource provisioning in the tenancy for the first resource type; Dropping the request determines whether the determined resource usage in the tenancy associated with the resource tag corresponding to the first resource type is consistent with the first request for the resource provisioning in the tenancy of the first resource type. The method of claim 8 or 9, comprising dropping the request based on exceeding a tag-based quota.

11. storing the tag-based allocation data includes storing in the memory device tag-based allocation data representing a plurality of tag-based allocations of resource provisioning in the tenancy assigned to a corresponding plurality of user groups of the tenancy; receiving the request includes receiving a request including resource type data representing a user group category assigned to a user of the system requesting the resource; determining a resource usage in the tenancy associated with a resource tag corresponding to the user group category; The comparing includes comparing the determined usage to a first tag-based allocation of resource provisioning in the tenancy assigned to the user group category; 11. The method of claim 8, 9, or 10, wherein dropping the request comprises dropping the request based on the determined resource usage in the tenancy associated with the resource tag corresponding to the user group category exceeding the first tag-based allocation of resource provisioning in the tenancy assigned to the user group category.

12. storing the tag-based allocation data includes storing in the memory device tag-based allocation data representing tag-based allocations of resource provisioning in the tenancy for a plurality of resource types of the tenancy assigned to a plurality of user groups of the tenancy; receiving the request includes receiving a request including resource type data including: i) resource type data representing a first resource type of the requested resource; and ii) user group data representing a user group category assigned to a user of the system requesting the resource; determining a resource usage in the tenancy associated with a resource tag corresponding to the first resource type provisioned to the first user group category; The comparing includes comparing the determined usage to a first tag-based allocation of resource provisioning in the tenancy of the first resource type assigned to the first user group category; 12. The method of claim 8, wherein dropping the request comprises dropping the request based on the determined resource usage in the tenancy associated with the resource tag corresponding to the first resource type to be provisioned to the first user group category exceeding the first tag-based allocation of resource provisioning in the tenancy of the first resource type assigned to the first user group category.

13. The method further comprises: storing in the memory device tag-based assignment data representing tag-based assignments of resource provisioning in the tenancy for a plurality of resource types of the tenancy assigned to a plurality of user groups of the tenancy; receiving a first request to track resource usage of the tenancy, the first request including request characteristic data representative of a first user group category and a first resource type, the method further comprising: The first resource provisioned by the first user group category. determining a first use of a resource in the tenancy associated with a resource tag corresponding to a type; and generating resource usage tracking data based on a first usage of the determined resources in the tenancy of the first resource type provisioned by the first user group.

14. The method further comprises: receiving an override request to provision the resource in the tenancy; selectively provisioning the resource based on the system receiving the override request; and and generating resource over-utilization data based on the resource being selectively provisioned in response to the system receiving the override request.

15. 1. A computer-readable medium having instructions for tag-based control of resource usage in an associated cloud infrastructure environment, the instructions, when read and executed by a computer, causing the computer to perform steps including: The method includes providing a tenancy in the associated cloud infrastructure environment, the computer comprising one or more processors and a memory device operatively coupled to the computer, the memory device storing tag-based control logic, the step further comprising: storing tag-based allocation data in the memory device, the tag-based allocation data representing a plurality of tag-based allocations of resource provisioning in the tenancy, the steps further comprising: receiving a request to provision a resource in the tenancy, the request including request characteristic data representing request characteristics of the request, the step further comprising: determining resource usage in the tenancy associated with a resource tag corresponding to the request characteristic of the request by the one or more processors executing the tag-based control logic; comparing the determined usage to the plurality of tag-based allocations by the one or more processors executing the tag-based control logic; and dropping the request to provision the resource based on the determined usage exceeding one of the plurality of tag-based allocations by the one or more processors executing the tag-based control logic.

16. providing the tenancy includes providing a plurality of compartments for storing the resources, each compartment of the plurality of compartments providing isolation of a set of resources in the respective compartment relative to one or more other sets of resources in other compartments; determining the usage includes determining usage of the resources in the tenancy associated with the resource tags corresponding to the request characteristics of the request, collectively across the compartments; the comparing includes comparing the usage determined collectively across the compartments to the tag-based allocations of the tenancy; 16. The method of claim 15, wherein the dropping comprises dropping the request to provision the resource based on the usage determined collectively across the compartments exceeding one of the tag-based allocations. medium.

17. storing the tag-based allocation data includes storing in the memory device tag-based allocation data representing a plurality of tag-based allocations of resource provisioning in the tenancy for a corresponding plurality of resource types of the tenancy; Receiving the request includes receiving a request including resource type data representing a first resource type of the requested resource; The determining includes determining that usage of a resource in the tenancy associated with a resource tag corresponding to the first resource type is determined; The comparing includes comparing the determined usage to a first tag-based allocation of resource provisioning in the tenancy for the first resource type; 17. The medium of claim 15 or 16, wherein dropping the request comprises dropping the request based on the determined resource usage in the tenancy associated with the resource tag corresponding to the first resource type exceeding the first tag-based allocation of the resource provisioning in the tenancy of the first resource type.

18. storing the tag-based allocation data includes storing in the memory device tag-based allocation data representing a plurality of tag-based allocations of resource provisioning in the tenancy assigned to a corresponding plurality of user groups of the tenancy; receiving the request includes receiving a request including resource type data representing a user group category assigned to a user of the system requesting the resource; determining a resource usage in the tenancy associated with a resource tag corresponding to the user group category; The comparing includes comparing the determined usage to a first tag-based allocation of resource provisioning in the tenancy assigned to the user group category; 18. The medium of claim 15, 16, or 17, wherein dropping the request comprises dropping the request based on the determined resource usage in the tenancy associated with the resource tag corresponding to the user group category exceeding the first tag-based allocation of resource provisioning in the tenancy assigned to the user group category.

19. storing the tag-based allocation data includes storing in the memory device tag-based allocation data representing tag-based allocations of resource provisioning in the tenancy for a plurality of resource types of the tenancy assigned to a plurality of user groups of the tenancy; receiving the request includes receiving a request including resource type data including: i) resource type data representing a first resource type of the requested resource; and ii) user group data representing a user group category assigned to a user of the system requesting the resource; determining a resource usage in the tenancy associated with a resource tag corresponding to the first resource type provisioned to the first user group category; The comparing may include comparing the determined usage to resource provisioning in the tenancy of the first resource type assigned to the first user group category. comparing the first tag-based assignment to the first tag-based assignment of the first 19. The medium of claim 15, wherein dropping the request includes dropping the request based on the determined resource usage in the tenancy associated with the resource tag corresponding to the first resource type to be provisioned to the first user group category exceeding the first tag-based allocation of resource provisioning in the tenancy of the first resource type assigned to the first user group category.

20. moreover, storing in the memory device tag-based assignment data representing tag-based assignments of resource provisioning in the tenancy for a plurality of resource types of the tenancy assigned to a plurality of user groups of the tenancy; receiving a first request to track resource usage of the tenancy, the first request including request characteristic data representative of a first user group category and a first resource type; and determining a first use of a resource in the tenancy associated with a resource tag corresponding to the first resource type provisioned by the first user group category; and generating resource usage tracking data based on a first usage of the determined resources in the tenancy of the first resource type provisioned by the first user group.

Images