Systems and methods for tag-based resource limiting or allocation in cloud infrastructure environments

Abstract

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

Description

Technical Field

[0001] Copyright Notice Part of the disclosure of this patent document contains materials subject to copyright protection. The copyright owner does not object to the reproduction or copying by anyone of this patent document or patent disclosure as it appears in the patent file or records of the Patent and Trademark Office, but reserves all copyrights, whatever they may be, in all other cases.

[0002] Priority Claims and Cross - References to Related Applications: This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 884,931, filed on 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 on August 9, 2019, entitled "SYSTEM AND METHOD FOR TAG BASED REQUEST CONTEXT IN A CLOUD INFRASTRUCTURE ENVIRONMENT", each of which is hereby incorporated by reference in its entirety. METHOD FOR TAG BASED REQUEST CONTEXT IN A CLOUD INFRASTRUCTURE ENVIRONMENT" This application claims the benefit of priority to U.S. Patent Application No. 16 / 986,158, filed on August 5, 2020, entitled "SYSTEM AND METHOD FOR TAG BASED RESOURCE LIMITS OR QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT", and "SYSTEM AND METHOD FOR TAG BASED REQUEST CONTEXT IN A CLOUD INFRASTRUCTURE ENVIRONMENT", filed on August 5, 2020

[0003] This application claims the benefit of priority to U.S. Patent Application No. 16 / 986,158, filed on August 5, 2020, entitled "SYSTEM AND METHOD FOR TAG BASED RESOURCE LIMITS OR QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT", and U.S. Patent Application No. 16 / 986,159, filed on August 5, 2020, entitled "SYSTEM AND METHOD FOR TAG BASED REQUEST CONTEXT IN A CLOUD INFRASTRUCTURE ENVIRONMENT", each of which is hereby incorporated by reference in its entirety. This application claims the benefit of priority to U.S. Patent Application No. 16 / 986,158, filed on August 5, 2020, entitled "SYSTEM AND METHOD FOR TAG BASED RESOURCE LIMITS OR QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT", and "SYSTEM AND METHOD FOR TAG BASED REQUEST CONTEXT IN A CLOUD INFRASTRUCTURE ENVIRONMENT", filed on August 5, 2020 The applicant also claims the benefit of priority to U.S. Patent Application No. 16 / 986,160, and each of the above applications is incorporated herein by reference in its entirety.

[0004] Technical field The embodiments described herein generally apply to cloud infrastructure environments such as Infrastructure as a Service (IaaS). In particular, the present invention relates to systems and methods for providing systems and methods for providing resource constraints within such cloud infrastructure environments. [Background technology]

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

[0006] Year after year, more and more businesses and organizations are migrating their mission-critical applications and systems to cloud infrastructure environments. The reasons for this shift are varied. For example, many businesses are moving to the cloud to reduce the cost and complexity of operating, maintaining, and expanding on-premises infrastructure. Similarly, cloud infrastructure also enables faster information technology (IT) delivery. Some businesses and organizations further view cloud infrastructure environments as a means of gaining a competitive advantage by adapting to more agile systems.

[0007] Within the IaaS (Infrastructure as a Service) model, the cloud provider is responsible for... In the future configuration, the infrastructure will be on-premises at each customer / client's location. It can provide, host, and manage infrastructure components. Traditionally, such components provided on-premises may include hardware, such as data warehouses and data centers, servers, storage, networking hardware, and software such as virtualization software.

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

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

[0010] overview: This specification describes systems and methods for implementing tag-based resource limits or allocations in a cloud infrastructure environment. The systems and methods described herein support tag-based resource limits / allocations in a cloud infrastructure environment. A fine-grained approach allows for resource limits to be implemented based on tags spanning multiple containers. Tags are a mechanism primarily used in resource management, and cloud providers also use them for cost management. The systems and methods can create mechanisms for controlling costs at the group level through tags. The systems and methods also provide compartment allocation for cloud infrastructure environments.

[0011] Cloud administrators have the ability to restrict resource usage in existing clouds, but only at a higher level, and do not consider resources at the level of specific users, specific resources and resource types, or container hierarchy structures. According to one embodiment, resources are associated with tags, and as a result, their usage can be controlled, tracked, and / or otherwise handled at the resource level as needed or desired. By imposing resource allocation and / or restrictions, administrators and others can limit user resource usage to an appropriate level, enabling fine-tuned cost control.

[0012] In one embodiment, customers can be assigned service level limits defined by the cloud infrastructure environment when creating an account. These service level limits restrict the total number of resources a customer can create across the entire tenancy (e.g., across multiple containers in multiple regions with multiple compartments). Tenancy and compartment administrators can use tag-based resource allocation to set resource-specific limits. Without such limits based on tags associated with resources, a user authorized to launch an instance could consume all available capacity across the entire tenancy. Tag-based resource limits solve this problem and, unlike service limits, can be accessed, for example, through the console, S These are configured and customized by clients and customers via the DK or API. Tag-based resource limits are applied on top of service limits and can be inherited through nested compartment hierarchies. This allows compartment administrators to limit resource consumption and set boundaries around acceptable resource usage. [Brief explanation of the drawing]

[0013] [Figure 1] This figure shows a system for providing a cloud infrastructure environment according to one embodiment. [Figure 2] This figure shows a system for providing a cloud infrastructure region within a cloud infrastructure environment, according to one embodiment. [Figure 3] This figure shows a cloud infrastructure environment system, according to one embodiment, that illustrates the relationships between compartments, compartment policies, subcompartments, and subcompartment policies for policy management and control across cloud infrastructure regions. [Figure 4]A diagram showing a cloud infrastructure environment 400 that illustrates the relationships between compartments, compartment policies, sub - compartments, and sub - compartment policies when moving a compartment. [Figure 5] A diagram showing a cloud infrastructure environment 500 that illustrates the meaning of policies when moving a compartment. [Figure 6] A diagram showing pairs of defined tags according to an exemplary embodiment. [Figure 7] A diagram showing the architecture of a system that enforces allocation or restrictions on resources in a cloud infrastructure environment based on tags, such as resource tags and resource request context tags, according to an exemplary embodiment. [Figure 8] A diagram showing a system that uses request context tags and / or resource tags to limit the use, such as resource provisioning, in a cloud infrastructure environment. [Figure 9] A functional schematic diagram of a system that provides resource request context tag - based restrictions / allocations in a cloud infrastructure environment according to one embodiment. [Figure 10] A flowchart showing a method for restricting or allocating the provisioning of resources in a cloud infrastructure environment based on a request context according to an exemplary embodiment. [Figure 11] A functional schematic diagram of a system that provides tag - based resource restrictions / allocations in a cloud infrastructure environment according to one embodiment. [Figure 12] A flowchart showing a method for restricting or allocating the provisioning of resources in a cloud infrastructure environment based on a resource tag according to an exemplary embodiment.

Best Mode for Carrying Out the Invention

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

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

[0016] In embodiments of this specification, the term “realm” may refer to a logical collection of regions. Realms are isolated from each other and do not share any data. A client’s tenancy may reside within a single realm and have access to each of the regions belonging to that realm. Realms may be provided, for example, for commercial regions and administrative cloud regions.

[0017] According to embodiments of this specification, 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.

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

[0019] According to embodiments of this specification, the term “compartment” can refer to a collection of related resources (such as instances, virtual cloud networks, and block volumes) that can only be accessed by a specific group authorized by an administrator. Compartments enable clients / users to organize their cloud resources and control access to them. Once a client / user begins working with resources in the console, compartments can provide filters for what the client / user is seeing.

[0020] In embodiments of this specification, the term “tenancy” may refer to the root compartment containing all of a tenant’s cloud resources. Additional compartments can be created within the tenancy (root compartment) and its corresponding policies to control access to resources within each compartment. When a user / client creates a cloud resource such as an instance, block volume, or cloud network, the user / client can specify which compartment the resource should belong to.

[0021] According to embodiments of this specification, the term “virtual cloud network” can refer to a virtual version of a traditional network, including subnets, route tables, and gateways on which instances operate. The cloud network resides within a single region, but includes all availability domains within that region. Each subnet defined in the cloud network resides within a single availability domain, or is located within a single availability domain. This could be across all availability domains within the region. At least one cloud network can be set up before instances can be launched.

[0022] According to embodiments of this specification, the term “instance” may refer to a compute host operating within a cloud. Cloud infrastructure environment instances enable users / clients to utilize hosted physical hardware, as opposed to traditional software-based virtual machines, thereby providing enhanced security and performance.

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

[0024] In embodiments of this specification, the term “shape” can refer to the specification of the number of CPUs and the amount of memory allocated to an instance. In load balancing, the shape can determine the pre-provisioned total maximum capacity (bandwidth) of the load balancer for inbound + outbound traffic. Available shapes may include, for example, 100Mbps, 400Mbps, and 8000Mbps.

[0025] In the embodiments of this specification, the term “key pair” can refer to an authentication mechanism used in a cloud infrastructure environment. A key pair consists of a private key file and a public key file. The public key can be uploaded, while the private key is stored on the user / client's device. The private key is secret to the user / client, 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 an instance. When an instance is provisioned, a public key may be provided, and the public key is stored in the instance's authorized key file. To log on to the instance, a 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 the user / client when submitting API requests.

[0026] According to embodiments of this specification, the term “block volume” may refer to a virtual disk that provides persistent block storage for a cloud infrastructure environment instance. Block volumes can be used, for example, to store data and applications, in a similar manner to a physical hard drive on a computer. Volumes can be isolated from one instance and attached to another instance without data loss.

[0027] According to embodiments of this specification, the term “object storage” may 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 that does not change very frequently. A typical use for object storage is data This includes, but is not limited to, backups, file sharing, and storage of unstructured data (e.g., logs and sensor-generated data).

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

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

[0030] Figure 1 shows a system for providing a cloud infrastructure environment according to one embodiment.

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

[0032] According to one embodiment, a client device such as a computing device 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.

[0033] According to one embodiment, tenancies can be supported within a cloud infrastructure environment. During registration and deployment, a tenancy can be created for each client / customer, which can have a secure and isolated partition within the cloud infrastructure where the client can create, organize, and manage its own cloud resources.

[0034] In one embodiment, the console interface 102 and API 104 give the client access to and control over each part of the infrastructure environment. In one embodiment, the console interface may include an intuitive graphical interface that allows the client 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, HTTPS (Hypertext Transfer Protocol). This may include REST APIs that utilize (user).

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

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

[0037] In an exemplary embodiment, the governance service provides tagging that enables clients, administrators, etc., to apply tags to their resources for informational or operational reasons while the resources are being instantiated. In a further exemplary embodiment, the governance service also provides tagging that enables clients and others to apply tags to their resources for informational or operational reasons after the resources have been instantiated, thereby enabling the retroactive enforcement of resource allocation or restrictions in the system using tags.

[0038] In one embodiment, the Identity and Access Management (IAM) service 120 can create a user profile for each client / customer / user in the IAM service, associated with user credentials (e.g., username and password). The client may also be granted administrator privileges in the cloud infrastructure through the IAM service.

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

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

[0041] According to one embodiment, the resources 140 provided by the cloud infrastructure environment can be divided into multiple layers, such as a compute resource layer 150, a network resource layer 160, and a storage resource layer 170.

[0042] In one embodiment, the compute resource layer 150 may include several resources, such as a bare metal instance 152, a virtual machine 154, an edge service 156, and a container 158. The compute resource layer can be used, for example, to provision and manage bare metal compute instances and to provision instances as needed to deploy and run applications, similar to an on-premises data center. The cloud infrastructure environment 100 in the exemplary embodiment supports several tags 140a associated with each resource, including a compute resource tag 150a associated with the compute resources 150, such as a bare metal instance 152, a virtual machine 154, an edge service 156, and a container 158.

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

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

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

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

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

[0048] In one embodiment, a cloud infrastructure environment can provide several graphical processing unit (GPU) computing instances within its computing resource layer. Accelerated computing requires a consistently high-speed infrastructure across all services. Using GPU instances, clients can process and analyze large datasets more efficiently, making them useful for complex machine learning (ML), artificial intelligence (AI) algorithms, and many industrial high-performance computing (HPC) applications. GPU computing instances can be provisioned as virtualized computing instances (where multiple GPU computing instances share the same bare-metal hardware) or as bare-metal instances, providing dedicated hardware for each GPU computing instance.

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

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

[0051] According to one embodiment, the network resource layer 160 may include several resources, such as a virtual cloud network (VCN) 162, a load balancer 164, an edge service 166, and a connectivity service 168. The cloud infrastructure environment 100 in an exemplary embodiment supports several 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, the load balancer 164, the edge service 166, and the connectivity service 168.

[0052] In one embodiment, a cloud infrastructure environment can provide several virtual cloud networks 162 at the networking resource layer. A virtual cloud network may include a virtual version of a traditional network, including subnets, route tables, and gateways on which client instances can operate. The cloud network resides within a single region but includes all availability domains within that region. Each subnet defined in the cloud network may reside within a single availability domain or span all availability domains within that region (preferred). At least one cloud network can be configured before launching instances. In one embodiment, the VCN handles public traffic, VPN connections, or high-speed connectivity services to connect to on-premises networks. The network can be configured via an internet gateway to securely extend.

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

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

[0055] In one embodiment, the load balancing service enables the creation of public or private load balancers associated with the 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 visible only within the VCN. Multiple listeners may be configured to load balance transport different layers of traffic (e.g., layer 4 and layer 7 (TCP and HTTP) traffic) for each IP address. Both public and private load balancers can route data traffic to any backend server reachable from the VCN.

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

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

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

[0059] In one embodiment, private load balancing may also be provided to isolate the load balancer from the internet and simplify security posture. The load balancer service may assign private addresses to the load balancer that serve as entry points for incoming traffic.

[0060] In one embodiment, a private load balancer may be configured to host both a primary and a standby load balancer for only one subnet, depending on a particular service. The load balancer may be regional or AD-specific, depending on the range of the host subnet. The load balancer is accessible only from within the VCN containing the host subnet, or as further restricted by security rules.

[0061] In one embodiment, the assigned floating private IP address is local to the host subnet. The primary load balancer and the standby load balancer each require an additional private IP address from the host subnet.

[0062] According to one embodiment, in the event of an availability domain failure, 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 in a regional subnet within a single availability domain region does not have failover capability in response to an availability domain failure.

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

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

[0065] According to one embodiment, the storage resource layer 170 may include several resources, such as a block volume 172, file storage 174, object storage 176, and local storage 178. The cloud infrastructure environment 100 according to an exemplary embodiment supports several 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.

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

[0067] According to one embodiment, the file storage 174 allows the client to create a scalable, distributed, enterprise-grade network file system. The file storage supports semantics, snapshot capabilities, and encryption at rest.

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

[0069] According to one embodiment, local storage 178 can provide high-speed and reliable storage in the form of solid-state drives for I / O-intensive applications, for example. These can be provided, for example, within 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.

[0070] Figure 2 shows a system for providing a cloud infrastructure region within a cloud infrastructure environment, according to one embodiment.

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

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

[0073] In one embodiment, availability domains are isolated from each other, fault-tolerant, and have a very low probability of simultaneous failures. Because availability domains do not share infrastructure such as power or cooling, or an internal availability domain network, a failure in one availability domain within a region is unlikely to affect the availability of others within the same region.

[0074] According to one embodiment, availability domains within the same region can be connected to each other by a low-latency, high-bandwidth network, thereby providing high-availability connectivity to the internet and on-premises, and enabling the construction of replicated systems across multiple availability domains for both high availability and disaster recovery.

[0075] In one embodiment, regions are independent of other regions and can be geographically separated (for example, across countries or continents). This then leads to the deployment of a particular application in the region where it is most likely to be used most frequently.

[0076] However, according to certain embodiments, applications may also be deployed in different regions for a variety of reasons. This could include, for example, mitigating risks when events such as weather systems take a region offline. In addition, applications may be deployed in other regions for strategic reasons such as tax domains or other business or social standards.

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

[0078] In one embodiment, compartments allow clients to organize cloud resources and control access to them. A compartment is a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that can only be accessed by specific groups authorized by an administrator. For example, one compartment might include, as an example, all servers and storage volumes that make up a company's human resources (HR) system deliverables, while other compartments could each be dedicated separately to, as a further example, the company's legal, marketing, accounting, sales, and information technology (IT) systems. In one example, only users authorized for that compartment can manage and / or access those servers and volumes. In a further example, a compartment could include all servers and storage volumes that make up the deliverables of a company's human resources (HR) system and its collections of legal, marketing, accounting, sales, and information technology (IT) systems. In one example, only users authorized for those parts of resources can manage and / or access those parts on the servers and volumes.

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

[0080] According to one embodiment, a compartment can have several layers. For example, a tenancy can be considered a root compartment that holds all of the client's cloud resources. Additional compartments can be created within the root compartment (tenancy), and corresponding policies can be created to control access to resources within each compartment. The client can access compute, storage, VCN, IP addresses and / or DNS instances, block volumes, and When creating cloud resources such as cloud networks, such resources can be directed to a specific compartment or multiple compartments. Compartments can span regions.

[0081] Failure Domain In one embodiment, a failure domain can include a grouping of hardware and infrastructure within an availability domain. Each availability domain can contain three failure domains. Failure domains allow instances to be distributed so that instances are not located on the same physical hardware within a single availability domain. A hardware failure or compute hardware maintenance affecting one failure domain does not affect instances in other failure domains.

[0082] According to one embodiment, the placement of resources such as compute, bare-metal DB systems, or virtual machine DB system instances can optionally be specified as a failure domain or new instance at startup. After placement, the failure domain can be further changed by terminating the resource in the current failure domain and starting a new instance of the resource in a different failure domain.

[0083] In one embodiment, a fault domain can be used for a number of reasons, such as protection from unexpected hardware failures and protection from planned downtime due to maintenance.

[0084] availability In one embodiment, service availability can be provided. A region within a cloud infrastructure environment can provide core infrastructure services and resources, including: • Computing: Computing (bare metal and VM, DenseIO and Standard), container engine for Kubernetes, registry... • Storage: Block volumes, file storage, object storage, archive storage • Networking: Virtual cloud network, load balancing, high-speed connectivity • Databases: Databases, Exadata cloud services, autonomous data warehouses, Autonomous Transactions ·process Edge: DNS • Platform: Identity and access management, tagging, auditing In one embodiment, the above services and resources may be generally available, but other services and resources may also be available additionally (for example, based on regional demand or customer requirements). For example, new cloud services may be made available in a region as quickly as possible based on a variety of considerations, including regional customer demand, the ability to achieve regulatory compliance where applicable, resource availability, and other factors. Due to the low-latency interconnect backbone, customers may use cloud services in other geographical regions with effective results when they are not available in their home region, provided that data residency requirements do not prevent them from doing so.

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

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

[0087] According to one embodiment, examples of resources available regionally include alarms, applications, buckets (although buckets are regional resources, they can be accessed from any location using the correct region-specific object storage URL for API calls), clusters, cloud event rules, customer premises equipment (CPE), DHCP option sets, dynamic routing gateways (DRGs), encryption keys, functions, images, internet gateways, jobs, key vaults, load balancers, local peering gateways (LPGs), metrics, NAT gateways, network security groups, node pools, ons-subscriptions, and ons-topics. This may include repositories, reserved public IPs, route tables, security lists, service gateways, stacks, subnets (once a subnet is created, it may be declared to be specific to a regional or availability domain), 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).

[0088] According to one embodiment, examples of availability domain-specific resources may include a DB system, a transient public IP, an instance (an instance can be attached to a volume within the same availability domain), a subnet (once a subnet is created, it can be declared to be specific to a regional or availability domain), and a volume (a volume can be attached to an instance within the same availability domain).

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

[0090] In one embodiment, tags can be applied to resources within a compartment. Tags can be used to organize resources according to a schema, such as a business needs schema. Tags can be applied to resources when they are created, or tags can be updated on existing resources. Tags associated with each resource may include, for example, a resource tag 140a associated with resource 140 (Figure 1), a computer resource tag 150a associated with computer resource 150, a network resource tag 160a associated with network resource 160, and a storage resource tag 170a associated with storage resource 170.

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

[0092] In one embodiment, a compartment is tenancy-width and can span regions. Once a compartment is created, it can be made available in any region to which the tenancy is joined.

[0093] According to one embodiment, a compartment can be deleted. In order to delete a compartment, all resources within the compartment may be removed prior to deletion.

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

[0095] According to one embodiment, each compartment created within a cloud infrastructure environment may have certain properties. For example, each compartment may be assigned a unique identifier (ID), and in addition, it may be provided with a modifiable description and name as needed. According to one embodiment, subcompartments may be defined hierarchically under a base compartment.

[0096] In one embodiment, access to and control of compartments and subcompartments can be restricted to administrators or other users with sufficient credentials. These credentials can be associated with different levels of compartment access. For example, an administrator may have permission to browse and access all compartments, as well as work with resources within any compartment of the tenancy, while a user with more restricted access may not have such a level of access and control.

[0097] Figure 3 shows a cloud infrastructure environment 300 illustrating the relationships between compartment 360, compartment policy 365, subcompartment 370, and subcompartment policy 375 for policy management and control across cloud infrastructure regions, according to one embodiment.

[0098] According to one embodiment, as described above, instances of the cloud infrastructure environment described in Figure 1 may be hosted in different regions such as cloud infrastructure regions 320, 330, 340, and 350. These can be accessed by customer networks 301 via a network 302 such as the internet, via a console, SDK, or API, as described above.

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

[0100] According to one embodiment, although not shown in the diagram, each cloud infrastructure region may include several services, each service including several resources such as management services, compute services, storage services, edge services, network services, and physical infrastructure.

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

[0102] In one embodiment, availability domains are isolated from each other, fault-tolerant, and have a very low probability of simultaneous failures. Because availability domains do not share infrastructure such as power or cooling, or an internal availability domain network, a failure in one availability domain within a region is unlikely to affect the availability of others within the same region.

[0103] According to one embodiment, availability domains within the same region can be connected to each other by a low-latency, high-bandwidth network, thereby providing high-availability connectivity to the internet and on-premises, and enabling the construction of replicated systems across multiple availability domains for both high availability and disaster recovery.

[0104] In one embodiment, regions are independent of other regions and can be geographically separated (for example, across countries or continents). This then leads to the deployment of a particular application in the region where it is most likely to be used most frequently.

[0105] However, according to certain embodiments, applications may also be deployed in different regions for a variety of reasons. This could include, for example, mitigating risks when events such as weather systems take a region offline. In addition, applications may be deployed in other regions for strategic reasons such as tax domains or other business or social standards.

[0106] According to one embodiment, there are several services available across regions. These include, for example, management services, compute services, storage services, edge services, and network services.

[0107] In one embodiment, compartments allow clients to organize cloud resources and control access to them. A compartment is a collection of related resources (such as instances, virtual cloud networks, and block volumes) that can only be accessed by a specific group authorized by the administrator. A compartment can be thought of as a logical group rather than a physical container. When working within the console, compartments can act as a filter for what is allowed to be seen.

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

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

[0110] According to one embodiment, when a compartment (i.e., a subcompartment) is created within a compartment, the subcompartment inherits access permissions from the compartment higher up in the hierarchy.

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

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

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

[0114] In one embodiment, some resources have attached resource dependencies, while others do not. When the parent resource moves, not all attached dependencies behave the same way.

[0115] In one 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, the attached dependencies move asynchronously and are not visible in the new compartment until the move is complete.

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

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

[0118] According to one embodiment, after creation, a compartment can be moved, for example, to a different parent compartment within the same tenancy. When a compartment is moved, all of its contents (including subcompartments and resources) are moved along with the compartment.

[0119] Figure 4 shows a system for compartment movement within a cloud infrastructure environment according to one embodiment.

[0120] According to one embodiment, as described above, instances of the cloud infrastructure environment 400 described in Figure 1 may be hosted in different regions. Compartments such as Compartment 405, Compartment A460, and Compartment B470 can be defined within the cloud infrastructure environment, and these compartments can span regions. Such compartments can be accessed by customer networks 401 via networks 402 such as the internet, through consoles, SDKs, or APIs, as described above.

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

[0122] In one embodiment, compartments allow clients to organize cloud resources and control access to them. A compartment is a collection of related resources (such as instances, virtual cloud networks, and block volumes) that can only be accessed by a specific group authorized by the administrator. A compartment can be thought of as a logical group rather than a physical container. When working within the console, compartments can act as a filter for what is allowed to be seen.

[0123] According to one embodiment, a compartment can have several layers. For example, tenancy 405 can be considered a root compartment that holds all of the client's cloud resources. The compartments can be organized in a hierarchical manner such that compartments A460 and B470 are below the tenancy compartment, subcompartment A465 is defined below compartment A, and subcompartment B475 is defined below compartment B. According to one embodiment, each compartment can be associated with one or more compartment policies (not shown).

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

[0125] According to one embodiment, a request with sufficient permissions can be received to move a compartment. That is, the request may come from a group of users who have "full resource management" permissions for the lowest-level shared parent compartment of the current compartment and the destination compartment of the compartment to be moved.

[0126] In other words, for example, a request to move subcompartment A465 from compartment A460 to compartment B470 (from 465 to 476) must be received from the user with sufficient permission. Since tenancy 405 is the parent compartment shared at the lowest level by both the source compartment, compartment A460, and the destination compartment, compartment B470, as shown in the diagram, a request to move subcompartment A must be received from a user who has permission to "manage all resources" within the compartment of tenancy 405.

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

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

[0129] Therefore, according to one embodiment, the compartment policy of compartment A460 previously applied to subcompartment A will no longer apply to the movement of subcompartment A to compartment B. Instead, the compartment policy of compartment B will be applied to subcompartment A. This is further illustrated in the following diagram.

[0130] Figure 5 shows a system for policy management and enforcement during compartment migration within a cloud infrastructure environment.

[0131] According to one embodiment, more specifically, Figure 5 shows the compartment hierarchy to which the compartments are moved and the results for different policies.

[0132] According to one embodiment, as described above, instances of the cloud infrastructure environment 500 described in Figure 1 may be hosted in different regions. Compartments such as tenancy 505, compartment A560 and compartment B565, and compartment D566 may be defined within the cloud infrastructure environment, and these compartments may span regions. Such compartments may be accessed by customer networks 501 via a network 502 such as the internet, via a console, SDK, or API, as described above.

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

[0134] According to one embodiment, a compartment can have several layers. For example, tenancy 505 can be considered a root compartment that holds all of the client's cloud resources. Compartments can be organized hierarchically, such that compartment A 560 is a lower level below tenancy. Compartments B 565 and D 566 are then organized as yet another level below compartment A 560, while subcompartment C 570 is initially shown as a level below compartment B. According to one embodiment, each compartment can be associated with one or more compartment policies, such as compartment B policy 582, compartment A policy 580, and compartment D policy 583. Such policies can manage, for example, user / client permissions for access to compartments, 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., "stacked") so that users accessing compartment B565 have interaction with compartment B565 that is managed / restricted by compartment B policy 582 in addition to compartment A policy 580.

[0135] According to one embodiment, for example, suppose compartment B policy 582 allows a group, group 1, to manage instance families within compartment AB (the compartment hierarchy is subcompartment A). (Including compartment B, which is a ment.)

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

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

[0138] According to one embodiment, under certain circumstances, moving a compartment can automatically update a policy. For example, a policy specifying the compartment hierarchy up to the compartment being moved can be automatically updated when the policy is attached to the current target parent's shared ancestor.

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

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

[0141] However, according to one embodiment, not all policies are automatically updated when a compartment is moved. For example, referring to Figure 5, suppose that in a situation where compartment C is moved from compartment B to compartment D, the compartment B policy (before the move) allows management of buckets in compartment C. When compartment C is moved, the compartment B policy is not automatically updated. Instead, the policy is no longer valid and can be removed (e.g., manually or automatically).

[0142] Tag-based resource limits / quotas In one embodiment, cloud administrators generally do not have the ability to restrict resource usage in an existing cloud. By granting users permission to create resources, users can create any number of resources up to a predefined account limit. Tag-based resource limits or allocations allow for imposing appropriate levels of restrictions on the ability to create or use resources within a compartment, enabling fine-tuned cost control.

[0143] In one embodiment, customers can be assigned service level limits defined by the cloud infrastructure environment when creating an account. These service level limits restrict the total number of resources that a customer can create across the entire tenancy (for example, across multiple regions with multiple compartments). Tenancy and compartment administrators can use tag-based resource limits or assignments to set strict resource-specific limits. Without such compartment limits on individual resources, only authorized users could launch instances. A user can consume all available capacity across the entire tenancy. Tag-based resource limits or quotas address this issue and, unlike service limits, are configured and customized by clients and customers, for example, via the console, SDK, or API. Tag-based resource limits or quotas are applied on top of service limits and can be inherited through nested compartment hierarchies. This allows cloud administrators to limit resource consumption and set boundaries around acceptable resource usage.

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

[0145] In one embodiment, when a client has resources (e.g., instances, VCNs, load balancers, and block volumes) across multiple compartments in a tenancy, it can be difficult to track, aggregate, report on, or take bulk actions on resources used for a specific purpose. 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 predefined tags, but other types of tags are also possible according to exemplary embodiments.

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

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

[0148] In one embodiment, to apply predefined tags to a resource, a user can first select a tag namespace, then select a tag key within the namespace, and then assign a value. An administrator can control which groups of users are allowed to use each namespace. According to an exemplary embodiment, tags may be applied to a resource when the resource is created. In another embodiment, tags may be applied to a resource after it has been provisioned, thereby enabling retroactive enforcement of resource allocation or restrictions in a system using tags. According to one embodiment, tags can be used to enable cost management and / or resource management. Thus, tags can be used to track costs.

[0149] Figure 6 shows two predefined tags according to one embodiment. Two tag namespaces, namespace 1 600 and namespace 2 620 (for example, namespace 1 could be "Sales" and namespace 2 could be "Human Resources") are set up. Tag keys 605, 610, 625, and 630 are defined in the namespaces. Within each namespace, the tag keys may be unique, however Tag key names can be repeated across namespaces. For example, both namespaces could contain a key named "environment".

[0150] In one implementation, many cloud providers impose service limits to protect against capacity shortages. However, clients often also want to set limits to prevent themselves from exceeding their resource limits. One such approach is to specify limits at the group level. A group can include a set of users, resources, or whatever a user wishes to specify. Group-level limits are set by the administrator / user of a particular tenancy / account.

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

[0152] However, according to one embodiment, a problem exists because there is a very simple mechanism for administrators to control costs. For example, an administrator can include or exclude certain groups from resource excess, or an administrator can exclude certain users who create resources by denying access. However, these are coarse-grained mechanisms, and customers generally do not have the ability to specify a finer-grained mechanism that gives them flexibility and better control over managing their cloud resources.

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

[0154] According to one embodiment, the system sets resource request context tag-based limits / allocations in a cloud infrastructure environment. The system provisioning resources in the cloud infrastructure environment based on the request context. Implement methods to restrict or impose quotas on it.

[0155] According to one embodiment, the system implements tag-based resource restrictions / allocations in a cloud infrastructure environment. The system performs methods to restrict or impose allocations on the provisioning of resources in the cloud infrastructure environment based on resource tags.

[0156] In one embodiment, in a highly secure environment, customers want to secure access to resources and customer data. For example, a customer might protect their resources by classifying them as highly confidential, confidential, restricted, public, etc., and grant users access based on user clearance according to the constraints. Users with access to classified resources / data need to be extremely careful when accessing the data to ensure there is no information leakage and to avoid inadvertent modification of resources across data classifications within a shared context. Embodiments of this specification provide improved systems and methods for enabling users to restrict access or modify resources within data classification boundaries for a given session / context, even if the user otherwise has higher access.

[0157] In one embodiment, cloud architectures can restrict / permit access to specific security boundaries using rule-based (role) access control technologies by placing users into roles. However, these technologies are coarse-grained. The responsibility lies with users to be careful and cautious about what they access, modify, or perform.

[0158] In one embodiment, the systems and methods of the present disclosure protect a user from accessing resources to perform an action unintended by the user. One example is when a user has access to highly categorized resources but accesses data of other categories. For example, suppose a user has a script that requires access only to uncategorized resources by filtering out highly categorized resources. Here, the user / script must know which data / resources are categorized and which are not.

[0159] In one embodiment, another example is when a user is only interested in shutting down non-business-critical infrastructure after the end of an operation, while wanting other business-critical resources to remain operational. In this case, the user must know exactly which instances should be turned off.

[0160] In one embodiment, the systems and methods of this specification provide a solution to such problems via tags attached to one or more requests to a resource. Requests from a script perform actions on behalf of the user, such as shutting down an instance, reading resource details, updating a resource, or accessing a categorized resource. The user sends these requests along with one or more tags attached to the request context. When a request performs an action on a resource, these tags from the request context can be inspected, and then access to perform that action can be denied or granted, even if the user initially had access to perform the action they wanted to perform. This avoids unintended access to highly categorized data or resources by the user performing an unintended operation on that particular resource. This may constitute tag-based automation. It can address a wide variety of use cases, not just in the area of ​​security.

[0161] According to one embodiment, by using tags that represent a resource request context, a security boundary can be formed via the tags when accessing a resource by sending a request.

[0162] In one embodiment, if a user wants to access a resource to perform a certain action, the user can generally make a call via a software development kit or make a direct API call. The user can pass one or more tags that are added to the request sent to the resource. While authorizing the user, the resource implementation can inspect the tags associated with the request, and if the tags match user tags, the request is allowed; otherwise, the request is rejected / denied.

[0163] Figure 7 shows an architectural flow for a user launching an instance in a system that enforces allocation or restriction of resources in a cloud infrastructure environment based on tags, such as resource tags and / or resource request context tags, according to an exemplary embodiment.

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

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

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

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

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

[0169] In one embodiment, in step 7, the computation control plane may check in 750 whether the requested use violates any tag-based restrictions / assignments. If the requested use does not violate any compartment assignments, the request may be processed, for example, in database 745. If the requested use violates any tag-based restrictions / assignments along the compartment tree, the request may be dropped and a message may be sent to notify the user.

[0170] According to one embodiment, tag-based limits / quotas apply across the entire tenancy, including all regions where the tenancy is an enabled compartment within the tenancy. If the requested instance violates the tag-based limits / quotas... When determining whether to approve a request, the CCP can ensure that the new request does not violate any of the quotas, for example, through a Service Developer Kit (SDK). If the request exceeds the quota, the CCP may drop the request.

[0171] According to one embodiment, the CCP SDK may be present in all control planes of the cloud infrastructure environment.

[0172] In one embodiment, the CCP can work with the Restriction Services data plane to check new requests against tag-based restrictions / assignments.

[0173] In one embodiment, when a client triggers an action to create a cloud resource, the request goes to the resource control plane. The resource control plane queries the restrictions service to determine whether the resource can be safely spun up, taking into account the restrictions configured at the group level. If the restrictions server returns a negative / failure response to the resource control plane, the resource is not created.

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

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

[0176] According to one embodiment, a client device 810 can submit a request 811 to a cloud infrastructure environment, and the request is associated with a tag 812, such as a tag representing the context of the request. The client device can submit the request to the cloud infrastructure environment 800 (running on device hardware 801) via one of the following interfaces: console 802, API 804, or SDK 806.

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

[0178] In one embodiment, if a client device enjoys high security / priority privileges (e.g., tamper protection or intelligence), the client device can utilize a wide range of tags on requests. For example, tags associated with requests may be used to help users prevent accidental access to protected resources. For instance, suppose certain computing resources can be shut down after 6 p.m. each day to save costs. Such computing resources would have low-security tags. However, the same system also has other computing resources that cannot be shut down (they must run 24 / 7). Such computing resources would have high-security tags. To shut down the low-privilege computing resources, the user would need to access each resource without having a tagged request and select the resource that should be shut down. You would have to either select only the S-rank resources or write a script to do so, to avoid shutting down highly privileged resources that need to run 24 / 7. This is difficult to maintain because computing resources can be added and removed on a daily basis.

[0179] In one embodiment, a user can instead provide a tagged request to shut down a low-privilege resource. That is, the tag associated with the request would share a low-security tag with computing resources that can be shut down at 6 PM. The tag could then proceed to all resources in the network, but would bypass highly secure resources that do not have the tag the request possesses. Thus, a tagged request to shut down computing resources would only shut down computing resources with matching low-security tags, bypassing highly secure tagged computing resources.

[0180] According to one embodiment, as another example, suppose client 810 wants to attach a highly secure compute instance to a block volume. In such a situation, the request to attach the highly secure compute instance may be tagged with a highly secure tag. By doing so, it can be ensured that the highly secure compute instance will not be attached to a block volume with a less secure tag, and instead, the request can only attach the highly secure compute instance to a similarly tagged (highly secure) block volume. In other words, the request will not attach a highly secure compute to a less secure block volume (the tag check will fail).

[0181] Request context tag-based restrictions / quotes Figure 9 is a schematic diagram of a system 900 that provides resource request tag-based restrictions / allocations in a cloud infrastructure environment according to one embodiment. Generally, a client device 810 (Figure 8) can submit a request 911 to the cloud infrastructure environment to provision a new resource from among multiple tagged resources 940. The multiple tagged resources 940 may be, for example, tagged compute resources 851-854 in the compute resource layer 850, tagged network resources 861-864 in the network resource layer 860, and / or tagged storage resources 871-874 in the storage resource layer 870.

[0182] According to the exemplary embodiments, resources are items provisioned 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 service protection types, and email delivery service types. The exemplary embodiments herein are not limited to these specific resource types and may include other types, further examples of resource types are mentioned below as examples.

[0183] [Table 1]

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

[0185] Resources provisioned in the cloud infrastructure environment may be grouped into containers 942, 944, and 946 based on the tag values ​​assigned to each resource, or on other criteria as needed or desired. For example, the first container 942 may store compute and storage resources provisioned in the cloud and associated with the accounting group of client user 701 (Figure 7), the second container 944 may hold compute resources provisioned in the cloud and associated with the sales group of client user 701, and the third container 946 may hold compute resources provisioned in the cloud and associated with the human resources group of client user 701. The exemplary embodiments herein are not limited to these groups, and other groups may be used similarly, with further exemplary groups being listed below as examples.

[0186] [Table 2]

[0187] In one example, resource instances are logically placed in different containers 942, 944, and 946, thereby providing separate cost centers, each cost center being assigned a tag value, and end users may be charged for access to different cost centers. The cost center tags are used for cost management and billing. A customer may model multiple cost centers within their end-group pricing. Each cost center may have a separate tag, and the cloud may allocate a limited set of resources to each tag.

[0188] In exemplary embodiments, one or more policies 920 provide a mechanism to protect the end user from accessing more resources than permitted by the standard contract for access, and substantial excess may occur when the end user accesses more resources than permitted under the standard contractual conditions of the standard contract. For example, a customer may submit a request for resources via the resource control plane 930 to activate the provisioning of multiple computing resources, such as 100 computing resources, while the contractual conditions only permit the provisioning of 90 computing resources at the standard rate, and the excess, in this embodiment 10, would incur additional costs for the customer end user.

[0189] As described above, and according to certain embodiments, a fine-grained approach can be used to impose resource limits based on tags. Tags are a mechanism primarily used in resource management, and cloud providers also use them for cost management. Systems and methods can create mechanisms for controlling costs at the group level through tags. For example, a user can specify fine-grained rules / policies such as: Set limits<resource type> to 10 in group A where target.resource.tag = “finance” (The limit <resource type> is set to 10 in group A, and the target resource tag is "finance".) In one embodiment, tags can be associated with resources and / or resource requests, and using the above approach, tags can protect customers from resource excess at one or more selected levels, such as the group level. In the example above, if the tag value is "Financial" in group A, user members will not be able to create more than 10 instances of <resource type>. This approach of limiting costs at the group level provides clients with a fine-grained mechanism for better managing costs and resource usage.

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

[0191] According to one example, each of the resource requests 911a to 911d includes fields containing data representing the type of resource instance being requested (resource type), data representing the group of resource instances being requested (resource group), and data representing the context of the resource request (context tag). In this regard, each of the resource requests 911a to 911d includes resource type fields 912a to 912d containing data representing the type of resource instance being requested (resource type). In addition, each of the resource requests 911a to 911d includes resource group fields 913a to 913d representing the group of resource instances being requested (resource group). Furthermore, each of the resource requests 911a to 911d includes request context fields 914a to 914d containing request context data (context tag) representing the context of the resource request.

[0192] According to one example, the computation control plane can fetch all tag-based limits / allocations 950 associated with tags that are part of a request from user 701 from the limit service data plane 740 (Figure 7) (alternatively, the fetch operation may be performed in the resource control plane 930). Such tag-based allocations can be applied across the entire tenancy, for example, and do not need to be compartment-specific.

[0193] In one embodiment, the computation control plane can check whether the requested use violates any tag-based restrictions / allocations for any allocation or restriction rules in memory 950. If the requested use does not violate any compartment allocations, the request can be processed, for example, by a database. If the requested use violates any tag-based restrictions / allocations along the compartment tree, the request may be dropped, and a message may be sent to notify the user.

[0194] According to exemplary embodiments, tag-based limits / quotas apply to compartments within a tenancy. According to exemplary embodiments described below, tag-based limits / quotas apply across the entire tenancy, including, for example, all regions that span multiple compartments where the tenancy is enabled. When determining whether a requested instance violates tag-based limits / quotas, the compute control plane can ensure that the new request does not violate any of the quotas, for example, via the Service Developer Kit (SDK). If the request exceeds the quota, the compute control plane can drop the request.

[0195] In one embodiment, the compute control plane SDK may reside in all control planes within the cloud infrastructure environment. In one embodiment, the compute control plane can work in conjunction with the restricting services data plane to check new requests against tag-based restrictions / allocations.

[0196] In one embodiment, tags can be associated with resources and / or requests for resources, and in this approach, tags can protect resources from inadvertent access and customer users from inadvertent resource overload.

[0197] In this regard, system 900 is provided using request context tags 914a to 914d to control the handling of resource 940 in the associated cloud infrastructure environment. The system may include one or more computers, each having one or more microprocessors that define a tenancy in the associated cloud infrastructure environment. In an exemplary embodiment, a memory device 940 operationally coupled to a computer stores logic executable by the computer to provide control over the handling of resources in the tenancy. The memory device may also store access control data 950 representing multiple required credential gate levels to enable the handling of resources in the tenancy. Requests 911a to 911d for handling a first resource in the tenancy may be received, and requests 911a to 911d include request context tag data 914a to 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 to a first required credential gate level among several required credential gate levels to enable the handling of the resource in the tenancy having the first privilege level classification. According to an exemplary embodiment, requests for handling the first resource are selectively permitted based on the request context information that matches the first required credential gate level.

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

[0199] According to an exemplary embodiment, a request to provision a first resource in a tenancy may include a request from a system user to provision a bare metal compute instance in the tenancy to give control to a user of one or more physical host machines in the compute resource tier of the associated cloud infrastructure environment. In this example, the request context tag data of the request includes user context tag data 913a-913d representing the user's user identification information. Access control data stored in a memory device includes user access control data representing multiple user-required credential gate levels to enable resource handling in the tenancy, and the user's user identification information is compared to a first user-required credential gate level among multiple user-required credential gate levels to enable resource handling in the tenancy, having a first privilege classification. In this example, the bare metal compute instance is selectively provisioned to the user in the tenancy based on the user's user identification information matching the first user-required credential gate level.

[0200] According to an exemplary embodiment, a request to provision a first resource in a tenancy may include a request to provision multiple resources in the tenancy, each having a first privilege level classification. In this case, the multiple resources in the tenancy are selectively provisioned based on request context information that matches the first required credential gate level.

[0201] According to an exemplary embodiment, the request context tag data of a request may include user context tag data 913a to 913d representing the user's user identification information, and a request dealing with a first resource may include a request dealing with all resources provisioned in the tenancy and associated with a second privilege level classification. System 900 operates to compare the user identification information of a request with a second requested request credential gate level among several required credential gate levels in order to enable the handling of resources in the tenancy having a second privilege level classification. Based on the user identification information that matches the second required credential gate level, System 900 selectively permits requests dealing with all provisioned resources associated with the second privilege level classification in the tenancy.

[0202] According to an exemplary embodiment, the tenancy may include a plurality of compartments 942, 944, 946 for storing resources associated with a second privilege level classification, each of which compartments provides isolation of the set of resources associated with the second privilege level classification within that compartment from one or more other sets of resources associated with the second privilege level classification in other compartments. The system 900 selectively permits requests that deal with all resources provisioned in the tenancy associated with a second privilege level classification spanning multiple compartments, based on user identification information that matches the second required credential gate level.

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

[0204] In one embodiment, when a client triggers an action to create a cloud resource, the request goes to the resource control plane. The resource control plane queries the restrictions service to determine whether the resource can be safely spun up, taking into account the restrictions configured at the group level. If the restrictions server returns a negative / failure response to the resource control plane, the resource is not created.

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

[0206] For the sole purpose of illustrating, and not limiting, the functionality of an exemplary embodiment, the first policy 922 can protect customers from resource excess at the financial group level with respect to resources grouped in the first container 942, according to the following fine-grained rules / policies: Set limits <compute>to 10 in Container #1 (642) where target.resource.tag = "Finance" (The limit <Calculation> is set to 10 in container #1 (642), and the target resource tag is "Financial".) In the specific example above, the user cannot create more than 10 instances of compute resources within the financial container 942. In this way, request 911d for provisioning resources within container 942 is processed by policy 922 to determine whether the request can be executed without any excess or otherwise.

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

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

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

[0210] In step 1020, 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 provision a compute resource type, or a request to provision a storage resource type.

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

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

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

[0214] If, in step 1060, the request context information is determined to match the first required credential gate level, then in step 1070, a request to handle the first resource is permitted, and the resource may be handled, for example, by creating an instance of the requested resource, provisioning the requested resource, terminating the requested resource, or otherwise deprovisioning it.

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

[0216] Resource tag-based limits / quotas Figure 11 is a schematic diagram of the functionality of a system 1100 that provides tag-based resource restrictions / allocation in a cloud infrastructure environment, according to one embodiment.

[0217] Generally, a client device 810 (Figure 8) can submit a request 1111 to the cloud infrastructure environment to provision a new resource from among multiple tagged resources 1040. The multiple tagged resources 1140 may be, for example, tagged compute resources 851-854 in the compute resource layer 850, tagged network resources 861-864 in the network resource layer 860, and / or tagged storage resources 871-874 in the storage resource layer 870.

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

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

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

[0221] In exemplary embodiments, one or more policies 1120 provide a mechanism to protect the end user from accessing more resources than permitted by the standard contract for access, and substantial excess may occur when the end user accesses more resources than permitted under the standard contractual conditions of the standard contract. For example, a customer may send a request for resources via the resource control plane 1130 to activate the provisioning of multiple computing resources, such as 100 computing resources, while the contractual conditions only permit the provisioning of 90 computing resources at the standard rate, and the excess, in this embodiment 10, would incur additional costs for the customer end user.

[0222] As described above, and according to certain embodiments, a fine-grained approach can be used to impose resource restrictions based on tags, particularly tags associated with resources. The tags associated with resources provide a mechanism that can be used in resource management 110 (Figure 1), and cloud providers can also use them for cost management. Through tags, the system and methods can create a mechanism for controlling costs at levels including the group level. For example, users can specify fine-grained rules / policies such as: Set limits<resource type> to 10 in group A where target.resource.tag = "finance" (The limit <resource type> is set to 10 in group A, and the target resource tag is "finance".) In one embodiment, tags can be associated with resources, and using the approach described above, tags can protect customers from resource excess at one or more selected levels, such as the group level. In the example above, if the tag value is "Financial" in group A, then user members of that group will not be able to create more than 10 instances of <resource type>. This approach of limiting costs at the group level provides clients with a fine-grained mechanism for better managing costs and resource usage.

[0223] According to an exemplary embodiment, a first policy 1120a protects customers from overuse of resources associated with a first tag and which may be grouped into any of containers 1142, 1144, or 1146. Similarly, a second policy 1120b protects customers from overuse of resources associated with a second tag and which may be grouped into any of containers 1142, 1144, or 1146. Likewise, third and fourth policies 1120c and 1120d protect customers from overuse of resources associated with third and fourth tags and which may also be grouped into any of containers 1142, 1144, or 1146.

[0224] According to one example, each of the resource requests 1111a to 1111d includes fields containing data representing the type of resource instance being requested (resource type), data representing the group of resource instances being requested (resource group), data representing the characteristics of the resource request (resource characteristics), and data representing the context of the resource request (context tag). In this regard, each of the resource requests 1111a to 1111d includes resource type fields 1112a to 1112d containing data representing the type of resource instance being requested (resource type). In addition, each of the resource requests 1111a to 1111d includes resource group fields 1113a to 1113d representing the group of resource instances being requested (resource group). Furthermore, each of the resource requests 1111a to 1111d includes request context fields 1114a to 1114d containing request context data (context tag) representing the context of the resource request. Furthermore, each of the resource requests 1111a to 1111d includes request characteristic fields 1115a to 1115d, which contain request characteristic data (characteristic tags) that represent the characteristics of the resource request. The request characteristic fields 1115a to 1115d are shown and explained separately for the sake of clarity, but it should be understood that they can be derived from resource type information, or resource group information, or any other information that forms the resource request.

[0225] In one example, the computation control plane can fetch all tag-based restrictions / allocations 1150 associated with a tag that is part of a request from user 701 from the restriction service data plane 740 (Figure 7) (alternatively, the fetch operation may be performed in the resource control plane 1130). Such tag-based allocations can be applied across the entire tenancy, for example, and do not need to be compartment-specific.

[0226] In one embodiment, the computation control plane can check whether the requested use violates any tag-based restrictions / allocations for any allocation or restriction rules in memory 1150. If the requested use does not violate any resource tag-based allocations, the request may be processed, for example, against a database. If the requested use violates any resource tag-based restrictions / allocations along the compartment tree, the request may be dropped, and a message may be sent to notify the user.

[0227] According to an exemplary embodiment, resource tag-based limits / quotas apply to compartments within a tenancy. According to the exemplary embodiment described below, resource tag-based limits / quotas apply across the entire tenancy, including, for example, all regions that span multiple compartments where the tenancy is enabled. When determining whether a requested instance violates resource tag-based limits / quotas, the compute control plane can ensure that the new request does not violate any of the quotas, for example, via the Service Developer Kit (SDK). If the request exceeds the quota, the compute control plane can drop the request.

[0228] In one embodiment, the compute control plane SDK may reside in all control planes within the cloud infrastructure environment. In one embodiment, the compute control plane can work in conjunction with the restricting services data plane to check new requests against resource tag-based restrictions / allocations.

[0229] In one embodiment, when a client triggers an action to create a cloud resource, the request goes to the resource control plane. The resource control plane queries the restrictions service to determine whether the resource can be safely spun up, taking into account restrictions configured at a selected level, such as the group level. If the restrictions server returns a negative / failed response to the resource control plane, the resource is not created and the request is dropped.

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

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

[0232] According to an example of the embodiment, the tenancy 305 comprises a plurality of compartments 1142, 1144, 1146 for storing resources, and each of the plurality of compartments provides isolation of the set of resources in each compartment from one or more other sets of resources in the other compartments. Resource tags corresponding to the request characteristics of the request Resource usage within a tenancy associated with a particular item is determined collectively across multiple compartments, and this collectively determined usage is compared to multiple tag-based allocations within the tenancy. Resource provisioning requests 1111a-1111d are dropped based on whether the collectively determined usage across multiple compartments exceeds one of the multiple tag-based allocations.

[0233] In an example of the embodiment, the tag-based allocation data 1150 stored in the memory device 1140 represents multiple tag-based allocations of resource provisioning in the tenancy for multiple corresponding resource types in the tenancy. In addition, the request characteristic data 1115a to 1115d of requests 1111a to 1111d to provision resources in the tenant includes resource type data representing first resource types 1112a to 1112d of the requested resources. In an exemplary embodiment, the use of a resource in the tenancy associated with a resource tag corresponding to the first resource type 1112a is determined and compared with a first tag-based allocation 1120a of resource provisioning in the tenancy for the first resource type. A request 1111a to provision a resource of the first resource type 1112a is dropped on the basis that the determined use of the resource in the tenancy, associated with the resource tag corresponding to the first resource type, exceeds a first tag-based allocation of the first resource type, which is stored as, for example, a policy 1120a of resource provisioning in the tenancy.

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

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

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

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

[0238] According to one embodiment, a request to provision a resource is dropped based on the determined usage exceeding one of several tag-based allocations. However, an override request to provision resources for the tenancy may be received by user 701. The resource is selectively provisioned based on the system receiving the override request, according to one embodiment. In addition, resource overuse data is generated based on the system selectively provisioning resources in response to receiving the override request.

[0239] Figure 12 is a flowchart illustrating a method 1200 for restricting or imposing allocations on the provisioning of resources in a cloud infrastructure environment based on resource tags, according to an exemplary embodiment.

[0240] According to Method 1200, in step 1210, a tenancy is provided and tag-based limit / allocation data is stored in memory. In its preferred form, the tenancy is provided by a computer, which includes one or more processors and a memory device operationally coupled to the computer, in an associated cloud infrastructure environment. The memory device stores tag-based control logic that can be executed by the computer to provide tag-based control of resource usage in the associated cloud infrastructure environment. In an exemplary embodiment, the tag-based allocation data stored in the memory device represents multiple tag-based allocations of resource provisioning in the tenancy.

[0241] In step 1220, a request is received to provision resources in the tenancy. The request includes request characteristics data that represents the request characteristics of the request.

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

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

[0244] One or more processors that execute tag-based control logic determine the use of resources associated with a tag, and the determined use is compared with multiple tag-based allocations in step 1260.

[0245] In step 1290, the resource request is dropped by one or more processors executing tag-based control logic, based on the determination in step 1270 that the usage exceeds one of several tag-based allocations.

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

[0247] In one embodiment, the tenancy is provided by providing multiple compartments for storing resources, each of which compartments provides isolation of the set of resources within that compartment from one or more other sets of resources in other compartments. In addition, determining usage involves determining the usage of resources in the tenancy, aggregated across the multiple compartments and associated with resource tags corresponding to the request characteristics of the request, and comparing involves comparing the determined usage, aggregated across the multiple compartments, with multiple tag-based allocations in the tenancy. Furthermore, dropping a request involves dropping a request to provision resources based on the determined usage aggregated across the multiple compartments exceeding one of multiple tag-based allocations.

[0248] According to an example of the embodiment, storing tag-based allocation data includes storing tag-based allocation data in a memory device that represents multiple tag-based allocations of resource provisioning in the tenancy for multiple corresponding resource types in the tenancy. In addition, receiving a request includes receiving a request that includes resource type data representing a first resource type of the requested resource, determining includes determining that the use of the resource in the tenancy associated with the resource tag corresponding to the first resource type is determined, further including comparing the determined use with a first tag-based allocation of resource provisioning in the tenancy for the first resource type, and dropping a request includes dropping the request on the basis that the determined use of the resource in the tenancy associated with the resource tag corresponding to the first resource type exceeds the first tag-based allocation of resource provisioning in the tenancy for the first resource type.

[0249] According to an example of the embodiment, storing tag-based assignment data includes storing tag-based assignment data in a memory device that represents multiple tag-based assignments of resource provisioning in a tenancy, assigned to multiple corresponding user groups in the tenancy; receiving a request includes receiving a request that includes resource type data representing a user group category assigned to a user of the system requesting the resource; determining includes determining the use of the resource in the tenancy associated with the resource tag corresponding to the user group category; comparing includes comparing the determined use with a first tag-based assignment of resource provisioning in the tenancy, assigned to the user group category; and dropping a request includes determining the resource tag corresponding to the user group category. This includes dropping a request based on the determined resource usage in the tenancy associated with a user group category exceeding a first tag-based allocation of resource provisioning in the tenancy assigned to that user group category.

[0250] According to an example of the embodiment, storing tag-based assignment data includes storing in a memory device tag-based assignment data representing tag-based assignments of resource provisioning in a tenancy for multiple resource types in a tenancy, assigned to multiple user groups in a tenancy; receiving a request includes receiving a request that includes 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 assigned to a user of the system requesting the resource. In addition, determining includes determining the use of a resource in a tenancy associated with a resource tag corresponding to a first resource type provisioned to a first user group category; and comparing includes comparing the determined use with a first tag-based assignment of resource provisioning in a tenancy for a first resource type assigned to a first user group category. Furthermore, dropping a request includes dropping a request on the basis that the determined use of resources in the tenancy, associated with resource tags corresponding to a first resource type provisioned in a first user group category, exceeds the first tag-based allocation of resource provisioning in the tenancy for the first resource type assigned to the first user group category.

[0251] According to one embodiment, tag-based allocation data is stored in a memory device, representing tag-based allocation of resource provisioning in a tenancy for multiple resource types in a tenancy, assigned to multiple user groups in the tenancy. The method further includes receiving a first request to track resource usage in a tenancy, the first request including request characteristic data representing a first user group category and a first resource type. In addition, it determines a first use of resources in the tenancy, associated with resource tags corresponding to a first resource type provisioned by the first user group category, and generates resource usage tracking data based on the determined first use of resources in the tenancy for the first resource type provisioned by the first user group.

[0252] The method further includes receiving override requests to provision resources in a tenancy, the system selectively provisioning resources based on the receipt of override requests, and generating resource overuse data based on the system selectively provisioning resources in response to the receipt of override requests.

[0253] According to various embodiments, the teachings herein may be conveniently implemented using one or more conventional general-purpose or dedicated digital computers, computing devices, machines, or microprocessors, including one or more processors, memories, and / or computer-readable storage media programmed in accordance with the teachings herein. Appropriate software coding can be readily prepared by a skilled programmer based on the teachings herein, as will be obvious to those skilled in the art of software technology.

[0254] In some embodiments, the teachings of this disclosure may include a computer program product that uses a computer-readable medium to transmit (e.g., store or carry) instructions for one or more programmable processors or computers to perform any of the processes of this teaching. A non-temporary computer-readable storage medium is one on which instructions that may be used to program a computer to perform any of the following actions are stored. Examples of such storage media may include, but are not limited to, hard disk drives, hard disks, fixed disks, or other electromechanical data storage devices, floppy disks, optical disks, DVDs, CD-ROMs, microdrives, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems, or other types of storage media or devices suitable for the non-temporary storage of instructions and / or data. Another example of a computer-readable medium is a transient medium that transmits such instructions between computer systems or between components of a given computer system. Examples of transient mediums may include, but are not limited to, carrier waves and transmitted signals.

[0255] Therefore, from a certain perspective, systems and methods for supporting tag-based resource limiting or allocation in a cloud infrastructure environment have been described. Cloud administrators generally do not have the ability to limit resource usage in existing clouds. By granting users permission to create resources, users can create any number of resources up to a predefined account limit. Tags are associated with resources to enable administrators to limit user resource usage to an appropriate level by enabling fine-tuned cost control. Resource usage in a tenancy is determined and compared with multiple tag-based allocations, and resource tags corresponding to the request characteristics of the request to provision a resource are associated with the resource, and the request to provision the resource is dropped based on whether the determined usage exceeds one of the multiple tag-based allocations.

[0256] The foregoing descriptions are provided for illustrative and illustrative purposes only. They are not intended to be exhaustive or to limit the scope of protection to the exact form disclosed. Many modifications and variations will be apparent to those skilled in the art. For example, some of the examples provided herein illustrate use with enterprise software application components such as Oracle Fusion Applications, cloud environments such as Oracle Cloud Infrastructure, and cloud services such as Oracle Fusion Analytics. However, according to various embodiments, the systems and methods described herein may be used with other types of enterprise software applications, cloud environments, cloud services, cloud computing, or other computing environments.

[0257] The embodiments have been selected and described to best illustrate the principles of this teaching and their practical application, so that those skilled in the art can understand the various embodiments and modifications suitable for the specific use intended. Their scope is intended to be defined by the claims and their equivalents.< / compute> < / compute>

Claims

1. A system for tag-based control of resource usage in an associated cloud infrastructure environment, A computer containing one or more microprocessors, The system comprises a tenancy defined in the associated cloud infrastructure environment, wherein the tenancy is associated with one or more compartments that control access to a collection of associated resources. The computer includes a memory device for storing tag-based allocation data representing multiple tag-based allocation amounts for resource provisioning in the tenancy, for use in controlling resource usage by the tenancy. In the tenancy, a request is received to provision resources, and the request includes request characteristics data representing the request characteristics of the request, The amount of resource usage in the tenancy associated with the resource tag corresponding to the request characteristics of the request is determined, and the determined amount is compared with the plurality of tag-based allocation amounts associated with the tenancy. A system in which the request to provision the resources in the tenancy is processed or dropped on the basis that the determined usage of the resources in the tenancy or associated compartment exceeds one of the plurality of tag-based allocations.

2. The tenancy comprises a plurality of compartments for storing the resources, and each of the plurality of compartments provides isolation of the set of resources in each compartment from one or more other sets of resources in other compartments. The usage of the resource in the tenancy, associated with the resource tag corresponding to the request characteristics of the request, is determined collectively across the multiple compartments, and the usage determined collectively across the multiple compartments is compared with the multiple tag-based allocations of the tenancy. The system according to claim 1, wherein the request to provision the resource is dropped on the basis that the usage, determined collectively across the multiple compartments, exceeds one of the multiple tag-based allocations.

3. The tag-based allocation data stored in the memory device represents multiple tag-based allocation amounts for resource provisioning in the tenancy for multiple corresponding resource types in the tenancy. In the tenancy, the request characteristics data of the request for provisioning the resource includes resource type data representing a first resource type of the requested resource, The resource usage in the tenancy associated with the resource tag corresponding to the first resource type is determined, and the determined usage is compared with the first tag-based allocation amount for resource provisioning of the first resource type in the tenancy. The system according to claim 1 or 2, wherein the request to provision the resource of the first resource type is dropped on the basis that the determined resource usage in the tenancy, associated with the resource tag corresponding to the first resource type, exceeds the first tag-based allocation for resource provisioning of the first resource type in the tenancy.

4. The tag-based allocation data stored in the memory device represents multiple tag-based allocation amounts of resource provisioning in the tenancy, allocated to multiple user groups corresponding to the tenancy. In the tenancy, the request characteristics data of the request for provisioning the resource includes user group data representing the user group category assigned to the user of the system requesting the resource, The resource usage in the tenancy associated with the resource tag corresponding to the user group category is determined, and the determined usage is compared with a first tag-based allocation of resource provisioning in the tenancy to which the user group category is assigned. The system according to any one of claims 1 to 3, wherein the request to provision the resource is dropped on the basis that the determined resource usage in the tenancy, associated with the resource tag corresponding to the user group category, exceeds the first tag-based allocation of resource provisioning in the tenancy assigned to the user group category.

5. The tag-based allocation data stored in the memory device represents the tag-based allocation amount of resource provisioning in the tenancy for multiple resource types of the tenancy, allocated to multiple user groups of the tenancy. The request characteristics data of the request for provisioning the resource in the tenancy includes: i) resource type data representing a first resource type of the requested resource; and ii) user group data representing a first user group category assigned to the user of the system requesting the resource. The amount of resource usage in the tenancy is determined, associated with the resource tag corresponding to the first resource type provisioned in the first user group category, and the determined amount is compared with the first tag-based allocation of resource provisioning in the tenancy for the first resource type assigned to the first user group category. The system according to any one of claims 1 to 4, wherein the request to provision the resource is dropped on the basis that the determined resource usage in the tenancy, associated with the resource tag corresponding to the first resource type provisioned to the first user group category, exceeds the first tag-based allocation of the resource provisioning in the tenancy for the first resource type assigned to the first user group category.

6. The tag-based allocation data stored in the memory device represents the tag-based allocation amount of resource provisioning in the tenancy for multiple resource types of the tenancy, allocated to multiple user groups of the tenancy. A first request is received to track the resource usage of the tenancy, and the first request includes request characteristic data representing a first user group category and a first resource type. A first usage of resources in the tenancy is determined, associated with a resource tag corresponding to the first resource type provisioned by the first user group category. The system according to any one of claims 1 to 5, wherein resource usage tracking data is generated based on a first usage of the determined resource in the tenancy of the first resource type provisioned by the first user group category.

7. The request to provision the said resource is dropped on the basis that the determined usage exceeds one of the multiple tag-based allocations. An override request is received to provision the resources of the aforementioned tenancy. The resources are selectively provisioned based on the system receiving the override request. The system according to any one of claims 1 to 6, wherein resource overuse data is generated based on the selective provisioning of the resources in response to the system receiving the override request.

8. A method for tag-based control of resource usage in an associated cloud infrastructure environment, The computer comprises one or more processors and a memory device operationally coupled to the computer, and the computer provides tenancy in the associated cloud infrastructure environment, wherein the memory device stores tag-based allocation data representing multiple tag-based allocation amounts for resource provisioning in the tenancy for use in controlling resource usage by the tenancy, and the method further, The method includes receiving a request to provision resources in the tenancy, the request including request characteristics data representing the request characteristics of the request, and the method further includes: One or more processors execute the tag-based control logic to determine the amount of resource usage in the tenancy, which is associated with the resource tag corresponding to the request characteristics of the request. The one or more processors execute the tag-based control logic to compare the determined usage with the plurality of tag-based allocations associated with the tenancy, A method comprising processing the request to provision the resource in the tenancy, or dropping the request to provision the resource on the basis that the determined usage of the resource in the tenancy or associated compartment exceeds one of the plurality of tag-based allocations.

9. Providing the tenancy includes providing a plurality of compartments for storing the resources, wherein each of the plurality of compartments provides isolation of the set of resources in each compartment from one or more other sets of resources in other compartments. Determining the usage includes determining the usage of the resources in the tenancy, collectively across the multiple compartments, and associated with the resource tags corresponding to the request characteristics of the request. The comparison includes comparing the usage determined collectively across the multiple compartments with the multiple tag-based allocations of the tenancy. The method according to claim 8, wherein the dropping includes dropping the request to provision the resource on the basis that the usage determined collectively across the multiple compartments exceeds one of the multiple tag-based allocations.

10. Storing the tag-based allocation data includes storing in the memory device tag-based allocation data representing multiple tag-based allocation amounts for multiple corresponding resource types of the tenancy and resource provisioning in the tenancy, Receiving the request includes receiving a request that includes resource type data representing a first resource type of the requested resource, The determination described above includes determining the amount of resource usage in the tenancy associated with the resource tag corresponding to the first resource type, The comparison described above includes comparing the determined usage with the first tag-based allocation of resource provisioning in the tenancy for the first resource type, The method according to claim 8 or 9, wherein dropping the request includes dropping the request on the basis that the determined resource usage in the tenancy, associated with the resource tag corresponding to the first resource type, exceeds the first tag-based allocation for the resource provisioning of the first resource type in the tenancy.

11. Storing the tag-based allocation data includes storing in the memory device tag-based allocation data representing multiple tag-based allocation amounts of resource provisioning in the tenancy, which are allocated to multiple corresponding user groups of the tenancy. Receiving the aforementioned request includes receiving a request that includes resource type data representing the user group category assigned to the user requesting the resource, The aforementioned determination includes determining the amount of resource usage in the tenancy associated with the resource tag corresponding to the user group category, The comparison described above includes comparing the determined usage with the first tag-based allocation of resource provisioning in the tenancy assigned to the user group category, The method according to any one of claims 8 to 10, wherein dropping the request is based on the fact that the determined resource usage in the tenancy, associated with the resource tag corresponding to the user group category, exceeds the first tag-based allocation of resource provisioning in the tenancy assigned to the user group category.

12. Storing the tag-based allocation data includes storing in the memory device tag-based allocation data representing the amount of tag-based allocation for resource provisioning in the tenancy, for multiple resource types in the tenancy, assigned to multiple user groups in the tenancy. Receiving the aforementioned request includes receiving a request that includes resource type data comprising i) resource type data representing a first resource type of the requested resource, and ii) user group data representing a first user group category assigned to the user requesting the resource, The determination described above includes determining the amount of resource usage in the tenancy associated with the resource tag corresponding to the first resource type provisioned in the first user group category, The comparison described above includes comparing the determined usage with a first tag-based allocation of resource provisioning in the tenancy for the first resource type assigned to the first user group category. The method according to any one of claims 8 to 11, wherein dropping the request is based on the fact that the determined resource usage in the tenancy, associated with the resource tag corresponding to the first resource type provisioned in the first user group category, exceeds the first tag-based allocation for resource provisioning in the tenancy for the first resource type assigned to the first user group category.

13. The above method further, The memory device stores tag-based allocation data representing the tag-based allocation amount of resource provisioning in the tenancy for multiple resource types of the tenancy, which is assigned to multiple user groups of the tenancy. The method includes receiving a first request to track the resource usage of the tenancy, wherein the first request includes request characteristic data representing a first user group category and a first resource type, and the method further includes: Determining a first usage of resources in the tenancy, associated with a resource tag corresponding to the first resource type provisioned by the first user group category, The method according to any one of claims 8 to 12, further comprising generating resource usage tracking data based on a first usage of the determined resources in the tenancy of the first resource type provisioned by the first user group category.

14. The above method further, Receiving an override request to provision the resources of the said tenancy, Selectively provisioning the resource based on receiving the override request, The method according to any one of claims 8 to 13, comprising generating resource overuse data based on the fact that the resource is selectively provisioned in response to receiving the override request.

15. A program for causing a computer to perform the method described in any one of claims 8 to 14.

Images