Context-sensitive techniques for optimizing network connectivity

Techniques described and suggested herein include systems and methods for optimizing network connections by using attributes of one or more of the connected entities. For example, a routing engine may be implemented to determine, based on various attributes of a client device, its desired destination, and/or the networks capable of connecting the client device and the destination, optimized parameters and routes for the network connection. Such optimization may involve the selection of an optimal network, the negotiation of an optimal connection type, and the like. The optimization may be made for one or more disparate criteria, such as data security, bandwidth, network latency, geographical proximity, and so forth.

BACKGROUND

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

However, network computing may rely on a large number of resources, many of which may have different performance characteristics, geographic location, security requirements, and the like, and a given destination of a network computing provider may be reached by several networks or network paths. A consumer of network computing services desiring to interact with such a destination may thus have difficulty determining which network or network path would provide an optimal connection, in terms of performance, stability, security, or some other criterion.

DETAILED DESCRIPTION

Techniques described and suggested herein include systems and methods for optimizing network connections between one or more client devices and one or more destinations, such as network destinations, by selecting an optimal interstitial network by which to connect the client devices and destinations. For example, a routing engine may be implemented to detect that a given client device requests a connection with a destination. The routing engine may determine, based on various attributes of the desired destination, the requesting client device, and/or the networks capable of connecting the client device and the destination, optimized parameters and routes for the network connection. Such optimization may involve the selection of an optimal network, the negotiation of an optimal connection type, and the like. The optimization, and therefore both the attributes and the factors considered when performing the optimization, may be on one or more disparate criteria, such as data security, bandwidth, network latency, geographical proximity, and the like.

The optimal configuration as determined by the routing engine may be processed by the client device (and/or, in some embodiments, by entities associated with the destination and/or the networks), so as to enable the client device to transact with the destination using optimized parameters. For example, a client device may be capable of remote management, such as by the use of mobile device management routines, and an optimal configuration may be provided to such routines for further processing by the client device. Thereafter, the client device may connect with the destination in the specified manner.

FIG. 1schematically illustrates an example environment where various attributes of client devices, destinations, and/or network may be used to optimize network connections, in accordance with some embodiments. One or more client devices102connect, request a connection with, or attempt to connect with one or more destinations104remote from the client devices102, via one or more networks106. As illustrated, some or all of the networks106may correspond to multiple destinations104. Furthermore, some or all of the destinations104may be reached by multiple networks.

The client devices102may include any devices or entities capable of communicating, such as over a network106, to a destination104. For example, the client devices102may be physical devices, such as smartphones, laptops, tablets, servers, desktop computers, routers and/or other network appliances, and the like. As another example, client devices102may be virtual devices, such as virtual hosts provided by or in connection with a computing resource service provider, e.g., one or more computing resources via one or more services provided by the computing resource service provider.

The destinations104may be any resource reachable by the client devices102, such as over a network104. For example, destinations104may include physical servers, network appliances (such as routers), virtual hosts such as those provided by a computing resource service provider, services provided by a computing resource service provider, smartphones, laptops, tablets, servers, desktop computers, and the like.

The networks106may include any entity or collection of entities that connect(s) one computing entity, such as a client device102, with at least one other entity, such as destinations104, whether directly or indirectly. In some embodiments, the networks106may be interconnected, and/or multiple networks may be combined into a given network. The networks106may be physical (e.g., using wired or wireless communications, between physical entities, and the like), virtual (such as may be provided via a service of a computing resource service provider, e.g., virtual versions of various network endpoints and components), or some combination thereof, and may be implemented any technology or combination of technologies as may be relevant to a given implementation. The networks may be, or include, computing entities, such as proxy devices, network appliances, servers (such as hosts, whether virtual or physical), and the like. For example, the networks may include interconnections between a client device102and at least one destination104, with one or more interstitial proxies or hosts between the client device102and the at least one destination104. In this example, the techniques described herein may include the selection (such as by a routing engine110, as described in more detail herein) of one or more of the interstitial proxies or hosts as, or as a part of, selecting an optimal network from amongst a plurality of networks.

Technologies implemented may relate to signaling protocols, network protocols (such as Internet protocols), cryptographic protocols, data security protocols, and the like, and may relate independently to each segment of the network and/or connection pair. The technologies used may relate to any network layer, as well, such as various layers of the Open Systems Interconnection model (OSI), which include application layers, presentation layers, session layers, transport layers, network layers, data link layers, and physical layers.

In connection with a connection request, e.g., by a client device102to a destination104, a routing engine110may be implemented to assess various attributes of the destinations104, the client devices102, the networks106, or some combination thereof, so as to determine the optimal configuration by which the client device102may connect to the requested destination104. The routing engine110may be a separate entity from any of the client devices102, networks106, and/or destinations104, or, in some embodiments, may be implemented in or as part of such components. In the case that the routing engine110is a separate entity, it may be implemented in a physical or virtual computing device, such as may be provided by a computing resource service provider.

The attributes assessed by the routing engine110may include any properties about the entity to which they relate. Such attributes may include performance characteristics, device type, security requirements, capacity (e.g., computing and/or storage capacity), geographic location (e.g., proximity to the remote entity), the nature of accessible data on a given entity, network characteristics (latency, bandwidth, stability, etc.) and the like. The routing engine110may use such information to select an optimal network from among the networks (e.g., routes, proxies or hosts) capable of connecting to a given requested destination. A network may be determined as optimal by virtue of one or more characteristics relevant to the connection, the client device, a customer utilizing the client device, the destination, a computing resource service provider implementing some or all of the aforementioned entities, or some combination thereof.

For example, an implementing computing resource service provider may instruct the routing engine110to optimize inbound connections to its destinations104by determining the network or set of networks106that results in the shortest physical distance of the network path between the requesting client device102and the requested destination104. In this example, the routing engine may determine the geographic location of the destination104, the geographic location of the client device102, and the additional physical distance generated by each eligible network106, so as to determine the network that provides the shortest overall physical distance between the client device and the destination.

As another example, a client device may request the highest security connection available to reach a certain quantum of data stored on one or more of the destinations104. In response, the routing may determine the security capabilities of the client device, as well as the security capabilities of the destination(s)104having the requested quantum of data. Based on these determinations, the routing engine may compare the security capabilities of the destination(s)104and the client device102, and further identify one or more networks106that allows for the highest level of network security between the endpoints given the respective security capabilities of the destination(s)104and the client device102.

The examples provided immediately above are not limiting. The routing engine110may optimize for any parameter relevant to the client device102, destination104, network106, or some combination thereof (or a user or administrator thereof), such as overall latency, system load balancing (e.g., amongst destinations and/or networks), user experience (e.g., responsive to the type of client device102requesting the connection), and so on. As previously mentioned, the routing engine110may optimize for such parameters by identifying and/or selecting one or more networks106by the characteristics of any component or combination of components thereof. For example, the routing engine110may, as previously discussed, select or identify one or more networks based on characteristics of interstitial proxies and/or hosts, and/or the potential effects on the parameters the selection thereof would cause.

At a time after the routing engine110determines an optimal configuration as discussed, the optimal configuration, or information relating to the determined optimal configuration, may be further processed by a relevant entity so as to configure the overall system in accordance therewith. In some embodiments, the optimal configuration is provided to a client entity102for further processing. For example, the optimal configuration is provided to the client entity102in, e.g., the form of a set of policies enforceable by remote management routines resident on the client device. Examples of such remote management routines include mobile device management (MDM) capabilities. In this example, once the optimal configuration is processed by the client device102, the client device may proceed with connecting to the remote destination104via, e.g., the optimal network106as determined by the routing engine110, as it would then be configured to do so.

In some embodiments, the destinations104themselves may be configured to instruct a given client device within, e.g., a given session, to further connect to the destination104via the determined optimal network106, after an initial connection therewith by an optimization-agnostic network or component thereof. For example, a client device102may initiate a session with a destination104via a first network106(e.g., with which it may have previously connected). A routing engine110may determine that, based on the attributes of the destination104, the client device102, and/or the networks106, a different network106may provide a more optimal connection and/or experience. As a result, the routing engine110may cause the destination104, and/or the first network106, to redirect or instruct the client device102to use the different network106for further and/or future connection, in accordance with the optimization performed.

In some embodiments, the routing engine110may also determine the optimal connection type, e.g., between the client device102and a network106, and/or between the network106and the destination104, in a similar fashion as described above for determining the optimal network106. For example, the routing engine110may assess attributes of the client device102and/or the network106(either before or after an optimal network106is determined), and determine an optimal connection type based on the assessed attributes. As a further example, if both the client device102and the (e.g., optimal) network106both support Transport Layer Security/Secure Socket Layer (TLS/SSL), the routing engine110may determine that a connection secured using TLS/SSL would be an optimal connection type. Other types of optimizations, such as for network latency, processing overhead, data security, cryptographic capabilities, and the like, are contemplated herewith, and it is contemplated that an optimized connection type may be relevant not just between the two immediate endpoints (e.g., between a client device102and a network106), but also downstream or upstream (e.g., at the destination104). In some embodiments, the routing engine110may take such downstream and/or upstream effects in consideration when making the determinations detailed herein.

FIG. 2schematically illustrates an example environment in which a routing engine determines one or more optimal networks by which a client device may connect to a destination, in accordance with some embodiments. A client device202, which may in some embodiments be similar to client device102described in connection withFIG. 1, connects, requests a connection with, or attempts to connect with one or more destinations204remote from the client device202, via one or more networks206. For clarity of illustration, multiple networks206are shown as connected to, or capable of connecting to, destination204. However, as previously discussed in connection withFIG. 1, some or all of the networks206may correspond to multiple destinations204. The networks206and the destination204may, in some embodiments, be similar to the networks106and the destinations104described above in connection withFIG. 1.

The client devices102may include any devices or entities capable of communicating, such as over a network106, to a destination104. For example, the client devices102may be physical devices, such as smartphones, laptops, tablets, servers, desktop computers, routers and/or other network appliances, and the like. As another example, client devices102may be virtual devices, such as virtual hosts provided by or in connection with a computing resource service provider, e.g., one or more computing resources via one or more services provided by the computing resource service provider.

As previously discussed, in connection with a connection request, e.g., by a client device202to a destination204, a routing engine214may be implemented to assess various attributes212of the destinations204, attributes210of the client devices102, attributes of the networks206, or some combination thereof, so as to determine the optimal configuration by which the client device202may connect to the requested destination204. The routing engine214may be similar in functionality and implementation to the routing engine110discussed above in connection withFIG. 1.

The attributes assessed by the routing engine214may include any properties about the entity to which they relate. As mentioned above, such attributes may include performance characteristics, device type, security requirements, capacity (e.g., computing and/or storage capacity), geographic location (e.g., proximity to the remote entity), the nature of accessible data on a given entity, network characteristics (latency, bandwidth, stability, etc.) and the like. The attributes may be pushed to the routing engine214, e.g., at some interval, provided to the routing engine214in connection with a request for such attributes by the routing engine214, and/or, in some embodiments, may be extracted from existing communications by the destinations204and/or client devices202by e.g., a listener implemented by the routing engine214. In some embodiments, the attributes may be provided as metadata.

The routing engine214may use such information to determine an optimal configuration for client device202to connect with destination204. The optimal configuration may include the identification of an optimal network206(illustrated as a solid arrow) from among the networks capable of connecting to a given requested destination. As previously discussed, a network may be determined as optimal by virtue of one or more characteristics relevant to the connection, the client device, a customer utilizing the client device, the destination, a computing resource service provider implementing some or all of the aforementioned entities, various characteristics of an interstitial host or proxy comprising or part of the networks, or some combination thereof.

In addition to the examples provided above in connection withFIG. 1, by way of further example, an implementing computing resource service provider may instruct the routing engine214to optimize inbound connections to its destinations204by providing requesting client devices202access to the destination204by way of a network206that is geographically nearest to the client device202, so as to, e.g., minimize network latency and/or maximize reliability of the connection portion between the client device202and the networks206(e.g., the so-called “last mile”). In such an example, as may be contemplated, a highly determinative attribute may be the geographical location of the client device, as well as that of the network, and such information may be requested by (or pushed to, as previously discussed) the routing engine214. Furthermore, the downstream effects of the selection of a given network, e.g., with regard to the geographical location of the destination, may be contemplated by the routing engine214, and the routing engine214may also take relevant attributes of the destination into account when making its determination.

As previously mentioned, the examples provided herein are not limiting, and it is contemplated that the routing engine214may optimize for any parameter relevant to the client device202, destination204, network(s)206, or some combination thereof (or a user or administrator thereof), such as overall latency, system load balancing (e.g., amongst destinations and/or networks), user experience (e.g., responsive to the type of client device202requesting the connection), and so on.

At a time after the routing engine214determines an optimal configuration as discussed, the optimal configuration, or information relating to the determined optimal configuration, may be further processed by a relevant entity so as to configure the overall system (or components thereof) in accordance therewith. As previously mentioned, the routing engine214may pass the determined optimal configuration to the client device202, e.g., via remote management routines, so as to cause the client device to connect with, e.g., a designated optimal network206when attempting to reach the destination204. As a further example, existing static routes between networks206and the destination204may be utilized, and an optimum static route/network/destination combination selected, from those static routes extant in the configuration at the time the routing engine214makes its determination.

In some embodiments, the routing engine214may cause, e.g., a service or other capability of an implementing computing resource service provider, to reconfigure networks206and/or reroute connections between existing networks206to the destination204in accordance with the determined optimal configuration. For example, routes within/between the networks206and the destination204may be reconfigured by, e.g., an implementing computing resource service provider, according to an optimal configuration as determined by the routing engine214. In such an example, a given network206may serve as an access point to the client device202in order to reach the destination204, but in connection with the client device202connecting with such a network, the routing engine214may cause the reconfiguration of routes between the network206and the destination204in a manner that may be transparent to the connecting client device202.

As previously mentioned, in some embodiments, the destinations204may be configured to instruct a given client device within, e.g., a given session, to further connect to the destination204via the determined optimal network206, after an initial connection therewith by an optimization-agnostic network or component thereof. For example, a client device202may initiate a session with a destination204via a first network(s) (e.g., with which it may have previously connected, illustrated by the dashed arrows). A routing engine110may determine that, based on the attributes212of the destination204, the attributes210of the client device202, and/or the networks206, a different network206may provide a more optimal connection and/or experience. As a result, the routing engine214may cause the destination204, and/or the first network206, to redirect or instruct the client device202to use the different network206for further and/or future connection, in accordance with the optimization performed.

In some embodiments, the client device202may, prior to submitting a connection request (e.g., for connecting to the destination204), issue a configuration request, directly or indirectly, to the routing engine214. Such a configuration request may be issues by, e.g., remote management routines accessible to the client device, and may be made in connection with (and/or separately from) an ensuing connection request. In some embodiments, the configuration request may be issued by some other entity of a computing resource service provider receiving a connection request from a client device202.

In some embodiments, the routing engine214may also determine the optimal connection type208, e.g., between the client device202and a network206, and/or between the network206and the destination204, in a similar fashion as described above for determining the optimal network206. Such determination of the optimal connection type208may be part of the overall optimal configuration determined by the routing engine214. For example, the routing engine214may assess attributes of the client device202and/or the network206(either before or after an optimal network106is determined), and determine an optimal connection type based on the assessed attributes.

As a further example, if both the client device202and the (e.g., optimal) network206both support Transport Layer Security/Secure Socket Layer (TLS/SSL), the routing engine214may determine that a connection secured using TLS/SSL would be an optimal connection type to be applied to a connection208between the client device202and the network206. As previously mentioned, other types of optimizations, such as for network latency, processing overhead, data security, cryptographic capabilities, and the like, are contemplated herewith, and it is further contemplated that an optimized connection type may be relevant not just between the two immediate endpoints (e.g., between a client device202and a network206), but also downstream or upstream (e.g., at the destination204). In some embodiments, the routing engine214may take such downstream and/or upstream effects in consideration when making the determinations detailed herein.

FIG. 3schematically illustrates an example data flow between client devices302, routing engines304, networks306, and destinations308in accordance with some embodiments. The client devices302, routing engines304, networks306, and destinations308may be similar to such components as described above in connection withFIGS. 1 and 2. WhileFIG. 3illustrates a linear data flow, it is contemplated that many of the processing steps and transitions described herein may not necessarily occur in the order illustrated, and some of such processing steps and transitions may occur asynchronously, synchronously, or contemporaneously with one or more other processing steps and/or transitions, as well as in any order. Other data flows differing than the one illustrated are also contemplated and examples are mentioned above in connection withFIGS. 1 and 2.

In some embodiments, a configuration request310is submitted by a client device302and received312, directly or indirectly, by a routing engine304. In response, a routing engine304submits attribute requests314,318,322, which are received316,320,324, by client device302, network306, and destination308, respectively. At a time after receipt316,320,324, attribute responses326,330,334, are provided by the client device302, network306, and destination308, respectively, and received328,332,336, by the routing engine304. Attributes may be similar to those discussed above in connection with at leastFIGS. 1 and 2.

At a time after the attribute responses are received from the client device302, network306, and destinations308, the routing engine304processes338the attribute responses to generate an optimal configuration340, which may include information identifying the optimal network306and/or connection type(s), and provides the optimal configuration340as a response to the configuration request310. At a time after receipt342, the client device302may, such as described in further detail above, be configured to connect in accordance with the optimal configuration provided by the routing engine304. Connection requests344by the client device302may then be sent to the identified optimal network306which, upon receipt346, further communicates the connection request348to the desired destination350.

As previously discussed, it is contemplated that the configuration requests may be initiated by other entities, such as by those of a computing resource service provider, rather than the client device. Additionally, also as previously discussed, the connection request may occur in a fashion temporally decoupled from that of the configuration request, in a different order than illustrated inFIG. 3, and the like. Furthermore, in some embodiments, data by the client device302may be replicated on multiple destinations, adding a further determination in connection with the processing of the attribute responses338of which destination308would be optimal with regard to the connection request.

FIG. 4schematically illustrates an example process for processing configuration and connection requests to enable a client device to connect with a destination using an optimal network, in accordance with some embodiments. At step402, an entity, such as a routing engine as described above in connection with at leastFIGS. 1 and 2, receives a configuration request in connection with a connection request, such as by a client device as described above in connection withFIGS. 1 and 2. At step404, an entity, such as a routing engine, determines one or more attributes of the destination, client device, and/or applicable networks to connect the destination and client device. As previously discussed, such attributes may be provided by the entities to which they pertain, or the, e.g., routing engine, may retrieve such information (e.g., submit an attribute request to the entities).

At step406, after determining the attributes in step404, the, e.g., routing engine processes the information received and determines an optimal configuration, which may include the identification of an optimal network for connecting the client device and/or destination. As previously discussed, the determination may be performed by the routing engine relative to any relevant optimization criterion, some examples of which were discussed above in connection with at leastFIGS. 1 and 2.

At a time after determining the optimal configuration in step406, the routing entity causes one or more of the client device, network, and/or destination to be configured in accordance with the optimal configuration at step408. As previously discussed, the entity to be configured may depend on the particular implementation, e.g., if the client device has access to remote management routines, and/or if the networks and/or the routes between the networks and the destinations are static or dynamically configurable (e.g., by an implementing computing resource service provider).

At step410, after the relevant entities are configured according to the optimal configuration generated in step406and provided in step408, the client device is enabled to connect with the destination via the optimal network as determined by the routing engine, and in accordance with the attributes of the relevant entities as determined in step404.

FIG. 5schematically illustrates an example process for connecting and optimizing with a remote destination using various attributes, in accordance with some embodiments. At step502, an entity, such as a client device as previously described in connection with at leastFIGS. 1-4, requests a connection a destination, such as the destinations described above in connection with at leastFIGS. 1-4. The client device may, in some embodiments, be configured with remote management routines, such as mobile device management capabilities, and the destinations may be remote to the client device and in an arbitrary geographical location not necessarily known to the client device.

At step504, attributes of the connecting entity (e.g., the client device) are provided by that entity, either asynchronously or synchronously in connection to, e.g., an attribute request from a routing engine. Such attributes may include any relevant information relating to the client device, some examples of which are provided in further detail above. For example, the connecting entity may provide information as to which of the available networks it prefers to connect to the destination, as well as its preferred connection type.

At step506, an optimal configuration is received by, e.g., the client device, from, e.g., a routing engine, in accordance with the attributes provided at step504, attributes of the desired destination, applicable networks available to connect the two entities, policies set by an implementing computing resource service provider, requirements of the client device, and the like. Such an optimal configuration may be similar in nature to that which is described above in connection with at leastFIGS. 1-4. In some embodiments, as previously discussed, the optimal configuration may be implemented by using remote management routines on the client device and available to the “pushing” entity, e.g., the routing engine (whether directly or indirectly). The optimal configuration may be generated according to one or more techniques described above in connection with at leastFIGS. 1-3, and, in some embodiments, using the process described above in connection withFIG. 4.

At step508, an entity, such as a client device, may negotiate an optimal connection type with which to connect to a network that in turn connects the client device to the destination. Such a negotiated optimal connection type may be a part of an optimal configuration as determined by, e.g., a routing engine as previously described.

At step510, the entity (e.g., client device) may then proceed to connect with the desired destination, via the optimal network designated by the received optimal configuration, and in some embodiments, using the optimal connection type designated by the optimal configuration (or prior to the generation of the optimal configuration).

FIG. 6shows an example of a customer connected to a computing resource service provider in accordance with at least one embodiment. The computing resource service provider602may provide a variety of services to the customer604and the customer604may communicate with the computing resource service provider602via an interface612, which may be a web services interface or any other type of customer interface. WhileFIG. 6shows one interface612for the services of the computing resource service provider602, each service may have its own interface and, generally, subsets of the services may have corresponding interfaces in addition to or as an alternative to the interface612.

The customer604may be an organization that may utilize one or more of the services provided by the computing resource service provider602to maintain and deliver information to its employees, which may be located in various geographical locations. Additionally, the customer604may be an individual that utilizes the services of the computing resource service provider602to deliver content to a working group located remotely. As shown inFIG. 6, the customer604may communicate with the computing resource service provider602through a network606, whereby the network606may be a communication network, such as the Internet, an intranet or an Internet service provider (ISP) network. Some communications from the customer604to the computing resource service provider602may cause the computing resource service provider602to operate in accordance with one or more embodiments described or a variation thereof.

The computing resource service provider602may provide various computing resource services to its customers. The services provided by the computing resource service provider602, in this example, include a virtual computer system service608and one or more other services610. It is noted that not all embodiments described include the services608-610described with reference toFIG. 6and additional services may be provided in addition to or as an alternative to services explicitly described. As described, each of the services608-610may include one or more web service interfaces that enable the customer604to submit appropriately configured API calls to the various services through web service requests. In addition, each of the services may include one or more service interfaces that enable the services to access each other.

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

The computing resource service provider602additionally maintains one or more other services610based at least in part on the needs of its customers604. For instance, the computing resource service provider602may maintain a database service for its customers604. A database service may be a collection of computing resources that collectively operate to run one or more databases for one or more customers604. The customer604may operate and manage a database from the database service by utilizing appropriately configured API calls. This, in turn, may allow a customer604to maintain and potentially scale the operations in the database.

FIG. 7illustrates a virtual computer system service in accordance with at least one embodiment. The virtual computer system service700, which may be physical hardware704, is used by a computing resource service provider for providing computation resources for customers. The physical hardware704may include physical hosts7061-m. The physical hosts7061-m, may be any device or equipment configured to execute instructions for performing data computation, manipulation, or storage tasks, such as a computer or a server. A physical host706may be equipped with any needed 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 that are compliant with any handshaking, communications or data transfer protocol. The physical hardware404may also include storage devices, such as storage disks and tapes, networking equipment and the like.

A virtualization layer708in the computing resources service provider enables the physical hardware704to be used to provide computational resources upon which one or more virtual hosts710may operate. The virtualization layer708may be any device, software, or firmware used for providing a virtual computing platform for the virtual hosts710. The virtual computing platform may include various virtual computer components, such as one or more virtual CPUs, virtual memory and the like. The virtual hosts710may be provided to the customers of the computing service resource provider and the customers may run an operating system or an application on the virtual host710. Further, the computing service resource provider may use one or more of its own virtual hosts710for executing its applications. Examples of the virtualization layer708include a hypervisor.

The virtualization layers708may provide a host activity report associated with the physical hardware704, one or more physical hosts706-mor the one or more virtual hosts710. The host activity report may include utilization, activity or operational information or statistics for the physical hardware704, physical hosts706-m, virtual hosts710or applications that are executed on the physical hosts706-mor the virtual hosts710. The information included in the host activity report may be gathered or compiled over an interval of time or taken at one or more snapshots in time.

The data store810can include several separate data tables, databases, data documents, dynamic data storage schemes and/or other data storage mechanisms and media for storing data relating to a particular aspect of the present disclosure. For example, the data store illustrated may include mechanisms for storing production data812and user information816, which can be used to serve content for the production side. The data store also is shown to include a mechanism for storing log data814, which can be used for reporting, analysis or other such purposes. It should be understood that there can be many other aspects that may need to be stored in the data store, such as page image information and access rights information, which can be stored in any of the above listed mechanisms as appropriate or in additional mechanisms in the data store810. The data store810is operable, through logic associated therewith, to receive instructions from the application server808and obtain, update or otherwise process data in response thereto. The application server808may provide static, dynamic or a combination of static and dynamic data in response to the received instructions. Dynamic data, such as data used in web logs (blogs), shopping applications, news services and other such applications may be generated by server-side structured languages as described herein or may be provided by a content management system (“CMS”) operating on, or under the control of, the application server. In one example, a user, through a device operated by the user, might submit a search request for a certain type of item. In this case, the data store might access the user information to verify the identity of the user and can access the catalog detail information to obtain information about items of that type. The information then can be returned to the user, such as in a results listing on a web page that the user is able to view via a browser on the user device802. 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 context of web pages, but may be more generally applicable to processing requests in general, where the requests are not necessarily requests for content.