CN108112268B

CN108112268B - Managing load balancers associated with auto-extension groups

Info

Publication number: CN108112268B
Application number: CN201680024791.9A
Authority: CN
Inventors: 马塞尔·罗伯特·古兹曼; 诺尔曼·约尔丹; 肖恩·琼斯; 艾哈曼德·奥斯曼·哈立德
Original assignee: Amazon Technologies Inc
Current assignee: Amazon Technologies Inc
Priority date: 2015-04-30
Filing date: 2016-04-29
Publication date: 2022-03-22
Anticipated expiration: 2036-04-29
Also published as: CN108112268A; EP3289458A1; CA2984191A1; WO2016176650A1; CA2984191C

Abstract

A computing resource service provider may provide computing instances organized into logical groups, such as auto-expansion groups. The compute instances assigned to the auto-scaling group may be associated with one or more load balancers configured to direct traffic to the compute instances. Further, customers of the computing resource service provider may add or remove load balancers from the auto-scaling group.

Description

Managing load balancers associated with auto-extension groups

CROSS-REFERENCE TO RELATED APPLICATIONS

This application incorporates by reference FOR all purposes the entire disclosure OF co-pending U.S. patent application No. 14,701,518 entitled "BACKGROUND PROCESSES IN UPDATE LOLANCERS OF AN AUTO SCALING GROUP" (attorney docket No. 0097749 US0) filed 2016, on 30.4.2016, co-pending U.S. patent application No. 14/701,522 entitled "MANAGING STATE FOR UPDATES LOAD BALANCERS OF AN AUTO SCALING GROUP" (attorney docket No. 0097749-518US0) filed 2016, on 30.4.9, and co-pending U.S. patent application No. 14/701,513 entitled "MANAGING LOLANCERS ASSOCIATED WITH AUTO-LINSCALING GROUPS (attorney docket No. 0097749-491US 0)".

Background

The use of hosted computing services and storage has expanded rapidly in recent years. Resources for network computing and storage are typically provided by computing resource providers that utilize large networks of computers, servers, and storage drives to enable clients (including content providers, customers, etc.) to host and execute various applications and network services. The use of network computing allows content providers and customers alike to efficiently and adaptively meet their computing needs. However, as virtual resource usage continues to grow, customers are encountering situations where virtual resources cannot adapt to their needs under certain circumstances (e.g., unexpected traffic spikes or the need to respond immediately to meet increasing loads). In response, network resource service providers are introducing auto-extensions. In many cases, a guest transmits a request to create an instance, such as a virtual machine instance executing on a hardware device. In the above case, the instances may be automatically expanded, thereby enabling the service provider to adapt to customer needs. Once the customer has set up the auto-scaling activities, it may be difficult for the customer to easily modify the instances and/or load balancer.

Drawings

Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

FIG. 1 illustrates an environment in which a customer may provide a request to an auto-scaling service to interact with instances included in an auto-scaling group and a load balancer associated with the auto-scaling group, according to an embodiment;

FIG. 2 illustrates an environment for instantiating and provisioning an instance to a set of implementation resources for automatically extending a group and correlating the instance with a load balancer, according to an embodiment;

FIG. 3 illustrates an environment in which an instance for automatically extending a group may be associated with a load balancer operated by a load balancing service, according to an embodiment;

FIG. 4 illustrates an environment in which an instance service and an auto-scaling service may manage a load balancer for an auto-scaling group, according to an embodiment;

FIG. 5 is an illustrative process for assigning instances of an auto-extension group to a load balancer using a background process, according to an embodiment;

FIG. 6 is an illustrative process for returning load balancer information to a customer of a computing resource service provider based at least in part on an application program interface call, according to an embodiment;

FIG. 7 is an illustrative process for adding a load balancer to an auto-scaling group based at least in part on an application programming interface call, according to an embodiment;

FIG. 8 is an illustrative process for removing a load balancer to an auto-scaling group based at least in part on an application programming interface call, according to an embodiment;

FIG. 9 is an illustrative messaging diagram for an example of updating an auto-extension group using a background process and a load balancer, according to an embodiment; and is

FIG. 10 illustrates an environment in which various embodiments may be implemented.

Detailed Description

In the following description, various embodiments will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. It will be apparent, however, to one skilled in the art that the embodiments may be practiced without specific details. In addition, well-known features may be omitted or simplified in order not to obscure the described embodiments.

The techniques described and suggested herein relate to customer management of virtual compute instances or instances that are simply assigned to an auto-expansion group and a load balancer associated with the auto-expansion group. Customers of a computing resource service provider hosting a computer system managed by the customer may programmatically create an auto-scaling group through one or more application programming interface calls to meet resource demands under certain circumstances (e.g., unexpected traffic spikes or the need for immediate response to meet increased loads). An auto-scaling group may manage resources for one or more computer instances (e.g., virtual computer system instances) created by a customer. A load balancer may be provided to a customer of a computing resource service provider to facilitate request processing of one or more instances of an automatically expanding group of customers. For example, a customer may operate a website using an auto-scaling group of computing resources, and a load balancer may be configured to direct traffic among the auto-scaling group of computing resources (such as one or more computer instances). In addition, the website may receive requests from a plurality of other clients over the network. Subsequently, the computing resource service provider can configure the load balancer to direct requests to a particular instance of the auto-expansion group or the auto-expansion group of the executing web site such that the load generated by processing the requests is distributed among the computer instances executing the web site.

The auto-scaling service may automatically and dynamically manage auto-scaling groups to manage computing resources or any resource that may be subject to demand fluctuations. For example, the auto scaling service may use various factors to determine whether to automatically and dynamically adjust and/or allocate resources in response to an event (such as a load on a group that exceeds a threshold). Further, the customer may also need to adjust and/or allocate resources and/or manage the instances allocated to the auto-scaling group in response to the event. The customer may interact with the automated scaling service by communicating a request to the computing resource service provider. The request may include a command, an Application Programming Interface (API) call, a Remote Procedure Call (RPC), or other instructions configured to cause a service of a computing resource service provider to perform various functions.

The computing resource service provider may expose API calls to the customer to enable the customer to modify a load balancer associated with the auto-extension group while the auto-extension group is running. These API calls may eliminate customer requirements from having terminated and/or delete an auto-expansion group or load balancer in order to modify the association between the load balancer and the auto-expansion group. For example, a customer may submit an API request to an auto-extension service to add a load balancer to an auto-extension group. In various embodiments, adding a load balancer to the auto-scaling group causes the compute instances included in the auto-scaling group to be assigned to the load balancer, such that the load balancer distributes network traffic to the compute instances assigned to the load balancer. The auto-scaling service may include a database configured to maintain state information and/or other information about load balancers attached to the auto-scaling group. The database may be configured to track state information of load balancers associated with the auto-scaling group to avoid maintaining a one-to-one mapping of load balancers to instances.

The state information may include a variety of different states, such as an added state, an in-service state, and a removed state. The add state may indicate that the background process is allocating all instances in the group to the load balancer, and upon completion the background process updates the state to be added. The added state may indicate that all instances in the auto-expansion group have been assigned to a load balancer that was previously in the added state. The in-service state may indicate that the load balancer is directing traffic to at least one health instance of the auto-scaling group, as described in more detail below. The removal status may indicate that an instance of the auto-expansion group is currently being deallocated to a particular load balancer. For any new instances added to the auto-expansion group, the background process may determine whether the load balancer assigned to the auto-expansion group is in an added state, or an in-service state due to customer interactions or the configuration of the auto-expansion group. If the load balancer is in one of these states, the background process may register or assign a new instance to the load balancer.

FIG. 1 shows an illustrative example of an environment 100 in which a load balancer may be assigned to a particular auto-expansion group 102 to process requests 118 directed at computer instances of the auto-expansion group operated by a client 106. Computing resource service provider 104 may provide computing resources to customers 106. The customer 106 may perform a variety of functions using a physical host 142, described in more detail below, operated by the computing resource service provider 104. For example, the customer 106 may use the computing resources of the computing resource service provider 104 to operate a website or log server. In addition, the customer 106 may create an auto-expansion group managed by the computing resource service provider 104. Auto-expansion group 202, described in more detail below, may comprise a set of computer instances operated by customer 106. The auto-scaling group may be configured to add or remove computer instances and other computing resources to/from the auto-scaling group based at least in part on settings provided by the customer 106 and/or the computing resource service provider 104.

In some embodiments, customer 106 may include an organization that operates computing resources accessible to other customers or other entities of a typical computing resource service provider. For example, a customer may operate a website accessible to the user over a network (such as the Internet). The term "tissue" (unless the context clearly indicates otherwise) is intended to be understood in a broad sense to imply a group of subjects organized in some way. The customer 106 may use the computing resources of the computing resource service provider 104 to operate the load balancer 120 and the auto-scaling group 102 that are configured to distribute requests 118 to the computing resources (such as computer instances) of the customer 106. As shown in FIG. 1, the computing resources of a customer 106 may include a physical host 142 operated by a computing resource service provider 104 and/or implemented by the physical host 142. However, in various embodiments, the computing resources utilized by customers 106 include computing resources of customers or other entities according to the present disclosure. For example, a customer may use the computing resources of the computing resource service provider 104 to operate the load balancer 120 to direct traffic to one or more servers operated by the customer 106.

The request 118 may be received by the load balancer 120 or by one or more other systems of the computing resource service provider 104 (such as a request listener not shown in fig. 1 for simplicity) and directed to the load balancer 120. Load balancer 120 may be a computer system or virtual computer system configured to distribute requests 118 to one or more computer instances supported by physical hosts 142 in order to optimize resource utilization and/or avoid overloading of particular computer instances. For example, the load balancer 120 may include physical hardware connected to a server rack or otherwise included in a data center. In another example, the load balancer 120 may include one or more virtual machines supported by a particular physical host 142 operated by the computing resource service provider 104, as described in more detail below.

In some embodiments, the number of requests 118 may be greater than the number of requests that the load balancer 120 may handle, taking into account the number of computing resources currently allocated to the load balancer 120. Thus, customer 106 may determine to add an additional load balancer 122 to the auto-expansion group. Clients 106 may communicate requests, such as API calls, configured to cause computing resource service provider 104 or components thereof (e.g., auto-scaling services described in more detail below) to associate additional load balancers 122 with auto-scaling group 102. As described herein, associating the load balancer 120 with the auto-expansion group 102 includes assigning computer instances included in the auto-expansion group 202 to the load balancer 120, such that the load balancer directs requests and/or other network traffic to the computer instances of the auto-expansion group, as described in more detail below.

The customer 106 may be able to update (e.g., add or remove) a set of load balancers associated with the automated expansion group 102 regardless of whether the computing resource service provider 104 or a component thereof is currently updating the set of load balancers associated with the automated expansion group 102. For example, a particular customer may accidentally transmit a request to add and/or remove a load balancer 120 from the auto-scaling group 102, and then at some later point in time, the customer may transmit a second request to reverse the unexpected request while the computing resource service provider 104 is processing the unexpected add and/or remove request. Due to the second request, the computing resource service provider 104 may terminate processing the unexpected request and begin processing the second request. Further, the computing resource service provider 104 may generate audit information corresponding to operations performed in adding and removing load balancers to the auto-scaling group. The audit information may enable the customer 106 to determine the results of previous add or remove operations and the progress or status of existing load balancers.

As described above, the computing resource service provider 104, or a component thereof (such as an auto-extension service described in more detail below), may execute a background process configured to allocate and de-allocate computer instances of the auto-extension group 102 to the load balancer 120 and the additional load balancer 122. Further, the background process may be configured to cause client 106 to modify the capacity of autoexpansion group 102 (e.g., cause a computer instance to start or terminate within autoexpansion group 102) regardless of the current state of the background process. For example, a background process may assign a set of computer instances of auto-scaling group 102 to load balancer 120; the client may then cause a new set of computer instances to be added to the auto-scaling group 102, and thus, the background process may add the new set of computer instances to the set of computer instances to be assigned to the load balancer 120.

The background process may query a load balancer database maintained by the auto-extension service, described in more detail below in conjunction with fig. 2, to determine whether any load balancers associated with the auto-extension group 102 are in a transitional state (e.g., an added state, and/or a removed state). If at least one load balancer is present in the transitional state, the background process may determine a set of computer instances and corresponding operations based at least in part on the state of the at least one load balancer. For example, if the load balancer is in the add state, the background process may determine a collection of computer instances to allocate to the load balancer. The background process may assign the computer instance to the load balancer by passing the API call to a load balancer service that indicates the load balancer 120 and the computer instance to be assigned to the load balancer 120. In various embodiments, the background process may communicate the request directly to the load balancer 120, requesting the load balancer 120 to manage traffic directed to the computer instance.

In some embodiments, adding additional load balancers 122 may include instantiating one or more load balancers and assigning the instantiated load balancers to auto-scaling groups 102. In addition, assigning additional load balancers 122 can include updating one or more other computer systems. For example, the request listener may be updated with information corresponding to the additional load balancer 122 to route requests. In another example, a Domain Name System (DNS) entry or other naming system service entry can be updated to include an Internet Protocol (IP) address associated with the additional resource 122.

The customer 106 may modify the capacity of the auto-scaling group 102 and/or the load balancer 120 assigned to the group by submitting API calls to an interface of the computing resource service provider 104 (not shown in FIG. 1 for simplicity). For example, customer 106 may assign additional computer instances to automated expansion group 102 through an administration console or other application configured to enable the customer to manage computing resources provided by computing resource service provider 104. The management console may be exposed to the customer 106 as a web page, where the executable code of the web page is configured to generate API calls to the computing resource service provider 104. The client 106 may provide information corresponding to the auto-expansion group 102, the computer instances of the auto-expansion group 102, and the load balancers assigned to the auto-expansion group 102 through the management console. For example, a customer may provide an API call to the computing resource service provider 104, and the API call may indicate a first number of load balancers to be added to the auto-expansion group and a second number of load balancers to be removed from the auto-expansion group 102. The information may include an IP address of a computer instance associated with the auto-scaling group 102, an identifier of the auto-scaling group, computing resources allocated to the computer instance and/or the auto-scaling group 102, computing power and network capacity of the computer instance and/or the auto-scaling group 102, routing information, an identifier of a load balancer, and any other information configured to enable the auto-scaling service to add and/or remove load balancers from the auto-scaling group.

FIG. 2 illustrates an environment for instantiating an instance 222 and provisioning the instance 222 to a set of implementation resources for automatically extending a group 202 and correlating the instance with a load balancer, according to an embodiment. As shown in FIG. 2, the computing resource service provider 204 operates a plurality of physical hosts 242. The physical host 242 may be any device or apparatus, such as a computer or server, configured to execute instructions for performing data computing, operations, or storage tasks. The physical host 242 may comprise any of the computer systems or virtual computer instances described above. The virtualization layer 244 operated by the computing resource service provider 204 enables the physical host 242 to be used to provide computing resources on which one or more instances 222 may operate. As described in more detail below, the virtualization layer 244 can be any means, software, or firmware for providing a virtual computing platform for the instance 222. The virtual computing platform may include various virtual computer components, such as one or more virtual CPUs, virtual memory, virtual disks, and so forth.

Auto-expansion group 202 may contain one or more instances 222 and may provision new instances 224 based at least in part on a variety of attributes. The various attributes may include a desired capacity as indicated by the customer, an overall load on the auto-scaling group 202, a load on a particular instance of the auto-scaling group 202, a request from the customer, a schedule, and any other attributes suitable for determining whether to add or delete an instance from the auto-scaling group 202. The instance 222 may be a virtual computer system configured to provide computing resources to customers of the auto-scaling group 202 and the computing resource service provider 204 by performing at least various operations. In some embodiments, the auto-scaling group 202 and instances operate as a single computing entity that performs various operations for the customer.

The load balancing service 236, described in more detail below in conjunction with FIG. 3, may provide load balancers and other traffic distribution services to the auto-scaling group 202. For example, the DNS entries for the load balancer may include IP addresses for the various load instances 222 of the auto-expansion group 202, and requests directed to the auto-expansion group 202 may be distributed to the instances 222 assigned to the load balancer. During an expansion event that requires the allocation of computing resources to the auto-expansion group 202, the computer instance image may be used to instantiate a new instance 224. Operations of one or more of the instances 222 may be terminated or suspended when computing resources are deallocated to the auto-expansion group 202. The auto-extension service, described in more detail below in connection with FIG. 3, may determine whether an instance 222 is to be added or removed from the auto-extension group 202.

As described above, the auto-scaling service 230 may also include a background process 232, and the background process may allocate or deallocate instances 222 to one or more load balancers. The background process 232 may include logic or other computer-executable code that, when executed by one or more processors of the physical host 242, causes the physical host 242 to perform various operations corresponding to adding and removing load balancers from the auto expansion group 202. In various embodiments, the auto-scaling service 230 or the load balancing service 236, when deallocating an instance 222 from one or more load balancers, will wait until all network connections to the instance 222 to be deallocated are terminated or completed. Once there are no more connections to the instances 222 to be deallocated, the load balancing service may remove the instances 222 from the set of examples to which the one or more load balancers direct traffic. This process may be referred to as connection exclusion, e.g., waiting until all current connections to a particular instance have terminated while preventing a new connection to the instance from being established.

Further, when computing resources are allocated or deallocated to the auto-expansion group 202, the background process 232 of the auto-expansion service 230 may communicate information corresponding to the allocation or deallocation of computing resources to the load-balancing service 236 to enable the load-balancing service to properly direct traffic to the auto-expansion group 202. For example, if a new instance 224 is added to the group, the background process may transmit an API call including an identifier of the new instance 224 configured to cause the load balancing service to assign the new instance 224 to one or more load balancers associated with the auto-scaling group 202. Further, the background process may update load balancer database 210 with information corresponding to instance 222, new instance 224, and one or more load balancers assigned to the auto-expansion group.

The load balancer database 210 may contain a set of rows and columns, where each row corresponds to a load balancer associated with the auto-expansion group 202, and each column contains information corresponding to the auto-expansion group 202, the instance 222, or other information suitable for adding or removing load balancers from the auto-expansion group 202. Load balancer database 210 may include information suitable for tracking the status of a particular load balancer. Further, the information included in the load balancer database 210 may be adapted by the background process 232 to determine operations to perform in order to add or remove load balancers from the auto-scaling group 202. For example, the background process 232 may query a database to determine one or more load balancers associated with the new instance 224. Further, as described herein, load balancer database 210 may include any database or any other data store configured to store information corresponding to one or more load balancers associated with autoexpansion group 202 (including state information associated with the one or more load balancers).

Load balancer database 210 may be any data store and/or storage device described herein. Further, data regarding the operation of the auto-extension group 202, the instance 222, the background process 232, and the new instance 224 may be collected and/or monitored by the auto-extension service 230 and stored in the load balancer database 210 or other data store to generate audit log information and metric information. The data regarding the operations of the auto-extension group 202, the instance 222, the background process 232, and the new instance 224 includes any information regarding the actions performed by the auto-extension group 202, the instance 222, the background process 232, and the new instance 224, such as pre-formed metric data (e.g., memory usage of the virtual host, file system, information regarding the virtual CPU, or any other information regarding the auto-extension group 220 or components thereof) or actions. In some embodiments, the data may be converted into a format suitable for use with an audit log or audit service. In various embodiments, the data is stored continuously using the on-demand storage service of the computing resource service provider 204 so that the customer can use the data to determine the operation of the background process 232 and the status of the load balancer associated with the auto-scaling group 202.

In some embodiments, when a particular customer submits an API call configured to update (e.g., add or remove) one or more load balancers associated with the auto-extension group 202, the auto-extension service 230 may perform several operations in order to process the API call. First, the auto-scaling service 230 may update a record in the load balancer database relating to one or more load balancers indicated in the API call for the auto-scaling group 202. This may ensure that any other instances (such as new instance 224) launched in the auto-expansion group 202 will be assigned to one or more load balancers. The update to the load balancer database 210 may occur in synchronization with receiving the request. Subsequently, the auto-scaling service 203 may queue an asynchronous process (e.g., a background process 232) that may determine a set of existing instances 222 and update the load balancer associated with the set of existing instances 222 to the client-directed load balancer or loadbalancers in the API call. The background process 232 may be non-deterministic, such that the same input (e.g., adding or removing the same set of load balancers) may not cause the background process 232 to operate in the same manner. For example, the order of operations may be different, the batch size to be allocated to the instances of the load balancer 222 may be different, and any other operations of the background process described herein may be different.

The background process 232 may also create a record in the extended history of a particular client (which may be retrieved using the DesscriptionActivities API). Records and/or APIs may be used to track the process of updating one or more load balancers associated with auto-extension group 202 and used for auditing purposes as desired by a user. The record and any corresponding audit information may include human-readable representations of operations performed by auto-scaling service 230, such as "update the load balancer for auto-scaling group A in response to a request by client 110581 to: (loadbalancer1, loadbalancer2, loadbalancer3) "was added. The record may also include a start time, an end time, and a completion status once the auto-scaling service has completed processing the request. As described above, the operation of the background process 232 will not lock or otherwise prevent updates to the auto-expansion group 202, nor will the background process 232 prevent other updates to the one or more load balancers associated with the auto-expansion group 202 from being processed at the same time. For example, if a particular client updates one or more load balancers associated with the auto-expansion group 202 while another update is being processed, the auto-expansion service 230 may terminate the previous update, restart the process, and generate another record in the client's auto-expansion history.

An environment such as that shown in fig. 1 may be useful to a provider, such as a computing resource provider, where a computing resource system manages load balancers assigned to an auto-scaling group in response to requests from customers. As discussed above, the computing resource system provides a mechanism to allow a customer to add or remove load balancers from a set of instances associated with an auto-scaling group. The environment in this case may include additional components and/or other arrangements, such as those shown in the networked environment 300 of FIG. 3. In this example, the network environment 300 includes a computing resource service provider 304 in data communication with a client device 306 and a server computer 342 over a network 306. In one embodiment, server computer 342 may be one or more computer hardware devices for implementing instance 320. For example, the server computer 342 may include hardware for implementing various types of computing resources, such as storage, virtualized storage, network devices, and the like, as described above in connection with FIG. 2. Furthermore, the implemented computing resources may be managed programmatically and remotely by customers of the distributed computing resource provider.

The server computer 342 includes a plurality of computer system devices, each capable of executing one or more instances 320 created by the distributed computing resource service provider 304. In one embodiment, each of server computers 342 includes a processor, a data store, an input/output bus, and/or any other component known in the art for executing instances 320. Additionally, instance 320 can be a virtual machine instance. As is known in the art, a virtual machine instance is an instance of a software implementation on a machine (i.e., a computer) that executes programs similar to a physical machine. For example, each of server computers 342 may be configured to execute instance manager 318, which can implement instance 320. For example, instance manager 318 may be a hypervisor, a virtualization layer, or another type of program configured to implement execution of multiple instances 320 on a single server computer 342. As discussed above, each of the instances 320 may be configured to execute all or a portion of an application. Additionally, the network 306 may be similar to the networks described above. Networking environment 300 may span one or more data centers, where each data center may be geographically distinct from one another. Additionally, the networked environment 300 shown in FIG. 3 may be one of several embodiments employed by a computing resource service provider.

In one embodiment, the computing resource service provider 304 includes a load balancer database 310, an instance service 312, a placement service 326, an auto-scaling service 330, a maintenance service 332, a metrics service 334, a load balancing service 336, and/or other components. The load balancer database 310 may include load balancer data 342. For example, as described above, load balancer database 310 includes one or more records of load balancer 340 associated with auto-expansion group 302. Each of the records of load balancer data 346 corresponds to a load balancer 340 of the networked environment 300.

Instance service 312 instantiates instance 320 based at least in part on a set of preferences provided by the customer. In one embodiment, instance service 312 receives a request 336 from a customer on client device 306 to create one or more instances 332, and optionally assigns created instances 320 to auto-scaling group 302. Further, the request 336 received from the client on client device 306 may also indicate a time to begin executing the requested instance 320. In response to receiving the request, instance service 312 instantiates instance 320. In various embodiments, the auto-scaling service 330 receives the request and transmits a command to the instance service 312 to instantiate the instance 320 to cause the instance to be associated with the auto-scaling group, for example, by associating the auto-scaling group 302 metadata with the instance 320. In one embodiment, the instance service 312 may place the instance in a standby state or separate the instance from the auto-scaling group in response to a request from the client device 306 and/or the auto-scaling service 330. For example, the auto-extension service 330 may communicate a request to the instance service 312 to remove auto-extension group 302 metadata associated with the instance 320 detached from the auto-extension group 302 based on the request 336. Further, the auto-scaling service 330 may de-allocate the separate instances from the load balancer 340.

The customer may interact with the computing resource service provider 304 (via appropriately configured and authenticated API calls) to provision, manipulate, and manage instances 320 associated with the auto-scaling group 302 instantiated on the server computer 342 and operated by the computing resource service provider 304. In addition, a customer may create one or more auto-extension groups 302, and auto-extension groups 302 may be a logical collection of instances 320. Further, instance 320 may be assigned to auto-expansion group 302 or may be a member of auto-expansion group 302. Autoextension service 330 may allow customers to interact with and manage various auto-extension groups 302. For example, a customer may set a maximum or minimum capacity for the auto-expansion group 302 via the auto-expansion service 330. Subsequently, auto-expansion group 302 may manage the instances 320 assigned to the auto-expansion group in order to maintain the settings provided by the customer. In various embodiments, a customer may create and manage an auto-scaling group 302 through a management console provided by a computing resource service provider 304 as described above.

The management console may be exposed to the customer as a web page; by interacting with the web page (e.g., through a browser application), the client may cause an API call to be generated. The generated API calls may cause the computing resource service provider 304, or a component thereof, to perform various operations directed by the customer. Once the customer has created auto-expansion group 302, the customer may assign one or more load balancers to auto-expansion group 302 by submitting request 336. In this case, the request 336 may be processed by the auto-scaling service 330 or other component of the computing resource service provider 304. The instances 320 of the auto-expanding group 302 may be used for various purposes, such as operating as a server supporting a website, operating a business application, or computing power that generally acts as a client. Other applications for instance 320 may be supporting database applications, e-commerce applications, business applications, and/or other applications. Additionally, a load balancer 340 may distribute traffic to the various instances 320 of the auto-scaling group 302 to enable operation of the instances for the various purposes described above and to prevent overloading of the instances 320 of the auto-scaling group 302. Although the instance service 312 is shown in FIG. 3, the computing resource service provider 302 may utilize any other computer system or computer system service, such as a computer system or computer system service that does not employ virtualization or instantiation and instead provisions dedicated or shared computing resources on computers/servers and/or other physical devices.

The layout service 326 provisions the instances 320 to one or more of the server computers 342. In one embodiment, the layout service 326 determines the server computer 342 to provision the new instance 320 based at least in part on the indicated automatically expanded set 302 of new instances 320. For example, the layout service 326 may identify one or more server computers 342 with appropriate capabilities to execute the instance 320. To this end, as will be described, the layout service 326 determines the capacity of each server computer 342 from the resource data 310 stored in the data store, and thus provisions the instances 230. The auto-scaling service 330 automatically scales the capacity of the previously requested set of instances 320 up or down based at least in part on the environment defined by the customer requesting the instance 320. For example, the auto scaling service 330 may reduce the number of instances 320 allocated to a customer during demand breaks and increase the number of instances 320 allocated to a customer during demand peaks.

In one embodiment, the autonomic extension services 330 remove a subset of the requested instances 320 for a period of low usage and/or idle time. For example, the autonomic extension services 330 may determine that the number of instances 320 requested by the customer is redundant and/or excessive. In response, the auto scaling service 330 may terminate a number of instances 320 assigned to the customer such that the remaining number of instances 320 assigned to the customer is not redundant and/or excessive. In another embodiment, the auto-scaling service 330 may remove a subset of the requested instances 330 if the usage does not exceed a predetermined threshold. Similarly, the auto-scaling service 330 increases the number of instances 320 over a period of high usage time. In one embodiment, the auto scaling service 330 may increase the number of instances 320 if the usage exceeds a predetermined threshold.

Request 326 received from client device 306 may include an API call to update or modify load balancer 340 associated with auto-extension group 302 as described above. The API call included in the request may be received at an interface of the computing resource service provider 304. Additionally, the API calls and/or requests may be authenticated by the computing resource service provider 304. The interface may direct the API call to the appropriate service for processing the request. For example, an API call to add a load balancer to auto-extension group 302 may be directed to auto-extension service 330, which is capable of handling request 326. Subsequently, the auto-scaling service 330 may store information corresponding to the load balancer 340 included in the request 326 to the load balancer database 310 in synchronization with receiving the request 326.

The background process, described in more detail above in connection with fig. 2, may periodically or aperiodically query the load balancer database 310 to determine whether any load balancers 340 are in a transitional state and create a workflow that executes in the background that is configured to update at least a portion of the instances 322 of the auto-scaling group 302 by at least adding and/or removing load balancers 340 to the instances 322. In various embodiments, the auto-extension service 330 may be configured such that only one background process may be executed for each auto-extension group 302. For example, if a client attempts to update a load balancer associated with an auto-scaling group while another update is being processed via the client device 306, an existing background process may be signaled that the background process should recalculate the operations needed to update the load balancer 340 and restart the process.

The background process may generate a dynamically configurable batch size for both the load balancer 340 and the instance 322 to perform the operation. For example, the background process may determine an entire set of load balancers 340 associated with the auto-extension set 302 and an entire set of instances 322 included in the auto-extension set 302. Subsequently, the background process may perform the operations needed to update load balancer 340 in batches (e.g., add and/or remove load balancer 340 to/from instances 322 in auto-scaling group 302). The background process may prioritize the batches based on a number of different factors. For example, the background process may perform all add operations before performing any remove operations. In another example, the background process may complete operations for a single load balancer before performing operations on any other load balancer indicated in request 326. The background process may communicate with one or more other services to complete the update load balancer operation included in request 326. For example, the background process may generate an API request configured to cause the load balancing service 336 to perform an operation included in a particular batch (e.g., add and/or remove load balancer 340 to/from an instance 322 in the auto-scaling group 302).

The maintenance service 332 schedules maintenance, software updates, and/or firmware updates for the server computer 342. In one embodiment, the maintenance service 332 schedules maintenance and software updates at appropriate times based at least in part on the available capacity of the server computer 342. For example, the maintenance service 332 may schedule maintenance and software updates when the corresponding server computer 342 has projected availability. In one embodiment, when maintenance service 332 determines that server computer 342 is not hosting any instances 320, maintenance service 332 may patch and restart server computer 342. Additionally, the maintenance service 332 can fix up the virtual machine associated with the instance 342 before instantiating a new image associated with the corresponding virtual machine, if necessary. For example, the maintenance service 332 can schedule the patching of the machine images based at least in part on the health status of the instances 320. In one embodiment, additional instances cannot be provisioned on the server computer 342 until the scheduled maintenance is complete.

Maintenance service 332 may also periodically or aperiodically check the health of instances 320 (including the instances assigned to autoexpansion group 302 and/or load balancer 340). The health check may include determining the load, utilization, and operation of various components of the instance 320, such as a central processing unit, memory, networking interfaces, operating systems, applications, and other components of the instance 320. In various embodiments, when maintenance service 332 determines that instance 320 is unhealthy based at least in part on the health check, maintenance service 332 or other components of service provider 304 (such as auto-scaling service 230) may initiate a workflow to remove the unhealthy instance from auto-scaling group 302. Further, if the maintenance service 332 determines that the previously unhealthy instance 320 has returned to a healthy state, the maintenance service 332 or other components of the service provider 304 (such as the auto-scaling service 230) may cause the instance 320 to move into service or cause the instance 320 to be attached to the auto-scaling group 302. Further, as described above, if the instance 322 assigned to the load balancer 340 returns to a healthy state, the auto scaling group 302 may update the state of the load balancer 340 to be in-service. In various embodiments, the health check may be performed by a second background process that is different from the background process described above in connection with fig. 2.

The metrics service 334 may be responsible for collecting resource data corresponding to the instances 320. The resource data obtained by the metrics service 334 can indicate the usage of various components of the instance 320, such as a central processing unit, memory, networking interfaces, operating systems, applications, and other components of the instance 320. This information may be used for a variety of different purposes, such as determining whether to allocate or deallocate resources to auto-expansion group 302. Additionally, the information may be used by the maintenance service 332 to determine the health of the instance 320 and/or the server computer 342. The metrics service 334 may obtain and aggregate utilization information for all instances 320 assigned to the auto-scaling group 302. Further, when adding or removing load balancers 340 from the auto-scaling group 320, the metrics service 334 can receive commands to add or remove load balancers 340 from a group of load balancers 340 for which the metrics service 332 collects and/or aggregates utilization information.

The load balancer service 336 may be provided to customers of the computing resource service provider 304 to facilitate request processing by the customer's instance 320. In various embodiments, instance 320 may be assigned to auto-expansion group 302 and load balancer service 336 may distribute traffic to instances 322 assigned to auto-expansion group 302. For example, a customer may use the resources of the computing resource service provider 304 to operate a website that uses the instances 320 assigned to the auto-scaling group 302. In addition, the website may receive requests from a plurality of other clients via the network 206. The computing resource service provider 304 may configure a load balancer of the load balancer service 336 to direct requests to the instances 320 of the auto-scaling group 302 of executing websites such that the load generated by processing the requests is distributed among the instances 320 of the auto-scaling group 302 of executing websites. The load balancer service 336 may be a computer system or virtual computer system configured to distribute requests to instances 320 assigned to load balancers in order to optimize resource utilization and/or avoid overloading of particular server computers 342. For example, a load balancer may include physical hardware connected to a server rack or otherwise included in a data center. In another example, the load balancer may include one or more virtual machines supported by the server computer 342.

FIG. 4 illustrates an example service 412 in accordance with at least one embodiment. An instance service 412, which may be implemented by physical hardware, is used by service provider 404 to provide computing resources for customers 406. The physical hardware may include a server computer 442. The server computer 442 may be any device or apparatus, such as a computer or server, that is configured to execute instructions for performing data computation, operations, or storage tasks. The server computer 442 may be equipped with any required processing capability, including one or more processors, such as a Central Processing Unit (CPU), a Graphics Processing Unit (GPU) or a Digital Signal Processor (DSP), memory (including static and dynamic memory), buses, and input and output ports conforming to any handshaking signal, communication, or data transfer protocol. The physical hardware may also include storage devices such as storage disks and tapes, network devices, and the like.

Virtualization layer 444 may include bare metal hypervisors or managed hypervisors. The virtualization layer 444 executing on the service computer 442 enables the physical hardware to be used to provide computing resources on which one or more computer instances 420 may operate. For example, the virtualization layer may enable the virtual machine 420 to access physical hardware on the server computer 442 through a virtual device driver on the virtual machine 420. The virtualization layer 444 may include a hypervisor or virtualization software and/or hardware. The virtualization layer may also include an instance of an operating system dedicated to managing computer instances 420 running on server computers 442. Each virtualization layer 444 may include its own networking software stack, responsible for communication with other virtualization layers 444, and at least in some embodiments, also responsible for enabling network connectivity between computer instances 420 running on server computers 442 and other computer instances 420 running on other server computers 442. Further, the server computers 442 may host multiple virtualization layers 444 of the same or different types on the same server computer 442. Virtualization layer 444 may be any means, software, or firmware for providing a virtual computing platform for computer instance 420. The virtual computing platform may include various virtual computer components, such as one or more virtual CPUs, virtual memory, and the like. Computer instance 420 may be provided to customer 406 of service provider 404, and customer 406 may run an operating system or application on computer instance 420. Further, service provider 404 may execute its applications using one or more of its own computer instances 420. At least a portion of computer instance 420 may execute kernel-level components for one or more other computer instances 420. For example, a particular computer instance may execute a parent partition configured to manage one or more child partitions executed by other computer instances, where the particular computer instance and the other computer instances are supported by the same virtualization layer 444.

Commands and other information may be included in API calls from the virtual machine management service 412 or the auto-scaling service 430 to the virtualization layer 444. Virtual machine management service 412 can enable clients 406 to manage and operate computer instances 420. For example, the guest 406 may communicate a request to the virtual machine management service 412 to terminate all computer instances 420 operated by the guest 406. The request may be an API call that includes information corresponding to client 406 and computer instance 420. The virtual machine management service 412 can determine a corresponding virtualization layer 444 for the computer instance 420 included in the request and communicate a termination command to the virtualization layer 444. Virtual machine management service 412 can be implemented in at least some embodiments to enable various client applications to run on virtual computer servers or computer instances 420 instantiated on behalf of clients 406. Computer instances 420 may each comprise a virtual machine, with its own operating system comprising a networking software stack, and a plurality of such instances may be hosted on a given server computer 442 at a service provider network data center.

Additionally, the load balancing service 436 described in more detail above in connection with fig. 3. Commands and other information included in the API call may be passed to the instance service 412. The instance service can determine the appropriate virtualization layer and cause instance 420 to operate according to the API call. For example, as described above, the load balancer service 436 may communicate API calls to the particular instance 420 implementing the load balancer, and the API calls may be configured to cause the load balancer to manage and direct traffic to a set of instances of the auto-scaling group. In various embodiments, the load balancing service 436 and the auto-scaling service may communicate the commands directly to the virtualization layer 444.

Fig. 5 shows an illustrative process 500 that may be used to assign instances of auto-extension groups to a load balancer using a background process, according to an embodiment. Process 500 may be performed by any suitable system, such as the auto-scaling service described above in connection with fig. 2 and 3, or any combination of systems or components thereof, such as the background processes described above. Returning to fig. 5, in an embodiment, process 500 includes receiving a request 502 to initiate an asynchronous workflow. An asynchronous workflow may be a set of operations or tasks to be performed by a service provider's computer system, such as an automated extension service, in which the sequence or order of operations does not require a previous operation to be completed before starting the next operation. For example, as described above, the auto-scaling service may receive a request to add a load balancer to an auto-scaling group that requires an asynchronous workflow in order to process the request. The auto-scaling service may then execute the background process 504. In a number of variations of process 500, the auto-scaling service may cause the background process to restart if the background process is currently executing, or may cause the background process to restart at a particular point in process 500.

The background process may then determine a set of load balancers in a transitional state 506. For example, the background process may query the load balancer database for the load balancer in an added state, or a removed state as described above. The background process may then determine a set of computer system instances associated with the load balancer in the transitional state. This may include all instances of the auto-expansion group, or only instances that are still to be allocated or deallocated to a particular load balancer of the load balancer group in the transitional state. The background process may then determine the order of operation and the batch size for the instance to be updated and the load balancer in the transitional state.

The determination may be based on a variety of factors, including multiple instances, multiple load balancers, an amount of load to load balance services, or other factors suitable for determining a batch size for updating the instances and load balancers. Further, the background process may query the load balancing service to determine an appropriate batch size (e.g., where instances are to be allocated or deallocated to the load balancer) based at least in part on the load of the load balancing service and/or the number or type of operations to be performed on the load balancer. In various embodiments, if the background process receives an error from the load balancing service, for example, if the load balancing service is unable to process the request, the background process may reduce the batch size and/or delay of transferring the batch-related API calls within a time interval.

The background process may then perform operation 512 associated with the determined lot. For example, the background process may communicate the API call to a load balancing service configured to assign 10 instances of the auto-scaling group to a particular load balancer indicated in the API call. Subsequently, the auto-scaling service and/or the background process may generate audit log information 514. As described above, the audit log information may enable a customer to obtain information corresponding to load balancers associated with an auto-scaling group and operations performed when load balancers are added and/or removed (e.g., results of performing determined batch operations). The auto-scaling service may generate at least a portion of the audit log information after enqueuing the asynchronous workflow, and may generate additional audit log information after completing the asynchronous workflow. For example, the automated extension service generates audit log information, including the operations performed according to the request and the start time. After the asynchronous workflow is completed, the auto-scaling service may generate audit log information, including the time the operation was completed and whether the operation was successful.

If additional requests are received 516, the background process may restart the process and determine the load balancer in the transitional state. If additional requests are not received 516, the background process may continue to perform operations related to the determined lot until all operations are completed. Once all operations are completed, the background process may update the load balancer database 518 with information related to the load balancer in the transitional state. For example, as described above, once all instances have been added to a particular load balancer, the background process may update the state information contained in the load balancer database to be added.

Fig. 6 is a block diagram illustrating an example of a process 600 for enabling a customer to obtain information corresponding to one or more load balancers associated with an automatically extended group of customers, in accordance with various embodiments. Process 600 may be performed by any suitable system, such as a server in a data center, a plurality of computing devices in a distributed system of computing resource service providers, or any service operated by a computing resource service provider, such as the auto-scaling service described above in connection with fig. 2 and 3. Process 600 includes a series of operations in which a DescriptloadBalancers application programming interface call is received from a requestor, the requestor is authenticated, and then if authenticated, the load balancer database is queried for the requested information and provided to the requestor. In some embodiments, the information obtained from the load balancer database may be formatted or otherwise modified for the requestor.

At 602, a computing resource service provider receives an application programming interface call from a client or other entity to describe a load balancer associated with an auto-scaling group. As described above, an automated expansion group or other component of a computing resource service provider may maintain a load balancer database. The load balancer database may contain information corresponding to load balancers associated with an auto-extension group, such as identification information of the load balancer, the particular auto-extension group associated with the load balancer, the status of the load balancer, the start time or end time at which the load balancer was assigned a particular status, and any other information suitable for describing the load balancer to a customer. Further, the request may indicate a subset of a set of load balancers associated with the automatically expanded set to which the client request information corresponds. For example, the customer may instruct a particular load balancer to obtain information for all load balancers that have been added or removed from the auto-scaling group, such as within the last 24 hour interval, or the customer may instruct one or more attributes of the load balancers to obtain the information.

At 604, the computing resource service provider determines whether the requestor has sufficient rights to have the request fulfilled. For example, the requestor may have provided proof of identity and possession credentials as parameters to have a DescriptloadBalancers application programming interface call. For example, the requestor may supply information sufficient to prove access to the credential as proof of possession of the credential corresponding to the identity, such as a password, an encrypted hash/digest of a password, an encrypted digital signature generated by a signed encryption key, or other key that may be verified by the computing resource service provider to authorize the requestor's identity. The computing resource service provider may provide the identity and proof to an authentication service, which may then verify the identity of the requestor and proof of the credentials. Once the identity of the requestor is verified, the computing resource service provider or authentication service may determine whether the security policy and/or role associated with the identity grants sufficient rights to allow the request to be fulfilled.

If the computing resource service provider is unable to determine identity (e.g., is not present in a secure database), then proof of credentials is insufficient to prove identity (e.g., a wrong password), or the identity of the requestor cannot be otherwise confirmed, the system performing process 600 may not proceed further in process 600. The system performing process 600 may respond to the authentication failure with an error message to the requestor and/or register the authentication failure in a security log 610. Otherwise, if the requestor is authenticated and determined to have sufficient rights to have the DescriptloadBalancers request fulfilled, the system performing process 600 may proceed to 606.

Once the computing resource service provider determines that the requestor has sufficient authority to fulfill the request, the computing resource service provider or a component thereof (such as an auto-scaling service) may query the load balancer database 606 for the requested information. The load balancer database may be maintained in a data storage service or database service of a computing resource service provider. In response to the query, the auto-scaling service may obtain the information indicated in the request. For example, the auto-scaling service may obtain a list of load balancers associated with the auto-scaling group and the status of the load balancers included in the list. The auto-scaling service may then provide a list of load balancers to the requestor in response to the request 608.

Fig. 7 is a block diagram illustrating an example of a process 700 for adding a load balancer to an auto-scaling group, in accordance with various embodiments. Process 700 may be performed by any suitable system, such as a server in a data center, a plurality of computing devices in a distributed system of computing resource service providers, or any service of a computing resource service provider, such as the auto-scaling service described above in connection with fig. 2 and 3. Process 700 includes a series of operations in which an AddLoadBalancer application programming interface call is received from a requestor, the requestor is authenticated, and then if authenticated, the load balancer database is updated with load balancer information and the load balancer is added to an auto-scaling group.

At 702, a computing resource service provider receives an application programming interface call from a client or other entity to add one or more load balancers to an auto-scaling group. Adding one or more load balancers to the auto-scaling group may cause the one or more load balancers to manage and direct network traffic to a set of instances contained in the auto-scaling group. Further, adding one or more load balancers to the auto-scaling group may include operations performed by various other services of the computing resource service provider. For example, a client may cause a load balancer to be created by submitting a request to a load balancing service as described in more detail above. In addition, the auto-extension service or components thereof (such as a background process) may add one or more load balancers to the auto-extension group by submitting batches of API calls to the load balancing service. For example, the background process may determine a batch of 10 instances to be assigned to a particular load balancer, generate an API call configured to cause the load balancing service to assign 10 instances to the particular load balancer, and provide the API call to the load balancing service.

At 704, the computing resource service provider determines whether the requestor has sufficient rights to have the request fulfilled. For example, the requestor may have provided proof of identity and possession credentials as parameters with an AddLoadBalancer application Programming interface call. For example, the requestor may supply information sufficient to prove access to the credential as proof of possession of the credential corresponding to the identity, such as a password, an encrypted hash/digest of a password, an encrypted digital signature generated by a signed encryption key, or other key that may be verified by the computing resource service provider to authorize the requestor's identity. The computing resource service provider may provide the identity and proof to an authentication service, which may then verify the identity of the requestor and proof of the credentials. Once the identity of the requestor is verified, the computing resource service provider or authentication service may determine whether the security policy and/or role associated with the identity grants sufficient rights to allow the request to be completed.

If the computing resource service provider is unable to determine identity (e.g., is not present in a secure database), then proof of credentials is insufficient to prove identity (e.g., a wrong password), or the identity of the requestor cannot be otherwise confirmed, the system performing process 700 may not proceed further in process 700. The system performing process 700 may respond to the authentication failure with an error message to the requestor and/or register the authentication failure in a security log 712. Otherwise, if the requestor is authenticated and determined to have sufficient permissions for the AddLoadBalancer request to be completed, the system performing process 700 may proceed to 706.

In 706, the system performing process 700 may update the load balancer database with information corresponding to the load balancer indicated in the request. For example, the request may include an identifier of the load balancer to be added, a customer associated with the load balancer, a computing resource service provider or service associated with its load balancer, or other information suitable for enabling the auto-scaling service to add the load balancer to the auto-scaling group. For example, updating the load balancer database may include generating a row in the database containing an identifier of the load balancer and a status of the load balancer. The status may be determined by the auto-scaling service. For example, if a load balancer has not been previously added to an auto-expansion group, the auto-expansion service may assign an addition status to a row corresponding to the load balancer in the load balancer database.

Subsequently, an auto-scaling service or other system executing process 700 may queue 708 the asynchronous workflow. The asynchronous workflow may be a process, such as process 500 described above in connection with FIG. 5, configured to assign instances of the auto-scaling group to the load balancer indicated in the request. The asynchronous workflow may be completed by the background process described above. The auto-scaling service may then generate audit log information 710. As described above, audit log information may enable a customer to obtain information corresponding to load balancers associated with an auto-extension group and operations performed when load balancers are added and/or removed. The auto-scaling service may generate at least a portion of the audit log information after enqueuing the asynchronous workflow, and may generate additional audit log information after completing the asynchronous workflow. For example, the auto-scaling service may generate audit log information, including the time the operation was completed and whether the operation was successful after completing the asynchronous workflow, including the operation and the start time requested to be performed.

Fig. 8 is a block diagram illustrating an example of a process 800 for removing a load balancer to an auto-scaling group, in accordance with various embodiments. Process 800 may be performed by any suitable system, such as a server in a data center, a plurality of computing devices in a distributed system of computing resource service providers, or any service of a computing resource service provider, such as the auto-scaling service described above in connection with fig. 2 and 3. Process 800 includes a series of operations in which a RemoveLoadBalancer application programming interface call is received from a requestor, the requestor is authenticated, then if authenticated, the load balancer database is updated with load balancer information, and the load balancer is removed to an auto-scaling group.

At 802, a computing resource service provider receives an application programming interface call from a client or other entity to remove one or more load balancers to an auto-scaling group. Removing one or more load balancers to an auto-scaling group may cause the one or more load balancers to manage and direct network traffic to a set of instances contained in the auto-scaling group. Further, removing one or more load balancers to the auto-scaling group may include operations performed by various other services of the computing resource service provider. For example, a client may cause a load balancer to be created by submitting a request to a load balancing service as described in more detail above. In addition, the auto-extension service or a component thereof (such as a background process) may remove one or more load balancers to the auto-extension group by submitting batches of API calls to the load balancing service. For example, the background process may determine a batch of 10 instances to be assigned to a particular load balancer, generate an API call configured to cause the load balancing service to assign 10 instances to the particular load balancer, and provide the API call to the load balancing service.

At 804, the computing resource service provider determines whether the requestor has sufficient rights to have the request completed. For example, the requestor may have provided proof of identity and possession credentials as parameters with a RemoveLoadBalancer application Programming interface call. For example, the requestor may supply information sufficient to prove access to the credential as proof of possession of the credential corresponding to the identity, such as a password, an encrypted hash/digest of a password, an encrypted digital signature generated by a signed encryption key, or other key that may be verified by the computing resource service provider to authorize the requestor's identity. The computing resource service provider may provide the identity and proof to an authentication service, which may then verify the identity of the requestor and proof of the credentials. Once the identity of the requestor is verified, the computing resource service provider or authentication service may determine whether the security policy and/or role associated with the identity grants sufficient rights to allow the request to be completed.

If the computing resource service provider is unable to determine identity (e.g., is not present in a secure database), then proof of credentials is insufficient to prove identity (e.g., a wrong password), or the identity of the requestor cannot be otherwise confirmed, the system performing process 800 may not proceed further in process 800. The system of process 800 executes to respond to the authentication failure with an error message to the supplicant and/or register the authentication failure in the security log 812. Otherwise, if the requestor is authenticated and determined to have sufficient rights for the RemoveLoadBalancer request to be completed, the system performing process 800 may proceed to 806.

At 806, the system performing process 800 may update the load balancer database with information corresponding to the load balancer indicated in the request. For example, the request may include an identifier of the load balancer to be removed, a customer associated with the load balancer, a computing resource service provider or service associated with its load balancer, or other information suitable for enabling the auto-scaling service to remove the load balancer to the auto-scaling group. For example, updating the load balancer database may include generating a row in the database containing an identifier of the load balancer and a status of the load balancer. The status may be determined by the auto-scaling service. For example, if a load balancer has not been previously removed to an auto-scaling group, the auto-scaling service may assign a removal status to the row corresponding to the load balancer in the load balancer database.

Subsequently, an auto-scaling service or other system executing process 800 may queue 808 the asynchronous workflow. The asynchronous workflow may be a process, such as process 500 described above in connection with FIG. 5, configured to assign instances of the auto-scaling group to the load balancer indicated in the request. The asynchronous workflow may be completed by the background process described above. The auto-scaling service may then generate audit log information 810. As described above, audit log information may enable a customer to obtain information corresponding to load balancers associated with an auto-extension group and operations performed when load balancers are added and/or removed. The auto-scaling service may generate at least a portion of the audit log information after enqueuing the asynchronous workflow, and may generate additional audit log information after completing the asynchronous workflow. For example, the auto-scaling service may generate audit log information, including the time the operation was completed and whether the operation was successful after completing the asynchronous workflow, including the operation and the start time requested to be performed.

Fig. 9 shows a messaging diagram illustrating an update 902 to a load balancer of an auto-scaling group using a background process 932, according to an embodiment. The update 902 to the load balancer may respond to API calls from clients (such as the API calls described above in connection with fig. 7 and 8) to update (e.g., add or remove) the load balancer associated with the auto-expansion group. The auto-extension service may perform updates using a background process 932 and may communicate with a load balancing service 936 to update associations with instances of auto-extension groups to one or more load balancers managed by the load balancing service. The background process may execute an asynchronous workflow as described above in connection with fig. 5. For example, as described above, the auto-scaling service may receive a request to add a load balancer to an auto-scaling group that requires an asynchronous workflow in order to process the request. Subsequently, the auto-scaling service may execute background process 932 by launching background process 904. In various implementations, the auto-scaling service may cause the background process to restart if the background process is currently executing, or may cause the background process to restart at an operation or step in the update load balancer 902API call.

The background process may then determine a set of load balancers in a transitional state to describe load balancer 926 in response to the request from the auto-scaling service. Thus, the background process may query the load balancer database for the load balancer in an added state, or a removed state as described above. In various embodiments, the auto-scaling service may request information corresponding to all load balancers associated with the auto-scaling group regardless of the state of the load balancers. The background process may then return a list of load balancers associated with the auto-extension group and additional information corresponding to the load balancers, such as status information or status information. Although a list is described, any data structure, ordered or unordered, may be used to return load balancer information to the auto-scaling service. As indicated in fig. 9, the process may be performed in a loop until the auto-scaling service receives a token indicating to proceed to the next step in the update load balancer 902 operation. The loop may be an optional parameter included in the API call received from the client.

Subsequently, the background process can determine a set of computer system instances related to the load balancer in the transitional state to describe the instance in response to a request from the auto-scaling service 908. This may include all instances of the auto-expansion group, or only instances that are still to be allocated or deallocated to a particular load balancer of the load balancer group in the transitional state. Subsequently, the background process 932 may determine a list of instances of the auto-extension group and provide the list of instances 910 to the auto-extension service. The background process may query a load balancer database or other database containing information corresponding to instances of the auto-expansion group. Although a list is described, any data structure, ordered or unordered, may be used to return load balancer information to the auto-scaling service. As indicated in fig. 9, the process may be performed in a loop until the auto-scaling service receives a token indicating to proceed to the next step in the update load balancer 902 operation. For example, describing the load balancer and describing the instance may be performed in a loop until the background process 932 determines that all information corresponding to the load balancer and instance has been obtained. The loop may be an optional parameter included in the API call received from the client.

The auto-scaling service may then determine the order of operation and the batch size for the instances to be updated and the load balancer in the transitional state (912). The determination may be based on a variety of factors, including multiple instances, multiple load balancers, an amount of load to load balance services, or other factors suitable for determining a batch size for updating the instances and load balancers. Further, the background process may query the load balancing service to determine an appropriate batch size (e.g., where instances are to be allocated or deallocated to the load balancer) based at least in part on the load of the load balancing service and/or the number or type of operations to be performed on the load balancer. In various embodiments, if the background process receives an error from the load balancing service, for example, if the load balancing service is unable to process the request, the background process may reduce the batch size and/or delay of transferring the batch-related API calls within a time interval.

Subsequently, the auto scaling service may perform operations related to the determined lot. For example, the background process may communicate the API call to a load balancing service configured to assign an instance of the auto-scaling group to a particular load balancer indicated in the API call (914). The load balancing service 936 may send an acknowledgement (916). The confirmation may include information corresponding to instances in the lot that were successfully assigned to the load balancer and instances that have not been successfully assigned to the load balancer. The validation may enable the auto-scaling service to determine the instances that have been assigned to the load balancer. For example, the acknowledgement may indicate that the particular instance was not successfully assigned to the load balancer, which may indicate that the instance was previously assigned to the load balancer.

If the update includes a load balancer to be removed from the auto-expansion group, the auto-expansion service may wait for the instance being deallocated from the load balancer to complete the connection exclusion operation as described above. The auto-scaling service may determine instance health periodically or aperiodically when an instance is in the process of excluding all current connections (918). The load balancing service 936 may return an acknowledgement indicating the remaining connections to the instance (920). Once all instances have been allocated or deallocated, the auto-scaling service may complete the load balancer update by communicating the completed load balancer update to the load balancing service 936. This may indicate to the load balancing service 936 that all batch operations have completed. Subsequently, the auto-scaling service may update 924 the background process that completed updating the load balancer. In various implementations, updating the background process to complete causes the background process to terminate the operation.

Subsequently, the auto-scaling service and/or the background process may generate audit log information. As described above, the audit log information may enable a customer to obtain information corresponding to load balancers associated with an auto-scaling group and operations performed when load balancers are added and/or removed (e.g., results of performing determined batch operations). The auto-scaling service may generate at least a portion of the audit log information after enqueuing the asynchronous workflow, and may generate additional audit log information after completing the asynchronous workflow. For example, the auto-scaling service may generate audit log information, including the time the operation was completed and whether the operation was successful after completing the asynchronous workflow, including the operation and the start time requested to be performed.

If additional requests are received, the background process may restart the process and determine the load balancer in the transitional state. If no additional requests are received, the background process may continue to perform operations related to the determined batch until all operations are completed. Once all operations are completed, the background process may update the load balancer database with information related to the load balancer in the transitional state. For example, as described above, once all instances have been added to a particular load balancer, the background process may update the state information contained in the load balancer database to be added.

Additionally, embodiments of the present disclosure may be described according to the following clauses:

1. a computer-implemented method, comprising:

under the control of one or more computer systems configured with executable instructions,

receiving a request to update a load balancer associated with an auto-expansion group, wherein the auto-expansion group comprises a set of computer instances, the one or more computer systems configured to manage sizes of the computer instances according to one or more attributes determined by a customer;

updating a load balancer database using the identifier of the load balancer indicated in the request and assigning a state to the load balancer in the load balancer database;

executing a background process configured to fulfill at least a portion of the request by at least modifying an association between the set of computer instances and the load balancer;

updating the status of the load balancer in the load balancer database; and

determining that at least one computer instance in the set of computer instances assigned to the load balancer has passed a health check.

2. The computer-implemented method of clause 1, wherein the request to update the load balancer comprises an add request to add the load balancer to the auto-expansion group.

3. The computer-implemented method of clauses 1 or 2, wherein the request to update the load balancer comprises a removal request to remove the load balancer from the auto-scaling group.

4. The computer-implemented method of any of clauses 1-3, wherein the computer-implemented method further comprises generating log information based at least in part on execution of the background process.

5. A system, comprising:

one or more processors;

memory comprising instructions that, when executed by the one or more processors, cause the system to:

receiving a request to add a load balancer to a set of computer instances organized as a set of computer instances;

determining that a load balancer data store lacks an entry related to the load balancer indicated in the request;

generating, in the load balancer data store, an entry containing an identifier of the load balancer and a status of the load balancer; and is

Executing a background process configured to assign the set of computer instances to the load balancer, wherein assigning the set of computer instances to the load balancer causes the load balancer to direct network traffic to the computer instances.

6. The system of clause 5, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to:

determining that at least one computer instance in the set of computer instances assigned to the load balancer has passed a health check; and is

Updating the state of the load balancer as in-service in the load balancer data store.

7. The system of clauses 5 or 6, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to:

receiving a second request to remove the load balancer from the set of computer instances; and is

Causing the background process to deallocate the set of computer instances to the load balancer, wherein deallocating the set of computer instances to the load balancer causes the load balancer to no longer direct network traffic to the computer instances.

8. The system of clause 7, wherein receiving the second request to remove the load balancer from the set of computer instances further comprises updating the state of the load balancer to a removed state in the load balancer data store, wherein the removed state indicates that the background process is in the process of deallocating the set of computer instances to the load balancer.

9. The system of clauses 7 or 8, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to remove a load balancer data store entry related to the load balancer as a result of the background process deallocating the set of computer instances to the load balancer.

10. The system of any of clauses 5-9, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to:

receiving a second request to update a second load balancer associated with the set of computer instances;

determining that the background process is currently processing the request; and is

Restarting the background process in order to cause the background process to complete the request and the second request.

11. The system of any of clauses 5-10, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to:

receiving a request to obtain information related to a set of load balancers associated with the set of computer instances, wherein the load balancers are members of the set of load balancers;

query the load balancer data store for the information related to the set of load balancers; and is

Providing results of the query in response to the request to obtain information.

12. The system of any of clauses 5-11, wherein generating the entry in the load balancer data store further comprises changing the status of the load balancer included in the request to indicate initiation of addition.

13. A non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by one or more processors of a computer system, cause the computer system to at least:

receiving a request to update one or more load balancers associated with a set of computer instances;

updating a load balancer data store based at least in part on the one or more load balancers indicated in the request, the updating including at least modifying a state assigned to each of the one or more load balancers in the load balancer data store; and is

Causing the background process to complete the request.

14. The non-transitory computer-readable storage medium of clause 13, wherein the instructions that cause the computer system to receive the request to update one or more load balancers associated with the set of computer instances further comprise instructions that cause the computer system to:

determining that the update to the one or more load balancers indicated in the request comprises adding at least one of the one or more load balancers to the set of computer instances; and is

Assigning a set of computer instances in the set of computer instances to the at least one load balancer.

15. The non-transitory computer-readable storage medium of clause 13 or 14, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to generate an audit log indicative of a set of operations performed in response to the received request.

16. The non-transitory computer-readable storage medium of any of clauses 13-15, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to determine that the background process has completed the request and update the state allocated to at least one of the one or more load balancers.

17. The non-transitory computer-readable storage medium of any of clauses 13-16, wherein the instructions that cause the computer system to receive the request to update one or more load balancers associated with a set of computer instances further comprise instructions that cause the computer system to:

determining that the update to the one or more load balancers indicated in the request comprises removing at least one load balancer of the one or more load balancers to the set of computer instances; and is

Deallocating a set of computer instances in the set of computer instances to the at least one load balancer.

18. The non-transitory computer-readable storage medium of any of clauses 13-17, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to:

receiving an Application Program Interface (API) call configured to obtain a list of load balancers associated with the set of computer instances; and is

Providing results of a query to the load balancer data store in response to the API call, the query configured to obtain a list of the load balancers associated with the set of computer instances.

19. The non-transitory computer-readable storage medium of any of clauses 13-18, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to authenticate the request prior to completing the request.

20. The non-transitory computer-readable storage medium of any of clauses 13-19, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to perform a health check on at least one computer instance of the set of computer instances, wherein the at least one computer instance is associated with at least one load balancer of the one or more load balancers.

21. A computer-implemented method, comprising:

detecting an update operation to a load balancer associated with an auto-scaling group comprising a set of computer instances, the one or more computer systems configured to manage a size of the computer instances according to one or more attributes determined by a customer, wherein the update operation is configured to modify an association between the load balancer and the set of computer instances of the auto-scaling group;

querying a load balancer database for information corresponding to the load balancer;

modifying the load balancer database based at least in part on the load balancer and the update operation to the load balancer, wherein modifying the load balancer database comprises modifying a state of the load balancer that indicates a status of the update operation;

storing the update in the load balancer database; and is

Updating the state of the load balancer as a result of detecting completion of the update operation.

22. The computer-implemented method of clause 21, wherein the state of the load balancer comprises at least one of: an added state, a removed state, and an in-service state.

23. The computer-implemented method of clauses 21 or 22, wherein the computer-implemented method further comprises modifying the status of the load balancer in the load balancer database to a removed status based at least in part on a customer request to remove the load balancer from the auto-scaling group.

24. The computer-implemented method of any of clauses 21-23, wherein the computer-implemented method further comprises modifying the status of the load balancer in the load balancer database to an added status based at least in part on a customer request to add the load balancer from the auto-scaling group.

25. The computer-implemented method of any of clauses 21-24, wherein the computer-implemented method further comprises generating an entry in the load balancer database for information corresponding to the load balancer due to the query lacking information corresponding to the load balancer.

26. A system, comprising:

one or more processors; and

detecting an operation associated with one or more load balancers assigned to a set of computer instances;

querying a data store associated with the set of computer instances for information corresponding to the one or more load balancers;

storing updates to the data store corresponding to the load balancer and the operations, the updates including a status of the one or more load balancers indicating a type of the operation; and is

Querying the data store for the status of the load balancer to determine to perform the operation associated with the load balancer assigned to the set of computer instances.

27. The system of clause 26, wherein the operations further comprise adding a load balancer to the set of computer instances, and the status of the one or more load balancers indicates that at least one instance of the set of computer instances is being assigned to the load balancer.

28. The system of clause 27, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to determine that the at least one instance has been allocated to the load balancer, and the status of the one or more load balancers indicates that the one or more instances of the set of computer instances have been allocated to the load balancer.

29. The system of clause 28, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to determine that at least one instance of the set of computer instances has passed a health check, and the status of the one or more load balancers indicates that at least one of the load balancers is in service.

30. The system of any of clauses 26-29, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to receive a request to remove at least one load balancer of the one or more load balancers from the set of computer instances, and the status of the at least one load balancer indicates that at least one instance of the set of computer instances is being deallocated from the load balancer.

31. The system of clause 30, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to:

determining that the one or more instances have been deallocated from the load balancer; and is

Marking entries from the data store corresponding to the load balancer for deletion.

32. The system of any of clauses 26-31, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to generate an entry in the data store for information corresponding to the load balancer since the query did not return information corresponding to the load balancer.

33. The system of clause 32, wherein the entry in the data store comprises a row in the data store that is associated with an identifier of the load balancer.

34. A non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by one or more processors of a computer system, cause the computer system to at least:

receiving a request to update at least one load balancer associated with a set of computer instances;

modifying a data store to include an identifier of the at least one load balancer and a status of the at least one load balancer, wherein the status of the at least one load balancer is determined based at least in part on the received request; and is

Performing one or more operations to complete the request based at least in part on the status of the at least one load balancer indicated in the data store.

35. The non-transitory computer-readable storage medium of clause 34, wherein the instructions that cause the computer system to modify the data store further comprise instructions that modify the data store to include audit information corresponding to the request to update the at least one load balancer.

36. The non-transitory computer-readable storage medium of clause 34 or 35, wherein the instructions that cause the computer system to modify the data store further comprise instructions to determine a previously recorded state of the at least one load balancer stored in the data store by at least querying the data store prior to modifying the data store.

37. The non-transitory computer-readable storage medium of any of clauses 34-36, wherein the instructions that cause the computer system to receive the request to update the at least one load balancer further cause the computer system to:

receiving a request to remove the at least one load balancer from the set of computer instances; and is

Modifying the state of the at least one load balancer in the data store to a removed state.

38. The non-transitory computer-readable storage medium of any of clauses 34-37, wherein the instructions further cause the computer system to:

receiving a second request from the background process for the load balancer in the transitional state;

obtaining a load balancer from the data store in one of one or more transitional states based at least in part on the state of the at least one load balancer included in the data store; and is

Providing the obtained load balancer in response to the second request.

39. The non-transitory computer-readable storage medium of any of clauses 34-38, wherein the instructions further cause the computer system to:

receiving a request to add the at least one load balancer to the set of computer instances; and is

Generating an entry to the data store including the identifier of the at least one load balancer and setting the status of the at least one load balancer to an added status.

40. The non-transitory computer-readable storage medium of any of clauses 34-39, wherein the instructions further cause the computer system to modify the state of the at least one load balancer included in the data store based at least in part on updates of the state of the at least one load balancer received from background processes.

41. The non-transitory computer-readable storage medium of any of clauses 34-40, wherein the instructions further cause the computer system to detect completion of the update to the at least one load balancer and thereby modify the status of the at least one load balancer in the data store.

42. A computer-implemented method, comprising:

detecting one or more load balancers in a set of load balancers in a transition state, wherein the transition state indicates that one or more load balancers associated with an auto-scaling group require updating, and wherein the auto-scaling group comprises at least one computer instance;

receiving a request from an auto-scaling service to initiate an asynchronous workflow configured to update computer instances of the auto-scaling group managed by the auto-scaling service by at least correlating the computer instances with at least one load balancer of a set of load balancers assigned to the auto-scaling group;

determining one or more computer instances of a set of computer instances of the auto-scaling group to be updated based at least in part on the determined one or more load balancers in the transitional state;

determining a set of batch operations configured to update an association between the determined one or more computer instances and the determined one or more load balancers in the transitional state;

causing the set of batch operations to be performed; and

the load balancer database is updated as a result of the execution of the set of batch operations.

43. The computer-implemented method of clause 42, wherein determining the set of batch operations configured to update the association between the determined one or more computer instances and the determined one or more load balancers in the transition state further comprises a set of application programming interface calls configured to cause the determined one or more computer instances to be assigned to the determined one or more load balancers to cause the determined one or more load balancers to distribute network traffic to the determined one or more computer instances.

44. The computer-implemented method of clause 42 or 43, wherein determining the set of batch operations configured to update the association between the determined one or more computer instances and the determined one or more load balancers in the transition state further comprises a set of application programming interface calls configured to cause the determined one or more computer instances to be removed from the determined one or more load balancers such that the determined one or more load balancers no longer distribute network traffic to the determined one or more computer instances.

45. The computer-implemented method of any of clauses 42-44, wherein the computer-implemented method further comprises receiving a second request to initiate an update to a computer instance of an auto-extension group and restarting the asynchronous workflow.

46. A system, comprising:

one or more processors; and

receiving a request to start a workflow;

completing the request by performing at least the following:

determining at least one load balancer in a set of load balancers in a transition state;

determining at least one computer instance in a set of computer instances to be assigned to the at least one load balancer in the transitional state;

determining an operation configured to assign the determined at least one computer instance to the determined at least one load balancer in the transitional state; and is

Causing the determined operation to be performed.

47. The system of clause 46, wherein the instructions that cause the system to determine the at least one load balancer of the set of load balancers in the transition state further comprise instructions that, when executed by the one or more processors, cause the system to:

query a data store for load balancer status information; and is

Determining that the at least one load balancer is in the transitional state based at least in part on a result of the query.

48. The system of clause 47, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to update load balancer status information in the data store based at least in part on a result of the determined operation.

49. The system of any of clauses 46-48, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to:

receiving a second request to initiate a second workflow;

the second requirement is fulfilled by performing at least the following:

determining a second at least one load balancer in the set of load balancers, wherein the second at least one load balancer is in a removed state; and is

Determining a second at least one instance of the set of computer instances to be removed from the at least one load balancer; and is

Causing additional operations to be performed, wherein the additional operations are configured to remove the determined second at least one computer instance from the determined second at least one load balancer in the transition state.

50. The system of clause 49, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to determine that the request and the second request are to occur simultaneously, and restart a background process configured to execute the second workflow.

51. The system of any of clauses 46 to 50, wherein the instructions that cause the system to cause the determined operations to be performed further comprise instructions that, when executed by the one or more processors, cause the system to provide the determined operations to a load balancing service.

52. The system of clause 51, wherein causing the determined operation to be performed further comprises an application program interface call to assign the at least one computer instance to the at least one load balancer.

53. The system of any of clauses 46-53, wherein the request to initiate the workflow is generated based at least in part on an application request from a client to add a particular load balancer to the set of computer instances.

54. A non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by one or more processors of a computer system, cause the computer system to at least:

determining a set of load balancers for updating based at least in part on each load balancer in the set of load balancers in a transition state by querying a data store at least for information corresponding to load balancers associated with a set of computer instances;

determining a set of computer instances associated with the set of computer instances, wherein an association between the determined set of computer instances and the determined set of load balancers is to be updated;

determining an operation configured to update an association between the determined set of computer instances and the determined set of load balancers;

causing an operation to be performed; and is

Updating the data store as a result of the execution of the set of operations.

55. The non-transitory computer-readable storage medium of clause 54, wherein the transition state indicates that at least one computer instance in the set of computer instances requires an update to the one or more load balancers in the transition state.

56. The non-transitory computer-readable storage medium of clauses 54 or 55, wherein the transition state comprises at least one of: an added state, and a removed state.

57. The non-transitory computer-readable storage medium of any of clauses 54-56, wherein the instructions that cause the computer system to generate the operation configured to update the association between the determined set of computer instances and the determined set of load balancers further comprise instructions that cause the computer system to generate the operation such that, when executed, the operation causes the determined set of computer instances to be deallocated from the determined set of load balancers.

58. The non-transitory computer-readable storage medium of any of clauses 54-57, wherein the instructions that cause the computer system to generate the operations configured to update the association between the determined set of computer instances and the determined set of load balancers further comprise instructions that cause the computer system to generate the operations such that, when executed, the operations cause the determined set of computer instances to be distributed from the determined set of load balancers.

59. The non-transitory computer-readable storage medium of any one of clauses 54-58, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to:

receiving a request to terminate a background process based at least in part on a request to update a load balancer associated with the group of computer instances, wherein the background process is configured to generate the operation; and is

Restarting the background process to process the request.

60. The non-transitory computer-readable storage medium of any of clauses 54-59, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to determine a number of computer instances of the set of computer instances to be updated to include in a particular one of the operations based at least in part on a computing capacity of a load balancing service.

61. The non-transitory computer-readable storage medium of any one of clauses 54-60, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to determine an order of operation based at least in part on information obtained from a load balancing service.

FIG. 10 illustrates aspects of an example environment 1000 for implementing various aspects, according to various embodiments. As should be appreciated, although a network-based environment is used for purposes of illustration, different environments may be suitably employed to implement various embodiments. The environment includes an electronic client device 1002, which electronic client device 1002 may comprise any suitable device operable to send and/or receive requests, messages or information over a suitable network 1004, and in some embodiments, communicate information back to a user of the device. Examples of such client devices include personal computers, mobile phones, handheld messaging devices, laptop computers, tablets, set-top boxes, personal data assistants, embedded computer systems, e-book readers, and so forth. The network may comprise any suitable network, including an intranet, the internet, a cellular network, a local area network, a satellite network, or any other such network and/or combination thereof. The components for such a system may depend at least in part on the type of network and/or environment selected. Protocols and components for communicating via such networks are well known and will not be discussed in detail herein. Communication over the network may be accomplished through wired or wireless connections, as well as combinations thereof. In this example, the network comprises the Internet as the environment includes a web server 1006 for receiving requests and serving content in response thereto, although for other networks alternative means for achieving a similar purpose may be used, as will be apparent to those of ordinary skill in the art

The illustrative environment includes at least one application server 1008 and a data store 1010. It should be understood that there may be several application servers, tiers or other elements, processes or components that may be linked or otherwise configured, which may interact to perform tasks, such as obtaining data from an appropriate data store. A server, as used herein, may be implemented in various ways, such as a hardware device or a virtual computer system. In some cases, a server may refer to a programming module that is executing on a computer system. As used herein, unless the context indicates otherwise or clearly indicates otherwise, the term "data store" refers to any equipment or combination of devices capable of storing, accessing and retrieving data, which may include any combination and number of data servers, databases, data storage devices and data storage media in any standard, distributed, virtual or aggregate environment. The application server may include any suitable hardware, software, and firmware for integrating with the data store as needed to execute aspects of one or more applications for the client device, handling some or all of the data access and business logic for the applications. The application server may provide access control services in cooperation with a data store and may be capable of generating content including, but not limited to, text, graphics, audio, video, and/or other content that cannot be provided to a user, which may be provided to the user by a web server in the form of hypertext markup language ("HTML"), extensible markup language ("XML"), JavaScript, cascading style sheets ("CSS"), or other suitable client-side structured language. Content delivered to a client device may be processed by the client device to provide the content in one or more forms, including but not limited to forms that are audibly, visually, and/or perceptible by other senses (including tactile, pinky, and/or olfactory). The processing of all requests and responses, and the transfer of content between the client device 1002 and the application server 1008, may be handled by the web server using PHP in this example: hypertext preprocessor ("PHP"), Python, Ruby, Perl, Java, HTML, XML, or other suitable server-side structured language. It should be understood that a web server and an application server are not required and are merely example components, as the structured code discussed herein may be executed on any suitable device or host, as discussed elsewhere herein. Further, operations described herein as being performed by a single device (unless the context clearly dictates otherwise) may be performed collectively by multiple devices, which may form a distributed and/or virtual system.

Data store 1010 may include a number of separate data tables, databases, data files, dynamic data storage schemes, and/or other data storage mechanisms and media for storing data related to particular aspects of the present disclosure. For example, the illustrated data repository may include mechanisms for storing production data 1012 and user information 1016, which may be used to provide content for the producer. The data store is also shown to include a mechanism for storing log data 1014, which may be used for reporting, analysis, or other such purposes. It should be understood that there may be many other aspects that may need to be stored in the data store, such as page image information and access rights information, which may be stored in any of the above listed mechanisms or in additional mechanisms in the data store 1010, as appropriate. The data store 1010 is operable by logic associated therewith to receive instructions from the application server 1008 and to obtain, update, or otherwise process data in response thereto. The application server 1008 may provide static data, dynamic data, or a combination of static and dynamic data in response to the received instructions. Dynamic data, such as that used in web logs (blogs), shopping applications, news services, and such other applications, may be generated by a server-side structured language as described herein, or may be provided by a content management system ("CMS") operating on or under the control of an application server. In one example, a user, through a device operated by the user, may submit a search request for a certain type of item. In this case, the data store may access the user information to verify the identity of the user, and may access the catalog detail information to obtain information about the type of item. The information may then be returned to the user, such as in a results list on a web page that the user can view via a browser on the user device 1002. Information for a particular item of interest can be viewed in a dedicated page or window of the browser. It should be noted, however, that embodiments of the present disclosure are not necessarily limited to the content of a web page, but may be more generally applicable to processing requests, where the request is not necessarily a request for content.

Each server will typically include an operating system that provides executable program instructions for the general management and operation of the server, and will typically include a computer-readable storage medium (e.g., hard disk, random access memory, read only memory, etc.) that stores instructions that, when executed by the processor of the server, allow the server to perform its intended functions. Suitable implementations for the operating system and general functions of the server are known or commercially available and are readily implemented by those of ordinary skill in the art, particularly in light of the disclosure herein.

In one embodiment, the environment is a distributed and/or virtual computing environment utilizing several computer systems and components interconnected by communication links using one or more computer networks or direct connections. However, those of ordinary skill in the art will appreciate that such a system may operate equally well in a system having a fewer or greater number of components than shown in FIG. 10. Accordingly, the description of the system 1000 in fig. 10 should be taken as illustrative in nature and not limiting the scope of the disclosure.

Various embodiments may also be implemented in a wide variety of operating environments, which in some cases may include one or more user computers, computing devices, or processing devices that may be used to operate any of a number of application programs. The user or client device may include any of a number of general purpose personal computers, such as desktop, laptop, or tablet computers running a standard operating system, as well as cellular, wireless, and handheld devices running mobile software and capable of supporting a variety of networks and messaging protocols. Such a system may also include a plurality of workstations running any of a number of commercially available operating systems and other known applications for purposes such as development and database management. These devices may also include other electronic devices such as virtual terminals, thin clients, gaming systems, and other devices capable of communicating via a network. These devices may also include virtual devices, such as virtual machines, hypervisors, and other virtual devices capable of communicating via a network.

Various embodiments of the present disclosure utilize at least one network familiar to those skilled in the art for supporting communications using any of a number of commercially available protocols, such as transmission control protocol/internet protocol ("TCP/IP"), user datagram protocol ("UDP"), protocols operating in layers of the open systems interconnection ("OSI") model, file transfer protocol ("FTP"), universal plug and play ("UpnP"), network file system ("NFS"), common internet file system ("CIFS"), and routable protocol suite. The network may be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, a satellite network, and any combination thereof.

In embodiments utilizing a web server, the web server may run any of a number of servers or mid-tier applications, including hypertext transfer protocol ("HTTP") servers, FTP servers, common gateway interface ("CGI") servers, data servers, Java servers, Apache servers, and business application servers. The server may also be capable of responding to requests from user devices, such as by executing a program that may be implemented in any programming language (such as

C. C # or C + +, or any scripting language (such as Ruby, PHP, Perl, Python, or TCL), as well as combinations thereof. The server may also include a database server, including without limitation a server-server

And

those commercially available, and open source servers such as MySQL, Postgres, SQLite, MongoDB, and any other server capable of storing, retrieving, and accessing structured or unstructured data. The database servers may include table-based servers, file-based servers, unstructured servers, relational servers, non-relational servers, or a combination of these and/or other database servers.

The environment may include a variety of data storage libraries and other memory and storage media as discussed above. These may reside in a variety of locations, such as on storage media local to (and/or resident in) one or more of the computers, or remote from any or all of the computers across a network. In one particular set of embodiments, the information may reside in a storage area network ("SAN") familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to a computer, server, or other network device may be stored locally and/or remotely as appropriate. Where the system includes computerized devices, each such device may include hardware elements that may be electrically coupled via a bus, including, for example, at least one central processing unit ("CPU" or "processor"), at least one input device (e.g., a mouse, keyboard, controller, touch screen or keyboard), and at least one output device (e.g., a display device, printer or speaker). Such systems may also include one or more storage devices, such as magnetic disk drives, optical storage devices, and solid state storage devices (such as random access memory ("RAM") or read only memory ("ROM")), as well as removable media devices, memory cards, flash memory cards, and the like

Such devices may also include a computer-readable storage medium reader, a communication device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and a working memory as described above. The computer-readable storage media reader can be connected to or configured to receive computer-readable storage media representing remote, local, fixed, and/or removable storage devices and storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information. The system and various devices will also typically include a number of software applications, modules, services or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or web browser. It will be appreciated that alternative embodiments may have many variations from the above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. In addition, connections to other computing devices (such as network input/output devices) may be employed.

Storage media and computer-readable media for containing the code or portions of code may comprise any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules or other data, including RAM, ROM, electrically erasable programmable read-only memory ("EEPROM"), flash memory or other memory technology, compact disc read-only memory ("CD-ROM"), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a system device. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the claims that follow.

Other variations are within the spirit of the present disclosure. Accordingly, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention, as defined in the appended claims.

The use of the terms "a" and "an" and "the" and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" are to be construed as open-ended terms (i.e., meaning "including, but not limited to,") unless otherwise noted. The term "connected," when unmodified and reference is made to physical connections, is to be construed as being partially or wholly contained within, attached to, or joined together even if there is some intervening. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. The use of the term "group" (e.g., "a set of items") or "subset" (unless otherwise indicated herein or contradicted by context) should be construed as a non-empty set comprising one or more members. Furthermore, unless otherwise indicated or contradicted by context, the term "subset" of a corresponding group does not necessarily denote an appropriate subset of the corresponding group, but the subset and the corresponding group may be equal.

Conjunctive language (such as phrases in the form "A, B, and at least one of C" or "A, B and at least one of C") (unless otherwise specifically stated or otherwise clearly contradicted by context) is otherwise understood by context as being generally used to present any non-empty subset of items, terms, etc. that can be A or B or C, or groups A and B and C. For example, in the illustrative example of a group of three members, the hyphen phrases "A, B, and at least one of C" and "A, B and at least one of C" refer to any of the following groups: { A }, { B }, { C }, { A, B }, { A, C }, { B, C }, and { A, B, C }. Thus, such conjunctive language is not generally intended to imply that certain embodiments require the presence of each of at least one of a, at least one of B, and at least one of C.

The operations of the processes described herein may be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The processes described herein (or variations and/or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions, and code (e.g., executable instructions, one or more computer programs, or one or more application programs) that are collectively executed on one or more processors may be implemented by hardware or combinations thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer readable storage medium may be non-transitory.

The use of any and all examples, or exemplary language (e.g., "such as") provided herein, is intended merely to better illuminate embodiments of the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

Embodiments of this disclosure are described herein, including the best mode known to the inventors for carrying out the invention. Variations of those embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the embodiments of the disclosure to be practiced otherwise than as specifically described herein. Accordingly, the scope of the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the scope of the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

Claims

1. A computer-implemented method for managing a load balancer, comprising:

receiving a request to adjust a number of load balancers assigned to an auto-expansion group, the auto-expansion group comprising a set of computer instances, wherein a size of the auto-expansion group is managed according to one or more attributes determined by a customer;

updating a load balancer database using identifiers of one or more load balancers and assigning a state to each of the one or more load balancers in the load balancer database;

executing a background process configured to fulfill at least a portion of the request by at least modifying the allocation of the set of computer instances to a load balancer;

determining resource utilization of the set of computer instances assigned to the load balancer; and

updating the state of the load balancer in the load balancer database based at least in part on the determination and the allocation modification for the set of computer instances.

2. The computer-implemented method of claim 1, wherein the request to adjust the number of load balancers comprises an add request to add a load balancer to the auto-scaling group.

3. The computer-implemented method of claim 1, wherein the request to adjust the number of load balancers comprises a removal request to remove a load balancer from the auto-scaling group.

4. A system for managing a load balancer, comprising:

one or more processors; and

receiving a request to adjust a number of load balancers assigned to a set of computer instances organized as a set of computer instance groups;

updating a load balancer data store with identifiers of one or more load balancers and assigning a state to each of the one or more load balancers in the load balancer data store;

executing a background process to complete at least a portion of the request by at least modifying the allocation of the set of computer instances to the load balancer;

monitoring resource utilization of the set of computer instances assigned to the load balancer; and

updating the state of the load balancer in the load balancer data store based at least in part on the monitoring and the allocation modification for the set of computer instances.

5. The system of claim 4, wherein updating the state of the load balancer comprises modifying the state to an added state, an in-service state, or a removed state.

6. The system of claim 4, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to:

receiving a second request to remove the load balancer assigned to the set of computer instances; and is

Causing a background process to de-allocate the set of computer instances to the load balancer, wherein de-allocating the set of computer instances to the load balancer causes the load balancer to no longer direct network traffic to the set of computer instances.

7. The system of claim 6, wherein receiving the second request to remove the load balancer from the set of computer instances further comprises updating the state of the load balancer to a removed state in the load balancer data store, wherein the removed state indicates that the background process is in the process of deallocating the set of computer instances to the load balancer.

8. The system of claim 6, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to remove a load balancer data store entry related to the load balancer as a result of the background process deallocating the set of computer instances to the load balancer.

9. The system of claim 4, wherein the memory further comprises instructions that, when executed by the one or more processors, cause the system to:

receiving a second request to update a second load balancer assigned to the set of computer instances;

10. A non-transitory computer-readable storage medium having stored thereon executable instructions that, when executed by one or more processors of a computer system, cause the computer system to at least:

receiving a request to adjust a number of one or more load balancers assigned to a group of computer instances;

updating a data store storing data using identifiers of one or more load balancers and assigning a state to each of the one or more load balancers in the data store;

executing a background process to fulfill at least a portion of the request by at least modifying an allocation of the set of computer instances to a load balancer of the one or more load balancers;

updating the state of the load balancer in the data store based at least in part on the monitoring and an allocation modification of the set of computer instances.

11. The non-transitory computer-readable storage medium of claim 10, wherein the instructions that cause the computer system to receive the request to adjust the number of the one or more load balancers assigned to the set of computer instances further comprise instructions that cause the computer system to:

determining that the request to adjust the number of the one or more load balancers comprises adding at least one load balancer assigned to the set of computer instances; and is

12. The non-transitory computer-readable storage medium of claim 10, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to generate an audit log indicative of a set of operations performed in response to the received request.

13. The non-transitory computer-readable storage medium of claim 10, wherein the instructions that cause the computer system to receive the request to adjust the number of the one or more load balancers assigned to a group of computer instances further comprise instructions that cause the computer system to:

determining that the request to adjust the number of the one or more load balancers includes removing at least one load balancer assigned to the set of computer instances; and is

14. The non-transitory computer-readable storage medium of claim 10, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to:

Providing results of a query to the data store in response to the API call, the query configured to obtain a list of the load balancers assigned to the set of computer instances.

15. The non-transitory computer-readable storage medium of claim 10, wherein the instructions further comprise instructions that, when executed by the one or more processors, cause the computer system to perform a health check on at least one computer instance of the set of computer instances, wherein the at least one computer instance is associated with at least one load balancer assigned to the set of computer instances.