Patent Publication Number: US-2021185114-A1

Title: Origin server cloaking using virtual private cloud network environments

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 15/419,880, entitled “ORIGIN SERVER CLOAKING USING VIRTUAL PRIVATE CLOUD NETWORK ENVIRONMENTS” and filed on Jan. 30, 2017, which is hereby incorporated by reference herein in its entirety. 
    
    
     BACKGROUND 
     Generally described, computing devices utilize a communication network, or a series of communication networks, to exchange data. Companies and organizations operate computer networks that interconnect a number of computing devices to support operations or provide services to third parties. The computing systems can be located in a single geographic location or located in multiple, distinct geographic locations (e.g., interconnected via private or public communication networks). Specifically, data centers or data processing centers, herein generally referred to as “data centers,” may include a number of interconnected computing systems to provide computing resources to users of the data center. The data centers may be private data centers operated on behalf of an organization or public data centers operated on behalf, or for the benefit of, the general public. 
     To facilitate increased utilization of data center resources, virtualization technologies may 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 matter. 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. 
     Generally, physical networks include a number of hardware devices that receive packets from a source network component and forward the packets to designated recipient network components. In physical networks, packet routing hardware devices are typically referred to as routers, which are implemented on stand-alone computing devices connected to a physical network. With the advent of virtualization technologies, networks and routing for those networks can now be simulated using commodity computing devices rather than actual routers. 
     Virtualized networks provide advantages over traditional networks, in that the can be rapidly created, configured, or destroyed without reconfiguring underlying physical hardware devices. However, they can also add a layer of complexity over traditional systems. For example, virtualized systems may not have direct physical addresses, as traditional systems would, making transmission of communications between virtualized systems more difficult. Moreover, at least some virtualized systems may be configured to be private, such that public network addressing schemes, which otherwise serve to enable communications between virtualized systems, are not directly usable to communicate between virtualized systems. Thus, existing functionalities and practices may not be directly usable on virtualized systems. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       Throughout the drawings, reference numbers may be re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate example embodiments described herein and are not intended to limit the scope of the disclosure. 
         FIG. 1  is a block diagram of an illustrative operating environment in which one or more origin servers are implemented in physical computing devices or in virtual machine instances hosted by physical computing devices within a third party VPC. 
         FIG. 2  is a block diagram of the operating environment of  FIG. 1  illustrating the operations performed by the components of the operating environment to request content, according to one embodiment. 
         FIG. 3  is a block diagram of the operating environment of  FIG. 1  illustrating the operations performed by the components of the operating environment to establish a secure connection between a POP and the managed VPC, according to one embodiment. 
         FIG. 4  is a flow diagram depicting a file retrieval routine illustratively implemented by a managed VPC, according to one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     Generally described, the present disclosure relates to providing an origin server within a virtual private cloud network environment that can service a content delivery network accessible via a public network, without requiring the origin server or the virtual private cloud network to be publically or externally addressable. The term “virtual private cloud network environment” (sometimes shortened to “virtual private cloud” or simply “VPC”) generally refers to a virtualized network environment, in which a collection of computing devices is enabled, for example, by a substrate network, to communicate, including for example as if the collection of computing devices existed within a local area network (LAN) environment. Accordingly, the devices within a VPC may often share a common subnet, and (from the perspective of the devices) directly communicate with one another without the use of complex routing protocols. However, unlike traditional LANs, the devices within a VPC need not share a direct physical interconnection. Instead, the devices may be located in geographically diverse regions, and in some instances may themselves be virtual devices (e.g., virtual machines). A substrate (e.g., physical) network may encapsulate or otherwise alter communications from devices associated with the VPC to create the illusion, from the point of view of devices within the VPC, that a LAN environment exists. VPCs provide many advantages over traditional LANs, in that the configuration of computing devices can be changed dynamically, via software, without changing a physical configuration of devices. Moreover, VPCs maintain many benefits of traditional LANs in that communications between the computing devices are relatively simple and secure. A single data center may include sufficient hardware to implement multiple VPCs, each of which may be isolated from each other (e.g., each VPC may include a separate substrate network). Additional details of the components included in VPCs and the techniques used to implement VPCs are described in U.S. patent application Ser. No. 15/245,089, entitled “EXTERNAL HEALTH CHECKING OF VIRTUAL PRIVATE CLOUD NETWORK ENVIRONMENTS” and filed on Aug. 23, 2016, which is hereby incorporated herein by reference in its entirety. 
     Origin servers may store primary versions of content for distribution to various user devices. For example, origin servers typically use publicly routable addresses (e.g., Internet protocol (IP) addresses) to provide content to content delivery networks (CDNs), which then distribute such content to various user devices. Because the origin servers are publicly accessible, the content stored therein is exposed and can be subject to unauthorized access. One way to mitigate this danger may be to set up a whitelist of known CDN IP addresses such that only those IP addresses included in the whitelist, and therefore only certain CDNs, can access the origin server. However, this is not a complete solution. If the whitelist is out of sync (e.g., because a CDN changed IP addresses, a new CDN has been introduced into service, etc.), then some CDNs may not be able to access the origin server. A user device may then receive an error when requesting content through certain CDNs. An administrator may have to manually reconfigure the origin server and periodically update the whitelist to allow all desired CDNs to access the origin server. In fact, even with a whitelist, an origin server may still be vulnerable to direct volumetric attacks. For example, a high volume distributed denial of service (DDoS) attack may still result in broad throttling of all traffic directed to and originating from the origin server. 
     An origin server could be implemented by a computing device within a VPC (e.g., a physical computing device, a virtual computing device, etc.) such that the origin server is accessible by devices within the VPC that share a common subnet. However, like traditional LANs, communications into a VPC from an external source (e.g., a publically addressed server) generally required the VPC to be at least in part publically addressable, and to have a computing device open to communications from a public space. This situation can be disadvantageous in that it can reduce the security of the VPC. 
     To address these issues, the present disclosure provides an origin server that is implemented within one or more devices within a VPC. The VPC may be managed by a third party, such as the entity that operates the origin server and/or owns the primary content distributed by the origin server. However, instead of communicating with various CDNs over a public network, the third party VPC may instead communicate with a managed VPC via a private network. As an example, the managed VPC may be owned and/or operated by the same entity as the entity that owns and/or operates one or more CDNs. Thus, no gateway, network address translation (NAT), or other such devices may be needed for the third party VPC and the managed VPC to communicate. Rather, a VPC identifier of the managed VPC and a VPC identifier of the third party VPC are used to pair the two VPCs. Once paired, a private route is then set up in the third party VPC that points to the private address space of the managed VPC. When a packet is generated by the third party VPC for transmission along the private route to the managed VPC, the third party VPC may encapsulate the packet with a header that points to the location of the managed VPC. Similarly, when a packet is generated by the managed VPC for transmission along the private route to the third party VPC, the managed VPC may encapsulate the packet with a header that points to the location of the third party VPC. Once the encapsulated packet is received, the managed VPC or the third party VPC may decapsulate the encapsulated packet and extract data (e.g., primary content stored by the origin server, a request for a file, etc.). Thus, to the managed VPC, the packet appears as if it originated from the third party VPC&#39;s private address space, and to the third party VPC, the packet appears as if it originated from the managed VPC&#39;s private address space. Optionally, the managed VPC and the third party VPC may communicate over a public network. The origin server may still not be publicly addressable, however, because the encapsulation techniques described herein may ensure that malicious or unauthorized systems cannot spoof, for example, a request for a file in an attempt to access the origin server. 
     The managed VPC can communicate with one or more CDNs to provide requested content retrieved from the third party VPC. Because the managed VPC communicates with one or more CDNs, the managed VPC is publicly addressable. However, the connection between a CDN and the managed VPC may be encrypted and pass through private infrastructure (e.g., routers, gateways, and/or other routing systems that are owned and/or operated by an entity that owns and/or operates the CDN and the managed VPC). Thus, the managed VPC may benefit from a higher level of protection than typical publically addressable systems. 
     As an illustrative example, a user device may request a file, such as a resource (e.g., a script, an image, video, audio, etc.), webpage content, etc. located at a URL, from a CDN. The CDN may include a cache in which certain files are stored (e.g., the most-frequently requested files). The CDN may query the cache to determine whether the requested file is stored therein. If the requested file is present, the CDN can return the file to satisfy the request. Otherwise, the CDN can transmit a request to the managed VPC for the file. The managed VPC may optionally include a cache in which certain files are stored. If the managed VPC includes a cache, the cache in the managed VPC may have a larger capacity than the cache in the CDN and may be referred to herein as a “mid-tier cache.” Thus, the mid-tier cache may serve as a potential intermediary source of content for CDNs, such that when a cache miss occurs at the CDN, the requested content can be retrieved from a mid-tier cache rather than the origin server that stores the primary copy of the content. If the managed VPC includes a mid-tier cache, the managed VPC can query the mid-tier cache to determine whether the requested file is stored therein. If the requested file is present, the managed VPC can transmit the requested file to the CDN via the private infrastructure and the CDN can forward the file to the user device. Otherwise, if the requested file is not present in the mid-tier cache or if the managed VPC does not include a mid-tier cache, the managed VPC can transmit a request for the file to the third party VPC via the private route established between the managed VPC and the third party VPC. The managed VPC (e.g., a communication manager in the managed VPC) can encapsulate the request with a header that points to a location of the third party VPC such that the encapsulated request is routed via the private route to the third party VPC. The third party VPC can decapsulate the encapsulated request, an origin server in the third party VPC can retrieve the file from a content data store in the third party VPC, and the origin server can generate a packet for transmitting the file to the managed VPC. Before transmission occurs, the third party VPC (e.g., a communication manager in the third party VPC) may encapsulate the packet with a header that points to a location of the managed VPC such that the encapsulated packet is routed via the private route to the managed VPC. The managed VPC receives the encapsulated packet, decapsulates the encapsulated packet, and extracts the file in the packet for transmission to the CDN. The CDN can then distribute the file to the user device to complete the request. 
     As will be appreciated by one of skill in the art in light of the present disclosure, the embodiments disclosed herein improves the ability of computing systems, such as those implementing virtual private cloud network environments, to service user requests for content without comprising the security of the origin server that manages the primary copy of the content. Specifically, aspects of the present disclosure enable origin servers to be included within a virtual private cloud network environment such that the origin servers are not publically addressable while still allowing the origin servers to provide content to CDNs for distribution to user devices. Moreover, the presently disclosed embodiments address technical problems inherent within computing systems; specifically, the expected exhaustion of IPv4 addresses. Because of IPv4 address exhaustion, numerous systems are transitioning to the use of IPv6 addresses. This transition can be burdensome and costly, as entire systems may receive new public addresses and may need to be reconfigured so that they can continue to communicate with one another using the new addresses. Because the origin server is embedded within a virtual private cloud network environment such that the origin server is not publicly addressable, no IPv4 or IPv6 address needs to be assigned to the origin server or VPC and therefore future version updates to IP will not affect the implementation or operation of the origin servers described herein. Thus, the present disclosure represents an improvement on existing virtual network systems and computing systems in general. 
     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 detailed description, when taken in conjunction with the accompanying drawings. 
     Example Origin Server Cloaking Environment 
       FIG. 1  is a block diagram of an illustrative operating environment  100  in which one or more origin servers  142  are implemented in physical computing devices or in virtual machine instances hosted by physical computing devices within a third party VPC  140 . The operating environment  100  further includes one or more points of presence (POPs)  120  and a managed VPC  130 . 
     As used herein, a POP is intended to refer to any collection of related computing devices utilized to implement functionality on behalf of one or many providers. POPs are generally associated with a specific geographic location in which the computing devices implementing the POP are located, or with a region serviced by the POP. For example, a data center or a collection of computing devices within a data center may form a POP. In some instances, the POPs may implement one or more services, such as CDN services, data storage services, data processing services, etc. For the purposes of the present disclosure, the POPs  120  implement CDN service(s)  122 . The CDN service(s)  122  can include one or more servers  124  communicatively coupled to a cache data store  126 . The server  124  and cache data store  126  may operate in conjunction to implement functionalities of the CDN service(s)  122 . For example, the server  124  and cache data store  126  may operate to cache distributed content (e.g., as provided by the one or more origin servers  142 ) and respond to requests from end users (e.g., via user devices  102 ) for such cached content. 
     The managed VPC  130  and the third party VPC  140  may each represent private virtualized networks implemented by a substrate network. The managed VPC  130  includes, for example, one or more servers  132 , an optional cache data store  134 , and a communication manager  136 . The servers  132  may generally provide any network-accessible functionality, such as web page hosting or database hosting, among many others known in the art. For example, the servers  132  and cache data store  134  may operate to cache distributed content (e.g., as provided by the one or more origin servers  142 ) and respond to requests from CDNs (e.g., POPs  120 ) for such cached content. The cache data store  134  may have a larger capacity than the cache data store  126  and therefore may be a mid-tier cache. Thus, the cache data store  134  may serve as a potential intermediary source of content for POPs  120 , such that when a cache miss occurs at a POP  120 , the requested content can be retrieved from the cache data store  134  rather than the origin server  142  that stores the primary copy of the content. In situations in which the managed VPC  130  does not include a cache data store  134 , the servers  132  may operate to respond to requests from CDN service(s)  122  for content by forwarding such requests to the third party VPC  140 . Thus, the servers  132  may not parse requests received from the CDN service(s)  122  and may merely encapsulate the request (e.g., reroute the request) for transmission to the third party VPC  140 , as described in greater detail below. 
     The communication manager  136  can configure, authorize, and/or otherwise manage communications internal to the managed VPC  130  and/or between the managed VPC  130  and other computing systems, such as the third party VPC  140 . For example, the communication manager  136  can provide logical networking functionality for one or more virtual computer networks that are provided within the managed VPC  130 . The communication manager  136  may configure communications between computing nodes in the managed VPC  130  so as to overlay a virtual network over one or more intermediate physical networks that are used as a substrate network. As an illustrative example, the communication manager  136  can manage communications between the servers  132  and the cache data store  134 , if present. As another example, the communication manager  136  can encapsulate any packets generated by the one or more servers  132  for transmissions external to the managed VPC  130  and decapsulate encapsulated packets received from VPCs external to the managed VPC  130 . As an illustrative example, the communication manager  136  can encapsulate requests for content generated by the one or more servers  132  for transmission to the third party VPC  140 . Once the request is encapsulated, the communication manager  136  can transmit the encapsulated request over the private network  115  (or the public network  110 ) to the third party VPC  140 . The communication manager  136  can also receive encapsulated packets from the third party VPC  140 , where the encapsulated packets include requested file(s). The communication manager  136  can decapsulate the encapsulated packets and forward the contents to the one or more servers  132 . In other embodiments, not shown, the communication manager  136  is located in the CDN service(s)  122  and performs the same operations described herein. 
     The third party VPC  140  includes, for example, the one or more origin servers  142 , a content data store  144 , and a communication manager  146 . The origin servers  142  may provide one or more sets of content (“distributions”) to a CDN (e.g., CDN service(s)  122 ) for subsequent transmission to user devices  102 . For example, origin servers  142  may include servers hosting web sites, streaming audio, video, or multimedia services, data analytics services, or other network-accessible services. The content data store  144  may store primary versions of content within various distributions. The one or more origin servers  142  may retrieve a primary copy of content that is stored in the content data store  144  for distribution to the user devices  102  via the POP  120  and the managed VPC  130  at the request of the managed VPC  130  (e.g., when a cache miss occurs at the managed VPC  130 ). 
     The communication manager  146  can configure, authorize, and/or otherwise manage communications internal to the third party VPC  140  and/or between the third party VPC  140  and other computing systems, such as the managed VPC  130 . For example, the communication manager  146  can provide logical networking functionality for one or more virtual computer networks that are provided within the third party VPC  140 . The communication manager  146  may configure communications between computing nodes in the third party VPC  140  so as to overlay a virtual network over one or more intermediate physical networks that are used as a substrate network. As an illustrative example, the communication manager  146  can manage communications between the origin servers  142  and the content data store  144 . As another example, the communication manager  146  can encapsulate any packets generated by the one or more origin servers  142  for transmissions external to the third party VPC  140  and decapsulate encapsulated packets received from VPCs external to the third party VPC  140 . As an illustrative example, the communication manager  146  can encapsulate packets that include requested files generated by the one or more origin servers  142  for transmission to the managed VPC  130 . Once the packet is encapsulated, the communication manager  146  can transmit the encapsulated packet over the private network  115  (or the public network  110 ) to the managed VPC  130 . The communication manager  146  can also receive encapsulated requests for content from the managed VPC  130 . The communication manager  146  can decapsulate the encapsulated requests and forward the requests to the one or more origin servers  142 . 
     The servers  132  and/or the origin servers  142  may be implemented, for example, in one or more physical computing devices of a substrate network and/or as virtual machines hosted by physical computing devices of a substrate network. Furthermore, the cache data store  134  and/or the content data store  144  may be implemented, for example, in one or more physical computing devices of a substrate network and/or as virtual machines hosted by physical computing devices of a substrate network. The communication manager  136  may be implemented, for example, in one or more physical computing devices or in one or more virtual machines hosted by physical computing devices that are in communication with the servers  132  via the substrate network. Likewise, the communication manager  146  may be implemented, for example, in one or more physical computing devices or in one or more virtual machines hosted by physical computing devices that are in communication with the origin servers  142  via the substrate network. 
     The third party VPC  140  may be managed by a third party, such as the entity that operates the origin server  142  and/or owns the primary content distributed by the origin server  142 . As illustrated in  FIG. 1 , instead of communicating with a POP  120  over a public network  110 , the third party VPC  140  may instead communicate with the managed VPC  130  via a private network  115 . In other embodiments, not shown, the third party VPC  140  communicates with the managed VPC  130  via the public network  110 , but the origin servers  142  implemented by the third party VPC  140  are still not publicly addressable or accessible. The public network  110  can be a publicly accessible network of networks, such as the Internet, and the private network  115  can be an organization&#39;s network that is wholly or partially inaccessible from computing systems external to the private network  115 . Thus, because the third party VPC  140  and the managed VPC  130  communicate via the private network  115 , no gateway, network address translation (NAT), or other such devices may be needed for the third party VPC  140  and the managed VPC  130  to communicate. 
     To establish the private network  115  connection, the managed VPC  130  and the third party VPC  140  are paired using a VPC identifier of the managed VPC  130  and a VPC identifier of the third party VPC  140 . For example, a network-based portal may allow an entity that operates the third party VPC  140  to manage the third party VPC  140 . The network-based portal may offer an option to the entity to cloak an origin server (e.g., reconfigure the network routing to an origin server such that the origin server is no longer publicly addressable). Upon a selection of the option to cloak an origin server, a communication manager (not shown) or other such physical computing device can identify the VPC identifier of a managed VPC that resides in the same geographic location as the third party VPC  140  (e.g., the managed VPC  130  in this case) and create a private route between the third party VPC  140  and the managed VPC that resides in the same geographic location as the third party VPC  140  using the respective VPC identifiers. Alternatively, upon a selection of the option to cloak an origin server, a communication manager (e.g., communication manager  136 , communication manager  146 , etc.) or other such physical computing device can identify the VPC identifier of a managed VPC that resides in a geographic location selected or authorized by the entity to serve as a region in which the origin server  142  can communicate. The communication manager or other such physical computing device can then create a private route between the third party VPC  140  and the managed VPC using the respective VPC identifiers. In an embodiment, the communication manager or other such physical computing device is located within the same data center as the third party VPC  140  (e.g., the communication manager  146  is located within the third party VPC  140 ). 
     The VPC identifiers of the managed VPC  130  and the third party VPC  140  may be associated with their respective private address space, and thus the private route may point from the private address space of the third party VPC  140  to the private address space of the managed VPC  130 . When a packet is generated by the origin server  142  in the third party VPC  140  for transmission along the private route to the server  132  in the managed VPC  130 , the third party VPC  140  (e.g., the communication manager  146 ) may encapsulate the packet with a header that points to the location of the managed VPC  130 . For example, the private route may be represented with a virtual IP address and the third party VPC  140  may store information that maps the virtual IP address to a location and/or a VPC identifier of the managed VPC  130  (e.g., where the VPC identifier corresponds with a location of the managed VPC  130 ). The communication manager  146  can receive the generated packet from the origin server  142 , encapsulate the packet with the header that points to the location of the managed VPC  130 , and forward the encapsulated packet to the managed VPC  130  (e.g., the communication manager  136 ). Once the encapsulated packet is received by the communication manager  136 , the communication manager  136  may decapsulate the encapsulated packet, extract data from the data portion of the packet (e.g., a file retrieved from the content data store  144 ), and forward the extracted data (or the decapsulated packet) to the server  132 . Thus, to the server  132 , the packet appears as if it originated from the private address space of the third party VPC  140 . The server  132  and the communication manager  136  may follow a similar process as the origin server  142  and the communication manager  146  to transmit packets to the third party VPC  140  (e.g., packets that, for example, include a request for content from the content data store  144 ) and the origin server  142  and the communication manager  146  may follow a similar process as the server  132  and the communication manager  136  to process received packets. 
     In an embodiment, the managed VPC  130  and the third party VPC  140  are implemented by physical computing devices located with the same data center in a specific geographic location. In other embodiments, the managed VPC  130  and the third party VPC  140  are implemented by physical computing devices located in different data centers in different geographic locations. 
     The managed VPC  130  can communicate with one or more POPs  120  to provide requested content retrieved from the third party VPC  140  via the public network  110 . Accordingly, the managed VPC  130  is publicly addressable. Typically, because the managed VPC  130  is publicly addressable, the managed VPC  130  could be subject to the same issues described above with respect to publicly addressable systems. However, the managed VPC  130  may be owned and/or operated by the same entity as the entity that owns and/or operates the POPs  120 . Thus, in some embodiments, the connection between a POP  120  and the managed VPC  130  may be encrypted and pass through private infrastructure (e.g., routers, gateways, and/or other routing systems that are owned and/or operated by an entity that owns and/or operates the POP  120  and the managed VPC  130 ). 
     The user devices  102  may communicate with the POPs  120  via the public network  110 . For example, a user device  102  may send a request for content (e.g., a specific file) to a POP  120  and receive the requested content from the POP  120  in response to the request. Accordingly, a user device  102  requests content from a POP  120  via the public network  110 , the POP  120  requests content from the managed VPC  130  via an encrypted connection that passes through private infrastructure in the public network  110 , and the managed VPC  130  requests content from the third party VPC  140  via the private network  115 . Additional details on the transmission of messages between each of these components are provided below with respect to  FIG. 2 . 
     Various example user devices  102  are shown in  FIG. 1 , including a desktop computer, laptop, and a mobile phone, each provided by way of illustration. In general, the user devices  102  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 user devices  102  may execute an application (e.g., a browser, a media player, etc.) that generates and transmits a request for content to a POP  120 . 
     The public network  110  may include any wired network, wireless network, or combination thereof. For example, the public network  110  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 public network  110  may be a publicly accessible network of linked networks, possibly operated by various distinct parties, such as the Internet. In some embodiments, the public network  110  may be a semi-private network, such as a corporate or university intranet. The public network  110  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 public network  110  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 public network  110  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. Similarly, the private network  115  may use any of the protocols described above. 
     Example Block Diagram for Requesting Content 
       FIG. 2  is a block diagram of the operating environment  100  of  FIG. 1  illustrating the operations performed by the components of the operating environment  100  to request content, according to one embodiment. As illustrated in  FIG. 2 , a user device may request a file from a CDN  122  at ( 1 ). The CDN  122  may include a cache (e.g., the cache data store  126 ) in which certain files are stored (e.g., the most-frequently requested files). The CDN  122  may query the cache to determine whether the requested file is available at ( 2 ). If the requested file is available in the cache, the CDN  122  can retrieve the file from the cache at ( 3 ). Otherwise, if the file is not available in the CDN  122  cache, the CDN  122  can transmit a request for the file to the server  132  in the managed VPC  130  at ( 4 ). The request may be transmitted over the public network  110 , but using private infrastructure. 
     As described above, the managed VPC  130  optionally includes a cache (e.g., the cache data store  134 ). If the cache data store  134  is present, the server  132  can query the cache data store  134  to determine whether the requested file is stored therein at ( 5 ). If the requested file is available, the server  132  can retrieve the file from the cache data store  134  at ( 6 ). Otherwise, if the requested file is not available in the cache data store  134  or if the cache data store  134  is not present in the managed VPC  130  (e.g., the managed VPC  130  does not serve as a mid-tier cache), the server  132  can generate a request for the file for sending to the origin server  142  (e.g., the request for the file generated by the server  132  can include a virtual address of the origin server  142  as a destination address). The communication manager  136  can intercept the generated request and encapsulate the request with a header that points to a location of the third party VPC  140  at ( 7 ) (e.g., the header includes the location of the third party VPC  140  as a destination address). The communication manager  136  then transmits the encapsulated request to the third party VPC  140  at ( 8 ). The encapsulated request may be transmitted via the private route established between the managed VPC  130  and the third party VPC  140  via the private network  115 . 
     The communication manager  146  can intercept the encapsulated request before it reaches the origin server  142 . The communication manager  146  can decapsulate the encapsulated request at ( 9 ) and forward the decapsulated request to the origin server  142  (e.g., based on the virtual address included in the original request generated by the server  132 ). Based on the received request, the origin server  142  in the third party VPC  140  can retrieve the file from the content data store  144  at ( 10 ). The origin server  142  can then generate a packet that includes the retrieved file in the data portion of the packet for transmission to the server  132  (e.g., the packet generated by the origin server  142  can include a virtual address of the server  132  as a destination address). The communication manager  146  can intercept the generated packet and encapsulate the packet with a header that points to a location of the managed VPC  130  at ( 11 ) (e.g., the header includes the location of the managed VPC  130  as a destination address). The packet may be encapsulated such that the encapsulated packet is routed via the private route to the managed VPC  130 . The communication manager  146  then transmits the encapsulated packet to the managed VPC  130  at ( 12 ). 
     The communication manager  136  can intercept the encapsulated packet before it reaches the server  132 . The communication manager  136  can decapsulate the encapsulated packet at ( 13 ) and forward the decapsulated packet to the server  132  (e.g., based on the virtual address included in the original packet generated by the origin server  142 ). Based on the received packet, the server  132  can then extract the file from the data portion of the packet and transmit the file to the CDN  122  at ( 14 ) via the private infrastructure in the public network  110 . The CDN  122  can then transmit the file to the user device  102  at ( 15 ) via the public network  110  to satisfy the file request. Optionally, the server  132  can store the retrieved file in the cache data store  134 , if present, such that the managed VPC can serve a future request for the file by retrieving the file from the cache data store  134  rather than the third party VPC  140 . 
     Example Block Diagram for Establishing Secure Connection Between POP and Managed VPC 
       FIG. 3  is a block diagram of the operating environment  100  of  FIG. 1  illustrating the operations performed by the components of the operating environment  100  to establish a secure connection between a POP  120  and the managed VPC  130 , according to one embodiment. As illustrated in  FIG. 3 , a control plane  310  transmits a digital certificate to a POP  120 A at ( 1 ). The control plane  310  may be a physical computing device present in a data center or other location in which one or more POPs  120  reside. The control plane  310  may manage digital certificate rotation, among other tasks. For example, the control plane  310  may automatically distribute a digital certificate to a new POP  120 , updated digital certificates to existing POPs  120 , digital certificates to managed VPCs  130 , and/or the like. 
     Upon receipt of the digital certificate, the POP  120 A signs the digital certificate at ( 2 ). The managed VPC  130  may already have a signed digital certificate. Thus, the POP  120 A and the managed VPC  130  may exchange their respective signed digital certificates to establish a secure connection at ( 3 ). For example, the secure connection may be a secure sockets layer (SSL) or transport layer security (TLS) connection. Because both the POP  120 A and the managed VPC  130  have their own digital certificate, the POP  120 A can trust the managed VPC  130  based on the digital certificate of the managed VPC  130  and the VPC  130  can trust the POP  120 A based on the digital certificate of the POP  120 A. 
     Once the secure connection is established, the POP  120 A and the managed VPC  130  can transmit data to each other via the secure connection at ( 4 ). For example, when the POP  120 A transmits data to the managed VPC  130 , the POP  120 A may use the public key provided in the digital certificate of the managed VPC  130  to encrypt the transmitted data. The VPC  130  can then decrypt the data using its private key. Likewise, when the managed VPC  130  transmits data to the POP  120 A, the managed VPC  130  may use the public key provided in the digital certificate of the POP  120 A to encrypt the transmitted data. The POP  120 A can then decrypt the data using its private key. 
     At some later time, the POP  120 A network address may change at ( 5 ). However, because the secure connection between the POP  120 A and the managed VPC  130  is established using the digital certificates, the network address change may not interrupt the secure connection. Thus, the POP  120 A and the managed VPC  130  can continue to send data via the secure connection at ( 6 ). 
     In addition, a new POP  120 B may be created at ( 7 ). In response to the creation or set up of the new POP  120 B, the control plane  310  can transmit a digital certificate to the new POP  120 B at ( 8 ). The POP  120 B may sign the digital certificate at ( 9 ) and the POP  120 B and the managed VPC  130  can exchange digital certificates to establish a secure connection at ( 10 ). 
     Example File Retrieval Routine 
       FIG. 4  is a flow diagram depicting a file retrieval routine  400  illustratively implemented by a managed VPC, according to one embodiment. As an example, the managed VPC  130  (e.g., the server  132  and the communication manager  136 ) of  FIG. 1  can be configured to execute the file retrieval routine  400 . The file retrieval routine  400  begins at block  402 . 
     At block  404 , a request for a file is received from a content delivery network. For example, a user device  102  may have requested the file from the CDN service  122 . The CDN service  122 , however, may have experienced a cache miss (e.g., the file was not stored in the cache data store  126 ). Thus, the CDN service  122  has forwarded the request to the server  132  in the managed VPC  130 . 
     At block  406 , a determination is made as to whether a cache is available in the managed VPC  130 . The cache data store  134  is optional and may or may not be present in the managed VPC  130 . For example, if the cache data store  134  is available or present, then the requested file may be stored therein and can be used to satisfy the request. If the cache data store  134  is available in the managed VPC  130 , then the file retrieval routine  400  proceeds to block  408 . Otherwise, if the cache data store  134  is not available in the managed VPC  130 , then the file retrieval routine  400  proceeds to block  412 . 
     At block  408 , a determination is made as to whether the file is stored in the cache of the managed VPC  130  (e.g., the cache data store  134 ). If the file is stored in the cache data store  134 , then the file retrieval routine  400  proceeds to block  410 . Otherwise, if the file is not stored in the cache data store  134  (e.g., another cache miss occurred), then the file retrieval routine  400  proceeds to block  412 . 
     At block  410 , the file is retrieved from the cache of the managed VPC  130 . The file may be present in the cache data store  134  and not the cache data store  126  because the cache data store  134  may serve as a mid-tier cache that has more storage capacity than the cache data store  126 . 
     At block  412 , a request for the file is transmitted to a VPC that includes an origin server via a private network. For example, the file request is transmitted to the third party VPC  140  via the private network  115 . The file request may be encapsulated in a header that points to a location of the third party VPC  140  to enable the transmission. As described above, before the request is received, the managed VPC  130  and the third party VPC  140  may be paired using their respective VPC identifiers. 
     At block  414 , an encapsulated packet is received from the third party VPC. The packet may be encapsulated with a header that points to a location of the managed VPC  130 . The packet may be encapsulated as a result of the origin server  142  generating a packet for transmission to the server  132 . The encapsulated packet may be received via the private route established between the managed VPC  130  and the third party VPC  140 . 
     At block  416 , the encapsulated packet is decapsulated to extract the packet and/or file. For example, the file may be located in the data portion of the packet. After the packet is decapsulated, the file retrieval routine  400  proceeds either to block  418  (e.g., if the cache data store  134  is present in the managed VPC  130 ) or to block  420  (e.g., if the cache data store  134  is not present in the managed VPC  130  or it is otherwise not desired to store the retrieved file in cache). 
     At block  418 , the retrieved file is stored in cache. For example, the file can be stored in the cache data store  134  such that the next time a request is received for the file, the managed VPC  130  can return the file stored in the cache data store  134  in place of submitting a request to the third party VPC  140  for the file. After the retrieved file is stored in cache, the file retrieval routine  400  proceeds to block  420 . 
     At block  420 , the file is transmitted to the content delivery network. The transmitted file may be retrieved from the cache data store  134  or the third party VPC  140 . The CDN service  122  may then distribute the file to the user device  102  that originally requested the file. After the file is transmitted to the content delivery network, the file retrieval routine  400  may be complete, as shown in block  422 . 
     Terminology 
     All of the methods and tasks described herein may be performed and fully automated by a computer system. The computer system may, in some cases, include multiple distinct computers or computing devices (e.g., physical servers, workstations, storage arrays, cloud computing resources, etc.) that communicate and interoperate over a network to perform the described functions. Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-transitory computer-readable storage medium or device (e.g., solid state storage devices, disk drives, etc.). The various functions disclosed herein may be embodied in such program instructions, or may be implemented in application-specific circuitry (e.g., ASICs or FPGAs) of the computer system. Where the computer system includes multiple computing devices, these devices may, but need not, be co-located. The results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices, such as solid state memory chips or magnetic disks, into a different state. In some embodiments, the computer system may be a cloud-based computing system whose processing resources are shared by multiple distinct business entities or other users. 
     Depending on the embodiment, certain acts, events, or functions of any of the processes or algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described operations or events are necessary for the practice of the algorithm). Moreover, in certain embodiments, operations or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. 
     The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware (e.g., ASICs or FPGA devices), computer software that runs on computer hardware, or combinations of both. Moreover, the various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor device can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor device includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor device can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor device may also include primarily analog components. For example, some or all of the rendering techniques described herein may be implemented in analog circuitry or mixed analog and digital circuitry. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few. 
     The elements of a method, process, routine, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of a non-transitory computer-readable storage medium. An exemplary storage medium can be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor device. The processor device and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor device and the storage medium can reside as discrete components in a user terminal. 
     Conditional language used herein, such as, among others, “can,” “could,” “might,” “may,” “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements or steps. Thus, such conditional language is not generally intended to imply that features, elements 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 other input or prompting, whether these features, elements or steps are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list. 
     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, 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, and at least one of Z to each be present. 
     While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As can be recognized, certain embodiments described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others. The scope of certain embodiments disclosed herein is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.