System and method for label-based resource limits or quotas in a cloud infrastructure environment

Abstract

The systems and methods described herein support tag-based resource limits or quotas in a cloud infrastructure environment. Cloud administrators generally have no ability to limit resource usage in an existing cloud. The granting of permissions to users to create resources allows them to create any number of resources up to a predefined account limit. Tags are associated with resources, allowing administrators to limit users' resource usage to an appropriate level by allowing fine-grained cost control. Usage of resources in a tenancy associated with a resource tag corresponding to a request characteristic of a request to provision resources is determined, and compared to a plurality of tag-based quotas, wherein the request to provision resources is discarded based on the determined usage exceeding one of the plurality of tag-based quotas.

Description

[0001] Copyright Notice

[0002] This patent document contains copyrighted material in parts of its disclosure. The copyright holder does not object to any fax copying of the patent document or its disclosure as it appears in the Patent and Trademark Office's patent documents or records, but otherwise retains all copyright rights.

[0003] Cross-referencing of priority claims and related applications:

[0004] This application claims priority to U.S. Provisional Patent Application No. 62 / 884,931, filed August 9, 2019, entitled “SYSTEM AND METHOD FOR TAG BASED RESOURCE LIMITS OR QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT”; and U.S. Provisional Patent Application No. 62 / 884,933, filed August 9, 2019, entitled “SYSTEM AND METHOD FOR TAGBASED REQUEST CONTEXT IN A CLOUD INFRASTRUCTURE ENVIRONMENT”; each of the above applications is incorporated herein by reference in its entirety.

[0005] This application also claims priority to the following applications: U.S. Patent Application No. 16 / 986,158, filed August 5, 2020, entitled “SYSTEMAND METHOD FOR TAG BASED RESOURCE LIMITS OR QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT”; and U.S. Patent Application No. 16 / 986,160, filed August 5, 2020, entitled “SYSTEMAND METHOD FOR TAG BASED REQUEST CONTEXT IN A CLOUD IN FRASTRUCTURE ENVIRONMENT”; each of the above applications is incorporated herein by reference in its entirety. Technical Field

[0006] The embodiments described herein are generally related to cloud infrastructure environments, such as Infrastructure as a Service (IaaS), and particularly relate to systems and methods for providing resource constraints within such cloud infrastructure environments. Background Technology

[0007] A cloud infrastructure environment can include a collection of complementary cloud services that enable users and clients (the terms “client” and “customer” are used interchangeably throughout this specification) to build and run a wide range of applications and services in a highly available, hosted environment.

[0008] Year after year, more and more businesses and organizations are migrating mission-critical applications and systems to cloud infrastructure environments. There are several reasons for this shift. For example, many businesses are moving to the cloud to reduce the cost and complexity of operating, maintaining, and building on-premises infrastructure. Similarly, cloud infrastructure allows for faster information technology (IT) delivery mechanisms. Some businesses and organizations also see cloud infrastructure environments as a means to gain a competitive advantage by adapting to more flexible systems.

[0009] Within the IaaS (Infrastructure as a Service) model, cloud providers can offer, host, and manage infrastructure components that would traditionally be deployed on-premise at each customer's / client's location. Such components, traditionally offered on-premise, can include hardware (e.g., data warehouses and data centers, servers, storage devices, networking hardware) and software (e.g., virtualization software).

[0010] In addition to providing traditionally on-premises hardware and software, IaaS providers can also offer services to their clients and customers. For example, clients and customers can be allowed to customize their IaaS subscriptions to meet their needs, which in turn allows for detailed and segmented billing and invoicing. IaaS can also support features such as load balancing, redundancy, replication, and recovery. Because these services are provided and supported by the IaaS provider (not the customer), this allows clients and customers to focus more on improving their service by pushing for greater automation and orchestration.

[0011] Cloud infrastructure enables users and clients to seamlessly run traditional enterprise applications and cloud-native applications on the same platform, thereby reducing operational overhead and enabling direct connectivity between the two types of workloads. Summary of the Invention

[0012] This paper describes systems and methods for providing tag-based resource limits or quotas in cloud infrastructure environments. The systems and methods described support tag-based resource limits / quotas in cloud infrastructure environments. Fine-grained methods can provide resource limits based on tags across multiple containers. Tags are a mechanism primarily used in resource governance, and cloud providers also use them for cost governance. The systems and methods can create a mechanism to control costs at the group level via tags. The systems and methods provide compartmentalized quotas for cloud infrastructure environments.

[0013] Cloud administrators have the ability to restrict resource usage in the existing cloud, but only at a high level and without a perspective on specific users, resources, resource types, or container hierarchy levels. According to embodiments, resources are associated with tags so that their use can be controlled, tracked, and / or otherwise disposed of at the necessary or desired resource level. Providing resource quotas and / or limits allows administrators and others to restrict users' resource usage to appropriate levels, thereby allowing for fine-tuned cost control.

[0014] According to an embodiment, service level limits (SLAs) defined by the cloud infrastructure environment can be assigned to customers at the time of account creation. These SLAs limit the total number of resources a customer can create across the entire lease (e.g., across multiple regions with multiple cubicles, and across multiple containers). Lease and cubicle administrators can leverage tag-based resource quotas 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 lease. Tag-based resource limits solve this problem and, unlike service limits, are set and customized by the client and customers via, for example, a console, SDK, or API. Tag-based resource limits can be applied on top of service limits and inherited through nested cubicle hierarchies. This allows cubicle administrators to limit resource consumption and set boundaries around acceptable resource usage. Attached Figure Description

[0015] Figure 1 The illustration depicts a system for providing a cloud infrastructure environment according to an embodiment.

[0016] Figure 2 The illustration depicts a system for providing cloud infrastructure zones within a cloud infrastructure environment, according to an embodiment.

[0017] Figure 3 A cloud infrastructure environment system according to an embodiment is shown, illustrating the relationships between compartments, compartment policies, sub-compartments, and sub-compartment policies for policy management and control across cloud infrastructure regions.

[0018] Figure 4 The cloud infrastructure environment 400 is shown, illustrating the relationship between the compartment, compartment policy, sub-compartment and sub-compartment policy when the compartment is moved.

[0019] Figure 5 The cloud infrastructure environment 500 is shown, illustrating the implications of the strategy when moving between cubicles.

[0020] Figure 6 A pair of labels defined according to an example embodiment are shown.

[0021] Figure 7An architecture of a system for enforcing quotas or limits on resources in a cloud infrastructure environment based on a tag, according to an example embodiment, is shown, where the tag includes, for example, a resource tag and a resource request context tag.

[0022] Figure 8 A system is shown that uses request context tags and / or resource tags to restrict usage such as the provisioning of resources in a cloud infrastructure environment.

[0023] Figure 9 This is a functional diagram illustrating a system for providing resource request context label-based limits / quotas in a cloud infrastructure environment, according to an embodiment.

[0024] Figure 10 This is a flowchart illustrating a method for limiting or imposing quotas on supplied resources in a cloud infrastructure environment based on a request context, according to an example embodiment.

[0025] Figure 11 This is a functional diagram of a system for providing tag-based resource limits / quotas in a cloud infrastructure environment, according to an embodiment.

[0026] Figure 12 This is a flowchart illustrating a method for limiting or imposing quotas on supplied resources in a cloud infrastructure environment based on resource tags, according to an example embodiment. Detailed Implementation

[0027] According to embodiments herein, the terms "bare metal host," "bare metal instance," or "bare metal compute instance" can refer to a physical host ("bare metal") machine provided for use in a cloud infrastructure environment. Bare metal compute instances run directly on bare metal servers without the need for hypervisors. When provisioning a bare metal instance, users / clients can maintain individual control over the physical CPU, memory, and network interface cards (NICs). Users / clients can configure and utilize the full capabilities of each physical machine as if it were hardware running in their own data center. Users / clients do not share physical machines with any other tenants.

[0028] According to the embodiments described herein, a cloud infrastructure environment can be physically hosted in regions and availability domains. The term "region" can refer to a local geographic area. The term "availability domain" can represent one or more data centers located within a region. A region consists of one or more availability domains. Cloud infrastructure can be region-specific, such as a virtual cloud network, or availability domain-specific, such as compute instances. Availability domains are isolated from each other, fault-tolerant, and unlikely to fail simultaneously or be affected by failures in another availability domain. When users / clients configure their cloud services, they can use multiple availability domains to ensure high availability and prevent resource failures. Some resources must be created within the same availability domain, such as instances and the storage volumes attached to them.

[0029] According to embodiments of this document, the term "domain" can refer to a logical collection of regions. Domains are isolated from each other and do not share any data. A client's lease can exist within a single domain and can access every region belonging to that domain. For example, domains can be provided for commercial regions and government cloud regions.

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

[0031] According to embodiments herein, the term "lease" can refer to a secure and isolated partition within a cloud infrastructure environment. When a client / user registers with the cloud infrastructure environment, the cloud infrastructure environment can create a lease for the user / client (or their company). A lease can be a place where a user / client creates, organizes, and manages their cloud resources.

[0032] According to embodiments of this document, the term "cubicle" can refer to a collection of related resources (such as instances, virtual cloud networks, block volumes) that can only be accessed by certain groups that have been granted permission by an administrator. Cubicles allow clients / users to organize and control their access to their cloud resources. When a client / user begins working with resources in the console, a cubicle can provide filters for the content the client / user is viewing.

[0033] According to the embodiments described herein, the term "lease" can refer to a root compartment that includes cloud resources for all tenants. Additional compartments can be created within a lease (root compartment), and corresponding policies can be used to control access to resources in each compartment. When a user / client creates cloud resources (such as instances, block volumes, or cloud networks), the user / client can specify which compartment the resource should belong to.

[0034] According to embodiments of this document, the term "virtual cloud network" can refer to a virtual version of a traditional network (including subnets, routing tables, and gateways) on which instances run. A cloud network resides within a single region but encompasses all availability domains within that region. Each subnet defined within a cloud network can either reside in a single availability domain or span all availability domains within a region. At least one cloud network can be set up before instances can be launched.

[0035] According to embodiments of this document, the term "instance" can refer to a computing host running in the cloud. In contrast to traditional software-based virtual machines, cloud infrastructure environment instances allow users / clients to utilize hosted physical hardware, thereby providing enhanced security and performance.

[0036] According to embodiments of this document, the term "image" can refer to a template for a virtual hard disk drive that defines the operating system and other software, such as Linux, for an instance. When an instance is launched, its characteristics can be defined by selecting its image. A collection of images can be provided, and images from existing instances that have already been configured (e.g., as templates) can be used to create instances with the same software and customizations.

[0037] According to embodiments of this document, the term "shape" can refer to a specification of the number of CPUs and the amount of memory allocated to an instance. In load balancing, shape can determine the total maximum capacity (bandwidth) that the load balancer pre-supplys for ingress and egress traffic. Available shapes can include, for example, 100 Mbps, 400 Mbps, and 8000 Mbps.

[0038] According to the embodiments described herein, the term "key pair" can refer to an authentication mechanism using 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 stored on the user / client's device. The private key is private to the user / client, much like a password. Key pairs can be generated according to different specifications, such as instance SSH key pairs and API signing key pairs. Instance SSH key pairs are used to establish a Secure Shell (SSH) connection to the instance. When provisioning an instance, the public key, stored in the instance's authorized key file, can be provided. To log in to the instance, the private key is provided, which is verified against the public key. API signing key pairs are in PEM (Privacy Enhanced Email) format and are used to authenticate users / clients when submitting API requests.

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

[0040] According to embodiments of this document, the term "object storage" can refer to a storage architecture that can be used to store and manage data as objects. Data files can be of any type. Once data is uploaded to object storage, it can be accessed from anywhere. Object storage can be used when there is a need to store large amounts of data and the data does not change very frequently. Typical uses of object storage include, but are not limited to, data backup, file sharing, and storing unstructured data (e.g., logs and sensor-generated data).

[0041] According to embodiments of this document, the term "bucket" can refer to a logical container used to store data and files. A bucket can contain an unlimited number of objects.

[0042] As mentioned above, a cloud infrastructure environment can include a collection 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.

[0043] Figure 1 A system for providing a cloud infrastructure environment according to an embodiment is shown.

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

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

[0046] According to an embodiment, leasing can be supported within a cloud infrastructure environment. During registration and deployment, a lease can be created for each client / customer, which may include a secure and isolated partition within the cloud infrastructure where the client can create, organize, and manage their cloud resources.

[0047] According to embodiments, console interface 102 and API 104 can provide clients with access to and control over corresponding portions of the cloud infrastructure environment. According to embodiments, 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 scope. Similarly, API 104 may include, for example, a REST API utilizing HTTPS (Hypertext Transfer Protocol Secure).

[0048] According to embodiments, an example of a console interface or API could be a configuration management tool (e.g., Ansible). Configuration management tools can be used for cloud infrastructure provisioning, orchestration, and configuration management. They can allow clients to automate complex operational processes such as configuring and provisioning cloud infrastructure, deploying and updating software assets, and orchestrating configurations.

[0049] According to an embodiment, the governance service 110 for the cloud infrastructure environment provides clients with tools to help them enable simple resource governance, manage costs, and control access to the cloud infrastructure. As an example, the governance service provides tagging, which allows clients to apply tags to their resources for informational or operational reasons. Defined tags can be controlled to prevent incorrect tags from being applied to resources. Tags can also provide a flexible target selection mechanism for management scripts. Similarly, the governance service can allow for managed budgets and track all actual and projected expenditures from a single location. This allows clients to monitor usage through a cost analytics dashboard and filter by compartment and tag to analyze expenditures by department, team, and project. This 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 later be retrieved, stored, and analyzed for security, compliance, and resource optimization across cloud infrastructure rights and compartments.

[0050] According to an example embodiment, the governance service provides tagging, allowing clients, administrators, and others to apply tags to their resources for informational or operational reasons while the resources are being instantiated. According to a further example embodiment, the governance service also provides tagging, allowing clients and others to apply tags to their resources for informational or operational reasons after the resources have been instantiated, thereby allowing the use of tags to track the enforcement of resource quotas or limits in the system.

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

[0052] According to an embodiment, the Identity and Access Management (IAM) service can be integrated with a cloud infrastructure environment. After client registration, the IAM service can create individual user credentials within the Identity Service, which can then allow single sign-on to cloud infrastructure services and access to additional cloud services.

[0053] According to an embodiment, provisioning service 130 can provide rentals within, for example, cloud infrastructure services, such as within resource 140. The provisioning service can be accessed and controlled via, for example, a console interface or via one or more APIs, such as API 104. The provisioning service can allow clients to provision and manage computing hosts, which may be referred to as instances. Clients can launch instances as needed to meet computing and application requirements. After a client launches an instance, the provisioned instance can be accessed from, for example, a client device. The provisioning service may also provide the ability to restart instances, attach and detach volumes from instances, and terminate instances.

[0054] According to an embodiment, the resources 140 provided by the cloud infrastructure environment can be decomposed into multiple layers, such as a computer resource layer 150, a network resource layer 160, and a storage resource layer 170.

[0055] According to an embodiment, the computing resource layer 150 may include multiple resources, such as, for example, bare metal instances 152, virtual machines 154, edge services 156, and containers 158. For example, the computing resource layer may be used to provision and manage bare metal computing instances, provisioning instances as needed to deploy and run applications, just as in a local data center. The cloud infrastructure environment 100 according to an example embodiment supports multiple tags 140a associated with each resource, including, for example, computer resource tags 150a associated with the computing resource layer 150, which includes, for example, bare metal instances 152, virtual machines 154, edge services 156, and containers 158.

[0056] According to an embodiment, a cloud infrastructure environment can provide control over one or more physical host (“bare metal”) machines within a compute resource tier. Bare metal compute instances run directly on bare metal servers without the need for hypervisors. When provisioning bare metal compute instances, clients can maintain individual control over the physical CPU, memory, and network interface cards (NICs). Bare metal compute instances can be configured and utilize the full capabilities of each physical machine as if it were hardware running in its own local data center. Therefore, bare metal compute instances are generally not shared between tenants.

[0057] According to embodiments, in contrast to software-based virtual environments, bare-metal computing instances can provide a high level of security and performance via associated physical hardware.

[0058] According to embodiments, a cloud infrastructure environment can provide control over multiple virtual machines within a compute resource tier. For example, a virtual machine compute host can be launched from an image that can determine the virtual machine's operating system and other software. For example, the type and quantity of resources available for that virtual machine instance can be determined based on the image from which the virtual machine is launched.

[0059] According to embodiments, virtual machine (VM) computing instances can include independent computing environments running on top of physical bare-metal hardware. Virtualization makes it possible to run multiple virtual machines that are isolated from each other. For example, VMs can be used to run applications that do not require the performance and resources (CPU, memory, network bandwidth, storage) of the entire physical machine.

[0060] In some embodiments, virtual machine instances can run on the same hardware as bare metal instances, which can provide full utilization of the same cloud-optimized hardware, firmware, software stack, and networking infrastructure.

[0061] According to embodiments, a cloud infrastructure environment can provide multiple graphics processing unit (GPU) compute instances within a compute resource tier. Accelerated computing requires a consistently fast infrastructure across each service. Leveraging GPU instances, clients can process and analyze massive datasets more efficiently, making them useful for complex machine learning (ML), artificial intelligence (AI) algorithms, and many industrial HPC applications. GPU compute instances can be provisioned as virtualized compute instances (where multiple GPU compute instances share the same bare-metal hardware) or as bare-metal instances providing dedicated hardware for each GPU compute instance.

[0062] According to an embodiment, a cloud infrastructure environment can provide multiple containerized compute instances within a compute resource layer. A standalone container engine service can be used to build containerized applications and launch them into the cloud. For example, a container service can be used to build, deploy, and manage cloud-native applications. The container service can specify the compute resources required by the containerized application, and then the container engine can supply the required compute resources for use within the cloud infrastructure environment (e.g., in a leased context) via a provisioning service.

[0063] According to an example, 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 host clusters. Such container services can group the containers that make up an application into logical units for easy management and discovery.

[0064] According to an embodiment, network resource layer 160 may include multiple resources, such as, for example, a virtual cloud network (VCN) 162, a load balancer 164, an edge service 166, and a connectivity service 168. A cloud infrastructure environment 100 according to an example embodiment supports multiple tags associated with each resource, including, for example, a resource tag 140a generally associated with resource 140, and network resource tags 160a associated with the virtual cloud network (VCN) 162, load balancer 164, edge service 166, and connectivity service 168.

[0065] According to embodiments, a cloud infrastructure environment can provide multiple virtual cloud networks 162 at the networking resource layer. A virtual cloud network can include a virtual version of a traditional network (including subnets, routing tables, and gateways) on which client instances can run. The cloud network resides within a single region but includes all availability domains within that region. Each subnet defined in the cloud network can either reside in a single availability domain or span all availability domains within a region (recommended). At least one cloud network can be configured before launching instances. In some embodiments, a VCN can be configured via an Internet gateway to handle public traffic, VPN connections, or fast connection services to securely extend the local network.

[0066] According to an embodiment, the cloud infrastructure environment can provide multiple load balancers 164 at the networking resource layer. The load balancing service can provide automated traffic distribution from an entry point to multiple servers reachable from a Virtual Cloud Network (VCN). Various load balancers can provide public or private IP addresses and supplied bandwidth.

[0067] According to embodiments, load balancers can improve resource utilization, scaling, and help 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. Load balancers can shorten maintenance windows by dumping traffic before removing unhealthy application servers from service for maintenance.

[0068] According to embodiments, the load balancing service enables the creation of public or private load balancers in conjunction 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 for the IP address to load balance traffic transported at different layers (e.g., Layer 4 and Layer 7 (TCP and HTTP) traffic). Both public and private load balancers can route data traffic to any backend server reachable from the VCN.

[0069] According to an embodiment, a public load balancer can accept traffic from the Internet and can create a public load balancer assigned a public address, which serves as the entry point for incoming traffic.

[0070] According to embodiments, the public load balancer is regional in scope. If the region includes multiple availability domains, the public load balancer may have, for example, a regional subnet or two availability domain-specific (AD-specific) subnets, each located in a separate availability domain. Using regional subnets, the load balancer can create a primary load balancer and a standby load balancer, each located in a different availability domain, to ensure accessibility even during availability domain outages. If load balancing is created across multiple AD-specific subnets, one subnet may host the primary load balancer, while another subnet hosts the standby load balancer. If the primary load balancer fails, the public IP address can be switched to the secondary load balancer. The service treats the two load balancers as equivalent.

[0071] According to an embodiment, if the region comprises only one availability domain, then the service requires only one subnet (either regional or AD-specific) to host both the primary and standby load balancers. In addition to assigned floating public IP addresses, the primary and standby load balancers can each have private IP addresses from the host subnet. If an availability domain outage occurs, then the load balancers do not failover.

[0072] According to embodiments, private load balancing can also be provided to isolate the load balancer from the internet and simplify security practices. The load balancer service can assign private addresses to the load balancer used as an entry point for incoming traffic.

[0073] According to an embodiment, a private load balancer can be created by a service to serve only one subnet, hosting both the primary and standby load balancers. The load balancer can be regional or AD-specific, depending on the scope of the host subnet. The load balancer can only be accessed from within the VCN containing that host subnet, or is subject to further restrictions by security rules.

[0074] In this embodiment, the assigned floating private IP address is local to the host subnet. Both the primary and backup load balancers require additional private IP addresses from the host subnet.

[0075] According to an embodiment, if an availability domain outage occurs, a private load balancer created in a regional subnet within a multi-AD region provides failover capability. A private load balancer created in an AD-specific subnet or a regional subnet within a single availability domain region does not have failover capability in response to an availability domain outage.

[0076] According to an embodiment, the cloud infrastructure environment can provide multiple edge services 166 at the networking resource layer. Generally, edge services include multiple services that allow clients to manage, protect, and maintain domains and endpoints. For example, these include DNS (Domain Name System), DDoS (Distributed Denial of Services) protection, and email delivery. These services enable clients to optimize performance, block network attacks, and extend communication.

[0077] According to an embodiment, the cloud infrastructure environment can provide multiple connectivity services 168 at the networking resource layer. Such connectivity services can provide a simple way to create dedicated, private connections between the client data center or existing network and the cloud infrastructure environment. The connectivity services can provide high bandwidth, as well as reliable and consistent networking.

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

[0079] According to an embodiment, block volume 172 provides high-performance network storage capacity to support a wide range of I / O-intensive workloads. Clients can use block volumes to extend the storage capacity of compute instances, providing persistent data storage that can be migrated across compute instances and hosting large databases.

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

[0081] According to embodiments, object storage provides high-throughput storage for unstructured data. Object storage services offer near-limitless 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 to increase durability.

[0082] According to an embodiment, local storage 178 can provide high-speed and reliable storage, such as solid-state drives, for I / O-intensive applications. These can be provided, for example, in bare-metal instances. 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.

[0083] Figure 2 The illustration depicts a system for providing cloud infrastructure zones within a cloud infrastructure environment, according to an embodiment.

[0084] According to the embodiments, the above are in Figure 1 Instances of the cloud infrastructure environment described herein can be hosted in different regions, referred to as cloud infrastructure regions 220. As mentioned above, these can be accessed by client network 200 via a network such as the Internet 210 through a console, SDK, or API. Each cloud infrastructure region may include management services 222, computing services 224, storage services 226, edge services 228, network services 230, and physical infrastructure 232.

[0085] According to embodiments, 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 that region. A region consists of one or more availability domains. Most cloud infrastructure resources can be region-specific, such as virtual cloud networks, or availability domain-specific, such as compute instances. Traffic between availability domains and between regions is encrypted.

[0086] According to the embodiments, availability domains are isolated from each other, fault-tolerant, and unlikely to fail simultaneously. Because availability domains do not share infrastructure (such as power or cooling systems) or internal availability domain networks, a failure in one availability domain within a region is unlikely to affect the availability of other availability domains in the same region.

[0087] According to an embodiment, availability domains within the same region can be interconnected through a low-latency, high-bandwidth network that can provide high availability connectivity to the Internet and locally deployed systems, and replicated systems can be built across multiple availability domains for high availability and disaster recovery.

[0088] According to one embodiment, the region is independent of other regions and can be geographically separated (e.g., spanning a country or continent). This then leads to the deployment of the application in the region where it is most likely to be used most frequently.

[0089] However, according to embodiments, applications can also be deployed in different regions for various reasons. For example, this could include mitigating risk when an event such as a weather system causes a region to go offline. Furthermore, applications can be deployed in other regions for strategic reasons, such as tax domains or other business or social guidelines.

[0090] According to an embodiment, there are several services available across regions. These include, for example, management service 222, computing service 224, storage service 226, edge service 228, and network service 230.

[0091] According to embodiments, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (such as instances, virtual cloud networks, block volumes) that can only be accessed by certain groups granted permission by an administrator. For example, a compartment may contain all the servers and storage volumes that make up the production of a company's human resources (HR) system, while, as a further example, other compartments may be separately dedicated to the company's legal, marketing, accounting, operations, and information technology (IT) systems. In this 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 production of the company's human resources (HR) system and its legal, marketing, accounting, operations, and information technology (IT) systems. In this example, only users with permission to a portion of those resources can manage and / or access those portions of the servers and volumes.

[0092] The cubicles in the example embodiments comprise one or more logical groups and are not necessarily physical storage containers, but they can be physical storage containers if desired or necessary. When working within a console, cubicles can act as filters for the content that can be viewed. Cubicles are a major building block that can be used for cloud resources, and they can be used to organize and isolate resources to make it easier to manage and protect access to those resources.

[0093] According to embodiments, a compartment can have several layers. For example, a lease can be viewed as a root compartment that holds all of a client's cloud resources. Additional compartments can be created within that root compartment (lease), and corresponding policies can be created to control access to resources in each compartment. When a client creates cloud resources (such as compute, storage, VCN, IP addresses and / or DNS instances, block volumes, or cloud networks), such resources can be directed to one or more specific compartments. Compartments can span regions.

[0094] Fault Domain

[0095] 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 so that they are not on the same physical hardware within a single availability domain. Hardware failures or compute hardware maintenance affecting one fault domain will not affect instances in other fault domains.

[0096] According to embodiments, the placement of resources such as compute, bare-metal database systems, or virtual machine database system instances may optionally specify a fault domain or a new instance at startup. Resources can additionally change their fault domain after placement by terminating the resource in the current fault domain and starting a new instance of the resource in another fault domain.

[0097] According to embodiments, fault domains can be used for a variety of reasons, such as preventing unexpected hardware failures and preventing disruptions to plans due to maintenance.

[0098] Availability

[0099] According to embodiments, service availability can be provided. Regions within a cloud infrastructure environment can provide core infrastructure services and resources, including: Computing: Computing (bare metal & virtual machines, DenseIO & standards), container engines for Kubernetes, registry Storage: Block volume, file storage, object storage, archive storage Networking: Virtual cloud network, load balancing, fast connection Databases: Databases, Exadata cloud services, autonomous data warehouses, autonomous transactions deal with Edge: DNS Platform: Identity and access management, tagging, auditing According to the embodiments, the services and resources described above are generally available, while other services and resources may also be additionally available (e.g., based on regional needs or customer requests). As an example, new cloud services can be made available in a region as quickly as possible based on various considerations, including regional customer needs, the ability to achieve regulatory compliance where applicable, resource availability, and other factors. Due to the low-latency interconnect backbone, customers can use cloud services in other geographic regions and obtain effective results when they are unavailable in their local region, provided that data residency requirements do not prevent them from doing so.

[0100] According to embodiments, 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 DC systems, instances, and volumes are domain-specific. Most other resources are regional.

[0101] 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.

[0102] According to embodiments, examples of regionally available resources may include alerts, applications, buckets (although buckets are regional resources, they can be accessed from any location when the correct region-specific object storage URL is used for API calls), clusters, cloud event rules, customer premises equipment (CPE), DHCP option sets, dynamic routing gateways (DRGs), encryption keys, features, images, internet gateways, jobs, keystores, load balancers, local peer-to-peer gateways (LPGs), metrics, NAT gateways, network security groups, node pools, ons-subscriptions, ons-topics, repositories, reserved public IPs, routing tables, security lists, service gateways, stacks, subnets (when a subnet is created, it can be declared as 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 where they are stored).

[0103] According to the embodiments, examples of availability domain-specific resources may include a DB system, a temporary public IP, an instance (an instance may be attached to a volume in the same availability domain), a subnet (when a subnet is created, it may be declared as regional or availability domain-specific), and a volume (a volume may be attached to an instance in the same availability domain).

[0104] cubicle

[0105] According to an example, an administrator can manage compartments within a cloud infrastructure environment.

[0106] According to an embodiment, tags can be applied to resources within a compartment. For example, tags can be used to organize resources based on patterns (such as business demand patterns). Tags can be applied to resources when they are created, or tags can be updated on existing resources. The tag associated with each resource may include, for example, a resource tag 140a generally associated with resource 140. Figure 1 ), computer resource tag 150a associated with computer resource layer 150, network resource tag 160a associated with network resource layer 160, and storage resource tag 170a associated with storage resource layer 170.

[0107] According to the embodiments, cubicles are important for the construction and organization of cloud infrastructure. Resources can be moved between cubicles, and resources organized by cubicle in the current area can be displayed (e.g., via a user interface). When working with and managing resources, a cubicle can be selected first.

[0108] According to one embodiment, a compartment is a rental area and can span regions. When a compartment is created, it can be made available in every region of the rental subscription.

[0109] According to an embodiment, a compartment can be deleted. To delete a compartment, all resources within it can be removed before deletion.

[0110] According to an embodiment, the action of deleting a cubicle can be asynchronous, and a work request is initiated. When the work request is executed, the cubicle's state changes to "deleting". If the work request fails, the cubicle is not deleted and it returns to the active state.

[0111] According to embodiments, each compartment created within a cloud infrastructure environment may have certain characteristics. For example, a unique identifier (ID) may be assigned to each compartment, and a modifiable description and name may be provided additionally and optionally. According to embodiments, sub-compartments (or sub-compartments) may be defined hierarchically under a base compartment.

[0112] According to an embodiment, access to and control over cubicles and sub-cubicles can be limited to an administrator or other users with sufficient credentials. Credentials can be associated with different levels of cubicle access rights. For example, an administrator may have permission to view and access all cubicles and use resources within any leased cubicle, but users with more restricted access rights would not have this level of access and control.

[0113] Figure 3 A cloud infrastructure environment 300 according to an embodiment is shown, illustrating the relationship between compartments 360, compartment policies 365, sub-compartments 370 and sub-compartment policies 375 for policy management and control across cloud infrastructure regions.

[0114] According to the embodiments, as described above, the upper Figure 1 Instances of the cloud infrastructure environment described herein can be hosted in different regions (such as cloud infrastructure regions 320, 330, 340, and 350). As mentioned above, these can be accessed by the customer network 301 via a network 302, such as the Internet, through a console, SDK, or API.

[0115] According to an embodiment, the client network 301 may include, for example, a single computer, a client computer network, or other such networks.

[0116] According to the embodiments, although not shown in the figures, each cloud infrastructure region may include multiple services, and each service includes multiple resources, such as management services, computing services, storage services, edge services, network services, and physical infrastructure.

[0117] According to embodiments, 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 that region. A region consists of one or more availability domains. Most cloud infrastructure resources can be region-specific, such as virtual cloud networks, or availability domain-specific, such as compute instances. Traffic between availability domains and between regions is encrypted.

[0118] According to the embodiments, availability domains are isolated from each other, fault-tolerant, and unlikely to fail simultaneously. Because availability domains do not share infrastructure (such as power or cooling systems) or internal availability domain networks, a failure in one availability domain within a region is unlikely to affect the availability of other availability domains in the same region.

[0119] According to an embodiment, availability domains within the same region can be interconnected through a low-latency, high-bandwidth network that can provide high availability connectivity to the Internet and locally deployed systems, and replicated systems can be built across multiple availability domains for high availability and disaster recovery.

[0120] According to one embodiment, the region is independent of other regions and can be geographically separated (e.g., spanning a country or continent). This then leads to the deployment of the application in the region where it is most likely to be used most frequently.

[0121] However, according to embodiments, applications can also be deployed in different regions for various reasons. For example, this could include mitigating risk when an event such as a weather system causes a region to go offline. Furthermore, applications can be deployed in other regions for strategic reasons, such as tax domains or other business or social guidelines.

[0122] According to an embodiment, several services are available across regions. These include, for example, management services, computing services, storage services, edge services, and network services.

[0123] According to an embodiment, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (such as instances, virtual cloud networks, block volumes) that can only be accessed by certain groups granted permission by an administrator. A compartment can be thought of as a logical group rather than a physical container. When working within a console, a compartment can act as a filter for the content that is allowed to be viewed.

[0124] According to an embodiment, a compartment can have several layers. For example, lease 305 can be considered as the root compartment holding all cloud resources for the client. Compartments can be organized hierarchically, such as compartment 360 being a level below a lease compartment, and sub-compartments 370 being additional layers below compartment 360. According to an embodiment, each compartment can be associated with one or more compartment policies, such as compartment policy 365 and sub-compartment policy 375. Tenant compartment policies are not shown in the figure.

[0125] According to an embodiment, during, at, or after the creation of a compartment or sub-compartment (such as compartment 360 and sub-compartment 370), policies such as compartment policy 365 and sub-compartment policy 375 can be written / created for each compartment and sub-compartment. Without appropriate policies, access to the compartment and / or sub-compartment can be restricted to users with a lease level 305 license.

[0126] According to an embodiment, when a compartment (i.e., a sub-compartment) is created within a compartment, the sub-compartment inherits access permissions from the compartment at its higher level.

[0127] According to an embodiment, after creating a compartment or sub-compartment policy, the policy may include a specification indicating which compartment the policy is attached to. This specification may include controls restricting access to sub-sequence control, modification, or deletion of the policy. In some embodiments, the policy may be attached to a lease, a parent compartment, or a specific compartment to which the policy targets.

[0128] According to an embodiment, new resources can be placed into a compartment. This can be done by specifying the compartment as the target after creating the new resource (the compartment is one of several pieces of information required to create the resource). This can be done via a console interface.

[0129] According to the embodiment, existing resources can also be moved to different compartments. Most resources can be moved after creation. Some resources cannot be moved from one compartment to another.

[0130] According to the implementation, some resources have attached resource dependencies, while others do not. When the parent resource moves, not all attached dependencies behave in the same way.

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

[0132] According to an embodiment, for other resources, attached resource dependencies are not moved to the new compartment. Such attached resources can be moved independently.

[0133] According to one embodiment, once 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 structure of the compartment organization, metering, billing, and alarms may also be affected.

[0134] According to an embodiment, after creation, a cubicle can be moved to, for example, a different parent cubicle within the same lease. After a cubicle is moved, all its contents (including child cubicles and resources) will move along with the cubicle.

[0135] Figure 4 The illustration depicts a system for compartment migration within a cloud infrastructure environment according to an embodiment.

[0136] According to the embodiments, as described above, the upper Figure 1 Instances of the cloud infrastructure environment 400 described herein can be hosted in different regions. Within the cloud infrastructure environment, compartments such as lease 405, compartment A 460, and compartment B 470 can be defined, and these compartments can span regions. As mentioned above, such compartments can be accessed by client network 401 via network 402, such as the Internet, through a console, SDK, or API.

[0137] According to an embodiment, the client network 401 may include, for example, a single computer, a client computer network, or other such networks.

[0138] According to an embodiment, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (such as instances, virtual cloud networks, block volumes) that can only be accessed by certain groups granted permission by an administrator. A compartment can be thought of as a logical group rather than a physical container. When working within a console, a compartment can act as a filter for the content that is allowed to be viewed.

[0139] According to an embodiment, a compartment can have several layers. For example, lease 405 can be considered as the root compartment holding all cloud resources for the client. Compartments can be organized hierarchically, such as compartment A 460 and compartment B 470 being levels under a lease compartment, while sub-compartment A 465 is defined under compartment A, and sub-compartment B 475 is defined under compartment B. According to an embodiment, each compartment can be associated with one or more compartment policies (not shown).

[0140] According to an embodiment, for example, a compartment defined within a lease can be moved by, for example, redefining the compartment or sub-compartment.

[0141] According to an embodiment, in order to move a compartment, a request with sufficient permissions can be received. That is, a request from a user belonging to a group that, for example, has "manage all resources" permission for the lowest shared parent compartment, for the current compartment and the destination compartment of the moving compartment.

[0142] That is, for example, a request to move sub-compartment A 465 (from 465 to 476) from compartment A 460 to compartment B 470 must be received from a user with sufficient permissions. Because lease 405 is the lowest shared parent compartment between the source compartment (compartment A 460) and the destination compartment (compartment B 470), the request to move sub-compartment A, as shown in the figure, must be received from a user with "Manage All Resources" permission within lease 405.

[0143] According to an embodiment, in another example, if a request to move sub-compartment A 465 from compartment A to compartment B is received from a user who only has the "manage all resources" permission within compartment A, the request may fail because the request from the user cannot manage the resources within the destination compartment (i.e., compartment B).

[0144] According to an embodiment, after a compartment is moved to a new parent compartment, the access policy of the new parent compartment takes effect, and the policy of the previous parent compartment no longer applies. In some cases, when nested compartments are moved using a policy that specifies a hierarchy, the policy can be automatically updated to ensure consistency.

[0145] Therefore, according to the embodiment, the compartment strategy previously applied to compartment A 460 of sub-compartment A will no longer apply to the migration from sub-compartment A to compartment B. Then, the compartment strategy for compartment B will be changed to apply to sub-compartment A. This will be explained further in the description of the following figures.

[0146] Figure 5 A system for policy management and enforcement during compartment migration within a cloud infrastructure environment is illustrated.

[0147] According to the embodiments, and more specifically, Figure 5 The diagram illustrates the compartment hierarchy within which compartments can be moved, and the results for different strategies.

[0148] According to the embodiments, as described above, the upper Figure 1 Instances of the cloud infrastructure environment 500 described herein can be hosted in different regions. Within the cloud infrastructure environment, compartments such as lease 505, compartment A 560, compartment B 565, and compartment D 566 can be defined, and these compartments can span regions. As mentioned above, such compartments can be accessed by customer network 501 via network 502, such as the Internet, through a console, SDK, or API.

[0149] According to an embodiment, the client network 501 may include, for example, a single computer, a client computer network, or other such networks.

[0150] According to embodiments, a compartment can have several layers. For example, lease 505 can be considered the root compartment, which holds all cloud resources for the client. Compartments can be organized hierarchically, such as compartment A 560 being a level under lease. Compartments B 565 and compartment D 566 are then organized as another level under compartment A 560, while sub-compartment C 570 is shown as a level initially located under compartment B. According to embodiments, 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. For example, such policies can 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 each other (i.e., a “stack”), such that a user accessing compartment B 565 will have their interactions with compartment B 565 governed / restricted by compartment B policy 582 in addition to compartment A policy 580.

[0151] According to an embodiment, for example, assume that compartment B policy 582 allows a group (group 1) to manage a series of instances in compartments AB (the compartment hierarchy includes compartment B being a sub-compartment of compartment A).

[0152] According to the embodiment, it is also assumed that compartment D policy 583 allows another group (group 2) to manage the series of instances in compartment AD (the compartment hierarchy includes compartment D being a sub-compartment of compartment A).

[0153] According to an embodiment, after compartment C is moved from compartment B to compartment D, members of group 1 can no longer manage the instance series in compartment C, while members of group 2 can now manage the instance series in compartment C.

[0154] According to an embodiment, in certain situations, some policies can be automatically updated after a compartment is moved. For example, when a policy is attached to a shared ancestor of the current and target parents, the policy that specifies the compartment hierarchy down to the compartment to be moved can be automatically updated.

[0155] Go back to reference Figure 5 For example, according to an embodiment, assume that the compartment A policy allows members of group (group X) to manage buckets in compartments B:C. When compartment C is moved to compartment D, the compartment A policy can be automatically updated to allow members of group X to manage buckets in compartments D:C due to the shared ancestor (compartment A) between compartments B and D.

[0156] According to an embodiment, the strategy attached to the lease can also be automatically updated after the compartment moves within the lease.

[0157] However, according to the embodiments, not all strategies are automatically updated after a compartment movement. For example, see reference... Figure 5In the case where compartment C is moved from compartment B to compartment D. Assume that the compartment B policy allows management of buckets in compartment C (before the move). When compartment C is moved, the compartment B policy is not automatically updated. Instead, the policy becomes invalid and can be removed (e.g., manually or automatically).

[0158] Tag-based resource limits / quotas

[0159] According to the implementation, cloud administrators generally do not have the ability to restrict the use of resources in the existing cloud. Granting users permission to create resources allows them to create any number of resources, up to a predefined account limit. Tag-based resource limits or quotas allow the ability to create or use resources within a compartment to be restricted to an appropriate level, thereby allowing for fine-tuning of cost control.

[0160] According to an embodiment, service level limits (SLAs) defined by the cloud infrastructure environment can be assigned to customers when an account is created. These SLAs limit the total number of resources a customer can create across the entire lease (e.g., across multiple regions with multiple compartments). Lease and compartment administrators can leverage tag-based resource limits or quotas to set resource-specific hard limits. If there were no such compartment limits for a single resource, a user authorized to launch an instance could consume all available capacity across the entire lease. Tag-based resource limits or quotas address this issue and, unlike service limits, are set and customized by the client and customers via, for example, a console, SDK, or API. Tag-based resource limits or quotas can be applied on top of service limits and inherited through nested compartment hierarchies. This allows cloud administrators to limit resource consumption and set boundaries around acceptable resource usage.

[0161] According to embodiments, tag-based resource limits or quotas enable lease and cubicle administrators to better control how resources are consumed in a cloud infrastructure environment, allowing administrators to easily allocate resources to users or user groups via, for example, a console, SDK, or API. Cubicle quotas are a powerful toolset for managing client spending within a lease.

[0162] According to embodiments, when a client has resources spanning multiple compartments (e.g., instances, VCNs, load balancers, and block volumes) in its lease, it can be difficult to track resources for a specific purpose, or to aggregate, report on, or perform batch actions on them. Tagging allows clients to define keys and values ​​and associate them with resources. Tags can be used to help organize and list resources. Generally, there are two types of tags: free-form tags and defined tags, but other types of tags are possible according to the example embodiments.

[0163] According to an 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 be applied to a single resource.

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

[0165] According to an embodiment, to apply defined tags to a resource, a user first selects a tag namespace, then selects a tag key within that namespace, and then assigns a value. Administrators can control which user groups are allowed to use each namespace. According to an example embodiment, tags can be applied to resources when they are created. In another embodiment, tags can be applied to resources after they are provisioned, thereby allowing the use of tags to track the enforcement of resource quotas or limits in the system. According to an embodiment, tags can be used to enable cost governance and / or resource governance. In that manner, tags can be used to track costs.

[0166] Figure 6 Two defined labels according to an embodiment are shown. Two label namespaces are set, namespace 1 600 and namespace 2 620 (e.g., namespace 1 could be "Operations" and namespace 2 could be "HumanResources"). Label keys 605, 610, 625, and 630 are defined in the namespaces. Within each namespace, label keys can be unique, but label key names can be repeated across namespaces. For example, both namespaces can contain a key named "Environment".

[0167] As per implementation examples, many cloud providers offer service limits to prevent capacity shortages. However, often clients also want to set limits to avoid overloading themselves. One such approach is to specify limits at the group level. A group can contain a collection of users, resources, or anything a user wants to specify. Group-level limits are set by the administrator / user of a specific lease / account.

[0168] According to an implementation example, a lease administrator or group administrator can configure limits at the group level to control their cloud costs. This assures the customer / company that a particular group will not exceed the usage limits set by the lease or account administrator, as cloud resources issue usage data that translates into dollar costs associated with the resources(s) created within that group. In this sense, a group can be considered a cost center group because all cloud costs of the resources(s) created by members of that group are allocated to the customer / company as a single, aggregated, one-time charge or aggregated for a single group account, etc.

[0169] However, according to the embodiments, there is a problem because there are very simple mechanisms for allowing administrators to control costs. For example, administrators can include or exclude specific groups in resource overruns, or they can exclude specific users from creating resources by denying access. However, these are coarse-grained mechanisms, and customers generally do not have the ability to specify fine-grained mechanisms that provide them with the flexibility and better control to manage their cloud resources.

[0170] According to embodiments, fine-grained methods can provide tag-based resource constraints, where all resources that can be supplied by one or more members of a specific group are associated with or otherwise provided with a cost center tag representing that group. Cost center tags of this nature provide a mechanism for resource governance, and cloud providers also use them for cost governance. Systems and methods can create a mechanism to control costs at the group level via tags. As an example, users can specify fine-grained rules / policies, such as: Set limits<resource type> to 10 in group A where target.resource.tag = "finance" According to the embodiment, the tag can be associated with a resource, and through the above method, the tag can protect customers from resource overruns at the group level. In the example above, when the tag value is "finance" in group A, user members will not be able to create more than 10 [items / items].<resource type> Example. This approach of limiting costs at the group level provides clients with a fine-grained mechanism for better management of costs and resource usage.

[0171] According to an embodiment, a system provides limits / quotas based on resource request context labels in a cloud infrastructure environment. The system performs a method for limiting or imposing quotas on supplied resources in the cloud infrastructure environment based on request context.

[0172] According to an embodiment, a system provides tag-based resource limits / quotas in a cloud infrastructure environment. The system implements a method for limiting or imposing quotas on supplied resources in a cloud infrastructure environment based on resource tags.

[0173] According to embodiments, in a highly secure environment, customers wish to protect access to resources and their data. As an example, customers protect their resources by classifying them into highly confidential, confidential, restricted, public, etc., and granting users access rights based on clearances that bind them to each classification. Users authorized to access classified resources / data need to be very careful when accessing the data to ensure no information leakage and to avoid unintentional modification of resources across data classifications in a shared context. Embodiments herein provide improved systems and methods for enabling users to restrict access to or modification of resources within the boundaries of a given session / context, even if the user may have higher access rights.

[0174] According to embodiments, cloud architectures can use role-based access control technologies to restrict / allow access to specific security boundaries by slotting users within roles. However, these technologies are coarse-grained. The responsibility lies with users to be diligent and careful about what they are accessing, modifying, or performing.

[0175] According to embodiments, the currently disclosed systems and methods protect users from accessing resources to perform certain operations when they do not intend to. One example is accessing other categories of data when a user can access highly categorized resources. For instance, suppose a user has a script that only needs to access uncategorized resources by filtering out highly categorized resources. Here, the user / script must know which data / resources are categorized and which are not.

[0176] According to an embodiment, another example is when a user is only interested in shutting down non-business-critical infrastructure after a business shutdown, but wants to continue running other business-critical resources. In this case, the user must know exactly which instances to shut down.

[0177] According to embodiments, the systems and methods described herein provide a solution to such problems via tags attached to one or more requests for a resource. Requests from scripts perform actions on behalf of the user, such as closing an instance, reading resource details, updating a resource, accessing a categorized resource, etc. Users send these requests, which have one or more tags attached to the request context. When these requests perform actions on a resource, these tags from the request context can be examined, and access can then be either denied or granted to perform the action the user intends to perform, even if the user initially had access to perform that action. This avoids unintentional access to highly categorized data or resources by performing actions that the user did not intend for a specific resource(s). This can fall under the category of tag-based automation. It can satisfy a wide variety of use cases, not just those related to security.

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

[0179] According to an embodiment, when a user wants to access a resource to perform an operation, the user can typically make a call through a software development kit (SDK) or directly through an API call. The user can pass one or more tags, which are added to the request sent to the resource. When authorizing the user, the resource implementation can check the tags associated with the request; if the tags match the user's tags, the request is allowed; otherwise, the request is rejected / denied.

[0180] Figure 7 An architectural process for enabling a user to launch an instance in a cloud infrastructure environment based on an example embodiment is shown, which enforces quotas or limits on resources based on tags (including, for example, resource tags and / or resource request context tags).

[0181] According to an embodiment, at step 1, user 701 requests to launch an instance in region 700, wherein the request is associated with one or more tags (e.g., free-form tags or defined tags) defined within region 700. In an example embodiment, the tag represents the context of a user's request for a resource.

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

[0183] According to an embodiment, in step 3, the API performs authentication at identity data plane 735.

[0184] According to an embodiment, at step 4, the request to initiate the instance can be forwarded to the Computation Control Plane (CCP) 730. Then, at step 5, the CCP can attach an authentication request at the Identity Data Plane.

[0185] According to an embodiment, at step 6, the computation control plane can extract (or alternatively, perform this extraction at the resource control plane) all tag-based limits / quotas 750 associated with the tag that is part of a request from user 701 from the limit service data plane 740. For example, such tag-based quotas can span the entire rental application and do not necessarily have to be compartment-specific.

[0186] According to an embodiment, at step 7, the computational control plane can perform a check to see if the requested use violates any tag-based limits / quotas in 750. If the requested use does not violate any compartment quotas, the request can be processed, for example, to database 745. If the requested use would violate any tag-based limits / quotas along the compartment tree, the request can be discarded and a message can be sent to notify the user.

[0187] According to an embodiment, tag-based limits / quotas are applied across, for example, the entire lease, including all regions within the lease where the lease is enabled, and the compartments within the lease. When determining whether a requested instance would violate any tag-based limits / quotas, CCP can ensure that a new request (e.g., via a Service Developer Kit (SDK)) does not violate any quotas. If a request exceeds the quota, CCP can cause the request to fail.

[0188] According to an embodiment, the CCP SDK can exist in every control plane of the cloud infrastructure environment.

[0189] According to an embodiment, CCP can work with the Restriction Service Data Plane to check new requests for tag-based restriction / quota checks.

[0190] According to an embodiment, when a client triggers an operation to create a cloud resource, the request is redirected to the resource control plane. The resource control plane queries the restriction service to see if it is safe to start the resource with restrictions configured at the group level. If the restriction server returns a negative / failure response to the resource control plane, the resource is not created.

[0191] Internally, when the limit service receives a request, it checks the tag associated with resource creation and looks in the repository, database, or storage to see the current usage of resources with that specific tag. If the tag value exceeds the limit configured at the group level, it sends a failure / negative response to the resource control plane, causing the resource creation to fail.

[0192] Labels for resource limits / quotas

[0193] Figure 8 A system is shown that uses request context tags and / or resource tags to restrict usage such as the provisioning of resources in a cloud infrastructure environment.

[0194] According to an embodiment, client device 810 can submit a request 811 to a cloud infrastructure environment, wherein the request is associated with a label 812 (such as a label representing, for example, the context of the request). The client device can submit the request to cloud infrastructure environment 800 (running on device hardware 801) via one of an interface such as console 802, API 804, or SDK 806.

[0195] According to an embodiment, a request can be forwarded to resource 840, which may include multiple layers (as described above), such as a computing resource layer 850 including tagged resources 851-854, a network resource layer 860 including tagged resources 861-864, and a storage resource layer 870 including tagged resources 871-874.

[0196] According to an embodiment, when a client device enjoys high security / priority privileges (e.g., fraud protection or intelligence), the client device can utilize a wide range of tags for requests. As an example, tags associated with a request can be used to help users avoid accidentally accessing protected resources. For instance, suppose certain computing resources can be turned off after 6 PM each day to save costs. These computing resources have low-security tags. However, there are other computing resources in the same system that cannot be turned off (they must run 24 / 7). These computing resources have high-security tags. To turn off the low-privilege computing resources, the user would have to go to each resource and only select those to turn off without a tagged request, or write a script to do so to avoid turning off the high-privilege resources that need to run 24 / 7. This is difficult to maintain because computing resources can be added and removed daily.

[0197] According to an embodiment, the user can then alternatively provide a tagged request to shut down low-privileged resources. That is, the tag associated with the request will share a low-security tag with computing resources that can be shut down at 6 PM. The tagged resource can then access all resources in the network, but it will bypass highly protected resources without the tag the request has. In this way, a tagged request to shut down computing resources only shuts down those computing resources whose low-security tags match, and the request bypasses highly secure tagged computing resources.

[0198] According to an embodiment, as another example, suppose client device 810 wants to attach a highly secure compute instance to a block volume. In this case, the request to attach the highly secure compute instance can be tagged with a highly secure label. By doing so, it is ensured that the highly secure compute instance will not be attached to a block volume with a lower security label; instead, a request can be made to attach only 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 instance to a low-security block volume (the label check will fail).

[0199] Limits / quotas based on request context tags

[0200] Figure 9This is a functional diagram of a system 900 that provides resource request tag-based limits / quotas in a cloud infrastructure environment according to an embodiment. Generally, client device 810 ( Figure 8 A resource request 911 can be submitted to the cloud infrastructure environment to provide new resources from a plurality of tagged resources 940. The plurality of tagged resources 940 can be any of, for example, tagged compute resources 851-854 of compute resource layer 850, tagged network resources 861-864 of network resource layer 860, and / or tagged storage resources 871-874 of storage resource layer 870.

[0201] According to the example embodiments, resources are items supplied in a cloud infrastructure environment and can be of various types, including, for example, compute resource types, storage service resource types, VCN service types, IP address service types, DNS service types, DDoS protection service types, and email delivery service types, etc. The example embodiments herein are not limited to these specific resource types and may also include other types, further examples of which are illustrated below by way of example.

[0202]

[0203] According to the example embodiment, the supplied resources and services are tagged. In the example embodiment, requests for resources and resources are associated with one or more tags. Furthermore, resources can be grouped based on their tag values. Essentially, in the example embodiment, the resource tag associated with each supplied resource is a key-value pair that can be attached to or otherwise associated with the supplied resource in the cloud infrastructure environment. Tag key-value pairs can be used for a variety of purposes, including, for example, various accounting purposes. In the example, the resource key-value pair tags associated with the supplied resources are used to group resources, where the grouping provided by the resource tags enables cost governance and / or resource governance of everything of value in the cloud infrastructure environment.

[0204] Resources provisioned in a cloud infrastructure environment can be grouped into containers 942, 944, and 946 based on tag values ​​assigned to each resource or other criteria that may be necessary or desired. As an example, the first container 942 can store resources already provisioned in the cloud and connected to client user 701 (…). Figure 7 The second container 944 can hold computing resources already provided in the cloud and associated with the operation group of client user 701, and the third container 946 can hold computing resources already provided in the cloud and associated with the human resources group of client user 701. The example embodiments herein are not limited to these groups and other groups may also be used, wherein further example groups are illustrated below by way of example.

[0205]

[0206] As shown in the example, resource instances are logically deployed across different containers 942, 944, and 946, providing separate cost centers. Each cost center is assigned a tag value, which can be charged to end users for access to various cost centers. The cost center tags are used for cost governance and accounting. Some customers can model multiple cost centers within their final group price. Each cost center can have a separate tag, and the cloud can assign a limited set of resources to each tag.

[0207] In an example embodiment, one or more strategies 920 provide a mechanism for end users to protect themselves from accessing more resources than permitted by the standard access contract, where excessive access to resources would occur under the standard contract terms. For example, a client could send a request for resources that activates the supply of multiple computing resources (such as, for example, 100 computing resources) via a resource control plane 930, where the contract terms only allow the supply of 90 computing resources at the standard rate, and any excess (10 in the example) would incur additional charges for the client end user.

[0208] As described above and according to embodiments, fine-grained methods can provide resource limits based on tags. Tags are a mechanism primarily used for resource governance, and cloud providers also use them for cost governance. Systems and methods can create mechanisms for controlling costs at the group level through tags. As an example, users can specify fine-grained rules / policies, such as: Set limits<resource type> to 10 in group A where target.resource.tag = "finance" According to embodiments, tags can be associated with resources and requests for resources, or both, and using the methods described above, tags can protect clients from resource overruns at one or more selected levels (such as, for example, at the group level). In the example above, when the tag value in group A is "finance," the user will not be able to create more than 10 [resources / resources].<resource type> This is an example. This approach of limiting costs at the group level provides clients with a fine-grained mechanism for better management of costs and resource usage.

[0209] According to the example embodiment, the first strategy 922 protects the client from resource overruns of the group in the first container 942 at the group level. Similarly, the second strategy 924 protects the client from resource overruns of the group in the second container 944 at the group level, and the third strategy 926 protects the client from resource overruns of the group in the third container 946 at the group level.

[0210] According to the example, each of resource requests 911a-911d includes fields containing data representing the type of the requested resource instance, data representing the group of the requested resource instance, and data representing the context tag of the resource request. Specifically, each of resource requests 911a-911d includes resource type fields 912a-912d, which contain data representing the type of the requested resource instance. Furthermore, each of resource requests 911a-911d includes resource group fields 913a-913d, which represent the group of the requested resource instance. Additionally, each of resource requests 911a-911d includes request context tag fields 914a-914d, which contain request context data representing the context tag of the resource request.

[0211] Based on the example, the control plane can be calculated from the restricted service data plane 740 ( Figure 7 Extract (or alternatively, extract at resource control plane 930) all tag-based limits / quotas 950 associated with the tag as part of a request from user 701. Such tag-based quotas can be applied across, for example, the entire lease and are not necessarily compartment-specific.

[0212] According to an embodiment, the computational control plane can perform checks to see if the requested use would violate any tag-based limits / quotas 950 of any quota or restriction rules in the memory device 941. If the requested use does not violate any compartment quotas, the request can be processed, for example, to a database. If the requested use would violate any tag-based limits / quotas along the compartment tree, the request can be discarded and a message can be sent to notify the user.

[0213] According to the example embodiment, tag-based limits / quotas are applied to compartments within a lease. According to the example embodiment described below, tag-based limits / quotas are applied across, for example, the entire lease (including all areas where the lease is enabled, essentially spanning multiple compartments). When determining whether a requested instance would violate any tag-based limits / quotas, the compute control plane can ensure that new requests (e.g., via a service developer kit (SDK)) do not violate any quotas. If a request exceeds a quota, the compute control plane can cause the request to fail.

[0214] According to one embodiment, the SDK for the compute control plane can exist in each control plane of the cloud infrastructure environment. According to another embodiment, the compute control plane can work in conjunction with the limiting service data plane to check new requests against label-based limits / quotas.

[0215] According to an embodiment, the tag can be associated with a resource and a request for the resource, or both, and using this method, the tag can protect the resource from unintentional access and also protect the client user from unintentional resource over-limitation.

[0216] In this regard, request context label fields 914a-914d are used to provide system 900 for controlling the disposal of resources 940 in an associated cloud infrastructure environment. The system may include one or more computers, each including one or more microprocessors that define leases in the associated cloud infrastructure environment. In an example embodiment, a memory device 941 operatively coupled to the computer stores computer-executable logic for providing control over the disposal of resources in the lease. The memory device may also store access control data representing multiple required credential gate levels for allowing the disposal of resources in the lease. A resource request 911a-911d for disposing of a first resource in the lease may be received, wherein the resource request 911a-911d includes request context label fields 914a-914d representing request context information of the request. A first privilege level classification associated with the requested first resource is determined, and the request context information of the request is compared with a first required credential gate level from a plurality of required credential gate levels for allowing the disposal of resources in leases with the first privilege level classification. According to an example embodiment, the request to dispose of the first resource is selectively authorized based on a match between the request context information and the first required credential gate level.

[0217] A request to dispose of a first resource may include a request to supply the first resource in a lease. According to an example embodiment, the first resource is selectively supplied in a lease based on a first required credential gate level matched with request context information.

[0218] According to an example embodiment, a request to supply a first resource in a lease may include a request from a system user to supply a bare-metal computing instance in a lease to provide control to a user of one or more physical hosts within a computing resource tier in an associated cloud infrastructure environment. In this example, the request context label data includes user context label data representing user identification information of the user. Access control data stored in a storage device includes user access control data representing multiple user-required credential gate levels for allowing disposal of resources in the lease, wherein the user's user identification information is compared with a first user-required credential gate level among the multiple user-required credential gate levels for allowing disposal of resources in the lease with a first privilege classification. In this example, the bare-metal computing instance is selectively supplied to the user in the lease based on a match between the user's user identification information and the first user-required credential gate level.

[0219] According to an example embodiment, a request to supply a first resource in a lease may include a request to supply multiple resources in the lease that have a first privilege level classification. In this case, multiple resources in the lease are selectively supplied based on a match between request context information and a first required credential gate level.

[0220] According to an example embodiment, the request context label data may include user context label data representing user identification information, and the request to dispose of a first resource may include a request to dispose of all resources supplied in a lease and associated with a second privilege level classification. System 900 operates to compare the user identification information of the request with a second required credential gate level from a plurality of required credential gate levels for allowing disposal of resources in a lease with a second privilege level classification. System 900 selectively authorizes the request to dispose of all resources supplied in a lease associated with a second privilege level classification based on the matching of the user identification information with the second required credential gate level.

[0221] According to an example embodiment, a lease may include multiple compartments storing resources associated with a second privilege level classification, wherein each of the multiple compartments provides isolation of the set of resources associated with the second privilege level classification within that compartment relative to one or more other sets of resources associated with the second privilege level classification in other compartments. System 900 selectively authorizes requests to process all resources supplied in the lease associated with the second privilege level classification based on user identification information matching a second required credential gate level and across the multiple compartments.

[0222] The request context data received by the system for disposing of the first resource in the lease may include one or more of the following: resource type data 912a-912d representing the type of the resource instance being requested, and / or resource group fields 913a-913d representing the group of resource instances being requested.

[0223] According to an embodiment, when a client triggers an operation to create a cloud resource, the request is redirected to the resource control plane. The resource control plane queries the restriction service whether the resource can be safely started, taking into account the restrictions configured at the group level. If the restriction server returns a negative / failure response to the resource control plane, the resource is not created.

[0224] Internally, when the limit service receives a request, it checks the tag associated with resource creation and looks in the repository, database, or storage to see the current usage of resources with that specific tag. If the tag value exceeds the limit configured at the group level, it sends a failure / negation response to the resource control plane, causing resource creation to fail.

[0225] For the purpose of describing the functionality of the example embodiments only and not for the purpose of limiting them, for resources grouped in the first container 942, the first policy 922 can protect customers from resource overruns at the Finance group level according to fine-grained rules / policies such as the following: Set limits <compute> to 10 in Container #1(642]where< / compute> target.resource.tag = "Finance" In the specific example above, a user will not be able to create more than 10 instances of computing resources in financial container 942. In this way, resource request 911d for supplying resources in container 942 will be processed by policy 922 to determine whether the request can be executed or otherwise executed without causing any overspending.

[0226] Similarly, for resources grouped in the second container 644, the second policy 924 can protect clients from resource overruns at the operation group level according to fine-grained rules / policies such as: Set limits<db storage> to 100 in Container #2(644]where target.resource.tag = "Operations" In the example above, a user will not be able to create more than 100 instances of storage resources in operating container 644. In this way, resource request 911c for supplying resources in container 944 will be processed by policy 924 to determine whether the request can be executed or otherwise executed without causing any overspending.

[0227] Similarly, for resources grouped within the third container 946, the third policy 926 can protect clients from resource overruns at the HR group level based on fine-grained rules / policies such as: Set limits <compute> to 10 and<db storage> to 100 in Container #3< / compute> (646]where target.resource.tag = "Human Resources" In the example above, a user will not be able to create more than 10 compute resource instances or more than 100 storage resource instances in the human resources container 946. In this way, resource requests 911a and 911b for provisioning resources in container 946 will be processed by policy 926 to determine whether the request can be executed or otherwise executed without causing any overspending.

[0228] Figure 10 This is a flowchart illustrating a method 1000 for limiting or imposing quotas on disposal resources (such as provisioned resources) in a cloud infrastructure environment based on a request context, according to an example embodiment. Referring now to this figure, in step 1010, a request to provision resources in the cloud infrastructure environment is received. This request may, for example, be the resource request 911a described above. The request may include, for example, a request context label field 914a representing request context information.

[0229] At step 1020, resource request 911a is examined and the context of the request for the requested resource is determined. The determined resource type may be, for example, a request to provide a computing resource type or a request to provide a storage resource type.

[0230] At step 1030, a privilege level classification associated with the requested resource is determined. According to an example embodiment, the resource may be stored associated with a tag reflecting the privilege level required to access that resource. The privilege level may be stored in one or more privilege level tags or stored as one or more privilege level tags, such as… Figure 8 in 851-854, 861-864, 871-874 and Figure 1 As shown at 140a, 16a, and 170a. For example, the identified resource group could be, for instance, a request for resources whose supply is grouped into a human resources group.

[0231] Based on the determined group of requests, resource request 911a can be assigned to a specific container at step 1040. In this example, resource request 911a may be assigned, for example, to a third container 946. A policy corresponding to the assigned compartment can be selectively applied to the resource request. In the illustrated example, a third policy 926 can be selectively applied to resource request 911a. If it is determined in step 1040 that supplying additional resources based on the content of resource request 911a will not exceed the limits and / or quotas specified in the policy 926 assigned to the compartment, then the instance requested in resource request 911a can be created in the compartment.

[0232] In step 1050, the request context information of resource request 911a is compared with a first required credential gate level among a plurality of required credential gate levels for allowing disposal of resources in a lease with a first privilege level classification.

[0233] If it is determined in step 1060 that the request context information matches the first required credential gate level, then in step 1070, the request for the first resource is authorized to be processed, and the resource can be processed, such as creating an instance of the requested resource, supplying the requested resource, terminating or otherwise canceling the supply of the requested resource, etc.

[0234] If it is determined in step 1060 that the request context information does not match the first required credential gate level, then in step 1080 the request to dispose of the first resource is discarded.

[0235] Resource tag-based restrictions / quotas

[0236] Figure 11 This is a functional diagram of a system 1100 that provides tag-based resource limits / quotas in a cloud infrastructure environment according to an embodiment.

[0237] Generally speaking, client devices 810 ( Figure 8 A resource request 1111 can be submitted to the cloud infrastructure environment to supply new resources among multiple tagged resources 1140. The multiple tagged resources 1140 can be any of, for example, tagged computing resources 851-854 of the computing resource layer 850, tagged network resources 861-864 of the network resource layer 860, and / or tagged storage resources 871-874 of the storage resource layer 870.

[0238] According to the example embodiment, the supplied resources and services are tagged. In the example embodiment, resources are associated with one or more tags. Furthermore, resources can be grouped based on their tag values. Essentially, in the example embodiment, the resource tag associated with each supplied resource is a key-value pair that can be attached to or otherwise associated with the supplied resource in the cloud infrastructure environment. Tag key-value pairs can be used for a variety of purposes, including, for example, various accounting purposes. In the example, the resource key-value pair tags associated with the supplied resources are used to group resources, where the grouping provided by the resource tags enables cost governance and / or resource governance of everything of value in the cloud infrastructure environment.

[0239] Resources supplied in a cloud infrastructure environment can be grouped into containers 1142, 1144, and 1146 based on the tag values ​​assigned to each resource.

[0240] As shown in the example, resource instances are logically deployed across different containers 1142, 1144, and 1146, providing separate cost centers. Each cost center is assigned a tag value, which can be charged to end users for access to various cost centers. The cost center tags are used for cost governance and accounting. Some customers can model multiple cost centers within their final group price. Each cost center can have a separate tag, and the cloud can assign a limited set of resources to each tag.

[0241] In an example embodiment, one or more strategies 1120 provide a mechanism for end users to protect themselves from accessing more resources than permitted by the standard access contract, where excessive access to resources would occur under the standard contract terms. For example, a client could send a request for resources that activates the supply of multiple computing resources (such as, for example, 100 computing resources) via the resource control plane 1130, where the contract terms only allow the supply of 90 computing resources at the standard rate, and any excess (10 in the example) would incur additional charges for the client end user.

[0242] As described above and according to embodiments, fine-grained methods can provide resource constraints based on tags, and particularly on tags associated with resources. The provision of resource-associated tags can be achieved through resource governance 110 (…). Figure 1 The mechanisms used in [the context of cost governance], and cloud providers can also use them for cost governance. Systems and methods can create mechanisms to control costs at levels including the group level via tags. As an example, users can specify fine-grained rules / policies, such as: Set limits<resource type> to 10 in group A where target.resource.tag = "finance" According to the embodiment, the tag can be associated with resources, and using the above method, the tag can protect customers from resource overruns at one or more selected levels (such as, for example, at the group level). In the example above, when the tag value in group A is "finance", the user will not be able to create more than 10 [items / items].<resource type> This is an example. This approach of limiting costs at the group level provides clients with a fine-grained mechanism for better management of costs and resource usage.

[0243] According to an example embodiment, first strategy 1120a protects customers from excess resources associated with a first tag and grouped in any of containers 1142, 1144, and 1146. Similarly, second strategy 1120b protects customers from excess resources associated with a second tag and grouped in any of containers 1142, 1144, and 1146. Likewise, third strategy 1120c and fourth strategy 1120d protect customers from excess resources associated with third and fourth tags and grouped in any of containers 1142, 1144, and 1146.

[0244] According to the example, each of resource requests 1111a-1111d includes fields containing data representing the type of the requested resource instance, data representing the group of the requested resource instance, and data representing the context tag of the resource request. Specifically, each of resource requests 1111a-1111d includes resource type fields 1112a-1112d, which contain data representing the type of the requested resource instance. Furthermore, each of resource requests 1111a-1111d includes resource group fields 1113a-1113d, which represent the group of the requested resource instance. Additionally, each of resource requests 1111a-1111d includes request context fields 1114a-1114d, which contain request context data representing the context tag of the resource request. Furthermore, each of resource requests 1111a-1111d includes request characteristic fields 1115a-1115d, which contain request characteristic data representing the characteristic tag of the resource request. For ease of discussion, request characteristic fields 1115a-1115d are shown and described separately; however, it should be understood that request characteristics can be derived from resource type information, resource group information, or any other information that forms the resource request.

[0245] Based on the example, the control plane can be calculated from the restricted service data plane 740 ( Figure 7 Extract (or alternatively, extract at resource control plane 1130) all tag-based quotas and / or limits 1150 associated with the tag as part of a request from user 701. Such tag-based quotas can span, for example, the entire rental application and are not necessarily compartment-specific.

[0246] According to an embodiment, the computational control plane can check whether the requested use violates any tag-based limits / quotas of any quota or restriction rules in the memory device 1141. If the requested use does not violate any resource tag-based quotas, the request can be processed, for example, to a database. If the requested use would violate any resource tag-based limits / quotas along the cubicle tree, the request can be discarded and a message can be sent to notify the user.

[0247] According to the example embodiment, resource tag-based limits / quotas are applied to compartments within a lease. According to the example embodiment described below, resource tag-based limits / quotas are applied across, for example, the entire lease (including all areas where the lease is enabled, essentially spanning multiple compartments). When determining whether a requested instance would violate any resource tag-based limits / quotas, the compute control plane can ensure that new requests (e.g., via a service developer kit (SDK)) do not violate any quotas. If a request exceeds a quota, the compute control plane can cause the request to fail.

[0248] According to one embodiment, the compute control plane SDK can exist in each control plane of the cloud infrastructure environment. According to another embodiment, the compute control plane can work in conjunction with the restricted service data plane to check new requests against resource tag-based limits / quotas.

[0249] According to an embodiment, when a client triggers an operation to create a cloud resource, the request is forwarded to the resource control plane. Taking into account the restrictions configured at the selected level (such as, for example, the group level), the resource control plane queries the restriction service whether it is safe to start the resource. If the restriction server returns a negative / failure response to the resource control plane, the resource is not created, and the request is discarded.

[0250] Internally, when the restriction service receives a request, it checks the tag associated with resource creation and looks in a repository, database, or storage to see the current usage of resources with that specific tag. A resource can be associated with more than one tag, and a resource can be associated with multiple different tags. If the tag value exceeds the limit configured at the selected level (such as, for example, at the group level), it sends a failure / negation response to the resource control plane, causing resource creation to fail.

[0251] According to an embodiment, memory device 1141 stores tag-based quotas and / or limits 1150, which represent lease 305 ( Figure 3 Multiple tag-based quotas for resource supply in the lease. Resource requests 1111a-1111d for supplying resources in the lease are received. Resource requests 1111a-1111d may include request characteristic fields 1115a-1115d representing the request characteristics. According to an embodiment, resource tags 150a, 160a, and 170a corresponding to the request characteristics are determined. Figure 1 The system analyzes the usage of resources in the associated leases and compares it with multiple tag-based quotas and / or limits. If the determined usage exceeds one of the multiple tag-based quotas, the request to supply resources is discarded.

[0252] According to an example embodiment, lease 305 includes multiple compartments for storing resources, wherein each of the multiple compartments provides isolation of the resource set within that compartment relative to one or more other sets of resources within other compartments. The usage of resources in the lease, associated with resource tags corresponding to the requested characteristics, is determined collectively across the multiple compartments, and the usage determined collectively across the multiple compartments is compared with multiple tag-based quotas of the lease. Resource requests 1111a-1111d for supplying resources are discarded based on the usage determined collectively across the multiple compartments exceeding one of the multiple tag-based quotas.

[0253] According to an example embodiment, the tag-based quotas and / or limits 1150 stored in memory device 1141 represent multiple tag-based quotas for resource supply in leases of corresponding multiple resource types. Furthermore, the request characteristic fields 1115a-1115d of resource requests 1111a-1111d for supplying resources in a lease include resource type data representing resource type fields 1112a-1112d of the requested resource. In an example embodiment, the usage of resources in a lease associated with a resource tag corresponding to the first resource type field 1112a is determined and compared with a first tag-based quota for resource supply in a lease of the first resource type. A resource request 1111a for supplying resources with the first resource type field 1112a is discarded based on the determined usage of resources associated with the resource tag corresponding to the first resource type exceeding the first tag-based quota stored, for example, as a first strategy 1120a for resource supply in a lease of the first resource type.

[0254] According to an example of an embodiment, tag-based quotas and / or limits 1150 stored in memory device 1141 represent multiple tag-based quotas for resource supply in leases corresponding to multiple user groups. Request feature fields 1115a-1115d of resource requests 1111a-1111d for supplying resources in a lease include user group data, representing the user group category of the user assigned to the system requesting the resource. The usage of resources in a lease associated with a resource tag corresponding to the user group category is determined and compared with a first tag-based quota for resource supply in leases allocated to the user group category. Requests to supply resources are discarded based on the determined usage of resources in a lease associated with a resource tag corresponding to the user group category exceeding the first tag-based quota for resource supply in leases allocated to the user group category.

[0255] According to an example of an embodiment, tag-based quota data stored in a memory device represents tag-based quotas for resource supply in leases allocated to multiple resource types across multiple user groups. Request characteristic data for a request to supply resources in a lease 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 the system requesting the resource. In this example, the usage of resources in a lease associated with a resource tag corresponding to a first resource type supplied to a first user group category is determined and compared to a first tag-based quota for resource supply in a lease allocated to the first resource type of the first user group category. Furthermore, a request to supply resources is discarded based on the determined usage of resources in a lease associated with a resource tag corresponding to a first resource type supplied to a first user group category exceeding the first tag-based quota for resource supply in a lease allocated to the first resource type of the first user group category.

[0256] According to an example of an embodiment, tag-based quotas and / or limits 1150 stored in memory device 1141 represent tag-based quotas of resource supply in leases allocated to multiple resource types across multiple user groups. A first request to track resource usage in a lease can be received from user 701, wherein the first request includes request feature fields 1115a-1115d representing a first user group category and a first resource type.

[0257] Determine the first usage of resources in a lease associated with a resource tag corresponding to a first resource type supplied by a first user group category, and generate resource usage tracking data based on the determined first usage of resources in a lease for the first resource type supplied by the first user group.

[0258] According to an example of an embodiment, a request to supply resources is dropped based on determined usage exceeding one of a plurality of tag-based quotas. However, a request to supply leased resources can be received from user 701. According to an example of an embodiment, resources are selectively supplied based on the system receiving the coverage request. Furthermore, resource usage excess data is generated based on resources selectively supplied in response to the system receiving the coverage request.

[0259] Figure 12 This is a flowchart illustrating a method 1200 for limiting or imposing quotas on supplied resources in a cloud infrastructure environment based on resource tags, according to an example embodiment.

[0260] According to method 1200, in step 1210, a lease is provided and tag-based limit / quota data is stored in memory. In its preferred form, the lease is provided by a computer comprising one or more processors and memory devices operatively coupled to a computer in an associated cloud infrastructure environment. The memory device stores tag-based control logic executable by the computer to provide tag-based control over resource usage in the associated cloud infrastructure environment. In an example embodiment, the tag-based quota data stored in the memory device represents multiple tag-based quotas for resource provisioning in the lease.

[0261] A request to supply resources in a lease is received at step 1220. This request includes request characteristic data representing the characteristics of the request.

[0262] In step 1230, the resource type of the requested resource is determined.

[0263] In step 1240, the usage of resources in the lease associated with the resource tag corresponding to the requested characteristics is determined by one or more processors executing tag-based control logic.

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

[0265] One or more processors that execute tag-based control logic determine the usage of resources associated with tags and compare the determined usage with multiple tag-based quotas at step 1260.

[0266] In step 1290, a resource request is discarded by one or more processors executing tag-based control logic based on a determination at step 1270 that the usage exceeds one of a plurality of tag-based quotas and the request to supply resources is rejected.

[0267] An instance of the requested resource is created in step 1280 by one or more processors executing tag-based control logic based on a request to supply resources, which is determined at step 1270 to have usage not exceeding one of a plurality of tag-based quotas.

[0268] According to an example embodiment, leasing is provided by offering multiple compartments of storage resources, wherein each of the multiple compartments provides isolation of its resource set relative to one or more other sets of resources in other compartments. Furthermore, determining usage includes jointly determining, across the multiple compartments, the usage of resources in the lease associated with resource tags corresponding to the requested characteristics, and comparison includes comparing the jointly determined usage across the multiple compartments with multiple tag-based quotas for the lease. Additionally, discarding a request includes discarding the request to supply resources based on the jointly determined usage across the multiple compartments exceeding one of multiple tag-based quotas.

[0269] According to an example embodiment, storing tag-based quota data includes storing tag-based quota data in a memory device that represents multiple tag-based quotas of resource supply in leases corresponding to multiple resource types. Furthermore, receiving a request includes receiving a request including resource type data representing a first resource type of the requested resource, and determining includes determining the usage of resources in a lease associated with a resource tag corresponding to the first resource type. Furthermore, comparing includes comparing the determined usage with a first tag-based quota of resource supply in a lease of the first resource type, and discarding a request includes discarding the request based on the determined usage of resources in a lease associated with a resource tag corresponding to the first resource type exceeding the first tag-based quota of resource supply in a lease of the first resource type.

[0270] According to an example of an embodiment, storing tag-based quota data includes storing tag-based quota data in a memory device that represents multiple tag-based quotas allocated to a plurality of user groups in a lease, and receiving a request includes receiving a request including resource type data representing user group categories of users assigned to the system requesting resources. Furthermore, determining includes determining the usage of resources in a lease associated with resource tags corresponding to user group categories, and comparing includes comparing the determined usage with a first tag-based quota allocated to the user group category in a lease. Additionally, discarding a request includes discarding the request based on the determined usage of resources in a lease associated with resource tags corresponding to user group categories exceeding the first tag-based quota allocated to the user group category in a lease.

[0271] According to an example of an embodiment, storing tag-based quota data includes storing tag-based quota data in a memory device that represents tag-based quotas of resource supply in leases allocated to multiple resource types of multiple user groups in leases, and receiving a request includes receiving a request including resource type data, which includes: i) resource type data representing a first resource type of the requested resource; and ii) user group data representing a user group category of the user assigned to the system requesting the resource. Furthermore, determining includes determining the usage of resources in a lease associated with a resource tag corresponding to a first resource type supplied to a first user group category, and comparing includes comparing the determined usage with a first tag-based quota of resource supply in leases allocated to the first resource type of the first user group category. Furthermore, discarding a request includes discarding the request based on the determined usage of resources in a lease associated with the resource tag corresponding to the first resource type supplied to the first user group category exceeding the first tag-based quota of resource supply in leases allocated to the first resource type of the first user group category.

[0272] According to an example embodiment, tag-based quota data representing tag-based quotas of resource supply in leases allocated to multiple resource types for multiple user groups is stored in a memory device. The method further includes receiving a first request to track resource usage in leases, wherein the first request includes request characteristic data representing a first user group category and a first resource type. Furthermore, a first usage of resources in a lease associated with a resource tag corresponding to a first resource type supplied by the first user group category is determined, and resource usage tracking data is generated based on the determined first usage of resources in a lease for the first resource type supplied by the first user group.

[0273] The method also includes receiving a coverage request for the supply of leased resources, selectively supplying resources based on the system receiving the coverage request, and generating resource usage excess data based on the selective supply of resources in response to the system receiving the coverage request.

[0274] According to various embodiments, the teachings herein can be readily implemented using one or more conventional general-purpose or special-purpose computers, computing devices, machines, or microprocessors, including one or more processors, memories, and / or programmable computer-readable storage media according to the teachings of this disclosure. Skilled programmers can readily prepare appropriate software code based on the teachings of this disclosure, as will be apparent to those skilled in the art of software.

[0275] In some embodiments, the teachings herein may include a computer program product that may use a computer-readable medium (or multiple media) to transmit (e.g., store or carry) instructions for one or more programmable processors or computers to perform any process of the teachings. An example of a computer-readable medium is a non-transitory computer-readable storage medium (multiple media) having instructions stored thereon / therein, which can be used to program a computer to perform any process of the teachings. Examples of such storage media may include, but are not limited to, hard disk drives, hard disk 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 cards or optical cards, nanosystems, or other types of storage media or devices suitable for the non-transitory storage of instructions and / or data. Another example of a computer-readable medium is a transient medium for transmitting 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.

[0276] Therefore, from one perspective, systems and methods for supporting tag-based resource limits or quotas in cloud infrastructure environments have been described. Cloud administrators generally lack the ability to limit resource usage in the existing cloud. Granting users permission to create resources allows them to create any number of resources, up to a predefined account limit. Tags are associated with resources, thereby allowing administrators to limit users' resource usage to appropriate levels by allowing fine-tuning cost controls. The usage of resources in a lease is determined by identifying resource tags associated with the characteristics of the resource provisioning request and comparing them to multiple tag-based quotas, where a resource provisioning request is dropped based on the determined usage exceeding one of the multiple tag-based quotas.

[0277] The foregoing description is provided for illustrative purposes only. It is not intended to be exhaustive or to limit the scope of protection to the precise forms disclosed. Many modifications and variations will be apparent to those skilled in the art. For example, while several of the examples provided herein illustrate use with enterprise software application components (such as Oracle FusionApplications); cloud environments (such as Oracle Cloud Infrastructure); and cloud services (such as Oracle FusionAnalytics), the systems and methods described herein can be used with other types of enterprise software applications, cloud environments, cloud services, cloud computing, or other computing environments, according to various embodiments.

[0278] The embodiments were chosen and described in order to best explain the principles of this teaching and its practical application, thereby enabling others skilled in the art to understand the various embodiments and modifications suitable for the particular intended use. The scope is intended to be defined by the following claims and their equivalents.

Claims

1. A tag-based control system for resource usage in an associated cloud infrastructure environment, the system comprising: A computer, including one or more microprocessors; Leasing, defined within the associated cloud infrastructure environment; as well as A memory device, operatively coupled to a computer, stores computer-executable logic for providing tag-based control over resource usage in a lease. The memory stores tag-based quota data representing multiple usage quotas for resource supply to a leasing user. The leased resources are provided in multiple compartments, each compartment providing isolation of its resource set relative to one or more other isolated resource sets in other compartments. The system receives a request from a leasing user for the supply of a first resource in the lease. This request includes request characteristic data representing the resource type of the requested first resource and the user group category assigned to the user requesting the first resource. This involves determining the usage of resource sets that span multiple compartments within a lease and are associated with resource tags, where the resource tags correspond to the resource types of the requested characteristic data. The usage of the identified isolated resource set is compared with the group usage quotas assigned to the user requesting the first resource from multiple usage quotas. In this case, requests for the supply of the first resource received from the leased user are discarded if the usage of the determined isolated resource set exceeds the group usage quota.

2. The system according to claim 1, wherein: The usage of resources in a lease is determined across the multiple compartments and associated with resource tags corresponding to the request characteristics of the request, and the usage determined across the multiple compartments is compared with the multiple usage quotas of the lease. as well as The request to supply the first resource is discarded if the usage situation determined across the multiple compartments exceeds one of the multiple usage situation quotas.

3. The system according to claim 1 or 2, wherein: Tag-based quota data stored in a storage device represents multiple usage quotas for resource supply in leases of corresponding resource types; The request characteristic data for a request to supply the first resource in a lease includes resource type data representing the first resource type of the requested resource; Determine the usage of resources in leases associated with resource tags corresponding to the first resource type, and compare it with a first tag-based quota of resource supply in leases of the first resource type; as well as The request to supply the first resource of the first resource type is discarded if the usage of the resource in the lease associated with the resource tag corresponding to the first resource type exceeds the first tag-based quota for the supply of resources in the lease of the first resource type.

4. The system according to claim 1 or 2, wherein: Tag-based quota data stored in a storage device represents multiple usage quotas of resource supply allocated to corresponding user groups in a lease; The request characteristics data for the supply of the primary resource in a lease include user group data representing user group categories that represent the users assigned to the system requesting the resource; Determine the usage of resources in leases associated with resource tags corresponding to user group categories, and compare it with a first tag-based quota of resource supply in leases allocated to user group categories; as well as The request to supply the first resource is discarded if the usage of resources in a lease associated with the resource tag corresponding to the user group category exceeds the first tag-based quota of resources supplied in the lease allocated to the user group category.

5. The system according to claim 1 or 2, wherein: Tag-based quota data stored in a storage device represents tag-based quotas for resource supply in leases allocated to multiple resource types across multiple user groups in a lease; The request characteristics data for supplying the primary resource in a lease include: i) Resource type data representing the first resource type of the requested resource; and ii) User group data representing the user group categories assigned to the system that requested the first resource; Determine the usage of resources in leases associated with resource tags corresponding to the first resource type supplied to the first user group category, and compare it with a first tag-based quota of resources supplied in leases to the first resource type allocated to the first user group category; and The request to supply the first resource is discarded if the usage of the resource in the lease associated with the resource tag corresponding to the first resource type supplied to the first user group category exceeds the first tag-based quota of resource supply allocated to the first resource type in the lease for the first user group category.

6. The system according to claim 1 or 2, wherein: Tag-based quota data stored in a storage device represents tag-based quotas for resource supply in leases allocated to multiple resource types across multiple user groups in a lease; Receive a first request to track the usage of leased resources, the first request including request characteristic data representing a first user group category and a first resource type; Determine the first usage of the resource in the lease associated with the resource tag corresponding to the first resource type supplied by the first user group category; as well as Resource usage tracking data is generated based on the first usage of resources in the lease of the first resource type supplied by the first user group.

7. The system according to claim 1 or 2, wherein: The request to supply the first resource is discarded based on the determined usage exceeding one of the multiple usage quotas; Receive the first resource coverage request for supply leasing; The system selectively supplies the first resource based on the coverage request received. as well as Resource usage excess data is generated based on the selective provision of the first resource in response to a system receiving an overlay request.

8. A method for tag-based control of resource usage in an associated cloud infrastructure environment, the method comprising: A computer is provided for lease in an associated cloud infrastructure environment, the computer including one or more processors and memory devices operatively coupled to the computer, the memory devices storing tag-based control logic; Tag-based quota data is stored in a storage device. The tag-based quota data represents multiple usage quotas of the resource supply for the leasing user. The resources under lease are provided in multiple compartments, wherein each compartment provides isolation of the resource set within that compartment relative to one or more other isolated resource sets in other compartments; Receive a request from the user of the lease to supply a first resource in the lease, the request including resource type representing the requested first resource and request characteristic data of the user group category assigned to the user requesting the first resource; The usage of a set of resources in a lease that spans the plurality of compartments and is associated with resource tags corresponding to requested resource type characteristic data is determined by the one or more processors executing tag-based control logic. The one or more processors executing the tag-based control logic compare the usage of the determined isolated resource set together with the group usage quotas assigned to the users requesting the first resource by the plurality of usage quotas; as well as The one or more processors executing tag-based control logic discard requests for the supply of first resources received from leased users based on the usage of a determined isolated set of resources exceeding the group usage quota.

9. The method according to claim 8, wherein: Determining usage includes jointly determining the usage of resources in a lease associated with resource tags corresponding to the request characteristics across the multiple compartments; The comparison includes comparing the usage patterns determined across the multiple compartments with the leased usage pattern quotas; as well as Discarding includes discarding a request to supply the first resource based on usage exceeding one of the multiple usage quotas determined jointly across the multiple compartments.

10. The method according to claim 8 or 9, wherein: Storing tag-based quota data includes storing tag-based quota data in a storage device that represents multiple usage quotas of resource supply in leases for corresponding multiple resource types; The request to receive includes a request to receive resource type data representing a first resource type of the requested first resource. The determination includes determining the usage of resources in leases associated with resource tags corresponding to the first resource type; The comparison includes comparing the determined usage with a first tag-based quota of resource supply in the lease of the first resource type; as well as The drop request includes a drop request based on the determination that the usage of resources in a lease associated with a resource tag corresponding to the first resource type exceeds the first tag-based quota of resource supply in the lease of the first resource type.

11. The method according to claim 8 or 9, wherein: Storing tag-based quota data includes storing tag-based quota data in a storage device that represents multiple usage quotas of resource supply in a lease allocated to corresponding user groups; Receiving a request includes receiving a request for resource type data that includes user group category data representing the user assigned to the system requesting the first resource; Determining includes identifying the usage of resources in leases associated with resource tags corresponding to user group categories; The comparison includes comparing the determined usage with a first tag-based quota of resource supply allocated to user group categories in leases; and Drop requests include dropping requests based on a first tag-based quota of resources in a lease that is associated with a resource tag corresponding to the user group category and whose usage exceeds the resource supply allocated to the user group category in the lease.

12. The method according to claim 8 or 9, wherein: Storing tag-based quota data includes storing tag-based quota data in a storage device that represents tag-based quotas for resource supply in a lease that are allocated to multiple user groups of multiple resource types in a lease; The request to receive includes a request for resource type data, which includes: i) Resource type data representing the first resource type of the requested first resource; and ii) User group data representing the user group categories assigned to the system that requested the first resource; Determine the usage of resources in leases, including determining the resource tags associated with the first resource type supplied to the first user group category; The comparison includes comparing the determined usage with a first tag-based quota of resource supply allocated to a first resource type in a lease for a first user group category; and The drop request includes a drop request based on the determination that the usage of resources in a lease associated with the resource tag corresponding to the first resource type supplied to the first user group category exceeds the first tag-based quota of resources supplied in a lease for the first resource type of the first user group category.

13. The method according to claim 8 or 9, further comprising: The following tag-based quota data is stored in the storage device: tag-based quota data representing the resource supply in a lease that is allocated to multiple user groups of multiple resource types in a lease; A first request to track the usage of leased resources is received, the first request including request feature data representing a first user group category and a first resource type; Determine the first usage of the resource in the lease associated with the resource tag corresponding to the first resource type supplied by the first user group category; as well as Based on the first usage of resources in the lease of the first resource type supplied by the first user group, resource usage tracking data is generated.

14. The method according to claim 8 or 9, further comprising: Receive the first resource coverage request for supply leasing; The system selectively supplies the first resource based on the coverage request received. as well as Resource usage excess data is generated based on the selective provision of the first resource in response to the system receiving an overlay request.

15. A non-transitory computer-readable storage medium having instructions thereon for tag-based control of resource usage in an associated cloud infrastructure environment, the instructions causing the computer to perform steps including: A computer is provided for lease in an associated cloud infrastructure environment, the computer including one or more processors and memory devices operatively coupled to the computer, the memory devices storing tag-based control logic; Tag-based quota data is stored in a storage device. The tag-based quota data represents multiple usage quotas of the resource supply to the leasing user. Resources are offered for rent in multiple compartments, wherein each compartment provides isolation of its resource set relative to one or more other isolated resource sets in other compartments; Receive a request from the user of the lease to supply a first resource in the lease, the request including resource type representing the requested first resource and request characteristic data of the user group category assigned to the user requesting the first resource; The usage of a set of resources in a lease that spans the plurality of compartments and is associated with resource tags corresponding to requested resource type characteristic data is determined by the one or more processors executing tag-based control logic. The one or more processors executing the tag-based control logic compare the usage of the determined isolated resource set together with the group usage quotas of multiple usage quotas assigned to the user requesting the first resource. as well as The one or more processors executing tag-based control logic may discard requests for the supply of first resources received from a leased user based on the determined usage of an isolated set of resources exceeding the group usage quota.

16. The storage medium according to claim 15, wherein: Determining usage includes jointly determining the usage of resources in a lease associated with resource tags corresponding to the request characteristics across the multiple compartments; The comparison includes comparing the usage patterns determined across the multiple compartments with the leased usage pattern quotas; as well as Discarding includes discarding a request to supply the first resource based on usage exceeding one of the multiple usage quotas determined jointly across the multiple compartments.

17. The storage medium according to claim 15 or 16, wherein: Storing tag-based quota data includes storing tag-based quota data in a storage device that represents multiple usage quotas of resource supply in leases for corresponding multiple resource types; The request to receive includes a request to receive resource type data representing a first resource type of the requested first resource. The determination includes determining the usage of resources in leases associated with resource tags corresponding to the first resource type; The comparison includes comparing the determined usage with a first tag-based quota of resource supply in the lease of the first resource type; as well as The drop request includes a drop request based on the determination that the usage of resources in a lease associated with a resource tag corresponding to the first resource type exceeds the first tag-based quota of resource supply in the lease of the first resource type.

18. The storage medium according to claim 15 or 16, wherein: Storing tag-based quota data includes storing tag-based quota data in a storage device that represents multiple usage quotas of resource supply in a lease allocated to corresponding user groups; Receiving a request includes receiving a request for resource type data that includes user group category data representing the user assigned to the system requesting the first resource; Determining includes identifying the usage of resources in leases associated with resource tags corresponding to user group categories; The comparison includes comparing the determined usage with a first tag-based quota of resource supply allocated to user group categories in leases; and Drop requests include dropping requests based on a first tag-based quota of resources in a lease that is associated with a resource tag corresponding to the user group category and whose usage exceeds the resource supply allocated to the user group category in the lease.

19. The storage medium according to claim 15 or 16, wherein: Storing tag-based quota data includes storing tag-based quota data in a storage device that represents tag-based quotas for resource supply in a lease that are allocated to multiple user groups of multiple resource types in a lease; The request to receive includes a request for resource type data, which includes: i) Resource type data representing the first resource type of the requested first resource; and ii) User group data representing the user group categories assigned to the system that requested the first resource; Determine the usage of resources in leases, including determining the resource tags associated with the first resource type supplied to the first user group category; The comparison includes comparing the determined usage with a first tag-based quota of resource supply allocated to a first resource type in a lease for a first user group category; and The drop request includes a drop request based on the determination that the usage of resources in a lease associated with the resource tag corresponding to the first resource type supplied to the first user group category exceeds the first tag-based quota of resources supplied in a lease for the first resource type of the first user group category.

20. The storage medium according to claim 15 or 16, further comprising: The following tag-based quota data is stored in the storage device: tag-based quota data representing the resource supply in a lease that is allocated to multiple user groups of multiple resource types in a lease; A first request to track the usage of leased resources is received, the first request including request feature data representing a first user group category and a first resource type; Determine the first usage of the resource in the lease associated with the resource tag corresponding to the first resource type supplied by the first user group category; as well as Based on the first usage of resources in the lease of the first resource type supplied by the first user group, resource usage tracking data is generated.

21. The medium according to claim 15 or 16, further comprising: Receive coverage requests for resources available for lease; Resources are selectively supplied based on the system receiving coverage requests; as well as Resource usage excess data is generated based on the selective provision of resources in response to the system receiving an overlay request.

22. A computer program product comprising instructions for tag-based control of resource usage in an associated cloud infrastructure environment, the instructions causing the computer to perform the steps of any one of claims 8 to 14 when read and executed by the computer.

Images