Patent Description:
To facilitate increased utilization of data center resources, virtualization technologies allow a single physical computing device to host one or more instances of virtual machines that appear and operate as independent computing devices to users of a data center. With virtualization, the single physical computing device can create, maintain, delete, or otherwise manage virtual machines in a dynamic manner. In turn, users can request computer resources from a data center, including single computing devices or a configuration of networked computing devices, and be provided with varying numbers of virtual machine resources.

Virtualization technologies and data centers enable a variety of new techniques for providing network-based services. One such technique is "micro-services," in which desired functionality is not simply housed within a single device providing a service, but distributed among a variety of smaller, fine-grained services (each a "micro-service"). Micro-services may be independently developed, maintained, managed, and scaled, providing higher flexibility and resiliency to "macro-services" built using the micro-services. A difficulty that arises in the use of micro-services is the need for such services to securely intercommunicate. Often, different micro-services are implemented on different platforms or hosts, and subject to different security constraints. Moreover, different micro-services may scale independently of one another. Independent scaling may be beneficial to the micro-service itself, but cause difficulties in integrating different micro-services. For example, a first micro-service may scale to a point where its communications to another micro-service overwhelm the resources of that other micro-service. American patent application <CIT> describes a security management system for delivering an application i.e. computer software application, hosted by a private application provider system of an individual and a company over a network i.e. Internet, to a user device.

Generally described, aspects of the present disclosure relate to facilitating secure, scalable connections between network-based services (such as micro-services) by utilizing an intermediary connection pool provided by a connection management service. As disclosed herein, the connection pool may enable connections to the services on each "side" of the pool to be scaled independently, such that scaling of one service does not overwhelm another service. The connection pool may further provide for traversal of disparate networks hosting respective services, such that services can interact with one another via the pool as if they existed within a common network. Still further, the connection pool may provide a robust security model, by decoupling authentication between two services such that the services can authenticate with one another without requiring each service be provided with authentication information of the other service.

As an illustrative example, consider an instance in which a user stores information in a network-accessible database. The database may provide a limited number of connections, such that if attempts by other services to access the database exceed that number, no connection to the database is possible. Further, consider that the user may configure a second, highly-scalable service to access and utilize information from the database. For example, the second service may be implemented through an on-demand code execution system (sometimes referred to as a "serverless" system), which functions to execute user-defined code on an on-demand basis. If each execution of the user-defined code attempts to access the database, then instances of the second service can be expected to fail if executions of the user-defined code exceed the maximum number of connections provided by the database.

Connection pools provide a solution to this problem, by acting as a "middle man" between network services. For example, where a database has capacity for n connections, a connection pool may initiate n (or less than n) connections to the database. Others services can connect to the connection pool, and submit queries the pool for further submission to the database. In this manner, connections to the database can be expected not to exceed capacity of the database. Moreover, connections pools can provide a type of "oversubscription," such that more than n instances of a service can communicate with the database. For example, many database protocols are multi-phase, requiring a service to first open a connection to the database and later use the connection to interact with the database. Thus, a connection between a service and a database can limit other connections to the database, regardless of whether the connection is actively being used. A connection pool can address this issue, by reusing a given connection to a database for multiple accessing services, as required based on activity of the service. For example, each service may initiate a connection to the connection pool independently of the database. As queries are submitted to the connection pool, the pool may select an unused connection to the database, and submit the query to the database over that connection. So long as the number of active connections required by services does not exceed the number of possible connections to the database, the number of services connected to the pool (and thus, "connected" to the database from the point of view of the service) can scale nearly limitlessly.

One example of a logical flow of communications between network services and a database, as facilitated by a connection pool, is shown in <FIG>. Specifically, in <FIG>, a number of network services <NUM>-<NUM> are shown, each of which functions based on a connection <NUM> to a database <NUM>. A volume of connections <NUM> of each service <NUM>-<NUM> is shown as a relative width of the connections <NUM>, with the sum of the volumes of connections 60A-C exceeding a volume of connection 60D. Thus, while the database <NUM> may support a limited number of connections 60D, the connection pool <NUM> enables the connections 60A-C of the services <NUM>-<NUM> to exceed that limited number. This configuration is particularly desirable in instances where services <NUM>-<NUM> are configured to scale independently of the database <NUM>.

One option in creating a connection pool <NUM> would be to manually configure a connection pool <NUM> for each database <NUM> (or other resource-limited service). For example, where the services <NUM>-<NUM> and database <NUM> are implemented in a hosted computing environment (sometimes referred to as a "cloud" computing environment), a user of that environment may also implement a connection pool <NUM>, such as by provisioning a virtual machine instance with software providing the connection pool <NUM>. However, user creation of connection pool <NUM> imposes significant disadvantages. For example, hosted computing environments often provide isolated networks to various services. Illustratively, a hosted computing environment may enable a user to configure a "virtual private network environment" or "virtual private cloud" ("VPC") such that computing devices included within the network are able to communicate with one another as if they were connected via a physical local area network (LAN). The database <NUM> of <FIG> may be included within such a VPC. If the network services <NUM>-<NUM> are not located within the VPC, use of a connection pool <NUM> would require that a user "pierce" the VPC boundary, enabling either the services <NUM>-<NUM> or the connection pool <NUM> to access the VPC.

Moreover, a user-configured connection pool <NUM> may generally require that the user handle authentication between the services <NUM>-<NUM>, the connection pool <NUM>, and the database <NUM>. Illustratively, network services <NUM>-<NUM> may be required to store authentication information for the pool <NUM>, and the pool <NUM> may be required to store authentication information for the database <NUM>. This may lead to complex, duplicative, and potentially insecure storage of authentication information. For example, where a network service <NUM> is implemented as user-defined code executing on an on-demand code execution system, storing authentication information in the service <NUM> may require "hard-coding" a username and password for the service into the user-defined code, which is not generally considered a best practice for security. Moreover, this storage may be duplicative, as the services <NUM>-<NUM> themselves may already be authenticated in some manner. For example, where the services <NUM>-<NUM> are implemented within a hosted computing environment, the services <NUM>-<NUM> can be expected to be authenticated to the hosted computing environment by virtue of their being hosted in that environment. It would be desirable for the services <NUM>-<NUM> to utilize this existing authentication to authenticate to the pool <NUM>, rather than requiring manual storage of additional authentication information.

Still further, manual user configuration of a connection pool <NUM> may require reconfiguration of network services <NUM>-<NUM> that utilize the pool. For example, a user may be required to modify each service <NUM>-<NUM> to direct requests to the pool <NUM>, such as by modifying user-defined code for the service. Should changes to the pool <NUM> occur (such as scaling of the pool <NUM>, relocation of the pool <NUM>, etc.), the user may be required to modify each service <NUM>-<NUM> to reflect these changes.

The above-noted problems are addressed in embodiments of the present disclosure, at least partly by use of a connection manager service <NUM> configured to provide connection pools for hosted services (such as databases). The connection manager service <NUM> as disclosed herein can be tightly integrated with a hosted computing environment <NUM> hosting both source services accessing a connection pool and target services accessed by a connection pool. Due at least partly to this integration, the connection manager service <NUM> can address the problems described above, by enabling secure traversal of isolated networks of the environment, enabling reuse of existing authentication information for hosted services (thus negating a need to separately store authentication information at each service), and enabling programmatic reconfiguration of source services as modifications to the connection pool are made.

While embodiments of the present disclosure are discussed with respect to specific connection-limited services, such as database services, embodiments of the present disclosure can be used to provide connection pooling to any connection-limited network service. Moreover, techniques described herein may be applied to managing communications between a variety of network-based services, and in some cases may be applied outside of the context of connection pooling.

The foregoing aspects and many of the attendant advantages of this disclosure will become more readily appreciated as the same become better understood by reference to the following description, when taken in conjunction with the accompanying drawings.

<FIG> is a block diagram of an illustrative operating environment <NUM> in which client devices <NUM> may interact with a hosted computing environment <NUM> via a network <NUM>. By way of illustration, various example client devices <NUM> are shown in communication with the hosted computing environment <NUM>, including a desktop computer, laptop, and a mobile phone. In general, the client devices <NUM> can be any computing device such as a desktop, laptop or tablet computer, personal computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA/mobile phone, mobile phone, electronic book reader, set-top box, voice command device, camera, digital media player, and the like. The hosted computing environment <NUM> may provide the client devices <NUM> with one or more user interfaces, command-line interfaces (CLIs), application programing interfaces (APIs), and/or other programmatic interfaces for utilizing services provided by the hosted computing environment <NUM>, including virtual private environments <NUM>, an on-demand code execution system <NUM>, an authentication service <NUM>, and a secrets manager service <NUM>. Although one or more embodiments may be described herein as using a user interface, it should be appreciated that such embodiments may, additionally or alternatively, use any CLIs, APIs, or other programmatic interfaces. Moreover, while end users may operate client devices <NUM>, client devices <NUM> may also include non-end-user devices, such as servers, or other devices that access respective services provided by the hosted computing environment <NUM>.

The client devices <NUM> and hosted computing environment <NUM> may communicate via a network <NUM>, which may include any wired network, wireless network, or combination thereof. For example, the network <NUM> may be a personal area network, local area network, wide area network, over-the-air broadcast network (e.g., for radio or television), cable network, satellite network, cellular telephone network, or combination thereof. As a further example, the network <NUM> may be a publicly accessible network of linked networks, possibly operated by various distinct parties, such as the Internet. In some embodiments, the network <NUM> may be a private or semi-private network, such as a corporate or university intranet. The network <NUM> may include one or more wireless networks, such as a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, or any other type of wireless network. The network <NUM> can use protocols and components for communicating via the Internet or any of the other aforementioned types of networks. For example, the protocols used by the network <NUM> may include Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), Message Queue Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and the like. Protocols and components for communicating via the Internet or any of the other aforementioned types of communication networks are well known to those skilled in the art and, thus, are not described in more detail herein.

The hosted computing environment <NUM> is depicted in <FIG> as operating in a distributed computing environment including several computer systems that are interconnected using one or more computer networks (not shown in <FIG>), which systems operate to provide the virtual private environments <NUM>, on-demand code execution system <NUM>, authentication service <NUM>, connection manager service <NUM>, and secrets manager service <NUM>. Illustratively, the environment <NUM> includes a number of rapidly provisioned and released computing resources configured to provide the virtual private environments <NUM>, on-demand code execution system <NUM>, authentication service <NUM>, connection manager service <NUM>, and secrets manager service <NUM>. The hosted computing environment <NUM> may also be referred to as a "cloud computing environment. " Each of the virtual private environments <NUM>, on-demand code execution system <NUM>, authentication service <NUM>, connection manager service <NUM>, and secrets manager service <NUM> could also operate within a computing environment having a fewer or greater number of devices than are illustrated in <FIG>. Thus, the depiction of the virtual private environments <NUM>, on-demand code execution system <NUM>, authentication service <NUM>, connection manager service <NUM>, and secrets manager service <NUM> in <FIG> should be taken as illustrative and not limiting to the present disclosure. For example, the elements of the environment <NUM> or various constituents thereof could implement various Web services components and/or peer to peer network configurations to implement at least a portion of the processes described herein. In some instances, two or more of the virtual private environments <NUM>, on-demand code execution system <NUM>, authentication service <NUM>, connection manager service <NUM>, and secrets manager service <NUM> may be combined into a single service. Each of the virtual private environments <NUM>, on-demand code execution system <NUM>, authentication service <NUM>, connection manager service <NUM>, and secrets manager service <NUM> may be implemented directly in hardware or software executed by hardware devices and may, for instance, include one or more physical or virtual servers implemented on physical computer hardware configured to execute computer executable instructions for performing various features that will be described herein. The one or more servers may be geographically dispersed or geographically co-located, for instance, in one or more data centers.

Within the hosted computing environment, the virtual private environments <NUM> represent virtual networking environments that are logically isolated from one another, as well as from other networks. Each environment <NUM> may include one or more virtual computing devices (e.g., virtual machines or VMs) provided by the environment <NUM> and configured to operate on behalf of a user, such as to provide a service. For example, an environment <NUM> of <FIG> is depicted as included a database instance <NUM>, which instance <NUM> can be implemented by a specifically configured virtual computing device hosted within the environment <NUM> on behalf of a user.

While a database instance <NUM> is depicted in <FIG> as an example of a network-accessible service implemented by a device within a virtual private environment <NUM>, the environments <NUM> may enable a wide variety of services. For example, the hosted computing environment <NUM> may enable client devices <NUM> request, obtain, configure, and manage different types of service instances, each of which represents a computing device (or portion of a computing device) configured to provide a service on behalf of a user. Each service instance may, for example, represent a physical computing device, a virtual computing device, a software container within a computing device, or a thread executing on a computing device. Each service instance may provide a network-accessible service, such as a database service, web hosting service, video transcoding service, or any of a wide variety of known network-accessible services. In one embodiment, a service instance, such as the database instance <NUM>, provides a micro-service on behalf of a user. The hosted computing environment <NUM> can provide a variety of interfaces through which client devices <NUM> may configure service instances. For example, the hosted computing environment <NUM> may enable a client device <NUM> to specify a hardware configuration of each of their service instances (e.g., processing power, memory, etc.) and a software configuration (e.g., an operating system, applications, etc., which may illustratively be provided in the form of a device image provisioned to a disk drive accessible to an instance). The hosted computing environment <NUM> may further enable a client device <NUM> to specify how instances within environments <NUM> should be created, destroyed, or maintained. For example, a client device <NUM> may specify that an instance should be created or destroyed at certain times or according to certain conditions specified by a user. A variety of techniques for hosting service instances within hosted computing environments are known in the art and thus the details of operation of the environment <NUM> to provide and manage service instances will not be discussed herein.

The hosted computing environment <NUM> is illustratively configured to enable devices within each virtual private environment <NUM> to interact with one another as if they were connected via a physical LAN. For example, where each device within an environment <NUM> is a virtual computing device hosted by a physical computing device, the hosted computing environment <NUM> may use virtual networking techniques to encapsulate traffic from the virtual computing devices, and pass that traffic over a substrate physical network connecting the physical computing devices. On receiving traffic from a first virtual device in an environment <NUM> over the substrate physical network, a physical device may decapsulate the traffic (e.g., strip away encapsulating headers to return the packet to its original state prior to encapsulation) and pass the traffic to another virtual device in the environment <NUM>. Thus, devices in an environment <NUM> may communicate as if they connected within a physical LAN, even when geographically distant. A variety of techniques for implementing virtual networks between computing devices are known in the art and thus will not be described in detail herein.

In general, virtual private environments <NUM> are configured and operate on behalf of an individual user or set of users (e.g., an organization). In addition, the hosted computing environment <NUM> includes a number of additional services generally accessible by users. For example, the environment <NUM> includes an on-demand code execution system <NUM> enabling on-demand execution of user-defined code. The on-demand code execution system <NUM> may also be referred to as a serverless computing system. Embodiments for providing an on-demand code execution system <NUM> are provided, for example, in <CIT> (the "'<NUM> Patent"), the entirety of which is hereby incorporated by reference. In brief, the on-demand code execution system <NUM> can enable client devices <NUM> to submit executable code (e.g., source code) implementing desired functionality, which functionality is generally referred to herein as a "task. " The system <NUM> can further enable a client device <NUM> to define one or more triggers that result in execution of the code on the system <NUM>. For example, a client device <NUM> may request that each time a specific application programming interface (API) call is made, the code should be executed on the system <NUM>. When a trigger occurs, the system <NUM> can configure an execution environment <NUM> for the code, which may correspond to a virtual machine instance, a software container, or other logically isolated environment in which code can execute. The system <NUM> can then execute the code within the environment <NUM>, resulting in a task execution <NUM>. When the task execution <NUM> completes, the system <NUM> can remove the environment <NUM>, thus freeing computing resources for other task executions. The system <NUM> can thus enable a client device <NUM> to execute user-defined code on the system <NUM>, without requiring the user to handle aspects of execution such as acquiring a computing device, provisioning the device with the code, etc..

In accordance with embodiments of the present disclosure, the execution environment <NUM> of <FIG> are further depicted as including a pooling interface <NUM>. Generally described, the pooling interface <NUM> can represent code executing within an execution environment <NUM> and enabling a task execution <NUM> in that environment to interface with a connection manager service <NUM> (described in more detail below). In one embodiment, the pooling interface <NUM> corresponds to code executed within an environment <NUM> of a task execution <NUM>, which can be interfaced with in a manner similar to the service for which a connection pool is implemented (e.g., the database instance <NUM>). For example, where the database instance <NUM> is a MYSQL™ database accessed via a transmission control protocol (TCP) server, the pooling interface <NUM> can act as a proxy for the MYSQL TCP server, by implementing a corresponding TCP server that accepts transmissions in a manner similar or identical to that of the MYSQL TCP server. As will be described in detail below, on receiving a communication from a task execution <NUM>, the pooling interface <NUM> may encapsulate the transmission with additional information enabling appropriate handling of the transmission on within the environment <NUM>, and submit the encapsulated transmission to the connection manager service <NUM> for eventual delivery to the database instance <NUM>.

Use of a pooling interface <NUM> may illustratively simplify generation of tasks by client devices <NUM>, by simplifying code that must be authored by a user. For example, each task execution <NUM> may result in a corresponding pooling interface <NUM> being implemented by the system <NUM>, creating a one-to-one correspondence between task execution <NUM> and pooling interface <NUM>. This correspondence can enable each task execution <NUM> to locally reference a respective pooling interface <NUM> for that execution <NUM>, such that the execution <NUM> need to be programmed to rely on external services to interface with a database instance <NUM>. For example, code of a task may be configured to interact with a database at a "localhost" address, thus giving the appearance (from the point of view of a task execution <NUM>) that a database exists locally. As discussed below, the pooling interface <NUM> may also facilitate authentication to a connection pool for the instance <NUM>, further simplifying code for a task.

In one embodiment, code implementing the pooling interface <NUM> is provided by an operator of the on-demand code execution system <NUM>, and may be associated with a task by inclusion of a reference to such code within user-defined code for a task. In this manner, the pooling interface <NUM> may be considered a "dependency" for a task, such that each task execution <NUM> results in execution of a corresponding the pooling interface <NUM>. Implementation of task dependencies on an on-demand code execution system is discussed in more detail in <CIT>, entitled "DEPENDENCY HANDLING IN AN ON-DEMAND NETWORK CODE EXECUTION SYSTEM," the entirety of which is incorporated by reference herein.

While execution environments <NUM> are depicted as within the on-demand code execution system <NUM>, in some instances the system <NUM> may be configured to create and manage such environments <NUM> within a virtual private environment <NUM> (e.g., when executing a task owned by an owner of that environment <NUM>). The environment <NUM> in which a task is executed may differ from the environment <NUM> in which a network-accessible service accessed by the task is hosted.

To facilitate interaction with the hosted computing environment <NUM>, the environment <NUM> further includes an authentication service <NUM> enabling client devices <NUM> to authenticate to services within the environment <NUM>, such as to create virtual private environments <NUM> or devices within the environments <NUM>, to create or trigger tasks on the on-demand code execution system <NUM>, and the like. Authentication services <NUM> are known in the art, and thus operation of the service <NUM> will not be described in detail herein. However, in brief, a client device <NUM> may authenticate to the service <NUM> using a set of authentication information (e.g., a username and password), and the authentication service <NUM> may return other authentication information, such as an authentication token, to the client <NUM>. The authentication token may then be provided from the client device <NUM> to other devices to authenticate the client device <NUM> to the other devices (which devices may verify the token by, for example, passing the token to the service <NUM> for verification). Services implemented on behalf of a client device <NUM>, such as a database instance <NUM> or task execution <NUM> may be authenticated with the authentication service <NUM> on initiation within the environment <NUM>. For example, a task execution <NUM> occurring at the request of the client device <NUM> may be provided, on initialization, with an authentication token identifying the task execution <NUM> as executing on behalf of the client device <NUM>.

In accordance with embodiments of the present disclosure, the hosted computing environment <NUM> further includes a connection manager service <NUM> configured to provide connection pools to services on the environment <NUM>, such as a database service provided by the database instance <NUM>. Each connection pool is provided by one or more connection proxies <NUM>, each of which illustratively represents a computing device configured to receive network traffic on behalf of a network service (e.g., the database instance <NUM>) and to transmit the traffic to the network service over a fixed number of connections to the service. In one embodiment, connection proxies <NUM> may each be "single-tenanted" and configured to provide a connection pool to a single network service. In another embodiment, connection proxies may be "multi-tenanted" and configured to provide connection pools for multiple services. In some cases, single tenanted proxies <NUM> may be preferable for their increased security. For example, a proxy <NUM> providing a connection pool for the database instance <NUM> may be configured to interact with the instance <NUM> as if the proxy <NUM> were part of the virtual private environment <NUM>. Single-tenancy may help to ensure that only appropriate traffic is routed to that environment <NUM> (which may occur, for example, if a multi-tenanted proxy <NUM> transmitted traffic to the incorrect environment <NUM>, such as due to misconfiguration or malicious traffic).

To assist in routing traffic to the connection proxies <NUM>, the connection manager service <NUM> further includes a connection router <NUM> implementing a "routing layer" for the service <NUM>. The connection router <NUM> illustratively acts as a known endpoint for services to attempt to communicate with a connection proxy <NUM>. On receiving traffic relate to a specific connection pool, the connection router <NUM> can identify one or more proxies <NUM> providing the pool and pass the traffic to the proxies <NUM>. In some instances, the connection router <NUM> may authenticate traffic before passing the traffic to a proxy <NUM>.

Still further, the connection manager service <NUM> includes a configuration interface <NUM>. The interface <NUM> may provide a "control plane" for the connection manager service <NUM>, enabling client devices <NUM> to create, configure, and delete connection pools for services. For example, the interface <NUM> may enable a client device <NUM> to create a connection pool for the database instance <NUM>, and to specify to the connection manager service <NUM> configuration information for the pool, such as an identifier of the instance <NUM>, authentication information to be used to access the instance <NUM>, and a number of maximum connections to the instance <NUM>.

As shown in <FIG>, the hosted computing environment <NUM> further includes a secrets manager service <NUM>, configured to securely store confidential information, such as authentication information. Illustratively, the secrets manager service <NUM> may provide a centralized location for a user to store sensitive information, such that any changes to that information (e.g., rotating a password), auditing of information, and the like need only occur at a single location.

In accordance with embodiments of the present disclosure, the secrets manager service <NUM> may be configured by a client device <NUM> to store authentication information for a service associated with a connection pool, such as the database instance <NUM>. Connection proxies <NUM> can be configured to securely interact with the secrets manager service <NUM> to obtain the authentication information prior to connecting to the database instance <NUM>, and to append that authentication information to traffic received at a connection pool as appropriate to enable the traffic to interact with the instance <NUM>. Thus, use of connection proxies <NUM> and secretes manager service <NUM> can enable other services, such as task executions <NUM>, to access the database instance <NUM> without requiring the services to themselves store authentication information for the database instance <NUM>. In one embodiment, services, such as task executions <NUM>, authenticate to the connection manager service <NUM> based on authentication information passed to the service at a time of initialization. For example, when a task execution <NUM> is triggered on behalf of a client device <NUM>, an authentication token can be passed to the execution <NUM>, which the execution <NUM> can use to authenticate with the connection manager service <NUM>. The service <NUM>, in turn, can retrieve authentication information for the database instance <NUM> from the secrets manager service <NUM> and use that authentication information to enable communications between the task execution <NUM> and the database instance <NUM>. The task execution <NUM> therefore need not store the authentication information, increasing security of the database instance <NUM>.

<FIG> depicts a general architecture of a computing system (a connection manager server <NUM>) implementing the connection manager service <NUM> of FIG. <NUM> The general architecture of the server <NUM> depicted in <FIG> includes an arrangement of computer hardware and software that may be used to implement aspects of the present disclosure. The hardware may be implemented on physical electronic devices, as discussed in greater detail below. The server <NUM> may include many more (or fewer) elements than those shown in <FIG>. It is not necessary, however, that all of these generally conventional elements be shown in order to provide an enabling disclosure. Additionally, the general architecture illustrated in <FIG> may be used to implement one or more of the other components illustrated in <FIG>.

As illustrated, the server <NUM> includes a processing unit <NUM>, a network interface <NUM>, a computer readable medium drive <NUM>, and an input/output device interface <NUM>, all of which may communicate with one another by way of a communication bus. The network interface <NUM> may provide connectivity to one or more networks or computing systems. The processing unit <NUM> may thus receive information and instructions from other computing systems or services via the network <NUM>. The processing unit <NUM> may also communicate to and from primary memory <NUM> and/or secondary memory <NUM> and further provide output information for an optional display (not shown) via the input/output device interface <NUM>. The input/output device interface <NUM> may also accept input from an optional input device (not shown).

The primary memory <NUM> and/or secondary memory <NUM> may contain computer program instructions (grouped as units in some embodiments) that the processing unit <NUM> executes in order to implement one or more aspects of the present disclosure. These program instructions are shown in <FIG> as included within the primary memory <NUM>, but may additionally or alternatively be stored within secondary memory <NUM>. The primary memory <NUM> and secondary memory <NUM> correspond to one or more tiers of memory devices, including (but not limited to) RAM, 3D XPOINT memory, flash memory, magnetic storage, and the like. The primary memory <NUM> is assumed for the purposes of description to represent a main working memory of the server <NUM>, with a higher speed but lower total capacity than secondary memory <NUM>.

The primary memory <NUM> may store an operating system <NUM> that provides computer program instructions for use by the processing unit <NUM> in the general administration and operation of the server <NUM>. The memory <NUM> may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, the memory <NUM> includes a user interface unit <NUM> that generates user interfaces (and/or instructions therefor) for display upon a computing device, e.g., via a navigation and/or browsing interface such as a browser or application installed on the computing device.

In addition to and/or in combination with the user interface unit <NUM>, the memory <NUM> may include a configuration interface unit <NUM>, a connection proxy unit <NUM>, and a connection router unit <NUM>, each of which represents code executable to implement a configuration interface <NUM>, connection proxy <NUM>, and connection router <NUM> of <FIG>, respectively.

The server <NUM> of <FIG> is one illustrative configuration of such a device, of which others are possible. For example, while shown as a single device, a server <NUM> may in some embodiments be implemented as multiple physical host devices. In other embodiments, the server <NUM> may be implemented as one or more virtual devices executing on a physical computing device. While described in <FIG> as a server <NUM>, similar components may be utilized in some embodiments to implement other devices shown in the environment <NUM> of <FIG>.

With reference to <FIG>, illustrative interactions will be described for configuring the connection manager service <NUM> to provide a connection pool for a connection-limited service, such as the database instance <NUM>. The interactions begin at (<NUM>), where a client device <NUM> submits to the configuration manager <NUM> a request to creation a connection pool for the instance <NUM>. The request may include information pertaining to how the connection pool interacts with the instance <NUM>. For example, the request may include a maximum number of connections to the instance <NUM> and an identifier of a secret (e.g., as stored on the secrets manager service <NUM>) to use to access the instance <NUM>. In addition, the request may specify how other devices may access the connection pool. For example, the request may specify permissions for the connection pool, such as an account, identity, or "role" (also referred to herein as an "authentication role") with permissions to access the connection pool. In some instances, the request may further specify information relating to a format of communications flowing through the connection pool, such as a wire protocol used by the database instance <NUM>. Illustratively, knowledge of the wire protocol used by the database instance <NUM> may enable the connection manager service <NUM> to more accurately detect a state of a connection flowing through the pool (e.g., as active or idle). For example, specific wire protocols (such as commonly used database wire protocols) may include commands indicative of an active (or idle) connection, and thus the connection manager service <NUM> may be configured to inspect communications across the connection pool to determine whether a connection between a source device (e.g., a service requesting access to the connection pool) and the database instance <NUM> is active or idle.

On receiving the request, the connection manager service <NUM>, at (<NUM>), generates one or more connection proxies <NUM>, which operate to provide the connection pool. Illustratively, the connection manager <NUM> may generate a virtual computing instance and provision the instance with software enabling the instance to accept connections from source devices and pass queries (or other data) received from source devices to the database instance <NUM> in accordance with embodiments of the present disclosure. In one embodiment, the connection proxies <NUM> are generated by the service <NUM> such that they are enabled to communicate with the instance <NUM>. For example, the service <NUM> may include the proxies <NUM> in the virtual private environment <NUM> of the instance <NUM> or otherwise modify the environment <NUM> to enable communications from the proxies to reach the instance <NUM>.

At (<NUM>), the configuration interface <NUM> returns to the client device <NUM> an identifier for the connection pool, which identifier may thereafter be used by source services to access the database instance <NUM> via the connection pool. In one embodiment, the identifier is a globally or universally unique identifier (a "GUID" or "UUID"). In another embodiment, the identifier is unique to an account of the client device <NUM> on the hosted computing environment <NUM>, and a combination of an account identifier of the account and the identifier of the connection pool form a globally unique identifier.

While the client device <NUM> may thereafter configure any number of (appropriately authenticated) services to access the instance <NUM>, connection pooling may be particularly beneficial in rapidly scalable and/or transient source services, such as services provided by task executions <NUM> on the on-demand code execution system <NUM>. Thus, <FIG> depicts interactions enabling such a task execution <NUM> to access the database instance <NUM> through the connection pool provided by the service <NUM>.

Specifically, at (<NUM>), the client device <NUM> interacts with the on-demand code execution system <NUM> to configure a task (e.g., the code that when executed results in task execution <NUM>) with the identifier of the connection pool, as well as specifying an account, identifier, or role for the task that enables the task to connect to the connection pool. The identifier and role information may be stored as metadata associated with the task, rather than within user-defined code for the task. Thus, modification of a connection pool identifier and/or role may not require modification of the user-defined code. When executing a task, the system <NUM> may, in addition to executing the user-defined code as a task execution <NUM>, implement a pooling interface <NUM> within an environment <NUM> of the task, and configure the pooling interface <NUM> to include an identifier of the task. The pooling interface <NUM> may be provided with authentication information for the user-specified role, such that the interface <NUM> can provide the authentication information to the service <NUM> to authenticate itself. Thereafter, the pooling interface <NUM> may operate to receive communications from the task execution <NUM>, and to submit them to the service <NUM> in an authenticated manner that also identifies the connection pool.

For example, as will be described in more detail below with respect to <FIG>, the pooling interface <NUM> may represent a TCP server that receives network transmissions from the task execution <NUM> according to a wire protocol also used by the database instance <NUM>. On receiving such a transmission, the interface <NUM> may encapsulate the transmission with additional information, such as authentication information and an identifier of the connection pool, and transmit the encapsulated transmission to the connection service <NUM> (e.g., to a router <NUM>). The service <NUM> may utilize the additional information to authenticate the transmission, and to route the request to an appropriate connection proxy <NUM>. The proxy <NUM> may then decapsulate the transmission and pass the transmission to the database instance <NUM>. Thus, from the perspective of the user-defined code executing as the task execution <NUM>, database queries may be submitted to a local endpoint (the interface <NUM>), without requiring authentication and without apparent reliance on external services. This model therefore greatly simplifies creation of tasks, and enables high scalability of tasks on the system <NUM>.

With reference to <FIG>, illustrative interactions will be described securely initiating connections between a connection pool provided by the connection manager service <NUM> of <FIG> and a network-based service to which the pool provides access (e.g., the database instance <NUM>). As discussed above, a connection pool implemented by connection proxies <NUM> may facilitate interaction with the database instance <NUM> by enabling source devices to submit queries to the pool, which are then passed to the instance <NUM> via an idle connection between the pool and the instance <NUM>. Thus, the interactions of <FIG> can enable a connection proxy <NUM> to create a secure connection to the instance <NUM>. In one embodiment, the interactions of <FIG> occur at initialization of the connection pool. For example, where the pool is configured to provide n connections to the instance <NUM>, the proxies <NUM> providing the pool may establish those connections on initialization, such that subsequent attempts to transmit information to the instance <NUM> can utilize the pre-established connections. In another embodiment, the interactions of <FIG> occur on an as-needed basis. For example, the proxies <NUM> of a pool may establish a connection to the instance <NUM> when there is no existing idle connection to the instance <NUM>. In some embodiments, the interactions of <FIG> may occur both on initialization of a proxy <NUM> and on an as-needed basis. For example, a pool may be configured with both a minimum and maximum number of connections to a service, such as the database instance <NUM>. On initialization, a proxy <NUM> hosting a pool may undertake the interactions of <FIG> in order to establish the specified minimum number of connections for the pool. Thereafter, the proxy <NUM> may repeat the interactions of <FIG> on an as-needed basis, until the maximum number of connections is reached.

For the purposes of description, it will be assumed that the database instance <NUM>, like many network-accessible services, requires clients to authenticate with the instance <NUM> prior to establishing a connection. Rather than storing authentication information for the instance <NUM> at the service <NUM>, a user may elect to store such information in a secure, centralized location, like that provided by the secrets manager service <NUM>. Thus, prior to establishing a connection to the instance <NUM>, the proxies <NUM> providing a pool can interact with the secrets manager service <NUM> to obtain authentication information for the instance <NUM>.

Specifically, at (<NUM>), the proxies <NUM> request the authentication information from the secrets manager service <NUM>. At (<NUM>), the service <NUM> authenticates the requesting proxies <NUM>. In one embodiment, the service <NUM> may authenticate the proxies <NUM> based on an authentication token provided to the proxies <NUM> on initialization. For example, when creating a connection pool, a client device <NUM> may specify an identity or "role" to be assumed by devices providing the pool. On initialization, proxies <NUM> may be provided with authentication information (e.g., a token) identifying their use of that role, which information may be passed to the secrets manager service <NUM>. The service <NUM> may then authenticate the proxies <NUM> using the provided information (e.g., by passing the token to the authentication service <NUM> and requesting verification of the token). After authentication, the service <NUM>, at (<NUM>), returns to the proxies <NUM> the authentication information for the database instance <NUM> (e.g., a username and password).

Thereafter, at (<NUM>), the proxies <NUM> utilize the authentication information for the database instance <NUM> to request a connection to the instance. Illustratively, the connection may be a MySQL protocol connection. The database instance <NUM> then, at (<NUM>), returns the connection information to the proxies <NUM>, thus establishing a connection between the instance <NUM> and the one or more proxies <NUM> providing a connection pool for the instance <NUM>. The connection may illustratively be encrypted to secure communications between the proxies <NUM> and the instance <NUM>. For example, the connection may utilize transport layer security (TLS) (or its predecessor, secure sockets layer (SSL)). Moreover, the connection may logically occur within a virtualize network of the virtual private environment <NUM>, further securing the connection.

While shown as two interactions in <FIG>, various protocols may require additional interactions between the proxies <NUM> and the instance <NUM> to establish a connection. For example, particular wire protocols may define a multi-step "handshake" enabling the proxies <NUM> and instance <NUM> to exchange information for the connection. As will be described below, the connection between proxies <NUM> and the instance <NUM> may thereafter be used to pass queries from source services, such as task executions <NUM> to the instance <NUM>. Notably, because authentication between the proxies <NUM> and instance <NUM> occurs independently of source services, the proxies <NUM> can also be viewed as "authentication proxies" for source services, allowing those services to utilize other authentication information (such as information gained by virtue of creation of the service on the hosted computing environment <NUM>) to access the connection pool, while utilizing database-specific authentication information (e.g., from the secrets manager service <NUM>) to connect to the instance <NUM>.

<FIG> and <FIG> are flow diagrams depicting illustrative interactions for initiating a connection between the connection manager service <NUM> and a network-based service, such as the task execution <NUM> on the on-demand code execution system <NUM>, attempting to utilize a connection pool provided by the connection manager service <NUM>.

The interactions of <FIG> begin at (<NUM>), where the system <NUM> initiates the task execution <NUM>. As discussed above, the task execution <NUM> generally represents execution of user-defined code, and can be triggered based on a variety of criteria monitored by the system <NUM>. For example, the system <NUM> may initiate the task execution <NUM> based on a call received from a client device <NUM>. In addition to initiating the task execution <NUM>, the system <NUM> also initiates the pooling interface <NUM>. In one embodiment, the system <NUM> initiates the pooling interface <NUM> based on a reference to the interface <NUM> within code of the task. For example, the user-defined task code (or metadata for the task) may contain an "include" statement referring to code of the pooling interface <NUM>, thus causing the system <NUM> to execute the interface <NUM> along with the task. In one embodiment, the pooling interface <NUM> is executed in a common execution environment as the task, thus enabling the task to utilize a relative network identifier for the pooling interface <NUM>, such as the "localhost" identifier. In another embodiment, the pooling interface <NUM> is executed in a separate execution environment. For example, the pooling interface <NUM> may be implemented as a "sidecar VM instance" as disclosed in <CIT>, entitled "EXECUTION OF AUXILIARY FUNCTIONS IN AN ON-DEMAND NETWORK CODE EXECUTION SYSTEM," the entirety of which is hereby incorporated by reference. Specifically, as disclosed in the '<NUM> Application, a sidecar VM instance may be a separate virtual machine instance with a lifecycle ties to the execution environment for the task, such that a change in status of the execution environment (e.g., startup, shutdown, sleep, etc.) results in the same change of status of the sidecar VM.

At (<NUM>), the task execution <NUM> transmits to the pooling interface <NUM> a request to connect to the database <NUM>. In one embodiment, because the task execution <NUM> utilizes the pooling interface <NUM> rather than attempting to directly connect to the database <NUM>, the task execution <NUM> need not specifically identify the database <NUM> within the request. Moreover, because the connection manager service <NUM> is configured to authenticate calls to the database based on authentication information provided by the on-demand code execution system <NUM> in initiating the task execution <NUM>, the task execution <NUM> need not specify authentication information for the database within the request. As such, the format of the request is greatly simplified. For example, where the task execution <NUM> represents executing Python code (e.g., formatted according to the Python <NUM> standard) and the database <NUM> is a MySQL database, the code may include a statement such as 'mydatabase = mysql. connect(host="localhost", user="", passwd="")', where 'mydatabase' is a handle to the connection, "mysql. connector" is a MySQL-provided class containing functions related to MySQL databases, and the "connect" function is a function attempting to initiate a connection to a MySQL database, which function is passed a "host" variable identifying "localhost" as a location of the database, and "user" and "passwd" variables specifying no authentication information for the database. The request is illustratively transmitted via the TCP protocol to a TCP server implemented by the pooling interface <NUM>.

While embodiments of the present disclosure may remove a need to specify an identifier of a connection pool within the request of interaction (<NUM>), in some instances it may be beneficial to enable that identifier to be specified by a task execution <NUM>. For example, the on-demand code execution system <NUM> may enable a task to be associated with multiple network-accessible, connection-limited services, each accessible via a distinct connection pool. The system <NUM> may further provide a pooling interface <NUM> for each such pool. To facilitate distinguishing between interfaces <NUM> for the respective pools, the on-demand code execution system <NUM> may provide an API enabling resolution of an identifier of a given connection pool into access information for an interface <NUM> of the pool. For example, the system <NUM> may provide a function to a task such as "getPoolAddress" which takes as a parameter a pool identifier, and which when invoked returns a network address and port number of the interface <NUM> for that pool. Thus, a task may call the getPoolAddress function to obtain an address and port number for a given pool, and insert that address and port into the "host" field of a connect function (or similar database function) in order to request a database connection from the pooling interface <NUM>. Notably, connecting to a service in this embodiment may require only specification of an identifier of the service within code of the task, without requiring, for example, authentication information of the service or knowledge of a network location at which the service is implemented to be hard-coded within task code.

On receiving the request, at (<NUM>), the pooling interface <NUM> adds to the request additional information to be utilized by the connection manager service <NUM> in routing and processing the request. Specifically, the service <NUM> adds information specifying at least an identifier for the connection pool of the database instance <NUM> and authentication information to be used by the service <NUM> to authenticate the request. Both of the above-noted items of information may be supplied to the pooling interface <NUM> by the system <NUM>, such as on initialization of the interface <NUM>. For example, as discussed above, a client device <NUM> may configure a task with metadata specifying a role of the task and an identifier of a connection pool for the database instance <NUM>. Thus, on initiating the task execution <NUM>, the system <NUM> may pass the identifier and an authentication token (or other authentication information) to the interface <NUM>. In one embodiment, the pooling interface <NUM> adds the above-noted information by use of network encapsulation techniques, by encapsulating the original request (e.g., in the form of a TCP packet) with an additional header specifying the above-noted information. Use of encapsulation may beneficially reduce or eliminate the need to modify the packet as transmitted by the task execution <NUM>.

At (<NUM>), the pooling interface <NUM> forwards the encapsulated request to the connection router <NUM>. As noted above, the router <NUM> can generally function to authenticate transmissions from pooling interfaces <NUM>, and to route those transmission to a connection proxy <NUM> providing a connection pool for a service, such as the database instance <NUM>.

Accordingly, at (<NUM>), the connection router <NUM> requests from the authentication service <NUM> authentication of the pooling interface <NUM> based on the authentication information provided by the interface <NUM> within the request. For example, the connection router <NUM> may submit to the authentication service <NUM> a request to validate an authentication token provided by the pooling interface <NUM>. The authentication service <NUM>, at (<NUM>), evaluates the authentication information and returns an authentication result to the connection router <NUM>. Illustratively, the authentication service <NUM> may verify or determine a role associated with the authentication token, and notify the connection router <NUM> that the interface <NUM> is authenticated as that role.

In addition, the router <NUM>, at (<NUM>), verifies that the role to which the interface <NUM> has been authenticated has permissions to access the connection pool identified within the request (e.g., based on permissions for the pool specified by a client device <NUM>). Should authentication of verification of permissions fail, the router <NUM> can notify the interface <NUM> of the failure, which may for example generate an error within a log of the task execution <NUM>. However, for the purposes of description of <FIG>, it will be assumed that the authentication result indicates successful authentication of the pooling interface <NUM>, and that the router <NUM> verifies that the role of the interface <NUM> has appropriate permissions to access the connection pool for the database instance <NUM>.

The interactions of <FIG> are continued in <FIG>, where, at (<NUM>), the connection router <NUM> identifies a connection proxy <NUM> providing a connection pool for the database instance <NUM>. In one embodiment, the connection router <NUM> may maintain a mapping of identifiers to proxies <NUM>, such as in a data store of the connection manager service <NUM>. In cases where the pool is provided by multiple proxies <NUM>, the router may in some embodiments select between the proxies <NUM> based on load balancing criteria. In another embodiment, the connection router <NUM> may utilize the domain name system (DNS) to identify the connection proxy <NUM>. For example, each connection proxy <NUM> providing a given pool may register with a DNS server (not shown in <FIG>) to associate an address of the proxy <NUM> to a domain name corresponding to an identifier of the connection pool (e.g., "poolID. connectionmanagerservice. hostedenvironment. The router <NUM>, on receiving a request, may thus generate the domain name based on the identifier, and interact with a DNS server to resolve the domain name into a network address of a proxy <NUM> providing the identified connection pool. The DNS server may, instances where a pool is provided by multiple proxies <NUM>, conduct DNS-based load balancing, such as by resolving a domain name of the connection pool into an address of one or more proxies <NUM> selected based on their load.

On identifying a proxy <NUM> providing the identified connection pool, the router <NUM> initializes a connection with the proxy <NUM>, at (<NUM>). The proxy <NUM>, in turn, responses to the router <NUM> indicating a successful connection. The router <NUM> thus indicates a successful connection to the interface <NUM>, which indicates a successful connection to the task execution <NUM>. In one embodiment, each of the connections between the respective task execution <NUM>, interface <NUM>, router <NUM> and proxy <NUM> is an encrypted connection, such as a TLS-compliant TCP connection. In some instances, additional interactions, such as multi-phase handshake, may occur between these components during establishment of a connection.

While <FIG> and <FIG> are described with respect to specific mechanisms of augmenting a request for a network service at a pooling interface <NUM>, embodiments of the present disclosure may be utilized to augment service requests (e.g., requests for operations) with a variety of information. For example, in addition to authentication information, requests may be augmented with a variety of types of state information for a task execution <NUM>, which may vary during a task execution or across executions. Such state information may include, e.g., permissions information for a task execution (e.g., network resources to which the execution has access permissions), a current real (e.g., "wall clock") time as maintained at the execution, a running time of the execution, a network location of the execution, etc. In addition to an identifier of a connection pool, requests may additionally or alternatively be augmented with a variety of types of metadata, any of which may be specified by an owner of a task during configuration of the task on the system <NUM>. By augmenting requests with state information and/or metadata, the need to hard-code such information into code of the task is reduced or eliminated. Moreover, by utilizing a pooling interface <NUM> to augment requests, such as via encapsulation, the code of the task may remain compatible with existing libraries or code packages not necessarily intended for use in the system <NUM> (e.g., code or libraries that expect a particular wire protocol, which may be intended for use within a local network, use outside a connection manager service <NUM> or on-demand code execution system <NUM>, etc.). Thus, portability of code is increased relative to conventional techniques.

<FIG> is a flow diagram depicting illustrative interactions for securely communicating between a first and second network-based service (e.g., the system <NUM> hosting the task execution <NUM> and the database instance <NUM>) utilizing a connection pool provided by the connection manager service <NUM> of <FIG>. The interactions of <FIG> are assumed for purposes of discussion to occur subsequent to connections being established between the elements of <FIG> (e.g., the execution <NUM> and the interface <NUM>, the interface and the router <NUM>, etc.). Thus, at (<NUM>), the task execution <NUM> submits a database query to the pooling interface <NUM> via the connection. Submission of the query may correspond for example, to execution of a statement in code such as 'mydatabase. execute("SHOW TABLES")', where "mydatabase" is a handle to a MySQL database connection, "cursor()" is a function that returns a "MySQLCursor" class object that executes operations against a database, and "execute" is a function that instructs to execute the operation passed to that function (e.g., "SHOW TABLES," an SQL command to list tables in a database). While <FIG> is discussed with respect to queries, a task execution <NUM> may execute any number of operations against a database.

At (<NUM>), on receiving the request from the task execution <NUM>, the pooling interface <NUM> adds to the query an identifier of the connection pool for the database <NUM> and authentication information of the task execution <NUM>. As noted above, both of the above-noted items of information may be supplied to the pooling interface <NUM> by the system <NUM>, such as on initialization of the interface <NUM>. In the embodiment shown in <FIG>, the interface <NUM> adds the information by encapsulating the query (e.g., as received in the form of a TCP packet) with a new header specifying the information.

At (<NUM>), the interface <NUM> transmits the encapsulated query to the connection router <NUM>, which at (<NUM>) forwards the query to the proxy <NUM> identified as providing the connection pool identified within the request (e.g., identified according to the interactions of <FIG> and <FIG>, discussed above).

At (<NUM>), the proxy <NUM> validates the query, by confirming that the pool identified within the encapsulated query matches a pool provided by the proxy <NUM>. In some embodiments, validation at the proxy <NUM> may be omitted, as the router <NUM> is expected to pass queries only to a proxy <NUM> providing a connection pool identified within a request. However, additional verification at the proxy <NUM> may increase security of the service <NUM>. In instances where no validation occurs at the proxy <NUM>, the router <NUM> may decapsulate the query and transmit the query to the proxy <NUM> in decapsulated form.

At (<NUM>), the proxy <NUM> decapsulates the query (if necessary), and transmits the query to the instance <NUM> via an existing connection to the instance <NUM>. (In the case that no existing connection to the instance <NUM> is in an idle state, the proxy <NUM> may initiate a new connection to the database, such as by the interactions of <FIG>, discussed above. ) As noted above, by using an existing connection to the instance <NUM>, a set of connections to the instance <NUM> may be "oversubscribed," enabling more services (e.g., task executions <NUM>) to maintain (from their point of view) connections to the instance <NUM> than the instance <NUM> would be able to support without use of a connection pool.

At (<NUM>), the instance <NUM> executes the query to generate a response, which is returned to the proxy <NUM>. The proxy <NUM>, in turn, returns the response to the router <NUM> at (<NUM>), which returns the response to the interface <NUM> at (<NUM>), which returns the response to the execution, at (<NUM>). Thus, the execution <NUM> is enabled to submit operations to the instance <NUM> and obtain a result of that operation.

In one embodiment, the proxy <NUM> transmits the query to the instance <NUM> by utilizing a virtual network of the virtual private environment 120A, such that (from the point of view of the instance <NUM>) the query appears to originate within the environment 120A. As noted above, the task execution <NUM> may submit the query to the interface <NUM> within a common execution environment (e.g., at a "localhost" address). Thus, the appearance of a local client-database connection is provided to both the task execution <NUM> and database instance <NUM>, despite these services existing in disparate and potentially otherwise isolated networks.

The above-described interactions provide a number of benefits over prior approaches. For example, as discussed above, these interactions enable a connection manager service to provide multiple connection pools associated with multiple services, even when such services exist within isolated network environments (e.g., virtual private environments <NUM>), and to route requests to such pools based on identifiers of the pools. These interactions further enable simplification of tasks on an on-demand code execution system, by enabling use of a pooling interface <NUM> that can append additional information to requests received from task executions, such as authentication information and an identifier of the service, thus enabling the task execution to make requests to a service without specifying this information. These interactions further enable authentication of hosted services based on a pre-existing authentication scheme of the hosted service, by utilizing authentication information provided by a hosting system to authenticate the hosted service to another network service (which may utilize a different authentication scheme). <NUM>-<NUM> depict illustrative routines that may be implemented by elements of the environment <NUM> to provide these benefits.

Specifically, <FIG> depicts a connection pool routing routine <NUM>, which may be used to provide connection pools for connection-limited services, and to route requests to those pools based on an identifier of the pool. The routine <NUM> may be implemented, for example, by the connection manager service <NUM>.

The routine <NUM> begins at block <NUM>, where the connection manager service <NUM> implements connection pools for connection-limited services. Illustratively, each connection pool may be implemented by one or more connection proxies <NUM>. Where the connection-limited services exist within isolated environments, the proxies <NUM> can be configured to access the isolated environments.

At block <NUM>, the connection manager service <NUM> receives a request to transmit an operation to a target network service, the request including an identifier of the connection pool. Illustratively, the request may be received at a connection router <NUM> of the connection manager service <NUM>. In one embodiment, the request may include the identifier as a header of an encapsulated data packet, the encapsulated portion of which corresponds to a wire protocol of the target network service. For example, the encapsulated portion may conform to a particular database protocol when the target network service is a database service.

At block <NUM>, the connection manager service <NUM> selects a device providing a pool for the target network service, based on the identifier as included within the request. Illustratively, the connection manager service <NUM> may utilize DNS to map the identifier to a network address of a proxy <NUM> providing a pool for the service. In some instances, the connection manager service <NUM> may apply load balancing criteria to select from multiple proxies <NUM> providing a pool for the service.

At block <NUM>, the connection manager service <NUM> routes the request to the target service through the selected device. Illustratively, the connection manager service <NUM> may pass the request to the device through a first network connection, and the device may then pass the request to the service via a pre-existing network connection (or, of no idle pre-existing connection exists, may create an additional connection to the network service.

The routine <NUM> then ends at block <NUM>.

<FIG> depicts a serverless service connections routine <NUM>, which may be utilized to enable serverless code executions (e.g., task execution <NUM>) to connect to network-accessible services, without requiring information for the service (such as an identifier of the service, or metadata of the task, authentication information, or other state information of the task execution) to be hard-coded into user-defined code. The routine <NUM> may be implemented, for example, by the on-demand code execution system <NUM>.

The routine <NUM> begins at block <NUM>, where the on-demand code execution system <NUM> obtains a request to execute code on the serverless system. The request may be obtained, for example, based on an API call from a client device <NUM>, detection of a pre-defined trigger condition on the system <NUM>, etc..

At block <NUM>, the on-demand code execution system <NUM> initiates execution of the serverless code (e.g., a task execution). For example, the system <NUM> may identify or generate an execution environment, such as a virtual machine instance or software container, for the code, provision the environment with the code, and execute the code within the environment. In addition to the code, the on-demand code execution system <NUM> further executes additional code providing a service interface for a target network-accessible service. The service interface may for example correspond to a TCP server accessible to the serverless code via a relative identifier (e.g., the "localhost" network address). In one embodiment, the service interface is implemented in the same execution environment as the serverless code.

At block <NUM>, the on-demand code execution system <NUM> passes execution state information to the interface. The execution state information may illustratively be any information regarding the task execution as implemented on the on-demand code execution system <NUM>, such as authentication information of the execution (e.g., an authentication token indicating that the task was executed by the system <NUM> in an authorized state), permissions information indicating resources to which the execution has access permissions, a current time as maintained at the task execution, etc.. In some embodiments, additional data may be passed to the interface, such as service metadata for the serverless code. The service metadata may be defined by a user of the on-demand code execution system <NUM> when configuring serverless code, such that the metadata is modifiable independent of the user-defined code. Service metadata may include, for example, an identifier of a connection pool for a service.

At block <NUM>, on-demand code execution system <NUM> receives a request to access the service from the serverless code at the interface. For example, the system <NUM> may obtain a local TCP data packet addressed to the interface.

At block <NUM>, the on-demand code execution system <NUM>, via operation of the interface, augments the request with state information, thus enabling a downstream component to obtain the state information without requiring the task execution to be hard-coded to provide such information. In one embodiment, augmenting the request may include encapsulating the request with a header including the state information. Use of encapsulation may be beneficial, for example, in allowing a wire protocol format of the initial request to be maintained. For example, encapsulation of the request by an interface may reduce or eliminate the need for use of custom libraries or functions within a task execution, instead enabling the task to utilize standard libraries or functions (e.g., those intended to access a local service or a service not associated with a connection manager service <NUM>).

At block <NUM>, the on-demand code execution system <NUM> routes the augmented request to the service using the interface. Illustratively, the interface may transmit the request to a router configured to route the request based on state information, such as by first authenticating the request based on an authentication token with which the request has been augmented at the interface.

<FIG> depicts a routine <NUM> providing authentication proxying for hosted service instances, which may be utilized to enable hosted service instances to utilize one set of authentication information (e.g., providing by a hosting system for the hosted service) to authenticate to other services utilizing other authentication information (e.g., a database service using a username and password), without requiring that the hosted service directly store the other authentication information. The routine <NUM> may be implemented, for example, by the connection manager service <NUM>.

The routine <NUM> begins at <NUM>, where the service <NUM> obtains a request for a hosted service instance to access a target service. The hosted service instance may correspond, for example, to a task execution on the on-demand code execution system <NUM>.

At block <NUM>, the service <NUM> obtains authentication information for the hosted service instance provided by a hosting system for the hosted service instance. For example, where the hosted service instance is a task execution on the on-demand code execution system <NUM>, the service <NUM> may obtain authentication information for the task execution from the system <NUM>. In some instances, the service <NUM> may query the hosting system for authentication information. In another embodiment, the authentication information may be included within the request (e.g., as a field of a header of the request).

At block <NUM>, the service <NUM> verifies the authentication information for the hosted service instance. Illustratively, the service <NUM> may transmit the authentication information to an authentication service that authored the information, in order to verify its authenticity. In addition, the service <NUM> may obtain permissions for the target network service, and verify that the authentication information complies with such permissions (e.g., that the authentication information corresponds to a role that has permissions to access the service).

At block <NUM>, the service <NUM> obtains authentication information for the target service. The authentication information is illustratively stored separately from the hosted service instance and independently modifiable. For example, the authentication information for the target service may be stored within a secrets manager service.

At block <NUM>, the service <NUM> submits the request to the target service using the authentication information for the target service. For example, the service <NUM> may initiate a connection to the target service using the authentication information for the target service, and pass the request to the target service over that connection. In this manner, a hosted service instance may pass requests to a target service without requiring that the hosted service instance itself store authentication information for the target service.

While illustrative routines are discussed above, various modifications or additions to these routines are possible and contemplated herein. For example, the routines of <FIG> may be implemented in combination to provide the benefits described herein, as depicted in the interactions of <FIG>, above. Thus, the interactions of <FIG> are intended to be illustrative and not exhaustive in nature.

All of the methods and processes described above may be embodied in, and fully automated via, software code modules executed by one or more computers or processors. The code modules may be stored in any type of non-transitory computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in specialized computer hardware.

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

Disjunctive language such as the phrase "at least one of X, Y or Z," unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y or Z, or any combination thereof (e.g., X, Y and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y or at least one of Z to each be present.

Unless otherwise explicitly stated, articles such as 'a' or 'an' should generally be interpreted to include one or more described items. Accordingly, phrases such as "a device configured to" are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, "a processor configured to carry out recitations A, B and C" can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

Claim 1:
A computer-implemented method comprising:
receiving a transmission of an operation to a target network service (<NUM>) of a plurality of connection-limited, network-accessible services, the transmission including an identifier of a connection pool, from a plurality of connection pools, corresponding to the target network service (<NUM>), wherein each connection pool of the plurality of connection pools provides a pool of connections to a corresponding connection-limited, network-accessible service of the plurality of connection-limited, network-accessible services;
identifying a computing device (<NUM>) providing the connection pool based at least in part on the identifier of the connection pool; and
routing the transmission to the computing device (<NUM>) providing the connection pool;
wherein the computing device (<NUM>) providing the connection pool obtains the transmission,
interacts with a secrets manager service (<NUM>) storing authentication information for the target network service (<NUM>),
obtains, from the secrets manager service (<NUM>), the authentication information for the target network service (<NUM>) prior to connecting to the target network service (<NUM>),
appends the authentication information to the transmission, and
forwards the transmission to the target network service (<NUM>) through an existing connection to the target network service (<NUM>).