Patent Description:
To leverage the numerous advantages of cloud computing, many cloud service providers purchase access to cloud resources provided by a cloud platform to enable, enhance, or otherwise operate their business. In turn, cloud service providers can configure various cloud resources allocated by the cloud platform with specific features and/or functions to offer products and/or services to their respective customers or users (often referred to collectively as tenants). As discussed, a cloud platform can serve many cloud service providers in various geographic locations. In addition, those cloud service providers can themselves have many tenants or customers. Thus, the number of end-users utilizing resources of a particular cloud platform can rapidly balloon into the millions as more service providers take to cloud computing. At such scale, security of individual tenants' computing resources and data is of utmost concern to cloud platforms and cloud service providers alike. To maintain security, individual tenants are typically assigned their own subscriptions to allocate cloud resources, thereby restricting unauthorized access to their data.

Unfortunately, as mentioned above, typical solutions for maintaining security boundaries between tenants requires that every individual tenant be assigned a subscription. Naturally, as the number of tenants grows into the millions, managing the multitude of subscriptions becomes cumbersome and impractical for individual cloud service providers. Furthermore, the computing and storage overhead created by assigning and managing millions of subscriptions places further burden on the overall cloud platform. For example, a small service provider may feasibly manage individual subscriptions for a few hundred tenants. However, as the service provider's tenancy grows into the thousands or even millions, the service provider must dedicate more and more resources and engineering effort to manage the tenancy's subscriptions.

Managing subscriptions in this way often unduly hampers the operations of service providers and can lead to compromised tenant security and ultimately a degraded experience for individual Thhis is tenants. For instance, if a service provider is unable to keep up with subscription management for a large number of tenants, breaches in security at the individual tenant level can subsequently go undetected. Such security breaches can lead to widespread security compromise and severe disruptions to service as the service provider must take portions of the service offline to address the security issue. In addition, the service provider must commit significantly more resources and engineering effort to address these issues than if a more streamlined way of managing subscriptions had been in place allowing the service provider to detect the security breach earlier.

It is with respect to these and other consideration that the disclosure made herein is presented. <CIT> describes an infrastructure for providing cloud services. A cloud infrastructure system, including one or more computing devices, performs a method for processing a subscription order for one or more services provided to a customer by the cloud infrastructure system. The method includes storing a subscription order information related to a subscription order received from a customer for one or more services provided by the cloud infrastructure system. The method includes identifying a process associated to be used for servicing the subscription order. The process comprises one or more execution steps for provisioning one or more resources for the one or more services identified in the subscription order. The method includes orchestrating the performance of the one or more execution steps corresponding to the process. The cloud infrastructure system sends a notification to a customer indicating a status of the subscription order.

<CIT> describes a cloud resource system including a resource engine and a configuration engine. The resource engine can identify a cloud resource based on a template and assign the cloud resource based on a subscription and the template. The configuration engine can maintain a pool of cloud resource object instances.

The disclosed techniques improve the efficiency and functionality of cloud services by providing a system for sharing individual subscriptions among multiple tenants. Generally described, a cloud service provider utilizes a location-based manager to retrieve a pool of subscriptions from a cloud platform to allocate cloud resources to various tenants at a resource unit (e.g., a server farm). Individual subscriptions within the pool can define a set of cloud resources of the server farm (e.g., compute, storage, etc.) and a time period during which a tenant associated with the subscription may utilize the set of cloud resources.

In various examples, the location-based manager can assign one or multiple subscriptions for a resource unit to share amongst multiple tenants. Stated another way, while each tenant can be allocated their own subset of the set of cloud resources defined by the subscription, every tenant is nonetheless associated with the same subscription to the cloud resources provided by the cloud platform. In this way, security boundaries between individual tenants can be maintained while also dramatically reducing the number of subscriptions a cloud service provider must manage. In addition, by assigning subscriptions at the granularity of resource units rather than tenants, the location-based manager can enhance the security of the cloud platform by creating a logical zone about individual resource units to serve as an additional security boundary. In the event that security boundaries between individual tenants fail to contain a security breach, the additional security boundary provided by the multi-tenant shared subscription can contain security issues thereby protecting other resource units from similar exploits.

As will be further discussed below, the location-based manager can be assigned a geographic region (e.g., a state, a country, a continent, etc.) that contains multiple geographic areas. Each geographic area can in turn contain multiple resource units, e.g., server farms, each providing cloud resource access to a set of tenants. In such situations, the location-based manager can be configured to manage subscriptions for many resource units located within the assigned geographic region. Furthermore, a cloud service provider can deploy multiple location-based managers to efficiently serve tenants across many geographic regions. This is possible due to the
drastic reduction in the number of subscriptions required to serve every tenant within a geographic region.

In contrast to existing solutions, assigning subscriptions at the resource unit level dramatically streamlines the process of subscription management for a cloud service provider by reducing the number of subscriptions needed to serve a given number of tenants. As discussed above, existing solutions require that ever tenant be assigned a unique subscription for access to the cloud platform's resources. Thus, as a cloud service provider's tenancy grows into the hundreds of thousands or even millions, managing the corresponding list of subscriptions becomes impractical requiring exorbitant commitment of resources and engineering effort. By reducing the number of subscriptions using the techniques described herein, a cloud service provider can realistically scale up to serve a large and geographically dispersed tenancy while maintaining and even enhancing security to ensure a seamless user experience.

As discussed above, and further herein, by sharing subscriptions amongst multiple tenants, the disclosed system can enable cloud service providers to efficiently manage subscriptions more efficiently and effectively. This is thanks to the significant reduction in the number of subscriptions required for a given number of tenants as a result of assigning multiple tenants to a subscription. In existing solutions that do not use multi-tenant subscription sharing, a cloud service provider must provide every tenant with a corresponding subscription which can cause subscription to become impractical as the number of tenants grows. This can potentially lead to compromised system security and ultimately a degraded user experience. By introducing subscription sharing, cloud service providers can easily and securely manage subscriptions for a large number of tenants thereby conserving computing resources and improving performance. Features and technical benefits other than those explicitly described above will be apparent from a reading of the following Detailed Description and a review of the associated drawings. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The term "techniques," for instance, may refer to system(s), method(s), computer-readable instructions, module(s), algorithms, hardware logic, and/or operation(s) as permitted by the context described above and throughout the document.

The techniques described herein provide systems for optimizing the use of computing resources and to improve the operation of cloud platforms that provide cloud resources for use by tenants of a cloud service provider. Cloud resources can include computing resources, storage, and other components for executing applications, storing data, and the like. The cloud service provider can utilize one or several location-based managers to administrate various cloud resources. Specifically, the location-based manager can acquire a pool of subscriptions from the cloud platform and assign subscriptions for sharing amongst multiple tenants. Individual subscriptions within the pool of subscriptions can define various parameters such as a cloud resource allocation (e.g., a number of cores, an amount of storage space), a time period during which the subscription is active, a roster of tenants associated with the subscription, and so forth.

The disclosed techniques address several technical problems associated with subscription management in cloud service providers that utilize cloud platforms for cloud resource access. For example, to maintain security boundaries between individual tenants, typical systems assign every tenant a subscription. However, as the number of tenants grows into the millions, subscription management becomes more and more cumbersome if not ultimately infeasible leading to degraded performance and user experience. By sharing individual subscriptions among multiple tenants, the system greatly reduces the number of subscriptions to be managed thereby dramatically streamlining the process of subscription management. Naturally, streamlining subscription management leads to reductions in the resources and engineering effort required to manage the set of subscriptions for a given number of tenants. Consequently, the disclosed techniques improve the performance of cloud platforms and associated cloud service providers, with particular benefit as the number of tenants grows large.

In another example of the technical benefit of the present disclosure, the multi-tenant subscription sharing described herein improves the security of cloud platforms and consequently cloud service providers. This is possible due to the multi-tenant subscription sharing discussed above and in further detail below. By reducing the number of subscriptions to manage, security breaches among individual tenants can be detected early on and quickly addressed or contained. In addition, by assigning subscriptions at resource unit granularity rather than to individual tenants, the location-based manager can create a logical zone about individual resource units that can isolate a resource unit from other resource units. Thus, the techniques described herein enable a system to maintain existing security boundaries between tenants as well as enhance security by implementing a security boundary between resource units. Furthermore, by isolating individual resource units, the disclosed system can improve the performance of the various resource units. By minimizing the impact of security breaches, the system can consequently experience reduced downtime leading to improved performance and an enhanced user experience.

Various examples, scenarios, and aspects that enable secure multi-tenant subscription sharing are described below with reference to <FIG>.

<FIG> illustrates an example system <NUM> in which a cloud service provider <NUM> utilizes a location-based manager <NUM> to manage a geographic area <NUM> containing multiple server farms 108A - 108N. In various examples, a geographic area can be an area defined by current geographic boundaries. In a specific example, a geographic area can be defined within the system as a well-defined subdivision of a greater region such as county of the United States, a city or municipality, and so forth. In other examples, a geographic area may be defined as an area encompassed by a certain radius (e.g., <NUM> miles). In addition, as will be described in more detail below, a location-based manager <NUM> deployed by the cloud service provider <NUM> can be assigned multiple geographic regions to manage, where an individual geographic region (e.g., a country) includes multiple geographic areas.

As discussed above, a geographic area <NUM> can include multiple server farms 108A-108N that are configured to provide access to computing resources 110A-110N and storage 112A-112N, which can collectively be referred to as cloud resources. In addition, each server farm <NUM> can be assigned a group of tenants that utilize the computing resources <NUM> and/or storage <NUM> of a server farm <NUM> to implement applications, store data, and the like. In various examples, a letter such as L, M, N, or P will be used to indicate a plurality of a particular item (e.g., server farms 108A-108N). It should be appreciated that such letters can represent a positive integer such as tens, hundreds, thousands, etc. and that different letters can represent different quantities of different items (e.g., tenants 114A-<NUM> and tenants 115A-<NUM>).

To enable the multi-tenant subscription sharing features discussed above, the location-based manager <NUM> can acquire a pool of subscriptions <NUM> from a cloud platform (see <FIG>). The location-based manager <NUM> can then assign subscriptions <NUM> from the pool of subscriptions <NUM> for the various server farms <NUM> under its management. As discussed above, and in further detail below, individual subscriptions <NUM> can define various parameters such as an allocation of cloud resources (e.g., computing resources <NUM>, storage <NUM>), a time period during which the subscription <NUM> is active, and a roster of tenants <NUM> associated with the subscription <NUM>. The location-based manager <NUM> can then associate the subscription <NUM> with multiple tenants <NUM>. It should be appreciated that the location-based manager <NUM> can assign one or multiple subscriptions <NUM> for a particular server farm <NUM>. In various examples, the number of subscriptions <NUM> associated with a server farm <NUM> can be automatically determined by the location-based manager <NUM> or configured as a pre-determined value by an administrative entity such as a network engineer or system administrator. For instance, a large server farm <NUM> having large amount of computing resources <NUM> and storage <NUM> may require multiple subscriptions <NUM> to efficiently subdivide the available cloud resources whereas a smaller server farm may only require a single subscription <NUM>.

As discussed above, a subscription can define an allocation of cloud resources such as computing resources <NUM> and storage <NUM>. The available cloud resource allocation can then be subdivided among a group of tenants <NUM> associated with the subscription <NUM>. In various examples, and discussed further below, the cloud resource allocation for an individual tenant can be determined in several ways. For instance, a tenant may request a specific amount of computing resources <NUM> and/or storage <NUM>. In a specific example, a tenant 114A wishing to implement an application on the server farm may request a specific amount of computing resources <NUM> (e.g., six cores, twelve cores, etc.) and a specific volume of storage <NUM> for data associated with the tenant's application (e.g., 25GB). In another specific example, an allocation of cloud resources for tenant 114A can be determined automatically by the location-based manager <NUM>. In such a scenario, tenant 114A may not be well apprised of the hardware requirements of their application. Accordingly, the tenant 114A can provide the cloud service provider <NUM> with information on their desired use case (e.g., a database, a machine learning application, etc.). In response, the location-based manager <NUM> can allocate an appropriate amount of computing resource <NUM> and/or storage <NUM> using the information provided by the tenant 114A. In addition, the location-based manager <NUM> can analyze other applications on server farms 108A-108N under its management as well as receive data from other location-based managers (see <FIG>) to determine an appropriate resource allocation for the tenant 114A.

In each of the above examples, the resource allocation of an individual tenant <NUM> can be adjusted over time to suit changing operational needs of the tenants <NUM>. For example, a tenant 114A may request additional computing resources <NUM> as their application expands and grows in complexity. In another instance, the location-based manager <NUM> can automatically adjust the resource allocation of a tenant 114A based on various criteria such as an activity history associated with a particular tenant, previous versions of an application associated with the tenant 114A, the amount of available computing resources <NUM> and/or storage <NUM>, and the like.

As discussed above, each tenant <NUM> is assigned a portion of the cloud resource allocation defined in the subscription <NUM>. Consequently, individual tenants <NUM> may only access computing resources <NUM> and storage <NUM> assigned to them by the location-based manager <NUM>. For example, a tenant 114A is may only access the portion of the computing resources 110A and storage 112A assigned by the location-based manager <NUM> and not the resources of other tenants 114B-<NUM> utilizing server farm 108A. Furthermore, by isolating individual tenants from each other within a server farm <NUM>, in the event a single tenant 114A suffers a security breach, such as by a malicious attacker from outside the cloud service provider <NUM>, the system can contain the security breach to the resources associated with the compromised tenant 114A and prevent more widespread damage to the system. In this way, the cloud service provider <NUM> can ensure that security boundaries between individual tenants are maintained and that each tenant <NUM> receives a stable user experience.

In addition to maintaining security boundaries between individual tenants <NUM>, the location-based manager <NUM> can additionally assign logical zones 120A-120N that encompasses an individual corresponding server farm 108A-108N. The logical zones 120A-120N serve to logically isolate a particular server farm 108A from other server farms 108B-108N under management by the location-based manager <NUM>. By isolating individual server farms <NUM> from each other, the system can prevent unauthorized access to a computing resources <NUM> or storage <NUM> of a server farm <NUM> from tenants <NUM> of another server farm. A logical zone <NUM> can be implemented using any method to logically isolate the server farms 108A-108N from each other. For instance, the logical zones 120A-120N can be implemented using virtual networks using various components such as virtual local area networks (VLANs), virtual switches, and the like. In addition, the VLANs can be configured to utilize standard networking protocols such as IPv4 or IPv6 which the server farms <NUM> can utilize for communication with the location-based manager <NUM>, the tenants <NUM>, and so forth.

As discussed above, by assigning a logical zone <NUM> to each server farm <NUM>, the location-based manager <NUM> can further enhance security of the cloud service provider <NUM>. Since server farms 108A-108N are logically isolated from each other, the logical zones 120A-120N can provide additional security boundaries between server farms 108A-108N in addition to the security boundaries that isolate individual tenants <NUM>. Thus, if the security of a single tenant <NUM> is compromised such that the security boundary isolating the tenant <NUM> is breached, the security issue can still be contained within a single server farm <NUM>. For instance, tenant 114A can suffer a security breach compromising the security boundary that isolates tenant 114A from tenants 114B-<NUM> of server farm 108A. However, thanks to the logical zone 120A that bounds server farm 108A, the security breached can be contained within server farm 108A by the security boundary provided by the logical zone 120A.

Turning now to <FIG>, aspects of a cloud platform <NUM> containing a cloud service provider <NUM> are shown and described. As discussed above, a cloud service provider <NUM> can utilize infrastructure such as server farms <NUM> and tools such as location-based manager <NUM> provided by a cloud platform <NUM> to offer products and services to tenants <NUM>. As will be discussed with regard to <FIG>, a cloud service provider <NUM> can deploy several location-based managers 104A-104N to manage server farms <NUM> that are dispersed across many geographic regions 204A-204N. It should be appreciated that while <FIG> illustrates a single cloud service provider <NUM>, cloud platform <NUM> can allow any number of cloud service providers <NUM> to utilize infrastructure provided by the cloud platform <NUM>.

As shown and described with respect to <FIG>, a location-based manager <NUM> can be configured to manage several server farms 108A-108N located within a geographic area <NUM>. To address diverse technical requirements, location-based managers 104A-104N can be optionally assigned a corresponding geographic region 204A-204N containing several geographic areas such as geographic areas 105A-<NUM> with each geographic region containing several server farms 108A-108N. In this way, a cloud service provider <NUM> can seamlessly scale operations as its associated tenancy grows in size and becomes more geographically dispersed.

In similar fashion to geographic areas <NUM>, a geographic region <NUM> can be defined using well-known boundaries such as country or state lines. For example, location-based manager 104A may be assigned geographic region 204A associated with the state of Washington while location-based manager 104B may be assigned geographic region 204B associated with the state of Oregon and so forth. Accordingly, geographic areas 105A-<NUM> can be associated with the various counties of Washington state, Similarly, geographic areas 106A-<NUM> can be associated with the various counties of Oregon and so forth. Alternatively, the geographic regions <NUM> can be defined at larger scales. For instance, location-based manager 104A can be assigned geographic region 204A corresponding to the Northwestern United States, which can include the states of Washington, Oregon, Idaho, Montana, and Wyoming. In this example, the geographic areas 105A-<NUM> that make up the geographic region 204A can be defined as an area encompassed within a certain radius as discussed above (e.g., <NUM> miles). Similarly, location-based manager 104B can be assigned geographic region 204B corresponding to the Northeastern United States and so forth. Upon assigning each location-based manager 104A-104N an associated geographic region 204A-204N, the location-based managers 104A-104N can acquire a pool of subscriptions 118A-118N from the pools of subscriptions <NUM> at the cloud platform <NUM>. The individual pools of subscriptions <NUM> associated with each location-based manager <NUM> can differ based on the needs of tenants <NUM> served by the location-based manager <NUM>, the size of the geographic region <NUM> managed by the location-based manager <NUM>, the amount of computing resources <NUM> and/or storage <NUM> available to the location-based manager <NUM>, among other factors. In a specific example, a location-based manager 104A may oversee a geographic region 204A containing several large server farms <NUM> that house a particularly high volume of computing resources <NUM> or storage <NUM>. Thus, to efficiently allocate resources and serve tenants <NUM>, location-based manager 104A may require a large pool of subscriptions 118A. Conversely, location-based manager 104B may manage a geographic region 204B that does not contain any large server farms and thus does not require as many subscriptions. Therefore, location-based manager 104B can acquire a smaller pool of subscriptions 118B in comparison to location-based manager 104A. Individual pools of subscriptions <NUM> can be preconfigured at the cloud platform <NUM> prior to acquisition by location-based managers 104A-104N by an administrative entity such as a network engineer, a system administrator, and the like. Preconfigured pools of subscriptions <NUM> can be determined based on engineering analysis by the administrative entity, feedback based on previously assigned pools of subscriptions <NUM>, and other factors. In other examples, individual pools of subscriptions <NUM> can be determined by the location-based manager <NUM> when acquiring the pool of subscriptions <NUM> from the cloud platform <NUM>. As discussed above, a pool of subscriptions <NUM> for a particular location-based manager <NUM> can be customized for the needs of the location-based manager <NUM>. In addition, a location-based manager can determine the pool of subscriptions <NUM> it requires based on availability of resources in server farms <NUM> within its associated geographic region <NUM>, the number of tenants <NUM> served by the location-based manager <NUM>, the technical needs of the tenants <NUM>, and other factors. Furthermore, individual pools of subscriptions <NUM> can be adjusted by an associated location-based manager <NUM>, over time to suit the needs of tenants <NUM> served by the location-based manager <NUM>. For instance, location-based manager 104A can receive an influx of new tenants <NUM> in geographic region 204A. In response, the location-based manager 104A may determine that a larger pool of subscriptions 118A is needed to efficiently allocate the cloud resources under its management. Location-based manager 104A can send a request to the cloud platform <NUM> to acquire an updated pool of subscriptions 118A from the pools of subscriptions <NUM>. In other examples, location-based manager 104A can acquire an updated pool of subscriptions 118A in response to cloud resource availability, increased utilization of cloud resources, among other factors.

Turning now to <FIG>, properties of an individual subscription <NUM> are illustrated and described. As described above, a location-based manager <NUM> can utilize a subscription <NUM> to allocate cloud resources such as computing resources <NUM> and storage <NUM> to a group of tenants <NUM> where each tenant is assigned a portion of the subscription <NUM>. In addition, assigning each tenant <NUM> an associated portion of the subscription <NUM> enables the system to maintain security boundaries between individual tenants to prevent unauthorized access to resources by the tenants <NUM> and to contain potential security breaches.

As discussed, each subscription <NUM> can include a cloud resource allocation <NUM> defining the amount of cloud resources (e.g., computing resources <NUM> and storage <NUM>) that are available for portioning among a group of tenants <NUM> sharing the subscription <NUM>. In various examples, cloud resource allocation <NUM> can define a specific amount of computing resources <NUM> and storage <NUM> which tenants <NUM> associated with the subscription <NUM> can utilize. For instance, cloud resource allocation <NUM> can specify that subscription <NUM> is allocated five hundred computing cores and one terabyte (TB) of storage located at a server farm <NUM>. In this example, as described above, tenants <NUM> associated with subscription <NUM> can request a specific amount of resources (e.g., <NUM> cores and <NUM> gigabytes). Location-based manager <NUM> can alternatively automatically assign portions of cloud resource allocation <NUM> to individual tenants <NUM>.

Cloud resource allocation <NUM> can also be adjusted over time to suit changing needs of tenants <NUM> and associated applications. For instance, a tenant 114A may require additional cloud resources as time goes on, however all available resources in cloud resource allocation <NUM> may have been allocated to tenants 114B-<NUM>. Location-based manager <NUM> can modify the parameters of cloud resource allocation <NUM> to allow tenant 114A to request additional resources. Alternatively, location-based manager <NUM> can acquire a new subscription <NUM> with a different cloud resource allocation <NUM> that specifies an increased amount of available cloud resources at server farm 108A.

Subscription <NUM> can also include a subscription time period <NUM> that specifies a time period during which cloud resources allocated by cloud resource allocation <NUM> are available for use by tenants <NUM> associated with subscription <NUM>. For instance, subscription time period <NUM> can specify that subscription <NUM> is valid for a period of one month. Accordingly, tenants <NUM> associated with subscription <NUM> can access cloud resources at server farm <NUM> for one month. Upon expiration of subscription time period <NUM>, tenants <NUM> associated with subscription <NUM> can request a renewed subscription <NUM> which can be assigned by location-based manager <NUM>. Alternatively, location-based manager <NUM> can detect that subscription time period <NUM> is nearing expiration can query tenants <NUM> associated with subscription <NUM> to renew subscription <NUM>. Location-based manager <NUM> can then automatically assign tenants <NUM> with a new subscription <NUM> having an updated subscription time period <NUM>. In still other examples, location-based manager <NUM> can modify subscription time period <NUM> to extend access for associated tenants <NUM> upon expiration of subscription time period <NUM>.

As discussed above, an individual server farm <NUM> can have one or multiple associated subscriptions <NUM>. Thus, it should be understood that varying subscriptions <NUM> can have varying subscription time periods <NUM>. For instance, a subscription <NUM> associated with server farm 108A may have an associated subscription time period <NUM> of two months whereas another subscription <NUM> can have an associated subscription time period <NUM> of six months. In addition, location-based manager <NUM> can assign subscriptions to tenants <NUM> based on how long a tenant <NUM> requests to have access to cloud resources at server farm 108A. For example, a tenant <NUM> may requests cloud resource access for a period of two months. Location-based manager <NUM> can accordingly associate tenant <NUM> with a subscription <NUM> having a subscription time period <NUM> of two months. Subscription <NUM> can additionally contain a server farm identification <NUM> that specifies a server farm <NUM> associated with subscription <NUM>. Server farm identification <NUM> can include data to identify associated server farm <NUM> such as serial numbers, IP addresses, geographic coordinates, and so forth. Similarly, subscription <NUM> can include billing policy <NUM> that specifies terms for tenants to purchase access to cloud resources provided by cloud platform <NUM> and/or products or services provided by cloud service provider <NUM>. For example, billing policy <NUM> can include fees paid periodically by individual tenants (e.g., once a month).

As discussed above, sharing a subscription <NUM> among multiple tenants allows a cloud service provider <NUM> to maintain security boundaries for individual tenants <NUM> while also dramatically reducing the number of subscriptions required to do so. This is possible by including security parameters <NUM> within subscription <NUM>. Security parameters <NUM> utilize a tenant roster <NUM> in conjunction with tenant roles <NUM> to set appropriate security boundaries for individual tenants and maintain a secure cloud environment. When assigning a subscription to various tenants <NUM>, location-based manager <NUM> can enumerate each associated tenant <NUM> in tenant roster <NUM>. A tenant <NUM> within tenant roster <NUM> can be identified using any suitable method such as a username, a unique identification number, an IP address, and so forth. In addition, tenants can be identified using any combination of the above-mentioned attributes or other attributes.

Location-based manager <NUM> can also assign a role to each tenant of tenant roster <NUM> from tenant roles <NUM>. Tenant roles <NUM> allow the location-based manager <NUM> to securely grant access to cloud resources to various tenants <NUM>. Tenant roles <NUM> can include roles of various privilege within the system. For instance, a tenant <NUM> may be assigned an "administrator" role which allows tenant <NUM> to freely access and modify data in their associated allocation of storage <NUM> among other benefits. In another example, a tenant <NUM> may be assigned a "reader" role which restricts tenant <NUM> from modifying data in their associated storage <NUM>. In a specific example, an allocation of computing resources <NUM> and storage <NUM> is shared by multiple tenants <NUM> belonging to the same organization (e.g., a shared workspace, a shared database, etc.). In this example, certain tenants <NUM> can be assigned the role of "administrator" while others are assigned as "reader. " In this way, the system can maintain secure access to cloud resources and applications for individual tenants even when tenants share a cloud resource allocation.

Furthermore, security parameters <NUM> can include application registry <NUM> which identifies applications utilizing cloud resources at server farm <NUM> associated with subscription <NUM> in server farm identification <NUM>. Upon requesting cloud resource access and being added to the tenant roster, tenants <NUM> can also register their associated applications with location-based manager <NUM> which is tracked in application registry <NUM>. For instance, if a tenant <NUM> wishes to implement a cloud database application, the application must be registered with the location-based manager in the application registry <NUM>. Thus, each tenant utilizing cloud resources of server farm <NUM> is associated with at least one application thereby streamlining subscription management and enhancing security of cloud service provider <NUM>.

Turning now to <FIG>, aspects of an individual tenant <NUM> are illustrated and described. As discussed above, individual tenants have several associated attributes such as a cloud resource allocation which can include computing resource allocation <NUM> and storage allocation <NUM>. Computing resource allocation <NUM> and storage allocation <NUM> can be determined based on a request generated by tenant <NUM> for access to a specific amount of cloud resources (e.g., <NUM> cores of compute, <NUM> GB of storage). In other examples, computing resource allocation <NUM> and storage allocation <NUM> can be configured by an administrative entity associated with tenant <NUM>. For instance, tenant <NUM> can be a computing device associated with a staff member at a particular company. In this example, computing resource allocation <NUM> and storage allocation <NUM> can be determined by the staff member's supervisor, IT department, and the like. In still other examples, computing resource allocation <NUM> and storage allocation <NUM> can be automatically assigned to tenant <NUM> by location-based manager <NUM> based on availability of cloud resources, current network traffic, user activity associated with the tenant, and so forth.

Tenant <NUM> can additionally contain data defining relationships between tenant <NUM>, cloud service provider <NUM>, and cloud platform <NUM> such as associated applications <NUM>, roles <NUM>, and associated subscriptions <NUM>. As discussed above, each tenant <NUM> is associated with an application in application registry <NUM>. It should be understood that tenant <NUM> can be associated with one or multiple applications. For example, tenant <NUM> may implement a database and a deep learning application utilizing server farm <NUM>, thus tenant <NUM> must register each application with location-based manager <NUM>. Similarly, tenant <NUM> can be associated with a role <NUM> or multiple roles. For instance, tenant <NUM> may belong to an organization that utilizes a shared cloud workspace housed at server farm <NUM> for communication and collaboration. In this case, tenant <NUM> can be assigned a role that enables them to communicate and share data but not modify some data such as underlying settings of the shared workspace. Conversely, in a personal workspace associated with tenant <NUM>, tenant <NUM> may be assigned a role that allows them to freely access and modify data. For tenant <NUM> to have multiple roles <NUM>, tenant <NUM> can also be associated with one or multiple subscriptions <NUM>. As discussed, tenant <NUM> can have access to multiple spaces that utilize different allocations of cloud resources such as the above-mentioned shared workspace and personal workspace. Consequently, tenant <NUM> can be associated with subscriptions that correspond to each of those spaces.

Referring now to <FIG>, aspects of a routine <NUM> for enabling secure multi-tenant subscription sharing are shown and described below. For ease of understanding, the processes discussed in this disclosure are delineated as separate operations represented as independent blocks. However, these separately delineated operations should not be construed as necessarily order dependent in their performance. The order in which the process is described is not intended to be construed as a limitation, and any number of the described process blocks may be combined in any order to implement the process or an alternate process. Moreover, it is also possible that one or more of the provided operations is modified or omitted.

The particular implementation of the technologies disclosed herein is a matter of choice dependent on the performance and other requirements of a computing device. Accordingly, the logical operations described herein are referred to variously as states, operations, structural devices, acts, or modules. These states, operations, structural devices, acts, and modules can be implemented in hardware, software, firmware, in special-purpose digital logic, and any combination thereof. It should be appreciated that more or fewer operations can be performed than shown in the figures and described herein. These operations can also be performed in a different order than those described herein.

It also should be understood that the illustrated methods can end at any time and need not be performed in their entireties. Some or all operations of the methods, and/or substantially equivalent operations, can be performed by execution of computer-readable instructions included on a computer-storage media, as defined below. The term "computer-readable instructions," and variants thereof, as used in the description and claims, is used expansively herein to include routines, applications, application modules, program modules, programs, components, data structures, algorithms, and the like. Computer-readable instructions can be implemented on various system configurations, including single-processor or multiprocessor systems, minicomputers, mainframe computers, personal computers, hand-held computing devices, microprocessor-based, programmable consumer electronics, combinations thereof, and the like. Thus, it should be appreciated that the logical operations described herein are implemented (<NUM>) as a sequence of computer implemented acts or program modules running on a computing system and/or (<NUM>) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as states, operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof.

For example, the operations of the routine <NUM> are described herein as being implemented, at least in part, by modules running the features disclosed herein can be a dynamically linked library (DLL), a statically linked library, functionality produced by an application programing interface (API), a compiled program, an interpreted program, a script or any other executable set of instructions. Data can be stored in a data structure in one or more memory components. Data can be retrieved from the data structure by addressing links or references to the data structure. Although the following illustration refers to the components of the figures, it should be appreciated that the operations of the routine <NUM> may be also implemented in many other ways. For example, the routine <NUM> may be implemented, at least in part, by a processor of another remote computer or a local circuit. In addition, one or more of the operations of the routine <NUM> may alternatively or additionally be implemented, at least in part, by a chipset working alone or in conjunction with other software modules. In the example described below, one or more modules of a computing system can receive and/or process the data disclosed herein. Any service, circuit or application suitable for providing the techniques disclosed herein can be used in operations described herein. With reference to <FIG>, routine <NUM> beings at operation <NUM> where a location-based manager acquires a pool of subscriptions from a cloud platform. As discussed, the subscriptions define a set of cloud resources provided by the cloud platform that are available for use by a cloud service provider for a defined period of time.

Proceeding to operation <NUM>, the location-based manager assigns at least one subscription for a resource unit (e.g., a server farm) of the cloud platform. As described above, the at least one subscription is shared among a plurality of tenants that each request access to cloud resources provided by the resource unit.

Next, at operation <NUM>, the location-based manager creates a logical zone about the resource unit that effectively isolates the resource unit from other resource units managed by the location-based manager. This logical zone, as shown in <FIG>, creates the security boundary that separates individual resource units and enhances security of the cloud service provider.

Finally, at operation <NUM>, the location-based manager deploys cloud resources associated with the at least one subscription for use by the plurality of tenants that share the subscription. As discussed above, the subscription can be updated or replaced over time by the location-based manager based on a variety of factors such as the number of tenants, cloud resource availability, and subscription time period.

<FIG> shows additional details of an example computer architecture <NUM> for a device, such as a computer or a server configured as part of the system <NUM>, capable of executing computer instructions (e.g., a module or a program component described herein). The computer architecture <NUM> illustrated in <FIG> includes processing unit(s) <NUM>, a system memory <NUM>, including a random-access memory <NUM> ("RAM") and a read-only memory ("ROM") <NUM>, and a system bus <NUM> that couples the memory <NUM> to the processing unit(s) <NUM>.

Processing unit(s), such as processing unit(s) <NUM>, can represent, for example, a CPU-type processing unit, a GPU-type processing unit, a field-programmable gate array (FPGA), another class of digital signal processor (DSP), or other hardware logic components that may, in some instances, be driven by a CPU. For example, and without limitation, illustrative types of hardware logic components that can be used include Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip Systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc..

A basic input/output system containing the basic routines that help to transfer information between elements within the computer architecture <NUM>, such as during startup, is stored in the ROM <NUM>. The computer architecture <NUM> further includes a mass storage device <NUM> for storing an operating system <NUM>, application(s) <NUM>, modules <NUM>, and other data described herein.

The mass storage device <NUM> is connected to processing unit(s) <NUM> through a mass storage controller connected to the bus <NUM>. The mass storage device <NUM> and its associated computer-readable media provide non-volatile storage for the computer architecture <NUM>. Although the description of computer-readable media contained herein refers to a mass storage device, it should be appreciated by those skilled in the art that computer-readable media can be any available computer-readable storage media or communication media that can be accessed by the computer architecture <NUM>.

Computer-readable media can include computer-readable storage media and/or communication media. Computer-readable storage media can include one or more of volatile memory, nonvolatile memory, and/or other persistent and/or auxiliary computer storage media, removable and non-removable computer storage media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Thus, computer storage media includes tangible and/or physical forms of media included in a device and/or hardware component that is part of a device or external to a device, including but not limited to random access memory (RAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), phase change memory (PCM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), optical cards or other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage, magnetic cards or other magnetic storage devices or media, solid-state memory devices, storage arrays, network attached storage, storage area networks, hosted computer storage or any other storage memory, storage device, and/or storage medium that can be used to store and maintain information for access by a computing device.

In contrast to computer-readable storage media, communication media can embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism. As defined herein, computer storage media does not include communication media. That is, computer-readable storage media does not include communications media consisting solely of a modulated data signal, a carrier wave, or a propagated signal, per se.

According to various configurations, the computer architecture <NUM> may operate in a networked environment using logical connections to remote computers through the network <NUM>. The computer architecture <NUM> may connect to the network <NUM> through a network interface unit <NUM> connected to the bus <NUM>. The computer architecture <NUM> also may include an input/output controller <NUM> for receiving and processing input from a number of other devices, including a keyboard, mouse, touch, or electronic stylus or pen. Similarly, the input/output controller <NUM> may provide output to a display screen, a printer, or other type of output device.

It should be appreciated that the software components described herein may, when loaded into the processing unit(s) <NUM> and executed, transform the processing unit(s) <NUM> and the overall computer architecture <NUM> from a general-purpose computing system into a special-purpose computing system customized to facilitate the functionality presented herein. The processing unit(s) <NUM> may be constructed from any number of transistors or other discrete circuit elements, which may individually or collectively assume any number of states. More specifically, the processing unit(s) <NUM> may operate as a finite-state machine, in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the processing unit(s) <NUM> by specifying how the processing unit(s) <NUM> transition between states, thereby transforming the transistors or other discrete hardware elements constituting the processing unit(s) <NUM>.

<FIG> depicts an illustrative distributed computing environment <NUM> capable of executing the software components described herein. Thus, the distributed computing environment <NUM> illustrated in <FIG> can be utilized to execute any aspects of the software components presented herein. For example, the distributed computing environment <NUM> can be utilized to execute aspects of the software components described herein.

Accordingly, the distributed computing environment <NUM> can include a computing environment <NUM> operating on, in communication with, or as part of the network <NUM>. The network <NUM> can include various access networks. One or more client devices 706A-706N (hereinafter referred to collectively and/or generically as "clients <NUM>" and also referred to herein as computing devices <NUM>) can communicate with the computing environment <NUM> via the network <NUM>. In one illustrated configuration, the clients <NUM> include a computing device 706A such as a laptop computer, a desktop computer, or other computing device; a slate or tablet computing device ("tablet computing device") 706B; a mobile computing device 706C such as a mobile telephone, a smart phone, or other mobile computing device; a server computer 706D; and/or other devices 706N. It should be understood that any number of clients <NUM> can communicate with the computing environment <NUM>.

In various examples, the computing environment <NUM> includes servers <NUM>, data storage <NUM>, and one or more network interfaces <NUM>. The servers <NUM> can host various services, virtual machines, portals, and/or other resources. In the illustrated configuration, the servers <NUM> host virtual machines <NUM>, Web portals <NUM>, mailbox services <NUM>, storage services <NUM>, and/or, social networking services <NUM>. As shown in <FIG> the servers <NUM> also can host other services, applications, portals, and/or other resources ("other resources") <NUM>.

As mentioned above, the computing environment <NUM> can include the data storage <NUM>. According to various implementations, the functionality of the data storage <NUM> is provided by one or more databases operating on, or in communication with, the network <NUM>. The functionality of the data storage <NUM> also can be provided by one or more servers configured to host data for the computing environment <NUM>. The data storage <NUM> can include, host, or provide one or more real or virtual datastores 726A-726N (hereinafter referred to collectively and/or generically as "datastores <NUM>"). The datastores <NUM> are configured to host data used or created by the servers <NUM> and/or other data. That is, the datastores <NUM> also can host or store web page documents, word documents, presentation documents, data structures, algorithms for execution by a recommendation engine, and/or other data utilized by any application program. Aspects of the datastores <NUM> may be associated with a service for storing files.

The computing environment <NUM> can communicate with, or be accessed by, the network interfaces <NUM>. The network interfaces <NUM> can include various types of network hardware and software for supporting communications between two or more computing devices including, but not limited to, the computing devices and the servers. It should be appreciated that the network interfaces <NUM> also may be utilized to connect to other types of networks and/or computer systems.

It should be understood that the distributed computing environment <NUM> described herein can provide any aspects of the software elements described herein with any number of virtual computing resources and/or other distributed computing functionality that can be configured to execute any aspects of the software components disclosed herein. According to various implementations of the concepts and technologies disclosed herein, the distributed computing environment <NUM> provides the software functionality described herein as a service to the computing devices. It should be understood that the computing devices can include real or virtual machines including, but not limited to, server computers, web servers, personal computers, mobile computing devices, smart phones, and/or other devices. As such, various configurations of the concepts and technologies disclosed herein enable any device configured to access the distributed computing environment <NUM> to utilize the functionality described herein for providing the techniques disclosed herein, among other aspects.

The disclosure presented herein also encompasses the subject matter set forth in the following clauses.

Example Clause A, a method comprising: acquiring, by one or more processing units of a location-based manager of a cloud service provider, a pool of subscriptions from a cloud platform configured to allocate cloud resources to the cloud service provider, where each subscription defines a specific set of cloud resources allocated for use for a defined time period; assigning, by the location-based manager of the cloud service provider, at least one subscription of the pool of subscriptions for a resource unit of the cloud platform, wherein the at least one subscription is shared by a plurality of tenants configured to request access to the cloud resources from the resource unit; creating, by the location-based manager of the cloud service provider, a logical zone that effectively creates a security boundary between the resource unit and other resource units managed by the location-based manager; and deploying, by the location-based manager of the cloud service provider, the cloud resources associated with the at least one subscription within the logical zone for use by the resource unit on behalf of the plurality of tenants.

Example Clause B, the method of Example Clause A, wherein the security boundary between the resource unit and other resource units comprises a virtual network.

Example Clause C, the method of Example Clause A or Example Clause B, wherein the security boundary is a first security boundary that isolates the resource unit from the other resource units managed by the location-based manager and the logical zone comprises one or more second security boundaries that isolate individual tenants of the plurality of tenants from other tenants of the plurality of tenants.

Example Clause D, the method of Example Clause C, wherein a second security boundary comprises one or more security parameters defined in the at least one subscription.

Example Clause E, the method of any one of Example Clauses A through D, wherein the location-based manager is configured to manage a geographic region comprising a plurality of geographic areas, and the location-based manager is deployed as a plurality of instances where each instance has an associated geographic area for managing cloud resources.

Example Clause F, the method of any one of Example Clauses A through E, wherein the allocation of cloud resources defined by each subscription of the pool of subscriptions is based on at least one of an availability of cloud resources at the cloud platform, a number of tenants utilizing the cloud service provider, or a geographic location of the cloud service provider.

Example Clause G, the method of any one of Example Clauses A through F, wherein the allocation of cloud resources defined by each subscription of the pool of subscriptions is adjusted based on data defining tenant activity by the plurality of tenants utilizing the cloud service provider. Example Clause H, a system comprising: one or more processing units; and a computer-readable medium having encoded thereon computer-readable instructions to cause the one or more processing units to: acquire, by a location-based manager of a cloud service provider, a pool of subscriptions from a cloud platform configured to allocate cloud resources to the cloud service provider, where each subscription defines a specific set of cloud resources allocated for use for a defined time period; assign, by the location-based manager of the cloud service provider, at least one subscription of the pool of subscriptions for a resource unit of the cloud platform, wherein the at least one subscription is shared by a plurality of tenants configured to request access to the cloud resources from the resource unit; create, by the location-based manager of the cloud service provider, a logical zone that effectively creates a security boundary between the resource unit and other resource units managed by the location-based manager; and deploy, by the location-based manager of the cloud service provider, the cloud resources associated with the at least one subscription within the logical zone for use by the resource unit on behalf of the plurality of tenants.

Example Clause I, the system of Example Clause H, wherein the security boundary between the resource unit and the other resource units comprises a virtual network.

Example Clause J, the system of Example Clause H or Example Clause I, wherein the security boundary is a first security boundary that isolates the resource unit from the other resource units managed by the location-based manager and the logical zone comprises one or more second security boundaries that isolate individual tenants of the plurality of tenants from other tenants of the plurality of tenants.

Example Clause K, the system of Example Clause J, wherein a second security boundary comprises one or more security parameters defined in the at least one subscription.

Example Clause L, the system of any one of Example Clauses H through K, wherein the location-based manager is configured to manage a geographic region comprising a plurality of geographic areas, and the location-based manager is deployed as a plurality of instances where each instance has an associated geographic area for managing cloud resources.

Example Clause M, the system of any one of Example Clauses H through L, wherein the allocation of cloud resources defined by each subscription of the pool of subscriptions is based on at least one of an availability of cloud resources at the cloud platform, a number of tenants utilizing the cloud service provider, or a geographic location of the cloud service provider.

Example Clause N, the system of any one of Example Clauses H through M, wherein the allocation of cloud resources defined by each subscription of the pool of subscriptions is adjusted based on data defining tenant activity by the plurality of tenants utilizing the cloud service provider.

Example Clause O, a computer-readable storage medium having encoded thereon computer-readable instructions that, when executed by one or more processing units, cause the one or more processing units to: acquire, by a location-based manager of a cloud service provider, a pool of subscriptions from a cloud platform configured to allocate cloud resources to the cloud service provider, where each subscription defines a specific set of cloud resources allocated for use for a defined time period; assign, by the location-based manager of the cloud service provider, at least one subscription of the pool of subscriptions for a resource unit of the cloud platform, wherein the at least one subscription is shared by a plurality of tenants configured to request access to the cloud resources from the resource unit; create, by the location-based manager of the cloud service provider, a logical zone that effectively creates a security boundary between the resource unit and other resource units managed by the location-based manager; and deploy, by the location-based manager of the cloud service provider, the cloud resources associated with the at least one subscription within the logical zone for use by the resource unit on behalf of the plurality of tenants.

Example Clause P, the computer-readable storage medium of Example Clause O, wherein the security boundary between the resource unit and the other resource units comprises a virtual network.

Example Clause Q, the computer-readable storage medium of Example Clause O or Example Clause P, wherein the security boundary is a first security boundary that isolates the resource unit from the other resource units managed by the location-based manager and the logical zone comprises one or more second security boundaries that isolate individual tenants of the plurality of tenants from other tenants of the plurality of tenants.

Example Clause R, the computer-readable storage medium of Example Clause Q, wherein a second security boundary comprises one or more security parameters defined in the at least one subscription.

Example Clause S, the computer-readable storage medium of any one of Example Clauses O through R, wherein the location-based manager is configured to manage a geographic region comprising a plurality of geographic areas, and the location-based manager is deployed as a plurality of instances where each instance has an associated geographic area for managing cloud resources.

Example Clause T, the computer-readable storage medium of any one of Example Clauses O through S, wherein the allocation of cloud resources defined by each subscription of the pool of subscriptions is adjusted based on data defining tenant activity by the plurality of tenants utilizing the cloud service provider.

Although the various configurations have been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended representations is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed subject matter.

Conditional language used herein, such as, among others, "can," "could," "might," "may," "e.g.," and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements, and/or steps. Thus, such conditional language is not generally intended to imply that features, elements, and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements, and/or steps are included or are to be performed in any particular embodiment.

While certain example embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions disclosed herein. Thus, nothing in the foregoing description is intended to imply that any particular feature, characteristic, step, module, or block is necessary or indispensable. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing the inventions disclosed herein. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope of certain of the inventions disclosed herein.

It should be appreciated that any reference to "first," "second," etc. elements within the Summary and/or Detailed Description is not intended to and should not be construed to necessarily correspond to any reference of "first," "second," etc. elements of the claims. Rather, any use of "first" and "second" within the Summary, Detailed Description, and/or claims may be used to distinguish between two different instances of the same element (e.g., two different server farms, two different location-based managers, etc.).

Claim 1:
A method comprising:
acquiring, by one or more processing units of a location-based manager (<NUM>) of a cloud service provider (<NUM>), a pool of subscriptions (<NUM>) from a cloud platform (<NUM>) configured to allocate cloud resources to the cloud service provider (<NUM>), where each subscription (<NUM>) defines a specific set of cloud resources allocated (<NUM>) for use for a defined time period (<NUM>); and a roster (<NUM>) of tenants associated with the subscription (<NUM>);
assigning, by the location-based manager (<NUM>) of the cloud service provider (<NUM>), at least one subscription (<NUM>) of the pool of subscriptions (<NUM>) for a resource unit (<NUM>) of the cloud platform (<NUM>), wherein the at least one subscription (<NUM>) is shared by a plurality of tenants (<NUM>) configured to request access to the cloud resources from the resource unit (<NUM>);
creating, by the location-based manager (<NUM>) of the cloud service provider (<NUM>), a logical zone (<NUM>) that effectively creates a security boundary between the resource unit (<NUM>) and other resource units (<NUM>) managed by the location-based manager (<NUM>); and
deploying, by the location-based manager (<NUM>) of the cloud service provider (<NUM>), the cloud resources associated with the at least one subscription (<NUM>) within the logical zone (<NUM>) for use by the resource unit (<NUM>) on behalf of the plurality of tenants (<NUM>).