Compartments

Customers of a service provider are able to provision compartments of the accounts. The both the accounts and the compartments, in some embodiments, may have associated computing resources and identities. One or more identities of the account may be authorized to perform administrative operations in the compartment. Identities of the compartment may lack the ability to perform any administrative actions outside of the compartment but inside of the account.

CROSS REFERENCE TO RELATED APPLICATIONS

This application incorporates by reference for all purposes the full disclosure of co-pending U.S. patent application Ser. No. 14/295,108, filed concurrently herewith, entitled “HIDDEN COMPARTMENTS” and co-pending U.S. patent application Ser. No. 14/295,146, filed concurrently herewith, entitled “TECHNIQUES FOR PROVIDING COMPARTMENTS.”

BACKGROUND

The use of network computing, storage, and other computing resources has proliferated in recent years. The resources for network computing and storage are often provided by computing resource service providers who leverage large-scale networks of computers, servers and storage drives to enable clients, including content providers, online merchants and the like, to host and execute a variety of applications and web services. Content providers and online merchants, who traditionally used on-site servers and storage equipment to host their websites and store and stream content to their customers, often forego on-site hosting and storage and turn to using the resources of the computing resource service providers. The usage of network computing allows content providers and online merchants, among others, to efficiently and adaptively satisfy their computing needs, whereby the computing and storage resources used by the content providers and online merchants may be added or removed from a large pool provided by a computing resource service provider as needed and depending on their needs.

Consumers of computing resources hosted by a computing resource service provider (often referred to as “cloud services” consumed from a “cloud provider,” respectively), may have accounts with the computing resource service provider for various purposes, such as to utilize computing resources to support a web page, to support computer science education and other education by enabling students to utilize computing resources provided by a computing resource service provider, to provide a streaming media site to millions of customers and thousands of employees as users of the account, and the like. For a single account of the computing resource service provider, multiple users may access the account to develop applications, utilize services and resources, design interfaces, and administrate the account. Usage of the account's resources may incur costs that may be billed to the owner of the account. Furthermore, when an account has multiple users, there is risk that some users may modify or delete important account resources, or incur excessive usage costs from their use of the account's resources. Conventional techniques for addressing such issues include requiring each user to create an individual user account; however this not only places a financial burden on the user (who, for instance, may lack a credit card or other form of payment), but does not allow the users to be governed by the policies of a controlling account.

DETAILED DESCRIPTION

Techniques described and suggested herein relate to web service containers (containers), defined herein as logical entities with an associated record structure, the record structure indicating that the container may grant, to one or more users, varying levels of access computing services and resources. One type of container is an account, which is a container for resources hosted by a computing resources service provider and further associated with billing information related to the agreement by the customer to pay for services, information about user credentials and access, and policies specifying the ownership and the scope of computing resources. Another type of container is a compartment, which bears many similarities to an account, such as being a container for resources hosted by computing resource service provider, and is described in more detail below.

The account may be created (e.g., set up and/or purchased) through completion of a web form that automatically configures the billing system, sets up the payment obligations, and creates a resource container with an account identity (ID). The account may support multiple users with unique identities recognized by the resources of the account. A user may be an individual, system, resource computing device, or other entity authorized to access to the account. Each user may have a unique name within the account and may present or otherwise prove the possession of security credentials, such as with a password, access key, and/or digital signature, to gain access to computing resources. Although an account may contain only one user, additional users may be added or removed from the account as needed.

Permissions defining what users may or may not do within an account may be assigned to users or groups of users according to policy documents or other encodings of policies assigned to the users or groups of users within the account. Each account has policies governing user access, but policies created in one account do not normally interact with policies in another account. Further, each account may have a number of roles; a role being an entity defining a set of permissions. Roles may not be attached to specific users or groups but may be assumed by trusted entities, such as a particular service, and multiple policies may be attached to each role.

Examples of roles include, but are not limited to, a trustee role and an administrator role. For example, a trustee having a trustee role may set policies restricting what can happen within an account or other container, however a trustee may not necessarily be able to fully administrate the account or container (e.g., to grant privileges within the account). Whereas an administrator having an administrator role may be able to fully administrate the account, and the trustee policy may state that the administrator role may not be removed. In some cases, the trustee may also have an administrator role and/or the administrator may have a trustee role.

An authorized user, (that is, an authenticated user having a role with sufficient privileges) may make requests to the web service to instantiate, that is, to create and provide resources such as a database resource and file storage. Commands and requests to the services may be performed by programmatic function calls to an API under the control of the web service account. Whether an entity is authorized to perform any particular action may be determined by an API call that includes a digital signature generated using a user credential of the entity. For example, a customer may use a private key to digitally sign a request to a service, whereupon the service forwards the digital signature and signed message to an authentication service that verifies the signature and responds with a credential (key) that the service may use to sign requests to the service or API that performs an action (such as, but not limited to, creating, deleting, and transferring compartments as described herein).

A compartment is a container having similarities to an account, but may be created to allow aspects of the account to detach and move into the compartment. In some embodiments, a compartment is an account with an additional association with a parent container (e.g., account or other compartment). In some examples, multiple compartments may be generated and enumerated within a single container. An API may allow an account user to create a compartment with a structure largely identical to the structure of an account (e.g., identical except for an additional association with the parent container), and which inherits aspects of the parent account. In at least one embodiment a service may create a compartment based on a request from a customer, contingent on authentication of the customer's credentials. A container hosting the compartment may have full access to the compartment and may be able to define the policies and permissions governing the compartment. By the container having full access, one or more identities of the container may be authorized to perform one or more administrative operations inside of the compartment. The ability to administer the account may correlate with the ability to administer the compartment so that, for instance, a user able to perform one or more operations in an account may also be able to perform those same operations in the compartment. In other examples, such a correlation may not be present, but permissions may be more specifically defined upon compartment creation.

Compartments provide certain advantages over an account. For example, once the purpose for which the compartment was created ends, the compartment may be terminated without negatively affecting the parent container and any resources within the compartment may subsequently be released without generating further usage cost to the owner of the parent account. Further, in some embodiments, a compartment may host one or more compartments within itself. Still further, a compartment may be created, configured, and, at some later period in time, transferred to a different account or the compartment may be converted to be a standalone account. Converting a compartment into a standalone account enables resellers to create, configure, and subsequently sell compartments to buyers as separate accounts. For example, an online marketplace seller could create a compartment with an installation of a software solution for a particular purpose and list the compartment on the marketplace as available for purchase, whereupon buyers would be able to purchase the compartment to use as their own account.

To create a compartment, the user may call a compartment creation API, which then creates a compartment, configures the parent-child relationship of the compartment, and configures one or more roles granting access (full or partial) to administer the compartment that may be assumable by the account in which the compartment resides. As noted, a user may be a service, and it one embodiment, the service may create a compartment by calling an API based on a pending customer request. Note that the API call may be performed by a user, a service, a console interface, or other process. One example of this embodiment includes, but is not limited to, a situation where a customer makes a request to create a database, whereupon a database service may make the appropriate API calls to create a compartment to host a database; the determination of whether the database service may be permitted to create the compartment being based on the credentials (such as a digital signature and signed message) of the customer being verified by an authentication service. For example, the customer credentials may be presented to an authentication service, which, upon confirming authorization, may provide the database service with a token which may be held by the database service as proof that the database service is authorized to perform certain operations for the customer.

When an entity, such as a user, or service, makes an API call regarding one or more resources hosted within a container, the entity may pass its credentials, which includes the entity's ID and typically also passes the ID of the container in which any resources should be created. For example, if the container type passed is a compartment, rather than an account, it will pass the ID of the compartment. From the perspective of a service, a compartment container appears to be no different than an account container, except that that the security policies limits enforced on the parent account may not be exceeded by the child compartment.

In various embodiments, any account user authorized to assume a role or otherwise having permissions that allow the creation of a compartment may create a compartment and have the same rights to resources within the compartment as the user would have had to the same resources within the account, however the user may not necessarily have the ability to fully administrate the compartment. In addition, or in the alternative, variations are also considered as being within the scope of the present disclosure. For example, an account user who creates a compartment in a manner described herein may be granted rights to fully administrate the compartment by an account administrator or user with sufficient permissions to grant permissions to administrate the compartment. As another example, an account user who creates a compartment in a manner described herein may not be granted rights to administrate or access one or more applications, services, or computer resources hosted by the compartment. As yet another example, in some embodiments, only a user or service having full access to the parent container may create a compartment within the container. In some embodiments, only users or services with particular roles may create a compartment within the container. In some examples, any user of a container may create a compartment within that container, with users of the compartment having equal or lesser access to resources within the compartment as the user had to resources within the parent container.

In at least another embodiment, a compartment may inherit account-specific metadata from its parent container. For example, an account may be configured for a particular geographic region with a compartment for running a product in that region. In this example, the compartment may inherit metadata detailing tax information and requirements relevant to the particular region from the parent account. Hence, it may be that charges and costs incurred by the compartment and from resource usage within the compartment accrue (i.e., aggregate) to the parent container. Alternately, a compartment may be configured to have separate billing records such that charges and costs incurred by the compartment and from resource usage within the compartment accrue to a different responsible party than the party responsible for charges associated with the parent container. In this manner, charges and other economic measurements related to resources in containers can be easily separated for the purpose of different tax treatments in different tax jurisdictions.

Tagging may be used to keep track of resource usage and billing within a compartment. A resource may be “tagged” with information (a tag) by creating, in a table or other data structure of a persistent data store, a relationship (association) between the information (e.g., an identity (ID) of a container) and the ID of a resource or particular type of resource. Because resource usage is also logged in a data store, the tag may be utilized in a query of one or more data stores to determine the usage associated with resources within a tagged container or associated with particular tagged resources within the container. For example, a compartment may have tagging enabled such that resources within the compartment may be tagged, such as with the compartment ID so that, as they are utilized resource usage is attributable to the compartment. Advantages of tagging compartments and resources may include providing an ability to segregate resource usage within the compartment from aggregated billing, usage reports and cost breakdowns in order to generate itemized billing invoices or resource use reports for particular compartments or for a specific project. In at least one embodiment, when a compartment and/or resource within the compartment is tagged, users and services within the compartment may not have visibility that the compartment or resource is tagged, but users and services within the parent container may have visibility that the compartment or resource within the compartment is tagged. In at least another embodiment, when a compartment and/or resource is tagged, users and services within the compartment may have visibility that the compartment or resource is tagged; for example, a properly authenticated call to an API to view an inventory of a container may return a list of child compartments and tagged compartments may have a mark indicating that the compartment is tagged, or an inventory of resources within a container may provide a list of the resources of the container and all child compartments with a mark next to each tagged resource identifying the compartment ID the resource is tagged with. In this manner, users of the compartment may be able to determine which resources are being separately tracked or billed to the compartment from other non-tagged resources. To users and services within a compartment who do not have visibility which compartment or resources are tagged, tagged resources may not be differentiated from non-tagged resources. As another embodiment usable in combination with other embodiments, resources within a compartment may be tagged independently from other resources within the compartment. As still another embodiment usable in combination with other embodiments, some resources within the compartment may be tagged and some resources within the compartment may not be tagged. Yet another embodiment usable in combination with other embodiments, some resources within the compartment may be tagged without tagging other resources within the compartment.

In at least another example, aggregated usage reports and cost breakdowns may be generated to view itemized billing or resource use of particular compartments, particular users or resources within a compartment, or particular groups of users within a compartment. In at least another embodiment, aggregated usage reports for one or more containers may be combined into an overall usage report of all resource usage within the one or more containers.

Relationships and roles configured by a parent container may propagate downward to the container, however relationships and roles configured within a compartment may not propagate upward to the parent container. For example, permissions, policies, and roles set within the compartment may not grant access to resources outside the compartment, but however, permissions, policies, and roles set within a parent container granting access to users or services within a compartment may do so. Note, however, that policy restrictions set within the compartment may take precedence over grants of access to resources even if granted within a parent container. Cross-compartment relationships may be managed in the same way as cross-account relationships may be managed (e.g., through roles, resource APELs, etc.) by the computing resource service provider, except that, in various embodiments, the compartment may have a distinct and separate namespace and policy scope than its parent account.

A container user who has one or more roles or permissions allowing the user to update administrative policies of the container may be granted the same permissions to a child compartment created within the container. In this case, the administrative policies of the compartment may be modifiable by administrators of the parent container as well as any user who has been delegated an administrative role under the parent container. Thus, the administrative users of the parent container may have the ability to modify the policies of the compartment, thereby permitting security policies of the compartment users to be managed by the administrative users of the parent containers; for example, account users with the ability to assign roles and permissions within the account may also assign roles and permissions to users within child compartments of that account. Although the roles, policies, and permissions of the users of the parent container may allow those users the same access to resources within the compartment as they would to resources within the parent container, the roles, policies, and permissions specified for compartment users may not necessarily grant access to resources of the parent container.

In at least one embodiment, fulfillment of an API call for a specific API may transfer ownership of a compartment to a different container. Normally, changing ownership of resources is costly and difficult to manage or automate; however, by using compartments, because of the way metadata about compartments and containers are kept, the ownership of all resources linked to the compartment may be changed by simply changing ownership of the compartment. Note that the API call may be performed by a user, a service, a console interface, or other process. In some embodiments, there may be an API for administration of a compartment, which may permit administrative users of the parent container to designate new administration permissions specific to the child compartment or replace the current administrators of the child compartment with the administrators of the container that is assuming ownership of the child compartment. In some examples, the transfer of permissions and roles may occur automatically with the change of ownership of a compartment. In at least another embodiment, the role permitting the original parent container to administrate the child compartment may not be altered. In other examples, the parent container may designate another container as having an administrative role over the child compartment, but the parent container may not relinquish ownership over the child compartment; for example, the owner of the parent container may authorize a third party support provider to have access to troubleshoot, update, or perform maintenance on to the resources within the child compartment, while still maintaining ownership over the child compartment. The authorization to grant the third party support provider the necessary access may be performed by an API call with a digitally signed user credential from the container owner or other authorized entity.

A computing resource service provider may allow customers to create compartments dynamically, as needed, or may allow customers to reserve a number of compartments the customer knows in advance will be needed. For instance, in exchange for a commitment to pay for a compartment for a long term (regardless of actual usage), the per-time-unit cost of the compartment may be lower. For instance, some computing resources (e.g., virtual computer systems, also referred to as instances) may be billed hourly at a certain rate per hour. For a one-year commitment to pay for the instance, the per-hour rate may be lowered. Similar billing structures may be configured for compartments, such as when resources in compartments have the ability to be utilized in accordance with a short-term on-demand model as well as with a longer term reservation model. Compartments created on demand may have different account billing structures than reserved compartments, and under certain conditions, it may be more cost effective to reserve compartments than to create compartments dynamically. In at least one embodiment, compartments may be reserved for a specified time (i.e., term). In at least another embodiment, when a term of a reserved compartment expires, the reserved compartment may be renewed for another term. In at least another embodiment, the term of a reserved compartment may be indefinite.

A compartment may also be designated as a hidden compartment; a hidden compartment being a compartment wherein at least some users of the parent compartment have restrictions on the ability to view, access, or administer the compartment or resources within the compartment. For example, a compartment for a legal department of a company may be created under the company account, with a requirement that no users outside the legal department, including administrators of the company account, may view data objects in that compartment. In such a case, users and administrators of the parent account may be restricted in their ability to view or access resources within the compartment. Other examples of hidden compartments include compartments created for secret projects and compartments containing protected information that should not be viewable by one or more users of parent container.

Yet another example of a hidden compartment may be a compartment, not visible to individual users, but rather created for use by a service, such as a database service. For example, if a user calls a database service from a container, the database service may call a hidden compartment API to create a separate hidden database resource compartment, if one does not already exist, within the user container, with database service having rights to administrate the hidden compartment. Note that the API call may be performed by a user, a service, a console interface, or other process. The database service may subsequently launch the requested instance within the database resource hidden compartment. In some examples, launching a database instance involves launching different resources using different services of the computing resource service provider, where the launched resources are collectively configured as the database instance. An advantage of the database resource hidden compartment is that billing for resource use within the database resource compartment may be calculated and/or billed against the database resource compartment separately from the parent container. In some cases, the usage of resources within a hidden compartment may be itemized within the billing invoice of the customer associated with the parent container. Alternately, the usage of resources within the hidden container may be aggregated with similar resource usage incurred outside of the hidden container; for example, database usage within a hidden container and separate database usage within the parent account or standard container within the parent account may be summed together as a single item on the customer invoice. In other cases, all resource usage within the hidden compartment is grouped together as a single item on the customer bill; for example, a database service and one or more virtual machine services all running within a hidden compartment incurring their own costs may be grouped together as a single cost for the hidden compartment on the customer invoice. In some instances, the customer associated with the parent container may receive a separate bill for the hidden compartment for costs incurred by the usage of resources within the hidden compartment. In other cases, such as where a customer is utilizing a compartment within an account of a vendor, resource usage incurred within a hidden compartment of the customer may be billed directly to the vendor by a computing resource service provider, and the vendor, in turn, may re-bill the customer.

In at least one embodiment a service may create the hidden compartment based on a request from a customer, pending authentication of the customer's credentials. For example, for a service or other entity to create a compartment in a customer's account, the service or other entity may be required to present cryptographic proof of a pending request by the customer whose fulfillment involves the creation of the compartment. In some examples, the service or other entity may submit a digital signature of a request by a customer to an authentication service that evaluates the digital signature. If the authentication service determines that the digital signature is valid, the authentication service may provide the service or other entity with a credential (e.g. cryptographic key) that the service or other entity can use to digitally sign a request to create the compartment and, in some examples, digitally sign requests to other services to provision resources inside of the compartment.

In at least one embodiment, a service that creates a hidden compartment may have an administrative role associated with the compartment. In at least another embodiment, the service that creates a hidden compartment assumes a particular role over the compartment, the particular role determined by a predetermined policy. Assumption of a role may involve submitting an API call to an identity management system of a computing resource service provider which, upon cryptographic verification of authorization to assume the role, provides a credential usable to digitally sign requests to perform administrative operations in connection with the compartment. Note that the API call may be performed by a user (via a user computing device), a service, a console interface navigated by a user, or in other ways. In some examples, fulfillment of a user request for a usage report or inventory of resources within a container includes providing an inventory of at least some of the hidden compartments within the container. In at least another embodiment, one or more hidden compartments may not appear within a usage report generated in response to an inventory request. Whether hidden compartments are identified in an inventory or usage report may be a configurable setting that a customer can, at least for some compartments, set themselves. In some examples, resources hosted within a hidden compartment may not appear within a usage report generated in response to an inventory request.

In another example, a customer on an online marketplace may select to purchase a digital product, such as a media product with attached digital rights management (DRM), and the digital product may be launched or placed in a new hidden compartment having controls on the customer's ability to execute, view, snapshot, print or alter the product. In at least one embodiment, the billing for the digital product may aggregate directly to the customer. In some examples, the billing aggregates to the marketplace provider, with the marketplace provider separately billing the customer.

Containers may also have quota limits assigned to measurable qualities associated with an account. For example, an account may have a quota setting a limit on the number of instantiations of a particular type of resource (e.g., virtual computer system) that may be created within the container. For example, an account may have a quota of 500 allowable virtual computer system instances (referred to simply as “instances”) and the account may further have 500 users with the ability to create instances. In this example, if all of the users are members of the account and one or more of the users create more than one instance, the number of available instances in the quota may be prematurely exhausted. Therefore, an administrative user of the account may want to restrict the number of instances that individual users or groups of users may instantiate in order to ensure that the users do not exceed the quota or consume more than their share of instances. Just as with accounts, quotas may be separately assigned to one or more containers within an account.

The types of quotas within the scope of the present disclosure are not limited to instantiations of certain types of resources. In at least one embodiment, quotas may be used to set limits on the amount of time that individual users or groups of users may spend logged into the container. In at least another example, quotas may be used to limit the cost incurred by an individual user or group of users of the container. In another example embodiment, quotas may be used to limit the number of users or groups a container may have. In at least another example, quotas may be used to limit the number of users that may be logged into a container at one time. In at least another example, quotas may be used to limit the number of files that may be within a container. As another example, quotas may be used to limit the number of files that may be within a particular directory or all directories within a container. Quotas may also be used to limit the file size of files within a container or a particular directory or all directories within a container. In at least another embodiment, quotas may be used to limit the number of text/instant messages provided through the container by a user or group of users the network bandwidth used by a container, user, or group of users the amount of data that may be uploaded or downloaded to a container or by a user or group of users and the like. In other examples, quotas may be used to limit the amount of storage space usable by a container, the number of databases within a container, the size of databases within a container, the number or size of tables within databases within a container the amount of virtual memory usable by a container, user, or group of users, the number of active threads or active processes within a container, the number of invalid logon attempts to the container by a user or group of users, the number of database queries a user or group of users may make within the container in a given time period, the number of snapshots that may be made of a container, and/or the number of simultaneous connections to a database.

In at least another embodiment, quotas may be used to limit the number of compartments that may reside within a container, the number of certain types of compartments that may reside within a container; for example, configuring quota for a container to have a limit of possible five compartments hosting databases, ten compartments for virtual machines, etc. In at least another example, quota limits may be set on the number of containers created by a particular type of user (e.g., individual, service, etc.); for example, a quota may be set to limit database resources running within a container to only create up to four compartments.

The aggregated quota limit of a particular measurable quantity for a parent container and all of its children is considered as a quota pool. Quotas may be further assigned to compartments within the container, as long as the aggregation of the consumed portions of the quotas of the container and its child compartments do not exceed the quota pool. The quotas limits assigned by administrators of a container to child compartments of the container may be considered quota aggregation groups.

Quota aggregation groups may be utilized to ensure that the resources of an account are not prematurely exhausted or exceeded. For example, a quota aggregation group may be created within a compartment with limits reflecting a subset of the parent container's quota pool. An administrative user may then assign users to the compartment, with the users limited according to the assigned quota aggregation group. In this example, the assigned users may be limited in the number of instances they can create within the compartment. Thus, by creating a compartment for each user or group of users and assigning a quota aggregation group to the compartment, the administrative user may ensure that the quota of the parent container is not prematurely or unnecessarily depleted. In the example of the account with 500 allowable instances and 500 users, the administrative user may create a compartment having a quota aggregation group for each user, assigning a quota limit of one instance to each quota aggregation group. In an alternate embodiment, child compartments may have quotas independent of and not limited by the quota pool of the parent container.

In at least one embodiment, when a compartment is transformed into a standalone account, the quota limits do not follow the standalone account and the quota limits aggregate back to the quota pool of the parent container. In at least another embodiment, when a compartment is transformed into a standalone account, the quota limits follow the standalone account and the quota limits do not aggregate back to the quota pool. In at least another embodiment, when a compartment is transformed into a standalone account, the quota limits follow the standalone account, but, as well, the quota limits may be aggregated to the quota pool of the parent container. Likewise, in at least another embodiment, when a compartment is deleted, the quota limits assigned to the quota aggregation groups of the deleted compartment may aggregate back to the quota pool of the parent container. In at least another embodiment, when a compartment is deleted, the quota limits assigned to the quota aggregation groups of the deleted compartment may not aggregate back to the quota pool of the parent container. In some embodiments, the effect of compartment transformation on quota limits is programmatically configurable and/or context dependent.

A quota aggregation group of a compartment may be considered as a quota pool by child containers of the parent container. In at least one embodiment, where a compartment with a quota limit assigned to a quota aggregation group is transferred to be the child of another compartment having an equal or larger quota limit assigned to its own quota aggregation group, the quota pool of the original parent container increases by the limit specified by the quota aggregation group of the transferred compartment, while the limit assigned to the quota aggregation group of the other compartment is deducted by the limit specified by the quota aggregation group of the transferred compartment. In some examples, where a compartment with a quota limit assigned to a quota aggregation group is transferred to be the child of another compartment having a smaller quota limit assigned to its own quota aggregation group, the quota pool of the original parent container increases by the limit specified by the quota aggregation group of the other compartment, the limit assigned to the quota aggregation group of the transferred compartment is configured to equal the limit assigned to the quota aggregation group of the other compartment, and the limit assigned to the quota aggregation group of the other compartment is depleted. In some embodiments, a compartment having a larger quota limit assigned to its quota aggregation group than that allowed by the quota aggregation group of another compartment may not be transferred to be under the ownership of that other compartment. In other embodiments, the quota pool of the original parent container and the quota aggregation group of the other compartment are not affected by the quota limits of the transferred compartment.

In at least one embodiment, quota limits assigned to quota aggregation groups may deducted from the quota pool of the parent container. In this embodiment, for example, a container having two child compartments may have a quota pool creation limit of 100 instances. The administrative user of the container may assign a 75 instance limit to a quota aggregation group of the first child compartment, meaning that a maximum of 25 instances may be assigned to a quota aggregation group of the second child compartment. In such a case, if the 75 instance limit is assigned to the quota aggregation group of the first compartment and a 25 instance limit is assigned to the quota aggregation group of the second compartment, the parent container may not create any instances of its own because all instance limits of its quota pool have been allocated. In some embodiments, quota limits assigned to quota aggregation groups may not be deducted from the parent container, but may be tracked to ensure that the overall quota pool is not exceeded. In such examples, using the above example of the container having two child compartments and a quota pool creation limit of 100 instances, the administrative user may assign a 75 instance limit to a quota aggregation group of the first child compartment and a 50 instance limit to a quota aggregation group of the second child compartment, retaining a quota pool creation limit of 100 instances. In this embodiment, quota limits cumulatively exceeding the quota pool may be assigned, but the quota pool may still limit the aggregated instance usage; that is, allocation of computing resources belonging to the account may impact the quotas assigned to a compartment. For example, if the first child compartment creates its limit of 75 instances, the parent container and the second child compartment may cumulatively only create a maximum of 25 instances, even though the second child container has a limit of 50 instances assigned to its quota aggregation group, because the quota pool of the account limits the total number of instances created to 100. In some examples, the quota aggregation group of a compartment may be adjusted based on whether computing resources of the account are allocated independently from (i.e., outside) the compartment. In at least another embodiment, certain users of a compartment may assign quota limits on a quota aggregation group of the compartment as long as the quota limits do not exceed the quota pool of the parent container.

A computing resource service provider may allow customers to create instances dynamically, as needed, within a container, or may allow customers to reserve a number of instances the customer knows in advance will be needed. Instances (i.e., virtual computer systems) created on demand may have different account billing structures than long-term commitment instances, and under certain conditions, it may be more cost effective to reserve instances than to generate instances dynamically. In at least one embodiment, instances may be reserved for a specified time (i.e., term), where the term may be longer than a standard term for on-demand instances. For example, a customer may commit to a term of one year where on-demand instances may have a standard unit of billing of one hour. In exchange for the commitment, the customer may receive a lower per-hour price for use of the instance. In at least another embodiment, when a term of a long-term commitment instance expires, the long-term commitment instance may be renewed for another term. In at least another embodiment, the term of a long-term commitment instance may be indefinite.

In at least one embodiment, instances may be reserved for specific compartments. Long-term commitment instances for compartments may have a different billing structure than long-term commitment instances for accounts. In some embodiments, long-term commitment instances may be tagged for use only by compartments. In other embodiments, instances reserved for a parent container may be transferred to a child compartment. In this embodiment, for example, an account customer who has reserved a number of instances for an account may choose to assign a number of the long-term commitment instances to a compartment to take advantage of a more favorable billing structure.

A service may utilize available long-term commitment instances of the parent account for creating instances within compartments. For example, a database service may create a hidden compartment within an account and launch an instance within the hidden compartment as described herein. In this example, if the account has a number of long-term commitment instances, the database service may assign the long-term commitment instance to the hidden compartment and utilize the long-term commitment instance within the hidden compartment. In at least another embodiment, deleting the compartment may make the long-term commitment instances within the compartment available to the parent container. In at least another embodiment, deleting the compartment may delete any long-term commitment instances within the compartment.

In some embodiments, when compartment ownership is transferred to a different container, the long-term commitment instances within the compartment revert back to the original parent container. In other embodiments, when compartment ownership is transferred to a different container, the long-term commitment instances within the compartment remain with the compartment and do not revert back to the original parent.

An online marketplace may be configured to utilize compartments to support the buying and selling of computing resource stacks. A computing resource stack includes one or more computing resources that may be interrelated and bundled into a single package. A computing resource stack, when provisioned, may comprise multiple computing resources, perhaps from different services of the computing resource service provider. The computing resources of the stack may be collectively configured to operate as a collective unit. For example, a computing resource stack, when provisioned, may include a virtual computer system that is configured to store and read data from a virtual storage device (e.g., virtual block-level storage device) as well as access and/or write data to a specified logical data container of a data storage service. Thus, a provisioned computing resource stack may comprise computing resources where the computing resources are further configured to interoperate with one another. Therefore, a computing resource stack may comprise one or more compartments, such that an account user may create and configure a compartment, and then offer that preconfigured compartment for sale on an online marketplace.

An example of creating and configuring a compartment for sale on an online marketplace includes, but is not limited to, a situation where the user may create a compartment within the parent account (i.e., a computing resource stack provider account), instantiate one or more resources within the compartment, such as instantiating a database resource, file storage, and a point of sale application interface, configuring the one or more resources as desired, and then offer the compartment for sale to the public on an online marketplace.

In at least one embodiment, the account user may want to prevent the buyer of the compartment from having the ability to view and/or make snapshots of the one or more configured resources instantiated within the compartment. For example, virtual computer systems in the compartment may be configured with executable code that is proprietary to the vendor of the compartment. In this embodiment, the account user may create a hidden compartment instead of a standard compartment, or convert a standard compartment into a hidden compartment, and configure the user policy for buyers of the compartment to restrict visibility to and ability to snapshot resources instantiated within the hidden compartment.

The effect of acquisition of a compartment by one entity from another entity may vary in accordance with various embodiments. For example, when a compartment is purchased or otherwise acquired by a buyer, the compartment may be transformed into an account, and account billing services may be configured to indicate that the buyer will be responsible for future costs incurred by the purchased container. As another example, when a compartment is purchased by a buyer, a new account may be created for the buyer and the compartment may be transferred to the created account. In at least another embodiment, when a compartment is purchased by a buyer who already has an account, the compartment may be transferred to the buyer's account. In some examples, the compartment may remain a compartment under the customer (i.e., vendor) account, but the account billing services may be configured to indicate that the buyer will be responsible for future costs incurred by the purchased compartment. In at least another embodiment, the compartment may be transformed into an account, but the parent container retains permissions sufficient for one or more users of the parent container to maintain and upgrade the purchased container as desired.

In other examples, the compartment may remain a compartment under the vendor account, and the vendor may still manage the compartment and bill the buyer for usage costs. In at least one alternate example, the buyer may lease a compartment from the vendor under a leasing arrangement (i.e., an arrangement where a customer pays for use of the compartment based on an amount of time, which may have a set term, which may auto-renew). In the latter case, the vendor may retain permissions to delete, transfer or deactivate the compartment in the event that the lease ends or the lessee stops paying on the lease.

In at least another embodiment, a marketplace provider, such as a computing resource service provider, may allow vendors to host compartments for sale within a marketplace compartment. In this and other embodiments, the act of the vendor adding the compartment to an online marketplace may automatically cause the compartment to transfer to the computing resource service provider. Upon purchase of the compartment by a buyer, in at least this embodiment, the purchased compartment may then be transferred from the computing resource service provider to an account of the buyer or the compartment may be converted into an account of the buyer. Furthermore in this case, the marketplace provider may be responsible for structuring the billing arrangements between buyers and lessees of the compartments in the marketplace. Another variation of this embodiment may be that, rather than transferring the compartment to the marketplace provider, a vendor can sell a compartment to the marketplace provider and the marketplace provider hosts the compartment for resale.

In at least one embodiment, the computer resource service provider may manage the pool of unsold inventory. In one example of this embodiment, the computer resource service provider may create one or more compartments on demand after purchase by the buyer. In another example of this embodiment, the computer resource service provider may host a limited pool of inventory, so as to minimize the consumption of resources, and create new compartments only when the inventory falls below a certain threshold.

A compartment may be listed for sale on an online marketplace in response to one or more API calls. The API call may have one or more associated parameters that enable or disable various attributes associated with the compartment for sale as described herein. Examples of API parameters include, but are not limited to, a parameter for specifying whether a vendor may be able to delete a compartment after it is sold (e.g., if the compartment is provided to the purchaser under a leasing agreement) and a parameter specifying whether the vendor may administrate the compartment even if the compartment is transferred to a buyer's account (e.g., if the vendor is responsible for maintaining, troubleshooting, and upgrading instances within the compartment).

In some embodiments, the compartment may be initially instantiated under one customer account, and later that customer account may initiate the request to reassign ownership and billing responsibility for the compartment to another customer account; i.e., a request to dissociate the purchased container from the parent container customer and associate the purchased container with another customer. An example of these embodiments include, but are not limited to, a consultant who may be hired by a customer to instantiate and configure an instance within a compartment inside an account of the consultant, whereupon after completion the compartment is then moved to an account of the customer. In other embodiments, the request to reassign ownership and billing responsibility may be performed by an automated process initiated by one or more actions of the buyer, such as by clicking through a web marketplace interface.

Furthermore, in some examples, an online marketplace system for compartments may be configured to notify the seller when the inventory of a particular compartment is sold out. In at least one embodiment, the seller may be further notified when inventory stocks of a particular compartment drop below a threshold quantity. In at least another embodiment, the seller may be notified when a consumer rates or reviews a product. In at least another embodiment, the seller may add responses to reviews of its products.

In at least one embodiment, a seller may configure each compartment as desired before posting the compartment for sale. In at least another embodiment, the seller creates a snapshot of a compartment after configuration and may create a fully-configured new compartment by instantiating a virtual machine from the snapshot. In at least another embodiment, the purchase of a compartment on an online marketplace may automatically create a new compartment by instantiating a virtual machine from the snapshot and/or provisioning other resources of the compartment. In this embodiment, the inventory may never sell out unless the seller chooses to stop selling the compartment or chooses to put a limit on the number of compartments that may be purchased or purchased over a period of time (e.g., such as five compartments per day).

Compartments may incur costs for the account owner because they may be allocated resources for which the computer services provider may bill. An account owner selling compartments in a marketplace may wish to mitigate costs incurred by compartments available for purchase while they are idle and unsold. In at least one embodiment, the account owner may make a snapshot of the configured compartment, deleting the compartment, and offering the snapshot of the compartment for sale on the marketplace. In this embodiment, the only costs incurred by an unsold compartment may be the storage costs associated with storing the snapshot. In at least another embodiment, the computer services provider may have a different billing structure for compartments while they are idle and unsold.

When a compartment is created within the account, it may utilize a collection of computing resources reserved by the account owner. In other examples, when the compartment is sold, the compartment may be transferred to a different collection of computing resources allocated to the buyer, and the computing resources reserved by the account owner may be freed for creation of another compartment or for other use by the account owner. In another example, the buyer may be further presented with computer resource purchasing options for hosting the compartment. In still another example, the computing resource service provider may further bill the buyer for the collection of computing resources for hosting the purchased compartment. In an alternate embodiment, the computing resource service provider may bill the account owner for the collection of computing resources for hosting the compartment, and the account owner may bill the buyer for the collection of computing resources.

In at least another embodiment, after purchase by a buyer, the compartment may continue to occupy the computing resources originally reserved by the account owner, and the account owner may be allocated different but equivalent computing resources for creation of another compartment or for other use by the account owner. In at least one embodiment, when one or more compartments are purchased by a buyer, the one or compartments may be instantiated for users within the account of the buyer, wherein the purchased one or more compartments may be administrated by one or more services, such as a database resource, and the buyer may not have one or more permissions to the one or more compartments compartment (such as view or administrative permissions).

A computing resource service provider may host various computing systems that consist of distributed sets of a plurality of components, subsystems and resources and may further include, but not be limited to, virtualized and/or non-virtualized components, subsystems and resources. In such distributed and/or virtualized systems, the plurality of components, subsystems and/or computer resources may consist of a collection of one or more instances of a number of different types and configurations of resources. Such resources may include, but not be limited to, load balancers, scaling groups, computing systems, database systems, database storage, block storage systems, block storage, data domains, system properties and/or other such computer system resources.

A computing resource stack may further comprise one or more descriptions of the set of resource instances (referred to herein as stacks), which may include information about the resource elements associated with the computing system, such as the type, number, configuration, metadata and/or other such information describing the associated resource instances. Further information about stacks and instantiating a stack may be found in co-pending U.S. patent application Ser. No. 14/228,119, entitled “PARALLEL ASYNCHRONOUS STACK OPERATIONS”, and co-pending U.S. patent application Ser. No. 14/036,700, entitled “CANCEL AND ROLLBACK UPDATE STACK REQUESTS”, which are hereby incorporated herein by reference in their entirety. A stack may be described using one or more templates, which may include lists of resources and parameters associated with those resources such as the required number and types of resource instances, the resource instances and parameters including systems, system parameters, system configurations, software, hardware, virtual machines, storage, network resources and/or other such resources that may be used by the stack instantiation. A stack may further specify creation, configuration, and use of one or more of standard and hidden compartments, one or more quotas for one or more compartments, and one or more long-term commitment instances to assign to one or more compartments. In at least one embodiment, such stacks and/or templates may be listed for sale on an online marketplace. An advantage of buying and selling stacks in an online marketplace for instantiation within compartments is that, until the stack is purchased, it may be more cost efficient for the seller to only incur the cost of storage for the stack while the stack is in available inventory rather than incurring the cost of having an unsold compartment being hosted by a computer resource provider.

In an online marketplace enabled to sell stacks, a marketplace buyer may purchase a stack listed on a marketplace to be instantiated into one or more compartments within an account of the buyer. In one example, the buyer may already have one or more existing compartments available for the stack to be instantiated into. In another example, completing the purchase transaction may cause one or more compartments to be created for the stack to be instantiated into. In yet another example, an entity of the seller account may assume a trustee role and/or administrator role of one or more compartments of the buyer, and the seller instantiates the stack within the one or more compartments. Note that assuming a role may comprise modifying an existing role to include permissions sufficient for an entity acting in the role to perform the actions required by the role being assumed; i.e., an existing role for a container may assume an administrator role by being modified to allow entities having that role to fully administer the relevant container. As another example, the computer resource provider may assume the role of trustee and/or administrator for one or more compartments of the buyer, and the computer resource provider instantiates the stack within the one or more compartments. In a different example, one or more compartments may be created with a parent container of the seller account and the stack may be instantiated within the one or more compartments, with the buyer accessing the stack through the parent container. In this embodiment, the seller may supply the billing services for billing the costs incurred by the instantiation of the stack to the buyer, rather than the computer resource provider. In one example, when one or more stacks are purchased by a buyer for instantiation into a compartment, the instantiated one or more compartments may be administrated by one or more resources, such as a database resource, and the buyer may not have one or more permissions to the one or more compartments compartment (such as view or administrative permissions). In another example, the inventory for a particular stack may be unlimited. In another example, the seller may be able to restrict available inventory of stacks. In yet another example, the seller may be able to make stacks available for a limited time, such as for a sale.

Furthermore, an online marketplace for compartments may be configured to notify the seller when the inventory of a particular stack is sold out. In one example, the seller may be further notified when inventory stocks of a particular stack drop below a threshold quantity. In another example, the seller may be notified when a consumer rates or reviews a stack. As yet another example, the seller may add responses to reviews of its stacks. In at least one embodiment, the computer resource service provider may manage the pool of unsold inventory. In one example of this embodiment, the computer resource service provider may, after the purchase of a stack by a buyer, create one or more compartments on demand and instantiate the stack within the compartment. In another example of this embodiment, the computer resource service provider may host a limited pool of compartments with instantiated stacks, so as to minimize the consumption of resources, and instantiate new stacks and compartments only when the inventory falls below a certain threshold.

FIG. 1illustrates an aspect of an environment100in which an embodiment of the present disclosure may be practiced. The environment100illustrated inFIG. 1may be the same environment as illustrated inFIG. 2, below. As illustrated inFIG. 1, the environment100may include an account102, which a user104accesses through a network106. The account102may be, for instance, a customer account of multiple customer accounts managed by the computing resource service provider discussed below in connection withFIG. 1. The account102structure includes the resources available to authorized users of the account102, as well as the account102owner, and may further comprise one or more compartments108, through which, like the account102, the one or more compartments108may call an API110to access or instantiate computing resources112. Whether users and services are authorized to perform requested operations on other resources within the account102may be determined by one or more policies defining levels of access held by the users or services. Users and services may hold one or more roles within the account102, and policies may be applied to individual users or may be applied to a role as a whole. The role of administrator may provide full access to all resources of the account102, and each account102may have one or more users having the administrator role. Whether a user or service is authorized to perform any particular action may be determined by an API call that includes a digital signature generated using a user credential (e.g., secret cryptographic key). In one example, the account102may be an account102accessible remotely through the network106by the user104. In another example, the account102may be accessible remotely through a network106or locally on the same computing device by a computing resource.

The network106represents the path of communication between the user104and the account102. Examples of the network106include, but are not limited to, the Internet, a local area network, a wide area network and Wi-Fi. The one or more compartments108may be defined by one or more records with a similar structure to one or more records associated with the account102, and the one or more compartments108may be a child entity of either the account102or another compartment108(parent container). In at least one embodiment, compartments may be nested within other compartments. In at least another embodiment, there may be a limit to the level of nesting. As another embodiment that may be combined with various embodiments, the level of nesting may be limited to one so that, for instance, a compartment can be created within an account, but not within another compartment.

From the perspective of an API110, which may be an API of a particular sub-system (e.g., service) discussed below in connection withFIG. 2, the one or more compartments108may be virtually identical from an account102, other than a record indicating that the structure may be of a container type rather than an account type. The one or more compartments108may also have at least one record field indicating the parent container of the one or more compartments108. Like an account102, the one or more compartments108may have users associated with the one or more compartments108. Like an account102, whether users and services are authorized to perform requested operations on other resources within the one or more compartments108may be determined by one or more policies defining levels of access held by the users or services. Whether a user or service is authorized to perform any particular action may be determined by an API call that includes a digital signature generated using a user credential (e.g., secret cryptographic key). Users and services may hold one or more roles within the one or more compartments108, and policies may be applied to individual users or may be applied to a role as a whole. The role of trustee may have full or partial administrative access to some or all resources of the one or more compartments108, and each compartment108may have one or more users having the trustee role. Account102and compartment108records may be stored in one or more databases, and an identity access services may manage the roles and policies of the assigned users and services. In one example, the users associated with the one or more compartments108may not necessarily be associated with the parent container other than indirectly through the association of the compartment with the parent. In another example, trustees of the parent container may also be trustees of the one or more compartments108. In yet another example, the parent container may be a trustee of the one or more compartments108.

The API110represents a library of functions or routines that may be called to perform specific operations that interact with, generate, or operate on computing resources112. The API may be a web service API. Examples of computing resources112include virtual machines, databases, files, and example operations causable through the submission of API calls include, but are not limited to, operations that create instances of virtual computer system services and on-demand data storage services, block level storage services, archival data storage services and database services.

FIG. 2shows an example of a customer connected to a computing resource service provider in accordance with at least one embodiment. The computing resource service provider202may provide a variety of services to the customer204and the customer204may communicate with the computing resource service provider202via an interface226, which may be a web services interface or any other type of customer interface. WhileFIG. 2shows one interface226for the services of the computing resource service provider202, each service may have its own interface and, generally, subsets of the services may have corresponding interfaces in addition to or as an alternative to the interface226. The customer204may be an organization that may utilize one or more of the services provided by the computing resource service provider202to maintain and deliver information to its employees, which may be located in various geographical locations. Additionally, the customer204may be an individual that utilizes the services of the computing resource service provider202to deliver content to a working group located remotely. As shown inFIG. 2, the customer204may communicate with the computing resource service provider202through a network206, whereby the network206may be a communication network, such as the Internet, an intranet or an Internet service provider (ISP) network. Some communications from the customer204to the computing resource service provider202may cause the computing resource service provider202to operate in accordance with one or more embodiments described herein or a variation thereof.

The computing resource service provider202may provide various computing resource services to its customers. The services provided by the computing resource service provider202, in this example, include a virtual computer system service208, a block-level data storage service210, a cryptography service212, an on-demand data storage service214, a notification service216, an authentication system218, a policy management service220, a task service222and one or more other services224. It is noted that not all embodiments described herein include the services208-224described with reference toFIG. 2and additional services may be provided in addition to or as an alternative to services explicitly described herein. As described herein, each of the services208-224may include one or more web service interfaces that enable the customer204to submit appropriately configured API calls to the various services through web service requests. In addition, each of the services may include one or more service interfaces that enable the services to access each other (e.g., to enable a virtual computer system of the virtual computer system service208to store data in or retrieve data from the on-demand data storage service214and/or to access one or more block-level data storage devices provided by the block level data storage service210).

The virtual computer system service208may be a collection of computing resources configured to instantiate virtual machine instances on behalf of the customer204. The customer204may interact with the virtual computer system service208(via appropriately configured and authenticated API calls) to provision and operate virtual computer systems that may be instantiated on physical computing devices hosted and operated by the computing resource service provider202. The virtual computer systems may be used for various purposes, such as to operate as servers supporting a website, to operate business applications or, generally, to serve as computing power for the customer. Other applications for the virtual computer systems may be to support database applications, electronic commerce applications, business applications and/or other applications. Although the virtual computer system service208may be shown inFIG. 2, any other computer system or computer system service may be utilized in the computing resource service provider202, such as a computer system or computer system service that does not employ virtualization or instantiation and instead provisions computing resources on dedicated or shared computers/servers and/or other physical devices.

The block-level data storage service210may comprise one or more computing resources that collectively operate to store data for a customer204using block-level storage devices (and/or virtualizations thereof). The block-level storage devices of the block-level data storage service210may, for instance, be operationally attached to virtual computer systems provided by the virtual computer system service208to serve as logical units (e.g., virtual drives) for the computer systems. A block-level storage device may enable the persistent storage of data used/generated by a corresponding virtual computer system where the virtual computer system service208may only provide ephemeral data storage.

The computing resource service provider202also includes a cryptography service212. The cryptography service212may utilize one or more storage services of the computing resource service provider202to store keys of the customers in encrypted form, whereby the keys may be usable to decrypt customer212keys accessible only to particular devices of the cryptography service212.

The computing resource service provider202further includes an on-demand data storage service214. The on-demand data storage service214may be a collection of computing resources configured to synchronously process requests to store and/or access data. The on-demand data storage service214may operate using computing resources (e.g., databases) that enable the on-demand data storage service214to locate and retrieve data quickly, so as to allow data to be provided in responses to requests for the data. For example, the on-demand data storage service214may maintain stored data in a manner such that, when a request for a data object is retrieved, the data object can be provided (or streaming of the data object can be initiated) in a response to the request. As noted, data stored in the on-demand data storage service214may be organized into data objects. The data objects may have arbitrary sizes except, perhaps, for certain constraints on size. Thus, the on-demand data storage service214may store numerous data objects of varying sizes. The on-demand data storage service214may operate as a key value store that associates data objects with identifiers of the data objects which may be used by the customer204to retrieve or perform other operations in connection with the data objects stored by the on-demand data storage service214.

In the environment illustrated inFIG. 2, a notification service216may be included. The notification service216may comprise a collection of computing resources collectively configured to provide a web service or other interface and browser-based management console. The management console can be used to configure topics for which customers seek to be notified of, configure applications (or people), subscribe clients to the topics, publish messages, or configure delivery of the messages over clients' protocol of choice (i.e., hypertext transfer protocol (HTTP), e-mail and short message service (SMS), among others). The notification service216may provide notifications to clients using a “push” mechanism without the need to periodically check or “poll” for new information and updates. The notification service216may further be used for various purposes such as monitoring applications executing in the virtual computer system service208, workflow systems, time-sensitive information updates, mobile applications, and many others.

As illustrated inFIG. 2, the computing resource service provider202, in various embodiments, includes an authentication system218and a policy management service220. The authentication system218, in an embodiment, may be a computer system (i.e., collection of computing resources) configured to perform operations involved in authentication of users of the customer. For instance, one of the services208-216and220-224may provide information from a user to the authentication service218to receive information in return that indicates whether or not the user requests are authentic.

The policy management service220, in an embodiment, may be a computer system configured to manage policies on behalf of customers (such as customer204) of the computing resource service provider202. The policy management service220may include an interface that enables customers to submit requests related to the management of policy. Such requests may, for instance, be requests to add, delete, change or otherwise modify policy for a customer or for other administrative actions, such as providing an inventory of existing policies and the like.

The computing resource service provider202, in various embodiments, may also be equipped with a task service222. The task service222may be configured to receive a task package from the customer204and enable executing tasks as dictated by the task package. The task service222may be configured to use any resource of the computing resource service provider202, such as one or more instantiated virtual machines or virtual hosts, for executing the task. The task service224may configure the one or more instantiated virtual machines or virtual hosts to operate using a selected operating system and/or a selected execution application in accordance with a requirement of the customer204.

The computing resource service provider202additionally maintains one or more other services224based at least in part on the needs of its customers204. For instance, the computing resource service provider202may maintain a database service for its customers204. A database service may be a collection of computing resources that collectively operate to run one or more databases for one or more customers204. The customer204may operate and manage a database from the database service by utilizing appropriately configured API calls. This, in turn, may allow a customer204to maintain and potentially scale the operations in the database. Other services include, but are not limited to, object-level archival data storage services, services that manage and/or monitor other services and/or other services.

FIG. 3illustrates an aspect of an environment300in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 3, the environment300may include a user302(through an associated computing device) initiating API304calls through a network306. The API calls may perform specific operations on the various resources within the environment300, such as general services308, accounting services310, including usage reports312and billing314operations, one or more account management databases316for storing records pertaining to the administration of entities and relationships between entities and between entities and computing resources112the entities may access. API304calls may further include calls to identity management services for performing operations relating to access security and the management of individual users, authorizations, policies and permissions.

FIG. 4illustrates an aspect of an environment400in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 4, the environment400may include a user402who may access, through a network404, an account406of which the user may be a member. It is noted that user402may be an individual (using an associated computing device), system, service, computing device, or other entity authorized to access the account406. Whether an entity is authorized to perform any particular action may be determined by an API call digitally signed using a proper credential. It is further noted that examples of the network404include the same examples given above for the network106inFIG. 1and also discussed below. The account406may have one or more compartments408already within it, or the user or a service of the account may generate the one or more compartments408within the account406. As disclosed above, both the account406and the one or more compartments408within the account may call an API410to access or instantiate computing resources412, and the API410may regard calls from the one or more compartments408as if the calls had been made by the account406, with one exception being that the policies, roles and permissions of the one or more compartments408, generally the same or more restrictive than the policies, roles and permissions of the account406, will be applicable.

Within this environment400, there may be a second user414who may access, through a network416, a second account418. It is noted that user414, as with the user402, may be an individual, system, resource, computing device, or other entity authorized to access the second account406. Whether an entity is authorized to perform any particular action may be determined by an API call that includes a digital signature generated using a user credential of the entity. It is further noted that examples of the network416include the same examples given above for the network106inFIG. 1, and may either be the same network as the network404or a different network. In this environment, the user402may seek to transfer ownership of the one or more compartments108to the second account418; i.e., to dissociate the one or more compartments from the parent container to the second account. If the user402has authorization to do so, the user402may cause a call to API410, through the parent container, the account406in this case, of the one or more compartments408, to transfer ownership of the one or more accounts408to the second account418. In other words, the user may perform an API call in a manner demonstrating authority (e.g., by an authentic digital signature) to cause the compartment408to transfer to the account418. A system providing the API410may perform operations to records defining the parent-child relationship of the account406and the one or more compartments408, including any necessary update to accounting/billing records, updating the records to indicate the second account410as the parent container of the one or more compartments408. In one example, a user of the second account418indicates acceptance of the ownership transfer before the second account418may assume ownership of the one or more compartments418; if no acceptance is received, the parent-child relationship between the account406and the one or more compartments408may be unchanged.

After the second account418becomes the parent container of the one or more compartments408, calls including credentials associated with the one or more compartments408are viewed by API410as if the calls had been made by using credentials of the account418, with the same exceptions regarding the policies, roles and permissions of the one or more compartments408. In this case, however, more restrictive policies, roles and permissions of the parent container, here being the second account418, may take precedence over less restrictive policies, roles and permissions of the one or more compartments408. Effectively, the one or more compartments408may be treated by the API410as if the one or more compartments had been originally created within the second account418. In at least one embodiment, the one or more compartments408may now have access to certain computing resources422accessible to the second account418, but not accessible to the account406. In at least another embodiment, the one or more compartments408may still retain access to certain computing resources412of the account406that the one or more compartments408had access to prior to the transfer of ownership from the account406to the second account418. As another embodiment that may be combined with various embodiments, the compartment may have multiple parent containers; i.e., compartments may be shared between containers.

FIG. 5illustrates an aspect of an environment500in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 5, the environment500may include an account management service502for managing information and privileges associated with at least one account504and at least one compartment506A. As with other services described herein, the account management service may be a computer system comprising computing resources configured to perform various operations, as described elsewhere herein. The account management service may be a distributed computer system comprising compute, data storage (e.g., block-level and/or database storage), networking and/or other computing resources that are collectively configured to perform operations described herein. The account504may be associated with at least one record508, and the compartment506A may be associated with at least one record510A containing metadata about the respective entities and the parent-child relationship between the account504and the compartment506A. Note that in this illustration, the record510A indicates that the principal container type of the compartment506A is “Compartment,” whereas the record508indicates that the principal container type for the account504is “Account.” Further, in this illustration, the record510A indicates that the compartment506A is a child of the account504by having the Parent ID field configured to the value of the Customer ID field in record508. In at least one embodiment, an account may be distinguishable from a compartment because the record associated with the entity indicates a principal type of the entity. Various alternate methods exists for distinguishing an account from a compartment, including, but not limited to, where an account may be distinguishable from a compartment because the record associated with the entity indicates that the entity has a parent container, in the case of a compartment, or that the entity has no parent container, in the case of an account.

The environment500may also include an accounting/billing service510A for determining the responsibility for billing costs incurred by accounts and compartments. The accounting/billing service512may determine that the account504is responsible for costs incurred by the account504by first checking the Parent ID field in the record508, and, finding the field value null, may recognize that the account504has no parent container and is therefore the top entity in its hierarchy. The effect of the link between the Parent ID field of the record510A and the Container ID field of the record508may be that when the accounting/billing service512is determining responsibility for costs incurred by the compartment506A, it first checks the Parent ID field in the record510A, which refers the accounting/billing service512to the record508. The accounting/billing service512may then check the Parent ID field in the record508, and, finding the field value null, may recognize that the account504has no parent container and is therefore the top entity in its hierarchy, and, consequently, the entity responsibility for costs incurred by the compartment506A. In one example, the accounting/billing service512firsts checks the principal container type prior to checking the Parent ID field, and if the principal container type is “Account,” the accounting/billing service determines that the respective entity of the record is the entity responsible for costs incurred and querying the Parent ID field may be unnecessary. However, as noted, another embodiment usable in combination with other embodiments may be where a compartment maintains separate billing records and responsibility. An advantage of such an embodiment could be where an account owner may have separate compartments for different regions with different taxation requirements, such as an international account owner with a European compartment for one division of the company and a United State compartment and another division of the company, and billing responsibilities may need to be maintained separately for each compartment.

As illustrated,FIG. 5further depicts changes that may occur when the compartment506A of the account504is converted to be a separate account506B. The compartment506A may become an account506B by changes made to the record510A, which may be depicted in record510B. For example, the Parent ID field of record510A is changed to null in record510B, and likewise the principal container type of record510A is changed from “Compartment” to “Account” in record510B. The effect of this change may mean that, in addition to determining that the account504is responsible for costs incurred by account504as described above, when the accounting/billing service512is determining responsibility for costs incurred by the account506B, the accounting/billing service510may realize either that the Parent ID field in the record510B is now null or that the principal container type in the record510B is “Account,” either of which may indicate the account506B as responsible for its own incurred costs rather than the account504. In one example, the account506B may only be responsible for costs incurred after the compartment506A was converted to be the account506B. In another example, the account506B may be responsible for at least some costs incurred while account506B was still the compartment506under the account504. However, as noted, there may be various alternatives to determining billing responsibility, including that the compartment may maintain its own records detailing responsibility for its own billing charges.

FIG. 6illustrates an aspect of an environment600in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 6, the environment600includes an account602. The account602may have one or more users604who have access to the account602. Further, the account602may also have one or more compartments606, and each of the one or more compartments606may have one or more of its own users608. Further, the compartment606may also have one or more of its own compartments610, and each of the one or more compartments610may have one or more of its own users612. Note that any, all, or none of the users604,608and612may be an individual, system, service, computing device, or other entity authorized to access the respective containers. Whether an entity is authorized to perform any particular action may be determined by an API call that includes a digital signature generated using a user credential of the entity. In at least one embodiment, there may be no limit to the number of compartments that may be nested within other compartments. In at least another embodiment, there may be a limit to the depth level of nested compartments that may be created within the account602account. As another embodiment that may be combined with various embodiments, the depth level of nested compartments may be limited to one. As still another embodiment combinable with other embodiments, all of the users of a child entity may also be users of its parent container; for example, all of the one or more users612may be members of the group of one or more users608, and all of the one or more users608may be members of the group of one or more users604. As another possible embodiment, users associated with a compartment may not necessarily be users associated with the parent container; for example, at least a subset of the one or more users612may not be present within the group of one or more users608, and at least a subset of the one or more users608may not be present within the group of one or more users604.

FIG. 7is a flow chart illustrating an example of a process700for creating a compartment within an account in accordance with various embodiments. The process700may be performed by any suitable system, which may be an account management service, such as described above, which may be implemented using one or more devices discussed in connection withFIG. 23. In702, a device of the system performing the process700receives a request to create a compartment. Examples of the type of computing device receiving the request include, but are not limited to, at least one of a server, a distributed computing system, a mobile device, a virtual computing system, and any other device as described below.

In704, a computing device performs a check of the role of the requestor and applicable security policies to determine whether the requestor has sufficient permission to perform the requested action (i.e., creation of a compartment within the associated account). If the requestor does not have sufficient permissions to perform the action, the computing device denies the request in706and no further processing may be performed in environment700. Otherwise, if the requestor does have sufficient permission, the device performing the process700proceeds to708, wherein one or more records are generated to define the compartment structure, generating a sequence of policies, roles and permissions of the parent account and account users to apply to the compartment, instantiating any desired resources within the compartment, and linking the compartment structure to the parent account. Note that operations performed in708may be performed in various orders and may be performed by separate services or systems. Examples of resources that may be instantiated within the compartment include, but are not limited to virtual computing system services, database services, block database services, archive database services and other database services. As noted, the requestor may be a service making the request in response to a customer request, pending authorization based on the customer's credentials.

In710, account billing records may be updated to reflect the creation of the compartment, such that costs incurred by instantiated resources or resources executing within the compartment can be billed to the proper customer. In712, one or more records may be updated to configure an appropriate trustee policy for the new compartment; an example of providing a compartment with a trustee policy includes, but is not limited to, imparting at least one of one or more services, one or more roles and one or more users of the parent account with a role of trustee and/or administrator of the compartment, the trustee and/or administrator role having full access to administrate the compartment. Note the operations performed in708,710and712may be performed in various orders, including in parallel, and each operation may be performed by one or more devices different from the devices performing any of the other operations in process700.

FIG. 8is a flow chart illustrating an example of a process800for deleting a compartment in accordance with various embodiments. The process800may be performed by any suitable system, which may be an account management service, such as described above, which may be implemented using one or more devices discussed in connection withFIG. 23. In802, a device of the system performing the process800receives a request to delete a compartment. Examples of the type of computing device receiving the request include, but are not limited to, at least one of a server, a distributed computing system, a mobile device, a virtual computing system, and any other device as described below. As noted, the requestor may be a service making the request in response to a customer request, pending authorization based on the customer's credentials.

In804, the computing device performs a check of the role of the requestor and any applicable security policies to determine whether the requestor has sufficient permission to perform the requested action (i.e., deletion of the compartment within the associated account). If the requestor does not have sufficient permissions to perform the action, the computing device denies the request in806and no further processing may be performed in environment800. Otherwise, if the requestor does have sufficient permission, the device performing the process800proceeds to808, wherein the account management records may be updated to reflect that the compartment no longer exists. In one example, one or more records defining the compartment structure may be deleted. In another example, one or more records defining the compartment may be updated to reflect that the compartment is inactive.

In810, billing records may be updated to reflect that the compartment no longer has the ability to incur costs, and any outstanding costs incurred by the compartment may be updated and re-associated with the parent account. In one example, past costs incurred by the compartment remain associated with the compartment for historical reference, troubleshooting, and reporting purposes.

In812, a compartment de-provisioning workflow process is performed. Examples of operations that may be performed at this step include, but are not limited to any or none of the following, transferring any unused long-term commitment instances within the compartment to the long-term commitment instance pool of the parent account, transferring assigned quotas from the compartment to the quota pool of the parent account, and de-provisioning any active resources instantiated within the compartment. Examples of resources that may be instantiated within the compartment include, but are not limited to virtual computing system services, database services, block-level database services, archive database services and other database services. Note that the operations performed in808,810and812may be performed in various orders, including in parallel, and each operation may be performed by one or more devices different from the devices performing any of the other operations in process800.

FIG. 9is a flow chart illustrating an example of a process900for changing ownership or promoting a compartment to be an account in accordance with various embodiments. The process900may be performed by any suitable system, which may be an account management service, such as described above, which may be implemented using one or more devices discussed in connection withFIG. 23. The process900includes a series of operations wherein the parent-child relationship of an account and compartment may be changed to reflect either the compartment being assigned to a different account or the compartment being promoted to an account. In902, a device of the system performing the process900receives a request to change the owner of a compartment. Examples of the type of computing device receiving the request include, but are not limited to, at least one of a server, a distributed computing system, a mobile device, a virtual computing system and any other device as described below. As noted, the requestor may be a service making the request in response to a customer request, pending authorization based on the customer's credentials.

In904, the computing device performs a check of the role of the requestor and any applicable security policies to determine whether the requestor has sufficient permission to perform the requested action (i.e., changing the ownership of the compartment). If the requestor does not have sufficient permissions to perform the action, the computing device denies the request in906and no further processing may be performed in environment900. Otherwise, if the requestor does have sufficient permission, the device performing the process900proceeds to908, wherein the computing device determines whether the requestor has requested a reassignment of ownership to another account or a conversion of the compartment into an account.

If the requestor has indicated that the compartment may be assigned to another specified account, the device performing the process900proceeds to910where the computing device updates one or more account management records to reflect that the parent of the compartment now be the other specified account. In one example, the operation may further include updating account billing records to indicate that costs incurred by users and services within the compartment that occurred prior to the ownership reassignment may be the responsibility of the previous parent account, whereas all new costs incurred with the compartment become the responsibility of the new parent account. In still another example, the compartment may have its own corresponding billing records to be updated to indicate the parties responsible for billing and auditing charges.

In still another example, handshaking may be required; that is, when an entity requests to transfer a compartment to another account, a user or other entity with sufficient authority in the specified other account (as may be determined by passing a proper digitally signed credential to an API) must approve reassignment of the compartment to the other account. For example, a vendor may list a compartment for sale, whereupon the buyer may need to approve for the compartment to be transferred from the vendor's account to the buyer's account. Note that handshaking may be present in other cross-account and cross-compartment operations described herein, such as one account may require authenticated approval from another account to administrate or perform maintenance from the other account, or a lessor account may need to provide authenticated approval for certain requests by a compartment lessee, such as a request to delete the compartment.

Otherwise, if the requestor has indicated that the compartment may be converted into an account, the device performing the process900proceeds to912where the computing device updates one or more account management records to reflect that the previous account is no longer a parent of the compartment and that the principal type of the structure defining the compartment is now an account. In one example, a field indicating the identity of a parent container may be sufficient to distinguish an account from a compartment; e.g., a compartment entity will have a parent and an account entity will have no parent. In another example, the field reflecting the principal type of the container may be sufficient to distinguish an account from a container. As another example, account billing records may be further updated to reflect that costs incurred by the new account (formerly the compartment) may be the responsibility of the new account and not associated with the previous parent. As yet another example the operation may further include updating account billing records to indicate that costs incurred by users and services within the compartment that occurred prior to the conversion may be the responsibility of the previous parent account, whereas all new costs incurred with the new account become the responsibility of the new account. In at least another example, an account may be converted (e.g., demoted) to be a compartment and subsequently assigned to another container.

FIG. 10is a flow chart illustrating an example of a process1000for assuming a compartment in accordance with various embodiments. The process1000may be performed by any suitable system, which may be an account management service, such as described above, which may be implemented using one or more devices discussed in connection withFIG. 23. The process1000includes a series of operations wherein a compartment may be dissolved and the parent account assumes (e.g., absorbs) one or more users or services of the compartment into itself. In1002, a device of the system the process1000receives a request to assume a compartment. Examples of the type of computing device receiving the request include, but are not limited to, at least one of a server, a distributed computing system, a mobile device, a virtual computing system and any other device as described below. As noted, the requestor may be a service making the request in response to a customer request, pending authorization based on the customer's credentials.

In1004, the computing device performs a check of the role of the requestor and applicable security policies to determine whether the requestor has sufficient permission to perform the requested action (i.e., assuming the contents of the compartment). If the requestor does not have sufficient permissions to perform the action, the computing device denies the request in1006and no further processing may be performed in environment1000. Otherwise, if the requestor does have sufficient permission, the device performing the process1000proceeds to1008, wherein the computing device begins by obtaining a list of users within the compartment.

In1010and1012, the computing device compares the username or identity of each user within the compartment with current users within the parent account. Users that do not currently exist in the parent account may be assumed by the parent account, retaining any policies, roles and permissions applicable to compartment resources that are also being assumed. Users of the parent account who also have membership as users in the compartment being assumed may be retained in the parent account and their security records may be updated to retain policies, roles and permissions applicable to compartment resources that are also being assumed. In some embodiments, compartment users matching a username or user identity of a user in the parent account, but who may actually be different users, may be updated to generate a unique username or identity for the compartment user before being assumed by the parent account. In one example, the users of the compartment may not be assumed by the account, and, once the computing device determines that the requestor has sufficient permissions to perform the action in1004, the device performing the process1000proceeds instead to1014.

In1014, the computing device transfers the instantiation of resources in the compartment to the parent account. Also in1014, relevant accounting and billing records may be updated to reflect that the resources may now be instantiated in the parent account. In one example, the costs incurred by the compartment may be transferred to the parent account. In another example, the costs incurred by the compartment remain associated with the compartment, but records may be updated to reflect that parent account may be responsible for the costs. In still another example, only a subset of the one or more users, one or more resources within the compartment may be assumed by the parent account, and those remaining may be de-provisioned. Lastly, in1016, the compartment may be removed in accordance with operations similar to those illustrated inFIG. 8. Note that the operations performed in1008-1010,1012-1014and1016may be performed in various orders, including in parallel, and each operation may be performed by one or more devices different from the devices performing any of the other operations in process1000.

FIG. 11illustrates an example process of an environment1100in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 11, the environment1100includes a parent container1102. The parent container1102may be an account, a compartment, or another entity in which a compartment may be contained. The parent container has a number of associated users1104having one or more permissions, roles and/or policies assigned. It is noted that users1104may individually be any of an individual, system, service, computing device, or other entity authorized to access the parent container1102, as may be determined by passing a proper digitally signed credential to an API.

The parent container1102may further be the owner of a compartment1106. The compartment1106is a compartment that may have been transferred to the parent container1102from some other container entity (i.e., dissociated from the other container entity and associated with the parent container1102), may have been converted from an account into a compartment and assigned to the parent container1102, or may have been created within the parent container1102and is still contained within parent container1102. The users1104of the parent container may have access to the compartment1106, as defined by the roles, policies and permissions associated with the users1104.

The compartment1106may further contain one or more users1108having one or more permissions, roles and/or policies within the compartment1106; however users1108in the compartment1106do not necessarily have access to the parent container unless at least some of the users1108are also members of the users1104. The compartment1106may alternately be created as or converted to be a hidden compartment1110. A hidden compartment may be substantially similar to a standard compartment1106, but with restrictions on the access that users1104have over the hidden compartment1110.

FIG. 12illustrates an example process of an environment1200in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 12, the environment1200compares an account1202, having one or more users1204, with a standard compartment1206against that account1202if it had a hidden compartment1210instead of the standard compartment1206. It is noted that any or all of the users1204and/or1208may be an individual, system, service, computing device, or other entity authorized to access the respective account1202, compartment1206, or compartment1210in which they reside. Authorization may be determined by passing a proper digitally signed credential to an API. It is further noted that, although the standard compartment1206and the hidden compartment1210are shown inFIG. 12as residing within an account container, the account1202could just as easily be another container or other container type suitable for containing compartments.

The difference between a standard compartment1206and a hidden compartment1210is illustrated with arrows showing that one or more users1204may view and/or have other access to resources instantiated within the standard compartment1206, whereas the users1208do not necessarily have visibility or access to resources contained within account1202exclusive of the resources contained within compartment1206. With a hidden compartment1202, as with the standard compartment, the users1208do not necessarily have visibility or access to resources contained within account1202exclusive of the resources contained within the compartment1210. However, with a hidden compartment1210, at least some of the users1204may not have the ability to view and/or access resources contained within the compartment1210. The users1208have access to the resources of the hidden compartment1210as usual as defined by the particular policies, roles and permissions assigned to the users1210. Uses for the hidden compartment include, but are not limited to, setting up user space and instantiations of resources for secret projects, confidential data, resources that need to generate instantiations in a workspace protected from interference by users1204. In at least one embodiment a standard compartment may be converted to type of hidden compartment and vice versa. In at least another embodiment, a hidden compartment may be created in a similar manner as a standard compartment except for having a principal type of “hidden.”

FIG. 13is a flow chart illustrating an example of a process1300for creating a hidden compartment in accordance with various embodiments. The process1300may be performed by any suitable system, which may be an account management service, such as described above, database service, or any service with suitable permissions for performing the actions, which may be implemented using one or more devices discussed aboutFIG. 23. As illustrated inFIG. 13, the process1300includes a series of operations wherein a resource may be created within a hidden compartment. In1302, a device of the system performing the process1300receives a request to create a resource. Examples of the type of computing device receiving the request include, but are not limited to, at least one of a server, a distributed computing system, a mobile device, a virtual computing system and any other device as described below. As noted, the requestor may be a service making the request in response to a customer request, pending authorization based on the customer's credentials.

After determining that the requestor is authorized to have a resource created, as may be determined by passing a proper digitally signed credential to an API, the device performing the process1300proceeds to1304, wherein the computing device determines the identity of the container in which the hidden compartment will be created in. The identified container may be an account, a compartment, or another type of container in which a hidden compartment may be contained. In at least one embodiment, the identified container will be the container which also contains the identity of the user making the request. In an embodiment where the identity of the user is simultaneously contained within multiple containers, the identified container will be the one currently being accessed by the user in making the request to create a resource. It is noted that the user may be an individual, system, resource computing device, or other entity authorized to access the identified container, as may be determined by passing a proper digitally signed credential to an API.

After identifying the relevant container, the device performing the process1300proceeds to1306, wherein the computing device determines whether a hidden compartment already exists for this purpose (i.e., hosting the requested resource). In one example, a hidden compartment may already exist because it was created by a previous request or requestor. In another example, the hidden compartment already exists because a hidden compartment was previously generated and held in reserve.

If a hidden compartment already exists that may be used for this resource, the device performing the process1300selects this hidden compartment and proceeds to1310. Otherwise, if a hidden compartment does not already exist, the device performing the process1300generates a new compartment within the relevant container and sets it to be a hidden compartment. In at least one embodiment, a hidden compartment may be distinguished from a standard compartment by the trustee and/or administrator of the parent container not having view access to resources within the hidden compartment. In at least another embodiment, a hidden compartment may be distinguished from a standard compartment by a principal container type of “hidden” in one or more records defining the compartment. After the hidden compartment is generated, the device performing the process1300proceeds to1310. As another embodiment that may be combined with various embodiments, the existence of a hidden compartment may not normally be viewable to some users in a report or listing of compartments and resources of the parent container. As another embodiment combinable with other embodiments, some users of the parent container may be able to view the hidden compartment in a report or listing of compartments and resources of the parent container, but the users may only have limited visibility or permissions to resources within the hidden compartment. In at least another embodiment, each user or service may be limited to create and/or utilize only a specified number of hidden compartments. In1310, the service may be assigned a role giving the service permission to manage the hidden compartment and instantiate any resources as needed.

FIG. 14illustrates an aspect of an environment1400in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 14, the environment1400may include a user1402who may access, through a network1404, an account1406A of which the user is a member. It is noted that user1402may be an individual, system, service, computing device, or other entity authorized to access the account1406A. Authorization may be determined passing a proper digitally signed credential to an API It is further noted that examples of the network1404include the same examples given above for the network106inFIG. 1. The account1406A may also contain one or more compartments1408A. Both the account1406A and the one or more compartments1408A within the account may call an API1410to access or instantiate computing resources1412, and the API1410may regard calls from the one or more compartments1408A as if the calls had been made by the account1406A, with one exception being that the policies, roles and permissions of the one or more compartments1408A, generally the same or more restrictive than the policies, roles and permissions of the account1406A, will be applicable to the one or more compartments1408A.

In the environment1400, the account1406A may have an assigned quota of ten database instances. However, to ensure that the user1402does not use up the entire quota pool for the account1406A, or to ensure that the user1402does not exceed the quota for the account1406A (which may incur an increased billing cost), at least some of the quota from the quota pool of the account1406A may be assigned to the compartment1408A, and the user1402may then be restricted to only create database instances within that compartment1408A up to a quota limit, which in this example is five. The compartment1408B now has a quota limit of five, limiting the parent account1406B to five database instances at the account level, since five instances of the original quota have been transferred to the compartment1408B. In aggregate, the quotas assigned to the parent account1406B and the compartment1408B equal the total original quota pool of the parent account1406A. Thus, by assigning a quota to the compartment1408A from the quota pool of the account1406A, the parent account1406B may be assured that the user1402will not exhaust the quota pool prematurely.

FIG. 15is a flow chart illustrating an example of a process1500for quota aggregation in accordance with various embodiments. The process1500may be performed by any suitable system, which may be an account management service, such as described above, which may be implemented using one or more devices discussed in connection withFIG. 23. The process1500includes a series of operations wherein a compartment may be created and assigned a quota from the quota pool of the parent account. In1502, a device of the system performing the process1500receives a request to create a compartment within an account. The process1500may be performed to create either a standard compartment or a hidden compartment within an account or another compartment or hidden compartment.

After determining that the requestor is authorized to create a compartment within the account, as may be determined by passing a proper digitally signed credential to an API, the device performing the process1500proceeds to1504, wherein the compartment may be created according to steps similar to the process700illustrated inFIG. 7or process1300illustrated inFIG. 13. In1506, the device performing the process1500receives a request to assign a quota to the newly-created compartment. After determining that the requestor is authorized to assign quotas to the compartment, the device performing the process1500proceeds to1504, wherein the computing device verifies that the requested quota amount does not exceed the remaining quota pool of the parent account. If the requested quota amount exceeds the remaining quota pool of the parent account, the device performing the process1500proceeds to1510to deny the request. In at least one embodiment, the request may not be denied, but rather the quota pool of the parent may be increased by an amount necessary to support the quota amount requested for the child compartment.

Otherwise, if the requested quota amount does not exceed the quota pool of the parent account, the device performing the process1500proceeds to1512, whereupon the compartment may be assigned a quota according to the requested amount, and in1514, the requested quota amount may be deducted from the quota pool of the parent. In at least one embodiment, the parent quota pool remains the same, but the computing device keeps track of the assigned quota amounts versus the unassigned quota amounts. Note that the operations performed in1502-1504and1506-1514may be performed in various orders, including in parallel, and each operation may be performed by one or more devices different from the devices performing any of the other operations in process1500.

FIG. 16illustrates an aspect of an environment1600in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 16, the environment1600may include a user1602who may access, through a network1604, an account1606A of which the user is a member. It is noted that user1602may be an individual, system, resource computing device, or other entity authorized to access the account1606A. Authorization may be determined by passing a proper digitally signed credential to an API. It is further noted that examples of the network1604include the same examples given above for the network106inFIG. 1. The account1606A may also contain one or more long-term commitment instances1608A. In the example environment1600, a compartment1610may be created within the account1606B. The compartment1614may be either a standard compartment or a hidden compartment. At least one of the one or more long-term commitment instances1608A may be assigned to the compartment1610as an instance1612that may be instantiated within the compartment1610, leaving the remaining long-term commitment instances1608B assigned to the account.

FIG. 17is a flow chart illustrating an example of a process1700for instantiating a long-term commitment instance within a compartment in accordance with various embodiments. The process1700may be performed by any suitable system, which may be an account management service, such as described above, database service, or any service with suitable permissions for performing the actions, which may be implemented using one or more devices discussed aboutFIG. 23. In1702, a device of the system performing the process1700receives a request to create a database within a compartment. The process1700may be performed to create a database within either standard compartment or a hidden compartment. As noted, the requestor may be a service making the request in response to a customer request, pending authorization based on the customer's credentials.

After determining that the requestor is authorized to create a database within the compartment, as may be determined by passing a proper digitally signed credential to an API, the device performing the process1700proceeds to1704, wherein the computing device determines the identity of the parent container containing one or more long-term commitment instances. The parent container may be an account, a standard compartment, or a hidden compartment.

In1706, the device performing the process1700checks to determine whether a compartment has already been created for the database. The compartment may be either a standard compartment or a hidden compartment. If no compartment has been created for the database, the device performing the process1700proceeds to1708whereupon a compartment may be created within the account for the database. Depending upon whether the compartment is to be created as a standard compartment, the process for creating a compartment in1708may be similar to the operations performed by process700illustrated inFIG. 7or process1300illustrated inFIG. 13.

Once a compartment exists in which to instantiate the database, the device performing the process1700proceeds to1710wherein the device checks the compartment to determine whether an instance has been reserved in the compartment to be used for the database instantiation. If no instance has been reserved in the compartment, the device performing the process1700checks the parent container to determine whether the parent container contains a long-term commitment instance that may be transferred to the compartment to be used for the database instantiation. If parent container contains no long-term commitment instances, the device performing the process1700continues to traverse up the hierarchical tree of parent-child container relationships until either a long-term commitment instance usable for instantiating the database is found or the traversal reaches the root node without finding any suitable long-term commitment instances. In at least one embodiment, the traversal of the tree of parent-child container relationships stops after the first parent is checked.

If no long-term commitment instances are found, the device performing the process1700proceeds to1712, whereupon an instance for the new database is dynamically generated within the compartment. Otherwise, the device performing the process1700proceeds to step1714, whereupon the database may be either instantiated as the long-term commitment instance assigned to the compartment, or, if the long-term commitment instance was found elsewhere in the hierarchy, the found long-term commitment instance may be transferred to the compartment and the database instantiated as the long-term commitment instance.

FIG. 18illustrates an aspect of an environment1800in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 18, the environment1800may include a user1802who may access, through a network1804, an account1806of which the user is a member. It is noted that user1802may be an individual, system, service, computing device, or other entity authorized to access the account1806. Authorization may be determined by passing a proper digitally signed credential to an API. It is further noted that examples of the network1804include the same examples given above for the network106inFIG. 1. The account1806may also contain one or more compartments1808A. Both the account1806and the one or more compartments1808A within the account may call an API1810to access or instantiate computing resources1812, and the API1810may regard calls from the one or more compartments1808A as if the calls had been made by the account1806, with one exception being that the policies, roles and permissions of the one or more compartments1808A, generally the same or more restrictive than the policies, roles and permissions of the account1806, will be applicable to the one or more compartments1808.

In the environment1400, the compartment1808A may have been configured for resale by the user1802with various customized resources. A buyer1814may purchase the compartment1808A, whereupon the compartment1808A may be transformed into a standalone account1808B in a manner similar to the process disclosed inFIG. 9and illustrated inFIG. 5. The account billing records may also be updated to reflect that the buyer1814may be the responsible party for costs incurred by the standalone account1808B.

After the compartment1808A is converted into a standalone account1808B, the buyer1814may access, through a network1816, the standalone account1808B. It is noted that examples of the network1816include the same examples given above for the network106inFIG. 1, and may either be the same network as the network1804or a different network. The standalone account1808may call the API1810to access or instantiate computing resources1812, however the API1810no longer regards calls from the standalone account1808A as if the calls had been made by the former parent account1806.

In at least one embodiment, when the compartment1808A is purchased by the buyer1814, the compartment1808A may be transformed into the standalone account1808B and account billing services may be configured to indicate that the buyer1814will be responsible for future costs incurred by the standalone account1808B. In at least another embodiment, the compartment1808A may remain a compartment1808A under the account1806, but the buyer1814has access to the compartment1808, and the account billing services may be configured to indicate that the buyer1814may be responsible for future costs incurred by the purchased compartment1808A. As another embodiment that may be combined with various embodiments, the compartment1808A may be transformed into the standalone account1808B, but the account1806retains permissions sufficient for the user1802to upgrade and perform maintenance on the standalone account1808B as desired. In at least another embodiment, the user1802may initiate the request to reassign ownership and billing responsibility for the purchased container1808. As still another embodiment, combinable with other embodiments, the request to reassign ownership and billing responsibility may be performed by an automated process initiated by one or more actions by the buyer1814, such as clicking through a web marketplace interface.

FIG. 19illustrates an aspect of an online marketplace1900in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 19, the online marketplace1900may include a web page1902of a website which may be used to provide access to the online marketplace1900. The web page1902may include various graphical elements for enabling a user to navigate the online marketplace1900to find, purchase, and use preconfigured compartments. Note that interface elements are not limited to the graphical or textual elements as illustrated, but may be textual elements, graphical elements, animations, audible or haptic feedback regions, applications, and other elements which may be utilized with a web page. The web page1902may be displayed by various devices and applications, including, but not limited to, web browsers executing on a computing device and mobile applications executing on tablets and cellular telephones.

The online marketplace1900may feature user-friendly interface elements such as the different categories1904displayed in a left-side column on the web page1902. Examples of different categories1904which may be used to organize and navigate the online marketplace1900include, but are not limited to, such categories1904as categories for compartments configured to host a particular operating system, categories for applications configured to execute within a compartment, categories for databases configured to be hosted within a compartment, and other categories as desired for organization and other purposes. Note that these categories1904are non-limiting and used for illustrative purposes only.

The online marketplace1900may feature selection mechanisms including, but not limited to, graphical or hypertext markup language form elements such as radio-type buttons, checkboxes1906, dropdown lists, listboxes, multiselect boxes. The online marketplace1900may further feature such elements as textboxes for writing reviews1908and search boxes1910for performing text or image searches. The online marketplace1900may further include features to aid comparison shopping, such as reviews, like reviews viewable by clicking the review link1908, of products which may be viewed and/or created by consumers, ratings, like the star rating1912, and pricing information. Users may select their desired compartment and purchase by clicking an icon, button, or checkbox1906on the online marketplace. Users may further select to complete and pay for their purchase by clicking an interface element, such as checkout button1914.

The online marketplace1900may host compartments for sale by different owners of accounts with a computing resource service provider. The different account owners may have compartments listed for sale on the online marketplace1900which have been configured by the account owners under their own account. In this illustration of an online marketplace1900, an account owner, 123 Corp, has configured a “Point-of-Sale System” in a compartment and has offered it as a purchasable compartment1916for sale on the online marketplace1900. The purchasable compartment1916has been given an average rating1912of two stars by consumers, 44 of which have posted reviews which may be read by potential buyers by clicking the review link1908labeled “44 Reviews.” Likewise, XYZ Software has offered an “eCommerce System” purchasable compartment1920and a “Real Estate System” purchasable compartment1922for sale on the online marketplace1900. The purchasable compartment1920has been given an average rating of four stars by consumers, ten of which have posted reviews. The online marketplace1900may further be configured to display inventory information, such as the notification1924corresponding to the purchasable compartment1920that notifies consumers that only three compartments are left in stock. Other inventory information that may be displayed includes, but is not limited to, notifications that a product is in stock, sold out, or expected to be available for purchase on a certain date.

Furthermore, the online marketplace1900may be configured to notify the seller when the inventory of a particular compartment is sold out. In one example, the seller may be further notified when inventory stocks of a particular compartment drop below a threshold quantity. In another example, the seller may be notified when a consumer rates or reviews a product. In still another example, the seller may add responses to reviews of its products.

The online marketplace may allow a buyer to complete the purchase transaction by clicking an interface element, such as the checkout button1914. Clicking this button may take the buyer to a different web page where the buyer may enter payment information, such as credit card information, select various options and/or accessories for the selected products, and review the order before executing the transaction. In at least one embodiment, after the transaction is executed, the compartment may be converted into an account. In at least another embodiment, after the transaction is executed, the compartment may remain a compartment within a parent container. As another embodiment that may be combined with various embodiments, the buyer may also enter information about users, roles, and policies for each compartment purchased at this time. As another embodiment, combinable with other embodiments, multiple compartments may be selected to be installed in an account. In at least another embodiment, multiple compartments may be selected, any or all of which may be installed within one or more separate accounts.

FIG. 20illustrates an aspect of an online marketplace2000in which an embodiment of the present disclosure may be practiced. As illustrated inFIG. 20, the online marketplace2000includes a seller web page2002which may include various graphical elements for enabling a seller to list compartments configured by the seller for sale on the online marketplace. Note that interface elements are not limited to the graphical or textual elements as illustrated, but may be textual elements, graphical elements, animations, audible or haptic feedback regions, applications, and other elements which may be utilized with a web page. The web page2002may be displayed by various devices and applications, including, but not limited to, web browsers executing on a computing device and mobile applications executing on tablets and cellular telephones.

The online marketplace2000may feature interface elements for the seller web page2002, such as a table2004listing the compartments the seller has offered for sale, including information such as stock-keeping unit (SKU) numbers, product names, quantity available for purchase, and the sell price. The seller may be able to modify the sell price, quantity available, product name, and SKU number by clicking an interface element, such as an edit button2006. Additional interface elements may be present, such as checkboxes2008for selections of products for deletion, editing, activating, or inactivating inventory items from the marketplace. In one example, the online marketplace2000may have additional promotional features, such as options for creating special sales, options for creation of particular promotions and discounts, and options for offering and accepting gift cards and coupons for the seller's products.

The online marketplace2000may feature interface elements for the seller web page2002, such as a menu bar2010for selecting different screens and web pages for aiding the seller in managing products, such as a page listing the seller's inventory, a page listing the current orders buyers have made of the seller's products, and a reports page for displaying historical information and sales trends of the seller's products.

The online marketplace2000may feature interface elements for the seller web page2002to enable sellers to select compartments they have configured for sale, such as an add compartment button2012. After clicking such an interface element, the seller may be prompted with another interface allowing the seller to choose one or more compartments from a listing of available compartments the seller has created and/or configured. In one example, the seller may obtain or purchase compartments from another seller and make them available for resale.

The online marketplace2000may further feature interface elements for the seller web page2002to enable sellers to remove compartments from inventory, such as a remove compartments button2014. A seller may choose to remove compartments from inventory for various reasons, including, but not limited to, software installed within the compartment may be obsolete and need to be updated, the seller no longer wishing to sell the particular compartment, or the compartment was listed for sale as a limited promotion which has now ended.

FIG. 21is a block diagram illustrating an example of a process2100for selling compartments in a marketplace in accordance with various embodiments. The process2100may be performed by any suitable system, which may be an account management service, such as described above, a marketplace transaction service, or any service with suitable permissions for performing the actions, which may be implemented using one or more devices discussed aboutFIG. 23. In2102, a device of the system the process2100receives a request to create a compartment in a reseller account. The type of compartment requested may be either a standard compartment or a hidden compartment.

After determining that the requestor is authorized to have a compartment created within the account, as may be determined by passing a proper digitally signed credential to an API, the device performing the process2100proceeds to2104whereupon the device performing the process2100creates a compartment within the account according to a process similar to the processes disclosed inFIGS. 7 and 13. In2106, the requestor or other authorized user instantiates zero or more resources within the compartment, customizing the resources as desired by the requestor.

After the compartment and its resources have been configured to the satisfaction of the requestor, in2108, the requestor may offer the compartment up for sale. For example, the compartment may be purchasable from a marketplace website.

In2110, the device performing the process2100receives a request from a buyer to purchase the compartment. In one example, the request may be received from a buyer through a marketplace website. In another example, the request may be a notification from the reseller account that the buyer has purchased the compartment.

In2112, the device performing the process2100transforms the purchased compartment into a standalone account. In the illustrated embodiment, the device performing the process2100may transform the compartment into an account by changing the principal type of one or more records of the compartment to a type of “Account.” In still another example, a field in one or more records indicating the parent container of the compartment may be updated to reflect that the standalone account has no parent. As another example, an additional field may be updated to reflect the transformation of the container into the standalone account.

In2114, the device performing the process2100updates one or more accounting billing records to reflect that the buyer of the compartment (now the standalone account) will be responsible for costs incurred by the container. Note that the operations performed in the steps of the process2100may be performed in various orders, including in parallel, and each operation may performed by one or more devices different from the devices performing any of the other operations in process2100.

FIG. 22is a flow chart illustrating an example of a process2200for purchasing a stack for instantiation within one or more compartments in accordance with various embodiments. The process2200may be performed by any suitable system, which may be an account management service, such as described above, a marketplace transaction service, or any service with suitable permissions for performing the actions, which may be implemented using one or more devices discussed aboutFIG. 23. In2202, a device of the system performing the process2200may receive a request that an entity, such as a buyer, has purchased at least one stack from an online marketplace. An online marketplace for selling stacks may appear similar to the online marketplace depicted inFIG. 19, but that the products may be stacks rather than compartments. In one example, multiple stacks may be selected to be installed into a compartment. In another example, multiple stacks may be selected, any or all of which may be installed into one or more separate compartments.

In2204, the purchase transaction of the stack is completed. In one example, the buyer may be allowed to specify one or more compartments, quotas, long-term commitment instances, and hardware requirements for the purchased stack. Upon completion of the purchase transaction, the device performing the process2200proceeds to2206, wherein the device queries whether the buyer has an existing one or more compartments within a container allocated or usable for an instantiation of the purchased stack. If no suitable compartment or compartments are found, the device performing the process2200proceeds to step2208, wherein one or more compartments may be created according to steps similar to the process700illustrated inFIG. 7or process1300illustrated inFIG. 13in the buyer account as needed. Note that the type of compartment usable for instantiating a stack may be either a standard compartment or a hidden compartment, as may be determined by the buyer, the computing resource service provider, the seller, parameters of the stack, or of the particular requirements of the resources being instantiated according to the stack or stack template, or any combination of the above. In one example, multiple compartments may be required or generated in response to purchasing a stack. In another example, the stack template may specify the type and number of compartments to be created. In still at least another example, one or more compartments may be created within a parent container of the seller account and ownership of the one or more compartments may be transferred to the buyer according to steps similar to the process900illustrated inFIG. 9. As another example, the stack may specify quotas for one or more compartments created according to steps similar to process1500inFIG. 15.

In2210, the one or more existing and/or newly-created compartments may be selected by the device performing process2200. In2212, the device performing the process2200may instantiate the stack into the one or more selected compartments according to parameters of the stack or stack template and/or parameters specified by the buyer. In another embodiment, the instantiation of resources within the compartment are performed using one or more long-term commitment instances as illustrated in environment1600ofFIG. 16or according to steps similar to process1700inFIG. 17. In at least another embodiment, the stack may be instantiated within one or more compartments are created within a parent container of the seller and the buyer accesses the purchased stack through the parent container. In such an embodiment, the buyer may be billed by the seller for costs incurred by the stack instantiations rather than be billed by the computer resource provider.