Patent Publication Number: US-10771252-B1

Title: Data center security services

Description:
TECHNICAL FIELD 
     This disclosure relates to computer networks, and more specifically, to security services provided as a service on a network. 
     BACKGROUND 
     A hardware security module (HSM) is a computing device that stores, safeguards, and manages digital cryptographic keys, and also performs cryptographic operations. Typically, an HSM is a housed within a tamper-resistant casing and is designed to securely store cryptographic keys and other material. An HSM is also designed to perform cryptographic operations (e.g., encryption and decryption) without exposing unencrypted versions of the keys outside of the device, thereby preventing unauthorized disclosure of such keys. HSM devices sometimes take the form of a plug-in card or an external device that attaches directly to another computing device. 
     SUMMARY 
     This disclosure describes techniques for a cloud-neutral key management service for the generation, storage, and use of cryptographic keys by customers of the service. Systems in accordance with one or more aspects of the present disclosure may provide secure use and management of cryptographic keys as service to a plurality of data center users or customers that contract for services provided by the data center. Techniques in accordance with one or more aspects of the present disclosure may enable such customers to avoid administering HSM devices within their own on-premises network, while still storing cryptographic keys separately from encrypted data stored in a cloud network and thereby providing a more secure key management architecture. By providing access to HSM devices as a service, functions normally provided by an on-premises HSM device may be performed more efficiently. Further, techniques described herein may enable use of cryptographic keys in a cloud-neutral environment, and may be appropriate for use in public, private, hybrid, or multi-cloud environments. 
     In one example, this disclosure describes a method comprising authenticating, by a computing system within a data center and based on input received over a plurality of customer ports, each of a plurality of customers to access services provided by at least one hardware security module included within the computing system, including a first customer and a second customer; generating, by the at least one hardware security module, a plurality of cryptographic keys, including a first cryptographic key associated with the first customer and a second cryptographic key associated with the second customer, wherein the plurality of cryptographic keys are generate and stored securely within the at least one hardware security module; enforcing, by the computing system, restrictions on use of the plurality of cryptographic keys, including preventing use of the first cryptographic key by the second customer and preventing use of the second cryptographic key by the first customer; accessing, by the computing system and based on input received from a computing device operated by the first customer, a first set of customer data; generating, by the computing system, a first set of processed data by causing the at least one hardware security module to perform a cryptographic operation on the first set of customer data using the first cryptographic key; outputting, by the computing system, the first set of processed data over a private connection to a first cloud service provider network; accessing, by the computing system and based on input received from a computing device operated by the second customer, a second set of customer data; generating, by the computing system, a second set of processed data by causing the at least one hardware security module to perform a cryptographic operation on the second set of customer data using the second cryptographic key; and outputting, by the computing system, the second set of processed data over a private connection to a second cloud service provider network. 
     In another example, this disclosure describes a data center comprising: a plurality of cloud service provider ports, each coupled over a private connection to a different one of a plurality of cloud service provider networks, wherein the plurality of cloud service provider networks includes a first cloud service provider network and a second cloud service provider network; a plurality of customer ports, each of the customer ports coupled to a computing device operated by one of a plurality of customers of data center services, including a first customer operating a first computing device, and a second customer operating a second computing device; network infrastructure coupling the plurality of cloud service provider ports to the plurality of customer ports; and a computing system including at least one hardware security module, wherein the computing system is deployed within the data center and is connected to the network infrastructure, and wherein the computing system is configured to: authenticate, based on input received over the plurality of customer ports, each of a plurality of customers to access services provided by the at least one hardware security module, including the first customer and the second customer, generate, by interacting with the at least one hardware security module, a plurality of cryptographic keys, including a first cryptographic key associated with the first customer and a second cryptographic key associated with the second customer, wherein the plurality of cryptographic keys are generated and stored securely within the at least one hardware security module, enforce restrictions on use of the plurality of cryptographic keys, including preventing use of the first cryptographic key by the second customer and preventing use of the second cryptographic key by the first customer, access, based on input received from the first computing device, a first set of customer data, generate a first set of processed data by causing the at least one hardware security module to perform a cryptographic operation on the first set of customer data using the first cryptographic key, output the first set of processed data over at least one of the plurality of cloud service provider ports to the first cloud service provider network, access, based on input received from the second computing device, a second set of customer data, generate a second set of processed data by causing the at least one hardware security module to perform a cryptographic operation on the second set of customer data using the second cryptographic key, and output the second set of processed data over at least one of the plurality of cloud service provider ports to the second cloud provider network. 
     In another example, this disclosure describes a computer-readable storage medium comprises instructions that, when executed, configure processing circuitry of a computing system to authenticate, based on input received over a plurality of customer ports, each of a plurality of customers to access services provided by at least one hardware security module included within the computing system, including a first customer and a second customer; generate, by the at least one hardware security module, a plurality of cryptographic keys, including a first cryptographic key associated with the first customer and a second cryptographic key associated with the second customer, wherein the plurality of cryptographic keys are generate and stored securely within the at least one hardware security module; enforce restrictions on use of the plurality of cryptographic keys, including preventing use of the first cryptographic key by the second customer and preventing use of the second cryptographic key by the first customer; access, based on input received from a computing device operated by the first customer, a first set of customer data; generate a first set of processed data by causing the at least one hardware security module to perform a cryptographic operation on the first set of customer data using the first cryptographic key; output the first set of processed data over a private connection to a first cloud service provider network; access, based on input received from a computing device operated by the second customer, a second set of customer data; generate a second set of processed data by causing the at least one hardware security module to perform a cryptographic operation on the second set of customer data using the second cryptographic key; and output the second set of processed data over a private connection to a second cloud service provider network. 
     The details of one or more examples of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram that illustrates a conceptual view of a network system having a metro-based cloud exchange that provides multiple cloud exchange points according to techniques described herein. 
         FIG. 2  is a block diagram illustrating a high-level view of a data center that provides an operating environment for a cloud-based services exchange, according to techniques described herein. 
         FIG. 3A  and  FIG. 3B  are block diagrams illustrating example network infrastructure and service provisioning by a programmable network platform for a cloud exchange that aggregates the cloud services of multiple cloud service providers for provisioning to customers of the cloud exchange provider and aggregates access for multiple customers to one or more cloud service providers, in accordance with techniques described in this disclosure. 
         FIG. 4  is a block diagram illustrating an example of a data center-based cloud exchange point in which routers of the cloud exchange point are configured by programmable network platform with VPN routing and forwarding instances for routing and forwarding aggregated service traffic from multiple cloud service provider networks to a customer network, according to techniques described herein. 
         FIG. 5  is a block diagram illustrating an example of a data center-based cloud exchange point, according to techniques described herein. 
         FIG. 6A  through  FIG. 6F  are conceptual diagrams illustrating example cryptographic operations performed within an example data center, in accordance with one or more aspects of the present disclosure. 
         FIG. 7  is a flow diagram illustrating an example process for performing cryptographic operations in accordance with one or more aspects of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     Organizations that host data and applications within their own on-premises enterprise network traditionally use HSM devices to manage keys, perform authentication, and perform data encryption and decryption. Often, HSM devices are placed on-premises, within an organization&#39;s enterprise network. However, where an organization has multiple geographic locations, physical placement of additional HSM devices across such locations presents logistical challenges and can be costly. 
     An alternative approach is to use a cryptographic key management service that might be provided by a cloud service provider in place of at least some aspects of the traditional on-premises, physical HSM implementation. A key management service provided by a cloud service provider might be more convenient than administering and using on-premises HSM devices and may eliminate the cost and overhead of provisioning and managing HSM devices. However, there are drawbacks to such an approach. 
     One drawback to using a cryptographic key management service offered by a cloud service provider is that a cloud-based service may store cryptographic keys and data in the same environment and/or infrastructure. Such an arrangement increases the risk of harm that might result from a data breach, since unauthorized access to the environment that stores the keys and data results in unauthorized access to both the cryptographic keys and the data. In other words, if the keys and the data are separated with the keys stored to the on-premises enterprise network, that physical separation may provide an added level of defense, since a hacker that succeeds in gaining unauthorized access to the data will, in order to use the data, also have to succeed in gaining unauthorized access to a different computing system that stores the keys. 
     Another drawback to a cloud-based cryptographic key management service is that such a system might not work well in heterogeneous cloud environments. Often, an organization uses a combination of public, private, hybrid, or multi-cloud environments to support globally-distributed operations and/or mixed applications. In such situations, a cloud-based cryptographic key management service might not adequately support such an organization&#39;s systems, since the cloud-based cryptographic key management service might only be effective for use with data and applications hosted in that cloud service provider&#39;s own cloud environment. The cloud-based cryptographic key management service might not work when it is used from an external application (e.g., hosted outside the cloud) or from another environment (e.g., a different cloud service provider). 
     Still further, a cloud-based cryptographic key management service that is implemented through software, without use of HSM devices, is less secure. Without the more rigorous security protections provided by HSM devices, a software-based cryptographic key management service is vulnerable to hackers or rogue employees of the cloud service provider that gain access to plain-text cryptographic keys that may be stored in accessible memory or even persisted to disk by the cloud service provider. 
     This disclosure describes techniques for efficiently and effectively providing cryptographic services that include not only encryption, decryption, and other cryptographic operations, but also include key management services for creating, storing, maintaining, and administering cryptographic keys. Systems in accordance with one or more aspects of the present disclosure may provide secure management of cryptographic keys as service to a plurality of cloud service customers. Further, techniques in accordance with one or more aspects of the present disclosure may enable such customers to avoid administering HSM devices within their on-premises network, reducing or eliminating any need to invest time in ordering, physically placing, or provisioning of HSM hardware in multiple locations or geographies. By providing access to HSM devices as a service, functions normally provided by on-premises HSM device may be provided more efficiently, with the advantage of economies of scale that result from providing such services to multiple customers. Yet cryptographic keys and data may be securely protected through the use of HSM devices in a cloud-neutral environment, and may be fully capable of protecting data in public, private, hybrid, or multi-cloud environments. Further, in some examples described herein, cryptographic keys may be provisioned at the network edge, which may reduce latency, yet also may enable the keys to remain separate from encrypted data, thereby providing an added level of defense against data breaches. 
       FIG. 1  illustrates a conceptual view of a network system having a metro-based cloud exchange that provides multiple cloud exchange points according to techniques described herein. Each of cloud-based services exchange points  128 A- 128 D (described hereinafter as “cloud exchange points” and collectively referred to as “cloud exchange points  128 ”) of cloud-based services exchange  100  (“cloud exchange  100 ”) may represent a different data center geographically located within the same metropolitan area (“metro-based,” e.g., in New York City, N.Y.; Silicon Valley, Calif.; Seattle-Tacoma, Wash.; Minneapolis-St. Paul, Minn.; London, UK; etc.) to provide resilient and independent cloud-based services exchange by which cloud-based services customers (“cloud customers”) and cloud-based service providers (“cloud providers”) connect to receive and provide, respectively, cloud services. In various examples, cloud exchange  100  may include more or fewer cloud exchange points  128 . In some instances, a cloud exchange  100  includes just one cloud exchange point  128 . As used herein, reference to a “cloud exchange” or “cloud-based services exchange” may refer to a cloud exchange point. A cloud exchange provider may deploy instances of cloud exchanges  100  in multiple different metropolitan areas, each instance of cloud exchange  100  having one or more cloud exchange points  128 . 
     Each of cloud exchange points  128  includes network infrastructure and an operating environment by which cloud customers operating computing devices  108 A- 108 C (collectively, “customer computing devices  108 ”) receive cloud services from multiple cloud service provider networks  110 A- 110 N (collectively, “cloud service providers  110 ” or “cloud service provider networks  110 ”). Customer computing devices  108  may be computing devices of corresponding customer networks co-located within the corresponding data center of one of cloud exchange points  128 , or customer networks that receive services via transit network service providers  106 , as illustrated in  FIG. 1 . Cloud exchange  100  provides customers of the exchange, e.g., enterprises, network carriers, network service providers, and SaaS customers, with secure, private, virtual connections to multiple cloud service providers (CSPs) globally. The multiple CSPs participate in the cloud exchange by virtue of their having at least one accessible port in the cloud exchange by which a customer can connect to the one or more cloud services offered by the CSPs, respectively. Cloud exchange  100  allows private networks of any customer to be directly cross-connected to any other customer at a common point, thereby allowing direct exchange of network traffic between the networks of the customers. 
     Cloud customers operating computing devices  108  may receive cloud-based services directly via a layer 3 peering and physical connection to one of cloud exchange points  128  or indirectly via one of network service providers  106 A- 106 B (collectively, “NSPs  106 ,” or alternatively, “carriers  106 ”). NSPs  106  provide “cloud transit” by maintaining a physical presence within one or more of cloud exchange points  128  and aggregating layer 3 access from one or more devices  108 . NSPs  106  may peer, at layer 3, directly with one or more cloud exchange points  128  and in so doing offer indirect layer 3 connectivity and peering to one or more customer devices  108  by which customers (e.g., operating devices  108 ) may obtain cloud services from the cloud exchange  100 . Each of cloud exchange points  128 , in the example of  FIG. 1 , is assigned a different autonomous system number (ASN). For example, cloud exchange point  128 A is assigned ASN  1 , cloud exchange point  128 B is assigned ASN  2 , and so forth. Each cloud exchange point  128  is thus a next hop in a path vector routing protocol (e.g., BGP) path from cloud service providers  110  to customer devices  108 . As a result, each cloud exchange point  128  may, despite not being a transit network having one or more wide area network links and concomitant Internet access and transit policies, peer with multiple different autonomous systems via external BGP (eBGP) or other exterior gateway routing protocol in order to exchange, aggregate, and route service traffic from one or more cloud service providers  110  to customers. In other words, cloud exchange points  128  may internalize the eBGP peering relationships that cloud service providers  110  and customers would maintain on a pair-wise basis. Instead, a customer may configure a single eBGP peering relationship with a cloud exchange point  128  and receive, via the cloud exchange, multiple cloud services from one or more cloud service providers  110 . While described herein primarily with respect to eBGP or other layer 3 routing protocol peering between cloud exchange points and customer, NSP, or cloud service provider networks, the cloud exchange points may learn routes from these networks in other way, such as by static configuration, or via Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), or other route distribution protocol. 
     As examples of the above, one customer may have contracted with a cloud exchange provider for cloud exchange  100  to directly access layer 3 cloud services via cloud exchange points  128 C. In this way, that customer receives redundant layer 3 connectivity to cloud service provider  110 A, for instance. The customer at device  108 C, in contrast, is illustrated as having contracted with the cloud exchange provider for cloud exchange  100  to directly access layer 3 cloud services via cloud exchange point  128 C and also to have contracted with NSP  106 B to access layer 3 cloud services via a transit network of the NSP  106 B. A customer at device  108 B is illustrated as having contracted with multiple NSPs  106 A,  106 B to have redundant cloud access to cloud exchange points  128 A,  128 B via respective transit networks of the NSPs  106 A,  106 B. The contracts described above are instantiated in network infrastructure of the cloud exchange points  128  by L3 peering configurations within switching devices of NSPs  106  and cloud exchange points  128  and L3 connections, e.g., layer 3 virtual circuits, established within cloud exchange points  128  to interconnect cloud service provider  110  networks to NSPs  106  networks and customer networks, all having at least one port offering connectivity within one or more of the cloud exchange points  128 . 
     In some examples, cloud exchange  100  allows a corresponding one of customers of any network service providers (NSPs) or “carriers”  106 A- 106 B (collectively, “carriers  106 ”) or other cloud customers including a customer operating device  108 C to be directly connected, via a virtual layer 2 (L2) or layer 3 (L3) connection to any other customer network and/or to any of CSPs  110 , thereby allowing direct exchange of network traffic among the customer networks and CSPs  110 . The virtual L2 or L3 connection may be referred to as a “virtual circuit.” 
     Carriers  106  may each represent a network service provider that is associated with a transit network by which network subscribers of the carrier  106  may access cloud services offered by CSPs  110  via the cloud exchange  100 . In general, customers of CSPs  110  may include network carriers, large enterprises, managed service providers (MSPs), as well as Software-as-a-Service (SaaS), Platform-aaS (PaaS), Infrastructure-aaS (IaaS), Virtualization-aaS (VaaS), and data Storage-aaS (dSaaS) customers for such cloud-based services as are offered by the CSPs  110  via the cloud exchange  100 . 
     In this way, cloud exchange  100  streamlines and simplifies the process of partnering CSPs  110  and customers (via carriers  106  or directly) in a transparent and neutral manner. One example application of cloud exchange  100  is a co-location and interconnection data center in which CSPs  110  and carriers  106  and/or customers operating devices  108  may already have network presence, such as by having one or more accessible ports available for interconnection within the data center, which may represent any of cloud exchange points  128 . This allows the participating carriers, customers, and CSPs to have a wide range of interconnectivity options within the same facility. A carrier/customer may in this way have options to create many-to-many interconnections with only a one-time hook up to one or more cloud exchange points  128 . In other words, instead of having to establish separate connections across transit networks to access different cloud service providers or different cloud services of one or more cloud service providers, cloud exchange  100  allows customers to interconnect to multiple CSPs and cloud services. 
     In the example of  FIG. 1 , cloud exchange point  128 A includes computing system  150 , which may provide access to one or more hardware security modules  151  included within or connected to computing system  150 . In  FIG. 1 , computing system  150  is shown within cloud exchange point  128 A. In other examples, computing system  150  may be implemented outside of cloud exchange point  128 A. Alternatively, or in addition, one or more computing systems  150  may be included within other cloud exchange points  128  (e.g., cloud exchange point  128 B, cloud exchange point  128 N) or elsewhere within cloud exchange  100 . 
     In some examples, each hardware security module  151  shown within computing system  150  is a computing device that stores, safeguards, and manages digital cryptographic keys and also performs cryptographic operations. Each hardware security module  151  may be designed as a tamper-resistant device that prevents or foils attempts at hacking or disassembly. In some examples, hardware security module  151  may be constructed to ensure that cryptographic keys stored within hardware security module  151  are stored so that the keys cannot be read or accessed by any other device. Further, in some examples, each hardware security module  151  may be configured to disable itself and/or delete the content that it stores upon detecting an attempt at tampering. In general, hardware security module  151  may be designed to adhere to rigorous requirements and pass stringent product verification testing and/or application testing to verify the ability of hardware security module  151  to maintain the security and integrity of cryptographic material stored therein. One or more of hardware security modules  151  may be included within computing system  150 , or such devices may be configured as external devices that attach to computing system  150 . 
     In some examples, hardware security module  151  may be programmable to enable customers to modify or extend the behavior and functionality of hardware security module  151 . For instance, hardware security module  151  may be used to provide services to countries, jurisdictions, entities that require specific cryptographic algorithms that might not be implemented by hardware security module  151 . In such an example, hardware security module  151  may be capable of executing customer-provided code (or other custom code) that implements one or more cryptographic algorithms satisfying arbitrary requirements of one or more countries, jurisdictions, and/or entities. Such a capability may also be used to comply with data privacy regulations that may be imposed by one or more countries. Such customizations and/or extensions may be also applied to implement other types of capabilities, including any given business logic that might be required by a specific customer. 
     Cloud exchange  100  includes a programmable network platform  120  for dynamically programming cloud exchange  100  to responsively and assuredly fulfill service requests that encapsulate business requirements for services provided by cloud exchange  100  and/or cloud service providers  110  coupled to the cloud exchange  100 . The programmable network platform  120  may, as a result, orchestrate a business-level service across heterogeneous cloud service providers  110  according to well-defined service policies, quality of service policies, service level agreements, and costs, and further according to a service topology for the business-level service. 
     The programmable network platform  120  enables the cloud service provider that administers the cloud exchange  100  to dynamically configure and manage the cloud exchange  100  to, for instance, facilitate virtual connections for cloud-based services delivery from multiple cloud service providers  110  to one or more cloud customers operating devices  108 . The cloud exchange  100  may enable cloud customers to bypass the public Internet to directly connect to cloud services providers  110  so as to improve performance, reduce costs, increase the security and privacy of the connections, and leverage cloud computing for additional applications. In this way, enterprises, network carriers, and SaaS customers, for instance, can at least in some aspects integrate cloud services with their internal applications as if such services are part of or otherwise directly coupled to their own data center network. 
     In other examples, programmable network platform  120  enables the cloud service provider to configure cloud exchange  100  with a L3 instance requested by a cloud customer operating device  108 , as described herein. A customer may request an L3 instance to link multiple cloud service providers by the L3 instance, for example (e.g., for transferring the customer&#39;s data between two cloud service providers, or for obtaining a mesh of services from multiple cloud service providers). 
     Programmable network platform  120  may represent an application executing within one or more data centers of the cloud exchange  100  or alternatively, off-site at a back office or branch of the cloud provider (for instance). Programmable network platform  120  may be distributed in whole or in part among the data centers, each data center associated with a different cloud exchange point  128  to make up the cloud exchange  100 . Although shown as administering a single cloud exchange  100 , programmable network platform  120  may control service provisioning for multiple different cloud exchanges. Alternatively or additionally, multiple separate instances of the programmable network platform  120  may control service provisioning for respective multiple different cloud exchanges. 
     In the illustrated example, programmable network platform  120  includes a service interface (or “service API”)  114  that defines the methods, fields, and/or other software primitives by which applications  130 , such as a customer portal, may invoke the programmable network platform  120 . The service interface  114  may allow carriers  106 , customers, cloud service providers  110 , and/or the cloud exchange provider programmable access to capabilities and assets of the cloud exchange  100  according to techniques described herein. 
     For example, the service interface  114  may facilitate machine-to-machine communication to enable dynamic provisioning of virtual circuits in the cloud exchange for interconnecting customer and/or cloud service provider networks. In this way, the programmable network platform  120  enables the automation of aspects of cloud services provisioning. For example, the service interface  114  may provide an automated and seamless way for customers to establish, de-install and manage interconnections among multiple, different cloud providers participating in the cloud exchange. 
     In the example of  FIG. 1 , and in accordance with one or more aspects of the present disclosure, computing system  150  may provide services to authenticated users of cloud exchange  100 . For instance, in the example of  FIG. 1 , programmable network platform  120  detects input, through service interface  114 , that it determines corresponds to authentication credentials from users of customer computing device  108 A, customer computing device  108 B, and/or one or more other customer computing devices. Programmable network platform  120  outputs information about the input to computing system  150 . Computing system  150  evaluates that the authentication credentials and determines that each of the users of customer computing device  108 A and customer computing device  108 B are authorized to access some or all services provided by cloud exchange point  128 A, including cryptographic key use and management services provided by computing system  150  and hardware security modules  151 . 
     Computing system  150  may encrypt data  121 A received from customer computing device  108 A, e.g., via a private communication channel such as a virtual circuit. For instance, in the example of  FIG. 1 , customer computing device  108 A outputs one or more signals over network service provider  106 A. Network service provider  106 A communicates the signals to programmable network platform  120  through service interface  114 . Programmable network platform  120  outputs information about the signals to computing system  150  within cloud exchange point  128 A. Computing system  150  determines that the signals include data  121 A. Computing system  150  further determines that the signals correspond to a request, by an authenticated user of customer computing device  108 A, to create an encryption key, encrypt data  121 A, and send, e.g., via a separate private communication channel such as a virtual circuit, encrypted data  121 A for storage within cloud service provider network  110 A. Computing system  150  causes one or more hardware security modules  151  to generate an encryption key and associate the encryption key with the authenticated user of customer computing device  108 A. Hardware security module  151  uses the encryption key to encrypt data  121 A (designated by shaded  121 A). Computing system  150  outputs encrypted data  121 A to cloud service provider network  110 A for storage at one or more devices within cloud service provider network  110 A. 
     Concurrently, or at a different time, computing system  150  may encrypt data  121 B received from customer computing device  108 B. For instance, in the example of  FIG. 1 , customer computing device  108 B outputs one or more signals over network service provider  106 A. Network service provider  106 A communicates the signals to programmable network platform  120  (e.g., through service interface  114 ) and information about the signals is communicated to computing system  150 . Computing system  150  determines that the signals include data  121 B from customer computing device  108 B. Computing system  150  further determines that the signals correspond to a request, by an authenticated user of customer computing device  108 B, to create an encryption key associated with the user of customer computing device  108 B, encrypt data  121 B, and store encrypted data  121 B within cloud service provider network  110 N. Computing system  150  causes one or more hardware security modules  151  to generate an encryption key and associate the encryption key with the authenticated user of customer computing device  108 B. Hardware security module  151  uses the encryption key to encrypt data  121 B. Computing system  150  outputs encrypted data  121 B to cloud service provider network  110 N for storage at one or more devices within cloud service provider network  110 N. 
     In the example described, the user operating customer computing device  108 A and the user operating customer computing device  108 B may encrypt the data using keys separately generated by hardware security module  151 , and may choose any of cloud service provider networks  110  for storage of the data  121 A and/or data  121 B. Further, either or both of data  121 A and  121 B data may be stored at multiple cloud service provider networks  110 . Since the data is encrypted within cloud exchange  100 , no encryption services of any of cloud service provider networks  110  are needed, thereby enabling the encrypted data to be stored in a multi-cloud and cloud-neutral manner. Further, since cryptographic keys are provisioned at the network edge (e.g., by hardware security module  151  within cloud exchange point  128 A or otherwise within cloud exchange  100 ), keys may be created and available for use with less latency versus enterprise-hosted solutions in which key data is stored on the enterprise premises. In other words, the techniques may provide the technical advantage of lower latency encryption/decryption of data. This technical advantage may be particularly advantageous in cases in which encrypted data stored by one of cloud service provider networks  110  is decrypted by hardware security module  151  and the decrypted data is output by computing device  150  to another one of cloud service provider networks  110 . 
     Further, in the example of  FIG. 1 , customer data is stored within one or more cloud service provider networks  110 , while the cryptographic keys are stored securely within hardware security module  151  of cloud exchange point  128 A, outside the reach of any of cloud service provider networks  110 . Such an arrangement or implementation may be important to comply with data privacy regulations that might require an independent key management service that keeps keys and/or data separated, or within a specific country&#39;s jurisdiction, without storing those keys and/or data within a cloud service provider network that may include physical devices located across multiple jurisdictions. 
     In some examples, computing system  150  may further provide key management services, enabling customers control over the encryption keys they create and that are used to protect data associated with each customer. In some examples, such key management services provided by computing system  150  may enable customers to access an API (e.g., through service interface  114 ) to, for example, organize or manage what specific named keys can be used to encrypt or decrypt specific data. Further, such services may be used to create, import, rotate, disable, and/or delete cryptographic keys and/or other key material. In some examples, computing system  150  may also enable customers to define usage policies for cryptographic material and/or audit the use of cryptographic or encryption keys. 
     In some examples, key management services provided by computing system  150  may also include a whitelisting service that restricts access to cryptographic services to an approved list of jurisdictions. In such an example, computing system  150  may, prior to servicing requests, inspect information about the source of the data or the location of the user interacting with cloud exchange  100  (or computing system  150 ) to ensure that the source or location is included within the approved list of jurisdictions. In some examples, computing system  150  inspect the IP address of one or more devices involved in the request. In other examples, computing system  150  may identify a source or location through other means. 
     Further, in some examples, key management services may, alternatively or in addition, include replication services that enable, for example, keys created within  151  to be replicated across each of cloud exchange points  128  in  FIG. 1  or across multiple cloud exchanges  100 . For instance, in some examples, each of cloud exchange points  128  may provide key management services to a particular customer. Further, in some examples, multiple cloud exchanges  100 , perhaps widely dispersed geographically, may also provide key management services to that same customer. In such an example, when that customer creates a cryptographic key (e.g., through interactions with hardware security module  151 ), each of cloud exchange points  128  and/or cloud exchanges  100  may interact to ensure that the newly created key is replicated across some or all of cloud exchange points  128  and across other cloud exchanges  100 , and is thereby available to that customer when accessing services through other cloud exchange points  128  and/or other cloud exchanges  100 . Accordingly, one or more cryptographic keys may be duplicated in one geographic location, or duplicated in multiple locations across various geographical locations. To implement such functionality, keys may be stored in a common database accessible to one or more cloud exchange points  128  and/or one or more cloud exchanges  100 . Further, although  FIG. 1  illustrates one particular topology, techniques in accordance with one or more aspects of the present disclosure may be implemented using other topologies, including a hybrid topology that encompasses or includes both a full mesh topology and a hub-spoke topology. 
     Further example details of a cloud-based services exchange can be found in U.S. patent application Ser. No. 15/099,407, filed Apr. 14, 2016 and entitled “CLOUD-BASED SERVICES EXCHANGE;” U.S. patent application Ser. No. 14/927,451, filed Oct. 29, 2015 and entitled “INTERCONNECTION PLATFORM FOR REAL-TIME CONFIGURATION AND MANAGEMENT OF A CLOUD-BASED SERVICES EXCHANGE;” and U.S. patent application Ser. No. 14/927,306, filed Oct. 29, 2015 and entitled “ORCHESTRATION ENGINE FOR REAL-TIME CONFIGURATION AND MANAGEMENT OF INTERCONNECTIONS WITHIN A CLOUD-BASED SERVICES EXCHANGE;” each of which are incorporated herein by reference in their respective entireties. 
       FIG. 2  is a block diagram illustrating a high-level view of a data center  201  that provides an operating environment for a cloud-based services exchange  200 , according to techniques described herein. Cloud-based services exchange  200  (“cloud exchange  200 ”) allows a corresponding one of customer networks  204 D,  204 E and NSP networks  204 A- 204 C (collectively, “‘private’ or ‘carrier’ networks  204 ”) of any NSPs  106 A- 106 C or other cloud customers including customers  108 A,  108 B to be directly connected, via a layer 3 (L3) or layer 2 (L2) connection to any other customer network and/or to any of cloud service providers  110 A- 110 N, thereby allowing exchange of cloud service traffic among the customer networks and/or CSPs  110 . Data center  201  may be entirely located within a centralized area, such as a warehouse or localized data center complex, and provide power, cabling, security, and other services to NSPs, customers, and cloud service providers that locate their respective networks within the data center  201  (e.g., for co-location) and/or connect to the data center  201  by one or more external links. 
     Network service providers  106  may each represent a network service provider that is associated with a transit network by which network subscribers of the NSP  106  may access cloud services offered by CSPs  110  via the cloud exchange  200 . In general, customers of CSPs  110  may include network carriers, large enterprises, managed service providers (MSPs), as well as Software-as-a-Service (SaaS), Platform-aaS (PaaS), Infrastructure-aaS (IaaS), Virtualization-aaS (VaaS), and data Storage-aaS (dSaaS) customers for such cloud-based services as are offered by the CSPs  110  via the cloud exchange  200 . 
     In this way, cloud exchange  200  streamlines and simplifies the process of partnering CSPs  110  and customers  108  (indirectly via NSPs  106  or directly) in a transparent and neutral manner. One example application of cloud exchange  200  is a co-location and interconnection data center in which CSPs  110 , NSPs  106  and/or customers  108  may already have network presence, such as by having one or more accessible ports available for interconnection within the data center. This allows the participating carriers, customers, and CSPs to have a wide range of interconnectivity options in the same facility. 
     Cloud exchange  200  of data center  201  includes network infrastructure  222  that provides a L2/L3 switching fabric by which CSPs  110  and customers/NSPs interconnect. This enables an NSP/customer to have options to create many-to-many interconnections with only a one-time hook up to the switching network and underlying network infrastructure  222  that presents an interconnection platform for cloud exchange  200 . In other words, instead of having to establish separate connections across transit networks to access different cloud service providers or different cloud services of one or more cloud service providers, cloud exchange  200  allows customers to interconnect to multiple CSPs and cloud services using network infrastructure  222  within data center  201 , which may represent any of the edge networks described in this disclosure, at least in part. 
     By using cloud exchange  200 , customers can purchase services and reach out to many end users in many different geographical areas without incurring the same expenses typically associated with installing and maintaining multiple virtual connections with multiple CSPs  110 . For example, NSP  106 A can expand its services using network  204 B of NSP  106 B. By connecting to cloud exchange  200 , a NSP  106  may be able to generate additional revenue by offering to sell its network services to the other carriers. For example, NSP  106 C can offer the opportunity to use NSP network  204 C to the other NSPs. 
     Cloud exchange  200  includes an programmable network platform  120  that exposes at least one service interface, which may include in some examples and are alternatively referred to herein as application programming interfaces (APIs) in that the APIs define the methods, fields, and/or other software primitives by which applications may invoke the programmable network platform  120 . The software interfaces allow NSPs  206  and customers  108  programmable access to capabilities and assets of the cloud exchange  200 . The programmable network platform  120  may alternatively be referred to as a controller, provisioning platform, provisioning system, service orchestration system, etc., for establishing end-to-end services including, e.g., connectivity between customers and cloud service providers according to techniques described herein. 
     On the buyer side, the software interfaces presented by the underlying interconnect platform provide an extensible framework that allows software developers associated with the customers of cloud exchange  200  (e.g., customers  108  and NSPs  206 ) to create software applications that allow and leverage access to the programmable network platform  120  by which the applications may request that the cloud exchange  200  establish connectivity between the customer and cloud services offered by any of the CSPs  110 . For example, these buyer-side software interfaces may allow customer applications for NSPs and enterprise customers, e.g., to obtain authorization to access the cloud exchange, obtain information regarding available cloud services, obtain active ports and metro area details for the customer, create virtual circuits of varying bandwidth to access cloud services, including dynamic selection of bandwidth based on a purchased cloud service to create on-demand and need based virtual circuits to or between cloud service providers, delete virtual circuits, obtain active virtual circuit information, obtain details surrounding CSPs partnered with the cloud exchange provider, obtain customized analytics data, validate partner access to interconnection assets, and assure service delivery. 
     On the cloud service provider seller side, the software interfaces may allow software developers associated with cloud providers to manage their cloud services and to enable customers to connect to their cloud services. For example, these seller-side software interfaces may allow cloud service provider applications to obtain authorization to access the cloud exchange, obtain information regarding available cloud services, obtain active ports and metro area details for the provider, obtain active port details in a given data center for the provider, approve or reject virtual circuits of varying bandwidth created by customers for the purpose of accessing cloud services, obtain virtual circuits pending addition and confirm addition of virtual circuits, obtain virtual circuits pending deletion and confirm deletion of virtual circuits, obtain customized analytics data, validate partner access to interconnection assets, and assure service delivery. 
     Service interface  114  facilitates machine-to-machine communication to enable dynamic service provisioning and service delivery assurance. In this way, the programmable network platform  120  enables the automation of aspects of cloud services provisioning. For example, the software interfaces may provide an automated and seamless way for customers to establish, de-install and manage interconnection with or between multiple, different cloud providers participating in the cloud exchange. The programmable network platform  120  may in various examples execute on one or virtual machines and/or real servers of data center  201 , or off-site. 
     In the example of  FIG. 2 , network infrastructure  222  represents the cloud exchange switching fabric and includes multiple ports that may be dynamically interconnected with virtual circuits by, e.g., invoking service interface  114  of the programmable network platform  120 . Each of the ports is associated with one of carriers  106 , customers  108 , and CSPs  110 . 
     In some examples, a cloud exchange seller (e.g., an enterprise or a CSP nested in a CSP) may request and obtain an L3 instance, and may then create a seller profile associated with the L3 instance, and subsequently operate as a seller on the cloud exchange. The techniques of this disclosure enable multiple CSPs to participate in an Enterprise&#39;s L3 instance (e.g., an L3 “routed instance” or L2 “bridged instance”) without each CSP flow being anchored with an enterprise device. 
     In some aspects, the programmable network platform may provision a cloud exchange to deliver services made up of multiple constituent services provided by multiple different cloud service providers, where this is provided via the L3 instance as a service described herein. Each of these constituent services is referred to herein as a “micro-service” in that it is part of an overall service applied to service traffic. That is, a plurality of micro-services may be applied to service traffic in a particular “arrangement,” “ordering,” or “topology,” in order to make up an overall service for the service traffic. The micro-services themselves may be applied or offered by the cloud service providers  110 . 
       FIG. 3A  and  FIG. 3B  are block diagrams illustrating example network infrastructure and service provisioning by a programmable network platform for a cloud exchange that aggregates the cloud services of multiple cloud service providers for provisioning to customers of the cloud exchange provider and aggregates access for multiple customers to one or more cloud service providers, in accordance with techniques described in this disclosure. In this example, customer networks  308 A- 308 C (collectively, “customer networks  308 ”), each associated with a different customer, access a cloud exchange point within a data center  300  in order receive aggregated cloud services from one or more cloud service provider networks  320 , each associated with a different cloud service provider  110 . In some examples, customer networks  308  each include endpoint devices that consume cloud services provided by cloud service provider network  320 . Example endpoint devices include servers, smart phones, television set-top boxes, workstations, laptop/tablet computers, video gaming systems, teleconferencing systems, media players, and so forth. 
     Customer networks  308 A- 308 B include respective provider edge/autonomous system border routers (PE/ASBRs)  310 A- 310 B. Each of PE/ASBRs  310 A,  310 B may execute exterior gateway routing protocols to peer with one of PE routers  302 A- 302 B (“PE routers  302 ” or more simply “PEs  302 ”) over one of access links  316 A- 316 B (collectively, “access links  316 ”). In the illustrated examples, each of access links  316  represents a transit link between an edge router of a customer network  308  and an edge router (or autonomous system border router) of cloud exchange point  303 . For example, PE  310 A and PE  302 A may directly peer via an exterior gateway protocol, e.g., exterior BGP, to exchange L3 routes over access link  316 A and to exchange L3 data traffic between customer network  308 A and cloud service provider networks  320 . Access links  316  may in some cases represent and alternatively be referred to as attachment circuits for IP-VPNs configured in IP/MPLS fabric  301 , as described in further detail below. Access links  316  may in some cases each include a direct physical connection between at least one port of a customer network  308  and at least one port of cloud exchange point  303 , with no intervening transit network. Access links  316  may operate over a VLAN or a stacked VLAN (e.g, QinQ), a VxLAN, an LSP, a GRE tunnel, or other type of tunnel. 
     While illustrated and primarily described with respect to L3 connectivity, PE routers  302  may additionally offer, via access links  316 , L2 connectivity between customer networks  308  and cloud service provider networks  320 . For example, a port of PE router  302 A may be configured with an L2 interface that provides, to customer network  308 A, L2 connectivity to cloud service provider  320 A via access link  316 A, with the cloud service provider  320 A router  312 A coupled to a port of PE router  304 A that is also configured with an L2 interface. The port of PE router  302 A may be additionally configured with an L3 interface that provides, to customer network  308 A, L3 connectivity to cloud service provider  320 B via access links  316 A. PE  302 A may be configured with multiple L2 and/or L3 sub-interfaces such that customer  308 A may be provided, by the cloud exchange provider, with a one-to-many connection to multiple cloud service providers  320 . 
     To create an L2 interconnection between a customer network  308  and a cloud service provider network  320 , in some examples, IP/MPLS fabric  301  is configured with an L2 bridge domain (e.g., an L2 virtual private network (L2VPN) such as a virtual private LAN service (VPLS), E-LINE, or E-LAN) to bridge L2 traffic between a customer-facing port of PEs  302  and a CSP-facing port of cloud service providers  320 . In some cases, a cloud service provider  320  and customer  308  may have access links to the same PE router  302 ,  304 , which bridges the L2 traffic using the bridge domain. 
     To create an L3 interconnection between a customer network  308  and a cloud service provider network  320 , in some examples, IP/MPLS fabric  301  is configured with L3 virtual routing and forwarding instances (VRFs), as described in further detail below with respect to  FIG. 4 . In some cases, IP/MPLS fabric  301  may be configured with an L3 instance that includes one or more VRFs, and the L3 instance may link multiple cloud service provider networks  320 . In this case, a customer network  308  might not need to be interconnected or have any physical presence in the cloud exchange or data center. 
     Each of access links  316  and aggregation links  322  may include a network interface device (NID) that connects customer network  308  or cloud service provider  328  to a network link between the NID and one of PE routers  302 ,  304 . Each of access links  316  and aggregation links  322  may represent or include any of a number of different types of links that provide L2 and/or L3 connectivity. 
     In this example, customer network  308 C is not an autonomous system having an autonomous system number. Customer network  308 C may represent an enterprise, network service provider, or other customer network that is within the routing footprint of the cloud exchange point. Customer network includes a customer edge (CE) device  311  that may execute exterior gateway routing protocols to peer with PE router  302 B over access link  316 C. In various examples, any of PEs  310 A- 310 B may alternatively be or otherwise represent CE devices. 
     Access links  316  include physical links. PE/ASBRs  310 A- 310 B, CE device  311 , and PE routers  302 A- 302 B exchange L2/L3 packets via access links  316 . In this respect, access links  316  constitute transport links for cloud access via cloud exchange point  303 . Cloud exchange point  303  may represent an example of any of cloud exchange points  128 . Data center  300  may represent an example of data center  201 . 
     Cloud exchange point  303 , in some examples, aggregates customers  308  access to the cloud exchange point  303  and thence to any one or more cloud service providers  320 .  FIG. 3A  and  FIG. 3B , e.g., illustrate access links  316 A- 316 B connecting respective customer networks  308 A- 308 B to PE router  302 A of cloud exchange point  303  and access link  316 C connecting customer network  308 C to PE router  302 B. Any one or more of PE routers  302 ,  304  may comprise ASBRs. PE routers  302 ,  304  and IP/MPLS fabric  301  may be configured according to techniques described herein to interconnect any of access links  316  to any of cloud aggregation links  322 . As a result, cloud service provider network  320 A, e.g., needs only to have configured a single cloud aggregate link (here, access link  322 A) in order to provide services to multiple customer networks  308 . That is, the cloud service provider operating cloud service provider network  302 A does not need to provision and configure separate service links from cloud service provider network  302 A to each of PE routers  310 ,  311 , for instance, in order to provide services to each of customer network  308 . Cloud exchange point  303  may instead connect cloud aggregation link  322 A and PE  312 A of cloud service provider network  320 A to multiple cloud access links  316  to provide layer 3 peering and network reachability for the cloud services delivery. 
     In addition, a single customer network, e.g., customer network  308 A, need only to have configured a single cloud access link (here, access link  316 A) to the cloud exchange point  303  within data center  300  in order to obtain services from multiple cloud service provider networks  320  offering cloud services via the cloud exchange point  303 . That is, the customer or network service provider operating customer network  308 A does not need to provision and configure separate service links connecting customer network  308 A to different PE routers  312 , for instance, in order to obtain services from multiple cloud service provider networks  320 . Cloud exchange point  303  may instead connect cloud access link  316 A (again, as one example) to multiple cloud aggregate links  322  to provide layer 3 peering and network reachability for the cloud services delivery to customer network  308 A. 
     Cloud service provider networks  320  each includes servers configured to provide one or more cloud services to users. These services may be categorized according to service types, which may include for examples, applications/software, platforms, infrastructure, virtualization, and servers and data storage. Example cloud services may include content/media delivery, cloud-based storage, cloud computing, online gaming, IT services, etc. 
     Cloud service provider networks  320  include PE routers  312 A- 312 D that each executes an exterior gateway routing protocol, e.g., eBGP, to exchange routes with PE routers  304 A- 304 B (collectively, “PE routers  304 ”) of cloud exchange point  303 . Each of cloud service provider networks  320  may represent a public, private, or hybrid cloud. Each of cloud service provider networks  320  may have an assigned autonomous system number or be part of the autonomous system footprint of cloud exchange point  303 . 
     In the illustrated example, an Internet Protocol/Multiprotocol label switching (IP/MPLS) fabric  301  interconnects PEs  302  and PEs  304 . IP/MPLS fabric  301  include one or more switching and routing devices, including PEs  302 ,  304 , that provide IP/MPLS switching and routing of IP packets to form an IP backbone. In some example, IP/MPLS fabric  301  may implement one or more different tunneling protocols (i.e., other than MPLS) to route traffic among PE routers and/or associate the traffic with different IP-VPNs. In accordance with techniques described herein, IP/MPLS fabric  301  implement IP virtual private networks (IP-VPNs) to connect any of customers  308  with multiple cloud service provider networks  320  to provide a data center-based ‘transport’ and layer 3 connection. 
     Whereas service provider-based IP backbone networks require wide-area network (WAN) connections with limited bandwidth to transport service traffic from layer 3 services providers to customers, the cloud exchange point  303  as described herein ‘transports’ service traffic and connects cloud service providers  320  to customers  308  within the high-bandwidth local environment of data center  300  provided by a data center-based IP/MPLS fabric  301 . In some examples, IP/MPLS fabric  301  implements IP-VPNs using techniques described in Rosen &amp; Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” Request for Comments  4364 , February 2006, Internet Engineering Task Force (IETF) Network Working Group, the entire contents of which is incorporated by reference herein. In some example configurations, a customer network  308  and cloud service provider network  320  may connect via respective links to the same PE router of IP/MPLS fabric  301 . 
     Access links  316  and aggregation links  322  may include attachment circuits that associate traffic, exchanged with the connected customer network  308  or cloud service provider network  320 , with virtual routing and forwarding instances (VRFs) configured in PEs  302 ,  304  and corresponding to IP-VPNs operating over IP/MPLS fabric  301 . For example, PE  302 A may exchange IP packets with PE  310 A on a bidirectional label-switched path (LSP) operating over access link  316 A, the LSP being an attachment circuit for a VRF configured in PE  302 A. As another example, PE  304 A may exchange IP packets with PE  312 A on a bidirectional label-switched path (LSP) operating over access link  322 A, the LSP being an attachment circuit for a VRF configured in PE  304 A. Each VRF may include or represent a different routing and forwarding table with distinct routes. 
     PE routers  302 ,  304  of IP/MPLS fabric  301  may be configured in respective hub-and-spoke arrangements for cloud services, with PEs  304  implementing cloud service hubs and PEs  302  being configured as spokes of the hubs (for various hub-and-spoke instances/arrangements). A hub-and-spoke arrangement ensures that service traffic is enabled to flow between a hub PE and any of the spoke PEs, but not directly between different spoke PEs. As described further below, in a hub-and-spoke arrangement for data center-based IP/MPLS fabric  301  and for southbound service traffic (i.e., from a CSP to a customer) PEs  302  advertise routes, received from PEs  310 , to PEs  304 , which advertise the routes to PEs  312 . For northbound service traffic (i.e., from a customer to a CSP), PEs  304  advertise routes, received from PEs  312 , to PEs  302 , which advertise the routes to PEs  310 . 
     For some customers of cloud exchange point  303 , the cloud exchange point  303  provider may configure a full mesh arrangement whereby a set of PEs  302 ,  304  each couple to a different customer site network for the customer. In such cases, the IP/MPLS fabric  301  implements a layer 3 VPN (L3VPN) for cage-to-cage or redundancy traffic (also known as east-west or horizontal traffic). The L3VPN may effectuate a closed user group whereby each customer site network can send traffic to one another but cannot send or receive traffic outside of the L3VPN. 
     PE routers may couple to one another according to a peer model without use of overlay networks. That is, PEs  310  and PEs  312  might not peer directly with one another to exchange routes, but rather indirectly exchange routes via IP/MPLS fabric  301 . In the example of  FIG. 3B , cloud exchange point  303  is configured to implement multiple layer 3 virtual circuits  330 A- 330 C (collectively, “virtual circuits  330 ”) to interconnect customer network  308  and cloud service provider networks  322  with end-to-end IP paths. Each of cloud service providers  320  and customers  308  may be an endpoint for multiple virtual circuits  330 , with multiple virtual circuits  330  traversing one or more attachment circuits between a PE/PE or PE/CE pair for the IP/MPLS fabric  301  and the CSP/customer. A virtual circuit  330  represents a layer 3 path through IP/MPLS fabric  301  between an attachment circuit connecting a customer network to the fabric  301  and an attachment circuit connecting a cloud service provider network to the fabric  301 . Each virtual circuit  330  may include at least one tunnel (e.g., an LSP and/or Generic Route Encapsulation (GRE) tunnel) having endpoints at PEs  302 ,  304 . PEs  302 ,  304  may establish a full mesh of tunnels interconnecting one another. 
     Each virtual circuit  330  may include a different hub-and-spoke network configured in IP/MPLS network  301  having PE routers  302 ,  304  exchanging routes using a full or partial mesh of border gateway protocol peering sessions, in this example a full mesh of Multiprotocol Interior Border Gateway Protocol (MP-iBGP) peering sessions. MP-iBGP or simply MP-BGP is an example of a protocol by which routers exchange labeled routes to implement MPLS-based VPNs. However, PEs  302 ,  304  may exchange routes to implement IP-VPNs using other techniques and/or protocols. 
     In the example of virtual circuit  330 A, PE router  312 A of cloud service provider network  320 A may send a route for cloud service provider network  320 A to PE  304 A via a routing protocol (e.g., eBGP) peering connection with PE  304 A. PE  304 A associates the route with a hub-and-spoke network, which may have an associated VRF, that includes spoke PE router  302 A. PE  304 A then exports the route to PE router  302 A; PE router  304 A may export the route specifying PE router  304 A as the next hop router, along with a label identifying the hub-and-spoke network. PE router  302 A sends the route to PE router  310 B via a routing protocol connection with PE  310 B. PE router  302 A may send the route after adding an autonomous system number of the cloud exchange point  303  (e.g., to a BGP autonomous system path (AS_PATH) attribute) and specifying PE router  302 A as the next hop router. Cloud exchange point  303  is thus an autonomous system “hop” in the path of the autonomous systems from customers  308  to cloud service providers  320  (and vice-versa), even though the cloud exchange point  303  may be based within a data center. PE router  310 B installs the route to a routing database, such as a BGP routing information base (RIB) to provide layer 3 reachability to cloud service provider network  320 A. In this way, cloud exchange point  303  “leaks” routes from cloud service provider networks  320  to customer networks  308 , without cloud service provider networks  320  to customer networks  308  requiring a direct layer peering connection. 
     PE routers  310 B,  302 A,  304 A, and  312 A may perform a similar operation in the reverse direction to forward routes originated by customer network  308 B to PE  312 A and thus provide connectivity from cloud service provider network  320 A to customer network  308 B. In the example of virtual circuit  330 B, PE routers  312 B,  304 A,  302 A, and  310 B exchange routes for customer network  308 B and cloud service provider  320 B in a manner similar to that described above for establishing virtual circuit  330 B. As a result, cloud exchange point  303  within data center  300  internalizes the peering connections that would otherwise be established between PE  310 B and each of PEs  312 A,  312 B so as to perform cloud aggregation for multiple layer 3 cloud services provided by different cloud service provider networks  320 A,  320 B and deliver the multiple, aggregated layer 3 cloud services to a customer network  308 B having a single access link  316 B to the cloud exchange point  303 . 
     Absent the techniques described herein, fully interconnecting customer networks  308  and cloud service provider networks  320  would require 3×3 peering connections between each of PEs  310  and at least one of PEs  312  for each of cloud service provider networks  320 . For instance, PE  310 A would require a layer 3 peering connection with each of PEs  312 . With the techniques described herein, cloud exchange point  303  may fully interconnect customer networks  308  and cloud service provider networks  320  with one peering connection per site PE (i.e., for each of PEs  310  and PEs  312 ) by internalizing the layer 3 peering and providing data center-based ‘transport’ between cloud access and cloud aggregate interfaces. 
     In examples in which IP/MPLS fabric  301  implements BGP/MPLS IP VPNs or other IP-VPNs that use route targets to control route distribution within the IP backbone, PEs  304  may be configured to import routes from PEs  302  and to export routes received from PEs  312 , using different asymmetric route targets. Likewise, PEs  302  may be configured to import routes from PEs  304  and to export routes received from PEs  310  using the asymmetric route targets. Thus, PEs  302 ,  304  may configured to implement advanced L3VPNs that each includes a basic backbone L3 VPN of IP/MPLS fabric  301  together with extranets of any of customer networks  308  and any of cloud service provider networks  320  attached to the basic backbone L3VPN. 
     Each advanced L3VPN constitutes a cloud service delivery network from a cloud service provider network  320  to one or more customer networks  308 , and vice-versa. In this way, cloud exchange point  303  enables any cloud service provider network  320  to exchange cloud service traffic with any customer network  308  while internalizing the layer 3 routing protocol peering connections that would otherwise be established between pairs of customer networks  308  and cloud service provider networks  320  for any cloud service connection between a given pair. In other words, the cloud exchange point  303  allows each of customer networks  308  and cloud service provider networks  320  to establish a single (or more for redundancy or other reasons) layer 3 routing protocol peering connection to the data center-based layer 3 connect. By filtering routes from cloud service provider networks  320  to customer networks  308 , and vice-versa, PEs  302 ,  304  thereby control the establishment of virtual circuits  330  and the flow of associated cloud service traffic between customer networks  308  and cloud service provider networks  320  within a data center  300 . Routes distributed into MP-iBGP mesh  318  may be VPN-IPv4 routes and be associated with route distinguishers to distinguish routes from different sites having overlapping address spaces. 
     Programmable network platform  120  may receive service requests for creating, reading, updating, and/or deleting end-to-end services of the cloud exchange point  303 . In response, programmable network platform  120  may configure PEs  302 ,  304  and/or other network infrastructure of IP/MPLS fabric  301  to provision or obtain performance or other operations information regarding the service. Operations for provisioning a service and performed by programmable network platform  120  may include configuring or updating VRFs, installing SDN forwarding information, configuring LSPs or other tunnels, configuring BGP, configuring access links  316  and aggregation links  322 , or otherwise modifying the configuration of the IP/MPLS fabric  301 . Other operations may include making service requests to an orchestration system for cloud service provider networks  320 , as described in further detail below. 
       FIG. 4  is a block diagram illustrating an example of a data center-based cloud exchange point in which routers of the cloud exchange point are configured by programmable network platform  120  with VPN routing and forwarding instances for routing and forwarding aggregated service traffic from multiple cloud service provider networks to a customer network, according to techniques described herein. In this example, to establish virtual circuits  330 A- 330 B, PE routers  302 A and  304 A of IP/MPLS fabric  301  are configured with VRFs. PE  302 A is configured with VRFs  402 A and  404 A, while PE  304 A is configured with VRFs  402 B and  404 B. VRF  402 A is configured to import routes exported by VRF  402 B, and VRF  402 B is configured to import routes exported by VRF  402 A. The configuration may include asymmetric route targets for import/export between VRFs  402 A,  402 B. VRF  404 A is configured to import routes exported by VRF  402 B, and VRF  402 B is configured to import routes exported by VRF  402 A. The configuration may include asymmetric route targets for import/export between VRFs  402 A,  402 B. This configuration whereby a customer can access multiple layer 3 services from different CSPs each associated with separate VRFs to access the layer 3 services provides isolation of respective traffic exchanged with the CSPs. In some examples, PE  302 A may be configured with a single VRF to import routes exported by both VRF  402 B and VRF  404 B. As noted above with respect to  FIG. 3A  and  FIG. 3B , PEs  302 ,  304  may be further configured to bridge layer 2 traffic between customer  308 B and cloud service providers  320 . 
     In this example, PE  304 A operates BGP or other route distribution protocol peering connections  406 B,  408 B with respective PEs  312 A,  312 B to exchange routes with respective cloud service provider networks  320 A,  320 B. PE  302 A operates a BGP or other route distribution protocol peering connection  410  with PE  310 B to exchange routes with customer network  308 B. In some examples, PEs  302 A,  304 A may be statically configured with routes for the site networks. 
     An administrator or a programmable network platform described herein for cloud exchange point  303  may configure PEs  302 A,  304 A with the VRF  402 A- 402 B,  404 A- 404 B in order to leak routes between PEs  312  and PE  310 B and facilitate layer 3 connectivity for end-to-end IP paths illustrated here by virtual circuits  330 , while potentially optimizing the end-to-end IP paths by fostering data center-based or at least metro-based connectivity. Cloud exchange point  303  may thus provide dedicated cloud service provider access to customer network  308 B by way of private and/or public routes for the cloud service provider networks  320 . In the northbound direction, cloud exchange point  303  may provide dedicated cloud service provider distribution to multiple customer networks  308  by way of private and/or public routes for the customer networks  308 . Neither PE  310 B nor any of PEs  302 A,  304 A need access to the full Internet BGP routing table to reach cloud service provider networks  320  or customer networks  308 . Moreover, PEs  302 A,  304 A may be configured to aggregate customer/CSP routes and/or service traffic based on any one or more of physical, IP, service, and VRFs. 
       FIG. 5  is a block diagram illustrating an example of a data center-based cloud exchange point, according to techniques described herein. Cloud service provider networks  320  and customer networks  308  are not shown in  FIG. 5  for ease of illustration purposes. In these examples, the data center-based cloud exchange point  303  applies a network address translation (NAT) service  719  to, in part, enforce network address separation between the cloud service layer accessible via cloud aggregation links  322  and the cloud access layer accessible via cloud access links  316 . 
     A cloud exchange point  303  NAT device(s) that applies NAT service  719  performs NAT (or NAPT), which may also or alternatively include carrier-grade NAT (“CG-NAT” or “CGN”), to translate the cloud exchange point  303  addresses and CSP routes and/or to translate the cloud exchange point  303  addresses and customer routes. The cloud exchange point  303  NAT device(s) that applies NAT service  719  (also referred to herein as “NAT service  719  device”) may include one or more dedicated NAT appliances, one or more virtual machines executing on real server(s) and configured to apply NAT using network function virtualization (NFV), one or more service cards configured to apply the NAT service  719  and inserted in one or more of PEs  302 ,  304 , or other device(s) inbox or out-of-box. 
     NAT service  719  of  FIG. 5  may be implemented in one or more NAT service devices. In  FIG. 5 , the NAT service  719  is associated with an address pool  720  that is configured with routes for the cloud exchange point  303  autonomous system and from which the NAT service  719  may draw to automatically provision and map, for NAT purposes, to customer and/or cloud service provider routes received via peering sessions  700  and  708 A- 708 B, respectively. The network addresses for configured routes in address pool  720  (or “NAT pool  720 ”) may be public, private, or a combination thereof, and may represent IPv4 and/or IPv6 routes. In some examples, the network addresses are public in order to provide global uniqueness for the network addresses. 
     Address mappings  722  may specify one or more NAT mappings and/or network address and port translations (NAPT) that associate routes from address pool  720  for the cloud exchange point  303  with routes received by the cloud exchange point  303  routers from any of PEs  310 ,  312 . Routes received from any of PEs  310 ,  312  for translation and used in end-to-end service delivery may include any IP addresses/prefixes from enterprise/NSP customers of the cloud exchange provider, such addresses including private and/or public IPv4 and/or IPv6 addresses and received at any one or more of the cloud exchange points managed by the cloud exchange provider. 
     As noted above, NAT service  719  may perform NAT to translate customer routes for customer network  308 B (not shown in  FIG. 5 ) and cloud exchange point  303  routes advertised to PEs  312 A,  312 B for aggregated cloud access. As a result, CSP networks  320  (not shown in FIG.  5 ) receive the cloud exchange point  303  routes drawn from address pool  720  instead of the customer routes. The cloud exchange point  303  is thus able to filter customer network information from the CSPs, and the CSPs receive cloud exchange point  303  routes associated with a single autonomous system (i.e., the cloud exchange point  303  and one ASN per cloud exchange point) rather than customer routes (which could potentially number in the millions) associated with multiple different autonomous systems (and corresponding ASNs, which could potentially number in the hundreds) for various customers (enterprises and/or NSPs). 
     Further, because the cloud exchange point  303  does not advertise its routes other than to customers and CSPs, the cloud exchange point  303  does not announce its routes to the Internet, which may improve security and reduce the potential for Denial of Service (DoS) or other malicious activity directed to the cloud exchange point  303  and customers/CSPs with which the cloud exchange point  303  has peering relationships. In addition, the techniques described above may simplify end-to-end cloud service delivery processing and improve performance by ensuring that local traffic is processed locally (within the cloud exchange point  303 ). 
     In the illustrated example, NAT service  719  is associated with ingress service VRF  712  (“ingress  712 ”) and egress service VRF  714  (“egress  714 ”) for attracting service traffic that is associated with customer network  308 B and that is to be NATted. Ingress  712  and egress  714  constitute part of a customer service chain for cloud service traffic between customer network  308 B and CSP networks  320 A,  320 B. Customer VRF  710  associated customer network  308 B receives routes from customer PE  310 B via peering session  700 . Customer VRF  710  may be configured in a VPN-full mesh relationship with ingress service VRFs distributed in the cloud exchange point  303  (only one peering session  702  is illustrated, however). 
     In some examples, PE  302 A distributes, for VRF  710 , customer routes received via peering session  700  to the NAT service  719 , which dynamically maps the customer route prefixes to cloud exchange point route prefixes drawn from address pool  720 . The customer routes are installed to ingress service VRF  712 . The NAT service  719  installs the mappings to address mappings  722  and installs, to egress service VRF  714 , cloud exchange point routes that specify the cloud exchange point route prefixes and NAT service  719  as the next hop. In this way, NAT service  719  and more specifically egress service VRF  714  attracts downstream traffic from CSP network  320  that is intended for the customer network  308 B but destined for the cloud exchange point routes installed to egress service VRF  714 . Ingress service VRF  712  and egress service VRF  714  may establish peering session  704  and be configured with route targets to cause VRFs  712 ,  714  to leak routes to one another via iBGP, for instance. 
     Egress service VRF  714  may operate as a spoke VRF for corresponding hub VRFRs  730 A,  730 B in a manner similar to VRFs of PE  302 A operating as spoke VRFs in the example of  FIG. 4 . That is, egress service VRF  714  and VRFs  730 A,  730 B are configured with reciprocal route targets such that egress service VRF  714  advertises routes for the egress service VRF  714  for installation to VRFs  730 A,  730 B, while VRFs  730 A,  730 B advertise routes for corresponding CSP networks  320 A,  320 B to egress service VRF  714 . NATted upstream service traffic destined to any of CSP networks  320 A,  320 B passes through corresponding hub VRFs  730 A,  730 B. Each of peering sessions  706 A,  706 B may be used in this way to create hub-and-spoke VPNs for the respective CSP networks  320 A,  320 B. 
     PEs  302 ,  304  may establish tunnels with the NAT service  719  device. Routes exchanged via peering sessions  702  and  706 A,  706 B may include labeled routes for implementing MPLS/BGP IP-VPNs according to RFC 4364, incorporated above. 
     Cloud exchange point  303  may forward and apply NAT service  719  to downstream service traffic from PE  312 A, intended for customer network  308 A, as follows. PE  304 A receives a service packet on aggregation link  322 A. The packet has a destination address that is a cloud exchange point  303  address drawn from address pool  720 . VRF  730 A associated with aggregation link  322 A stores a route for the destination address that specifies an address for the NAT service  719  device, and PE  304 A tunnels the packet using VRF  730 A to the NAT service  719  device for application of the NAT service. 
     NAT service  719  uses address mappings  722  dynamically provisioned for routes for customer network  308 A and received from PE  302 A to perform NAT and replace the service packet destination address with a destination address in customer network  308 A. The NAT service  719  device may determine in ingress service VRF  712  the labeled route to PE  302 A (the label identifying VRF  710 ) and tunnel the modified service packet PE  302 A, which may identify VRF  710  from the label attached to the modified service packet. PE  302 A forwards the modified service packet to PE  310  via access link  316 B. In this way, cloud exchange point  303  provides a NAT service to the customer to separate the customer from the cloud service layer. In a similar way, the cloud exchange point  303  may apply NAT to upstream traffic to separate cloud service providers from the cloud or network access layer by which customer networks access the cloud exchange point. 
       FIG. 6A  through  FIG. 6F  are conceptual diagrams illustrating example cryptographic operations performed within an example data center, in accordance with one or more aspects of the present disclosure. Each of  FIG. 6A  through  FIG. 6F  illustrate data center  601  of system  600 . In each Figure, data center  601  includes cloud services exchange  200  (or “cloud exchange  200 ”). Cloud services exchange  200  communicates with any number of cloud service provider networks, including cloud service provider networks  110 A through  110 N (collectively “cloud service provider networks  110 ”) over CSP ports  612  using a communication channel, which may be private communication channel such as a virtual circuit. 
     System  600  further includes customer networks  203 A,  203 B, through  203 N (collectively “customer networks  203 ,” which represent any number of customer networks), and network service provider (NSP) networks  204 A,  204 B,  204 C, through  204 N (collectively “NSP networks  204 ,” which represent any number of NSP networks). Some of customer networks  203  may be included within or colocated within data center  601 , and other customer networks  203  may be located outside of data center  601  but may access data center  601  through an external connection or through one or more NSP networks  204 . Similarly, some of NSP networks  204  may be included within or colocated within data center  601  (e.g., NSP network  204 A), and other NSP networks  204  may be located outside of data center  601  (e.g., NSP network  204 B) but may access or communicate with data center  601  through an external connection. Each of customer networks  203  and/or NSP networks  204  may communicate with cloud services exchange  200  through customer ports  610  using a communication channel, which may be private communication channel such as a virtual circuit. 
     One or more customer computing devices  108 , such as customer computing devices  108 A,  108 B,  108 C, through  108 N (collectively “customer computing devices  108 ”) may each be operated by cloud customers and may receive services on behalf of or for the benefit of such customers from cloud services exchange  200 , data center  601 , and/or cloud service provider networks  110 . In some examples, each of customer computing devices  108  may access services of cloud services exchange  200  through a service interface or API (not shown in  FIG. 6A  through  FIG. 6F ) that may be integrated into a programmable network platform (also not shown in  FIG. 6A  through  FIG. 6F ). Such a services interface may be similar to service interface  114  of  FIG. 1  and/or  FIG. 2 . A programmable network platform implemented within  FIG. 6A  through  FIG. 6F  may correspond to or be similar to programmable network platform  120  of  FIG. 1  and/or  FIG. 2 . 
     In the illustrations of  FIG. 6A  through  FIG. 6F , customer network  203 A and customer computing device  108 A are considered to be associated with the same customer (e.g., “customer A”), and customer network  203 B and customer computing device  108 B are likewise assumed to be associated with the same customer (e.g., “customer B”). A similar convention applies to other customer networks  203  and customer computing devices  108  illustrated in  FIG. 6B  through  FIG. 6F  for any number of N customers. 
     As with cloud exchange  100  of  FIG. 1 , cloud services exchange  200  may provide customers of the exchange (e.g., enterprises, network carriers, network service providers, and SaaS customers), with secure, private, virtual connections to multiple cloud service providers (CSPs) globally. Each of cloud service provider networks  110  may participate in the cloud exchange by virtue of their having at least one accessible port in the cloud exchange by which one or more customer computing devices  108 , customer networks  203 , and/or NSP networks  204  can connect to the one or more cloud services offered by cloud service provider networks  110 , e.g., using a virtual circuit provided by the cloud services exchange  200 . Cloud services exchange  200  may allow private networks of customers to be directly cross-connected to other customers at a common point, thereby allowing direct exchange of network traffic between the networks of the customers. 
     Cloud services exchange  200  includes network infrastructure  222  and one or more computing systems  150 . Network infrastructure  222  may correspond to network infrastructure  222  of  FIG. 2  and may provide a L2/L3 switching fabric by which cloud service provider networks  110  and customers/NSPs interconnect, thereby enabling an NSP/customer to have options to create many-to-many interconnections with a one-time hook up to the switching network and underlying network infrastructure  222  that presents an interconnection platform for cloud exchange  200 . Cloud exchange  200  may thereby allow customers to interconnect to multiple cloud service provider networks  110  and cloud services using network infrastructure  222  within data center  601 . Computing system  150  may correspond to computing system  150  of  FIG. 1  and may provide access to one or more hardware security modules  151  for the purpose of providing cryptographic services, such as storage, creation, use, or other operations relating to one or more cryptographic keys  631  (including, e.g., cryptographic key  631 A) stored within one or more hardware security modules  151 . The cloud exchange  200  provider may also provision and manage computing system  150  of the cloud exchange  200 . As used herein, operations attributed to cloud exchange  200  may include operations of computing system  150  of the cloud exchange  200 . 
     For ease of illustration, only a limited number of cloud service provider networks  110 , data centers  601 , cloud services exchanges  200 , hardware security modules  151 , customer networks  203 , NSP networks  204 , customer computing devices  108 , and other components or devices are shown within  FIG. 6A  through  FIG. 6F  and/or in other illustrations referenced herein. However, techniques in accordance with one or more aspects of the present disclosure may be performed with many more of such systems, and collective references to components, devices, modules, and/or systems may represent any number of such components, devices, modules, and/or systems. 
     In  FIG. 6A , and in accordance with one or more aspects of the present disclosure, cloud services exchange  200  may encrypt data at the direction of an authenticated user of customer computing device  108 A. In an example that can be described with reference to  FIG. 6A , cloud services exchange  200 A may authenticate a user of customer computing device  108 A. For instance, in such an example, customer computing device  108 A outputs a signal over NSP network  204 A. NSP network  204 A communicates information about the signal over customer ports  610 , and the information about the signals is presented to a service interface of cloud services exchange  200 . Computing system  150  of cloud services exchange  200  determines that the signals include authentication credentials for a user of  108 A. Computing system  150  evaluates the authentication credentials and determines that the user of customer computing device  108 A is authorized to access some or all services provided by cloud services exchange  200 . 
     Cloud services exchange  200  may encrypt data  621 A received from customer computing device  108 A. For instance, in the example of  FIG. 6A , customer computing device  108 A outputs one or more signals over NSP network  204 A (see, e.g., reference arrow “ 1 ” in  FIG. 6A ). NSP network  204 A communicates information about the signals over customer ports  610  to cloud services exchange  200  (e.g., through a service interface or API). Computing system  150  within cloud services exchange  200  determines that the signals include data  621 A. Computing system  150  further determines that the signals correspond to a request, by an authenticated user of customer computing device  108 A, to create an encryption key, encrypt data  621 A, and store encrypted data  621 A. Computing system  150  causes one or more hardware security modules  151  to generate cryptographic key  631 A and associate cryptographic key  631 A with a name or identifier specified by a user of customer computing device  108 A. Hardware security module  151  stores cryptographic key  631 A securely within hardware included within hardware security module  151 , and cryptographic operations involving cryptographic key  631 A can thereafter be performed within hardware security module  151  by an authorized user specifying the name or identifier. Computing system  150  causes one or more hardware security modules  151  to encrypt data  621 A using cryptographic key  631 A, thereby producing encrypted data  621 A. 
     Cloud services exchange  200  may store encrypted data  621 A at one or more storage devices within system  600 . For instance, computing system  150  provides cloud services exchange  200  with access to encrypted data  621 A. Cloud services exchange  200  outputs, over CSP ports  612 , encrypted data  621 A to one or more of cloud service provider networks  110  for storage within one or more of cloud service provider networks  110 , without providing any of cloud service provider networks  110  access to cryptographic key  631 A (see reference arrow “ 2 ”). In the example shown in  FIG. 6A , cloud services exchange  200  outputs encrypted data  621 A to cloud service provider network  110 A for storage within cloud service provider network  110 A. In other examples, encrypted data  621 A may be stored elsewhere within system  600 . For example, cloud services exchange  200  may, alternatively or in addition, output encrypted data  621 A to customer network  203 A within system  600 , and one or more devices within customer network  203 A may store encrypted data  621 A, again without providing any device within customer network  203 A access to cryptographic key  631 A. Alternatively or in addition, cloud services exchange  200  may output encrypted data  621 A over NSP network  204 A for storage within customer computing device  108 A, also without providing customer computing device  108 A or any user of customer computing device  108 A with access to cryptographic key  631 A. Still further, cloud services exchange  200  may store encrypted data  621 A at another device within system  600 . 
     Thereafter, one or more devices within system  600  may access encrypted data  621 A making an appropriate request for the data from cloud services exchange  200 . For instance, in one example, and as further described in connection with  FIG. 6D  through  FIG. 6F , customer computing device  108 A may access data  621 A by authenticating with cloud services exchange  200  (and/or one or more of cloud service provider networks  110 ), and requesting access to data  621 A. In response to an appropriate request from customer computing device  108 A, cloud services exchange  200  retrieves data  621 A from storage (e.g., one or more of cloud service provider networks  110 , customer network  203 A, or elsewhere). Computing system  150  causes hardware security module  151  to decrypt data  621 C within hardware security module  151  using cryptographic key  631 A. Computing system  150  then outputs unencrypted (e.g., “plain text”) data  621 A (through a secure communication channel) to customer computing device  108 A. 
     Computing system  150  may similarly encrypt data received from one or more other customer computing devices  108 . In such an example, computing system  150  may cause one or more hardware security modules  151  to encrypt data and store the encrypted data at a specified location (e.g., within one or more of cloud service provider networks  110 , within data center  601 , or at another location). Accordingly, computing system  150  may provide cryptographic services, using hardware security modules  151 , to multiple customers, and enable storage at such data at multiple locations, including any of cloud service provider networks  110 . 
       FIG. 6B  illustrates an example operation in which cloud services exchange  200  may encrypt data received from customer network  203 A. For instance, in the example of  FIG. 6B , customer computing device  108 A outputs one or more signals over NSP network  204 A, and NSP network  204 A communicates information about the signals to cloud services exchange  200  over customer ports  610 . Cloud services exchange  200  determines that the signals correspond to a request to access data  621 B stored within customer network  203 A. Cloud services exchange  200  further determines that the signals include a request to encrypt data  621 B using cryptographic key  631 B, and store encrypted data  621 B. 
     Cloud services exchange  200  outputs one or more signals to customer network  203 A. Responsive to the signals, one or more computing devices within customer network  203 A generates and/or accesses data  621 B. One or more devices within customer network  203 A output one or more signals from customer network  203 A to cloud services exchange  200  over customer ports  610  (reference arrow  1  in  FIG. 6B ). Cloud services exchange  200  receives a signal and communicates information about the signal to computing system  150 . Computing system  150  determines that the signal includes data  621 B, generated by and/or accessed within customer network  203 A. In the example of  FIG. 6B , cryptographic key  631 B is stored within one or more hardware security modules  151 , possibly as a result of a previous encryption key generation operation. Computing system  150  causes one or more of hardware security modules  151  to access cryptographic key  631 B and encrypt data  621 B using cryptographic key  631 B. 
     As in the earlier example, cloud services exchange  200  may store encrypted data  621 B at one or more storage devices within system  600 . For instance, in the example of  FIG. 6B , computing system  150  provides cloud services exchange  200  with access to encrypted data  621 B. Cloud services exchange  200  outputs, over CSP ports  612 , encrypted data  621 B to cloud service provider network  110 A for storage within one or more devices included within cloud service provider network  110 A (reference arrow  2 ). Although in the example of  FIG. 6B  cloud services exchange  200  stores encrypted data  621 B within cloud service provider network  110 A, cloud services exchange  200  may alternatively, or in addition, store encrypted data  621 B within one or more other cloud service provider networks  110 , within devices included within customer network  203 A, or within other devices within system  600 . 
       FIG. 6C  illustrates an example operation in which cloud services exchange  200  may encrypt data received from cloud service provider network  110 A. For instance, in the example of  FIG. 6C , customer computing device  108 A outputs one or more signals over NSP network  204 A, and information about the signals are communicated to cloud services exchange  200  over customer ports  610 . Computing system  150  within cloud services exchange  200  determines that the signals include a request to access data  621 C within cloud service provider network  110 A, encrypt data  621 C using cryptographic key  631 C, and store encrypted data  621 C within a different one of cloud service provider networks  110  (e.g., any of cloud service provider networks  110 B through  110 N). In response to such a determination, computing system  150  outputs one or more signals to cloud service provider network  110 A. Responsive to the signals, one or more computing devices within cloud service provider network  110 A generates and/or accesses data  621 C at one or more devices within cloud service provider network  110 A. One or more devices within cloud service provider network  110 A output one or more signals from cloud service provider network  110 A to cloud services exchange  200  over CSP ports  612  (reference arrow  1 ). Cloud services exchange  200  receives one or more signals and communicates information about the signal to computing system  150 . Computing system  150  determines that the signals include data  621 C. 
     In the example described in connection with  FIG. 6C , computing system  150  within cloud services exchange  200  determines that the signals received over customer ports  610  include a request to access data  621 C within cloud service provider network  110 A. In other examples, computing system  150  within cloud services exchange  200  might receive a request to access data  621 C within cloud service provider network  110 A, but not over ports  610 . For instance, computing system  150  might receive such a command from a different source. Such a source may include a device within cloud services exchange  200  or an external device (not connected over ports  610 ). In other examples, computing system  150  within cloud services exchange  200  might access data  621 C within cloud service provider network  110 A, based on other circumstances, including an internally generated command. Accordingly, operations described herein might not, in some examples, be prompted by input received over ports  610 . 
     In some examples, data  621 C may be unencrypted data generated by a process executed within cloud service provider network  110 A or received from another device by a system included within cloud service provider network  110 A. Computing system  150  causes one or more hardware security modules  151  to access cryptographic key  631 C within hardware security module  151  and encrypt data  621 C using cryptographic key  631 C. 
     Cloud services exchange  200  may store encrypted data  621 C at one or more cloud service provider networks  110 . For instance, in the example of  FIG. 6C , computing system  150  receives encrypted data  621 C from hardware security module  151  and outputs encrypted data  621 C to cloud service provider network  110 B over CSP ports  612 , without providing cloud service provider network  110 B access to cryptographic key  631 C (arrow  2 ). One or more devices within cloud service provider network  110 B store encrypted data  621 C. In other examples, computing system  150  may also store encrypted data  621 C at one or more other cloud service provider networks  110 , or within another device (e.g., within customer network  203 A, within customer computing device  108 A, or elsewhere within system  600 ). 
       FIG. 6D  illustrates an example operation in which cloud services exchange  200  decrypts data received from customer computing device  108 A. For instance, in the example of  FIG. 6D , customer computing device  108 A outputs one or more signals over NSP network  204 A (arrow  1 ). NSP network  204 A communicates information about the signals to cloud services exchange  200  over customer ports  610 . Computing system  150  of cloud services exchange  200  determines that the signals include encrypted data  621 D. Computing system  150  further determines that the signals correspond to a request, by an authenticated user of customer computing device  108 A, to decrypt data  621 D using cryptographic key  631 D and perform processing on unencrypted or unencrypted data  621 D. In some examples, cryptographic key  631 D is identified by a user of customer computing device  108 A through a name or identifier that hardware security module  151  associates with cryptographic key  631 D. Computing system  150  causes one or more of hardware security modules  151  to decrypt data  621 D using cryptographic key  631 D, thereby producing unencrypted data  621 D. 
     Cloud services exchange  200  may output unencrypted data  621 D to one or more devices for processing. For instance, in one example, computing system  150  provides cloud services exchange  200  with access to unencrypted data  621 D. Cloud services exchange  200  outputs unencrypted data  621 D to one or more of cloud service provider networks  110  for processing. In the example of  FIG. 6D , cloud services exchange  200  outputs unencrypted data  621 D over CSP ports  612  (e.g., through a secure channel) to cloud service provider network  110 A (arrow  2 ). One or more devices within cloud service provider network  110 A perform the requested processing on data  621 D, and generate processing results data  622 D (arrow  3 ). Cloud service provider network  110 A may store processing results data  622 D within one or more devices included within cloud service provider network  110 A. 
     Cloud services exchange  200  may store encrypted data within one or more other cloud service provider networks  110 . For instance, still referring to  FIG. 6D , cloud service provider network  110 A outputs processing results data  622 D to cloud services exchange  200  over CSP ports  612  (arrow  4 ). Computing system  150  of cloud services exchange  200  causes hardware security module  151  to encrypt processing results data  622 D using cryptographic key  631 D (or another cryptographic key). Cloud services exchange  200  outputs one or more signals over CSP ports  612  to cloud service provider network  110 B (arrow  5 ). One or more devices within cloud service provider network  110 B detect a signal, determine that the signal includes data for storage, and store processing results data  622 D. 
       FIG. 6E  illustrates an example operation in which cloud services exchange  200  decrypts data received from customer network  203 A. For instance, in the example of  FIG. 6E , customer computing device  108 A outputs one or more signals over NSP network  204 A, and NSP network  204 A communicates information about eh signals to cloud services exchange  200  over customer ports  610 . Computing system  150  of cloud services exchange  200  determines that the signals correspond to a request, by an authenticated user of customer computing device  108 A, to access data  621 E, decrypt data  621 E using cryptographic key  631 D, and perform processing on unencrypted data  621 E. Computing system  150  further determines that data  621 E is stored within customer network  203 A. Computing system  150  outputs a signal over customer ports  610  to customer network  203 A. One or more devices within customer network  203 A detect a signal and respond by outputting encrypted data  621 E to cloud services exchange  200  over customer ports  610  (arrow  1 ). Computing system  150  of cloud services exchange  200  causes hardware security module  151  to decrypt data  621 E using cryptographic key  631 E, thereby producing unencrypted data  621 E. 
     Cloud services exchange  200  may output unencrypted data  621 E to one or more devices for processing. For instance, in the example of  FIG. 6E , computing system  150  provides cloud services exchange  200  with access to unencrypted data  621 E. Cloud services exchange  200  outputs unencrypted data  621 E over CSP ports  612  (e.g., through a secure channel) to cloud service provider network  110 A (arrow  2 ). One or more devices within cloud service provider network  110 A perform the requested processing on data  621 E, and generate processing results data  622 E (arrow  3 ). Cloud service provider network  110 A may store processing results data  622 E within one or more devices included within cloud service provider network  110 A. 
     Cloud services exchange  200  may store encrypted data within one or more other cloud service provider networks  110 . For instance, still referring to  FIG. 6E , cloud service provider network  110 A outputs processing results data  622 E to cloud services exchange  200  over CSP ports  612  (arrow  4 ). Computing system  150  of cloud services exchange  200  causes hardware security module  151  to encrypt processing results data  622 E using cryptographic key  631 E or another key specified by the user of customer computing device  108 A. Cloud services exchange  200  outputs one or more signals over CSP ports  612  to cloud service provider network  110 B (arrow  5 ). One or more devices within cloud service provider network  110 B detect a signal, determine that the signal includes processing results data for storage. One or more devices within cloud service provider network  110 B store encrypted processing results data  622 E. 
     In the examples of  FIG. 6D  and  FIG. 6E , data is processed within cloud service provider network  110 A to generate processing results data, and that processing results data is stored within cloud service provider network  110 B. In other examples, data may be processed elsewhere, such as in any of the other cloud service provider networks  110  or within one or more customer networks  203 . Similarly, processing results data may be stored elsewhere, such as within any of the other cloud service provider networks  110 , within one or more customer networks  203 , or elsewhere. 
       FIG. 6F  illustrates an example operation in which cloud services exchange  200  decrypts data accessed from cloud service provider network  110 A. For instance, in the example of  FIG. 6F , customer computing device  108 A outputs one or more signals over NSP network  204 A, and information about the signals is received by cloud services exchange  200  over customer ports  610 . Computing system  150  of cloud services exchange  200  determines that the signals correspond to a request, by an authenticated user of customer computing device  108 A, to access data  621 F within cloud service provider network  110 A, decrypt data  621 F using a specific cryptographic key, and perform processing on unencrypted data  621 F. Computing system  150  outputs a signal over customer ports  610  to cloud service provider network  110 A. One or more devices within cloud service provider network  110 A detect a signal and respond by outputting encrypted data  621 F to cloud services exchange  200  over CSP ports  612  (arrow  1 ). Computing system  150  of cloud services exchange  200  causes hardware security module  151  to decrypt data  621 F using cryptographic key  631 F, thereby producing unencrypted data  621 F. 
     Cloud services exchange  200  may output unencrypted data  621 F to one or more devices for processing. For instance, in the example of  FIG. 6F , computing system  150  provides cloud services exchange  200  with access to unencrypted data  621 F. Cloud services exchange  200  outputs unencrypted data  621 F over CSP ports  612  (e.g., through a secure channel) to cloud service provider network  110 B (arrow  2 ). One or more devices within cloud service provider network  110 B perform the requested processing on data  621 F, and generate processing results data  622 F (arrow  3 ). 
     Cloud services exchange  200  may store encrypted data within one or more cloud service provider networks  110 . For instance, still referring to  FIG. 6F , cloud service provider network  110 B outputs processing results data  622 F to cloud services exchange  200  over CSP ports  612  (arrow  4 ). Computing system  150  of cloud services exchange  200  causes hardware security module  151  to encrypt processing results data  622 F using cryptographic key  631 F or another cryptographic key. Cloud services exchange  200  outputs one or more signals over CSP ports  612  to cloud service provider network  110 N (arrow  5 ). One or more devices within cloud service provider network  110 N detect a signal, determine that the signal includes processing results data  622 F, and store processing results data  622 F. 
       FIG. 1  through  FIG. 5 , and  FIG. 6A  through  FIG. 6F  each illustrate at least one example cloud exchange, cloud exchange point, data center, computing system or other system. The scope of this disclosure is not, however, limited to the specific systems or configurations illustrated. Accordingly, other example or alternative implementations of systems illustrated herein, beyond those illustrated in the Figures, may be appropriate in other instances. Such implementations may include a subset of the devices and/or components included in the example(s) described in the Figures and/or may include additional devices and/or components not shown in the Figures. 
       FIG. 7  is a flow diagram illustrating an example process for performing cryptographic operations in accordance with one or more aspects of the present disclosure. In the example of  FIG. 7 , the illustrated process may be performed by computing system  150  included within cloud exchange point  128 A in the context illustrated in  FIG. 1 . In other examples, different operations may be performed, or operations described in connection with  FIG. 7  may be performed by one or more other computing systems, components, modules, systems, and/or devices. In some examples, such computing systems, components, modules, systems, and/or devices may be included within other cloud exchange points  128 , or across some or all cloud exchange points  128 . In other examples, such computing systems may be included elsewhere within the systems illustrated in  FIG. 1 . Further, in other examples, operations described in connection with  FIG. 7  may be merged, performed in a difference sequence, omitted, or may encompass additional operations not specifically illustrated or described. 
     In the process illustrated in  FIG. 7 , and in accordance with one or more aspects of the present disclosure, computing system  150  may authenticate each of a plurality of customers. For example, with reference to  FIG. 1 , computing system  150  may detect input over network service provider  106 A that it determines corresponds to authentication credentials for a user operating customer computing device  108 A ( 701 ). Computing system  150  may communicate an indication of the authentication credentials to one or more hardware security modules  151  included within computing system  150 . Hardware security module  151  may determine, based on the indication of the authentication credentials, that the user of customer computing device  108 A (e.g., the “first customer”) is authenticated to perform one more operations involving computing system  150  and/or hardware security module  151  ( 702 ). Hardware security module  151  may further determine, based on an indication of authentication credentials from a user operating customer computing device  108 B, that the user of customer computing device  108 B (e.g., the “second customer”) is also authenticated to perform one or more operations involving computing system  150  and/or hardware security module  151  ( 702 ). 
     Computing system  150  may generate a plurality of cryptographic keys ( 703 ). For example, again referring to  FIG. 1  in the context of the process of  FIG. 7 , hardware security module  151  may generate a plurality of cryptographic keys in response to input received from customer computing device  108 A, customer computing device  108 B, or from another device operated by an authenticated user. The cryptographic keys may include one or more keys associated with and/or for use by the first customer (i.e., an operator of customer computing device  108 A) and may include one or more keys associated with and/or for use by the second customer (i.e., an operator of customer computing device  108 B). 
     Computing system  150  may enforce restrictions on use of the plurality of cryptographic keys ( 704 ). For example, one or more of hardware security modules  151  in  FIG. 1  may provide cryptographic services to a plurality of customers, and in some examples, individual hardware security modules  151  may be shared by multiple customers. Accordingly, computing system  150  and/or hardware security module  151  may ensure, through authentication requirements or the like, that no customer is able to gain unauthorized access to cryptographic keys associated with another customer. 
     Computing system  150  may access a first set of customer data ( 705 - 1 ). For example, still referring to  FIG. 1 , computing system  150  may detect input over network service provider  106 A and determine that the input corresponds to a set of customer data (e.g., a “first set of customer data”) from customer computing device  108 A (e.g., operated by a “first customer”). Alternatively, or in addition, computing system  150  may detect input over network service provider  106 A that it determines corresponds to instructions to access customer data within one or more devices included within  128 A (e.g., such as a customer network as illustrated in  FIG. 2  and/or  FIG. 6A ). Alternatively, or in addition, computing system  150  may detect input over network service provider  106 A that it determines corresponds to instructions to access customer data included within one or more cloud service provider networks  110 . In examples where the customer data is not provided by customer computing device  108 A, computing system  150  may output a signal to one or more sources of customer data (e.g., customer networks within cloud exchange point  128 A or one or more cloud service provider networks  110  as specified by the instructions). Responsive to such signals, computing system  150  may detect input that it determines corresponds to the set of customer data (e.g., the “first set of customer data”) associated with the first customer. 
     Computing system  150  may generate a first set of processed data ( 706 - 1 ). For example, in  FIG. 1 , computing system  150  may cause hardware security module  151  to perform a cryptographic operation on the first set of customer data accessed by computing system  150  as described above. In one example, the cryptographic operation may involve encrypting the first set of customer data to generate the first set of processed data. In other examples, the cryptographic operation may be a decryption operation, a signing operation, and/or a verification operation on the first set of customer data. 
     Where the operation is an encryption operation, hardware security module  151  may use the one or more cryptographic keys associated with the first customer to encrypt the data. In some examples, hardware security module  151  may apply a symmetric encryption key to the data. In other examples, hardware security module  151  may apply a private encryption key to the data, thereby enabling another party with access to the corresponding public encryption key to decrypt the first set of customer data. 
     Computing system  150  may output the first set of processed data ( 707 - 1 ). For example, still referring to  FIG. 1 , computing system  150  may output the first set of processed (encrypted) data to one or more of cloud service provider networks  110 . In some examples, computing system  150  may output the processed data for storage at one or more cloud service provider networks  110 , such as cloud service provider network  110 A. In such an example, cloud service provider network  110 A may store the data, but cloud service provider network  110 A is unable to access the data, since it has been encrypted with a key securely stored within hardware security module  151  of cloud exchange point  128 A. If cloud service provider network  110 A does not have access or control over cloud exchange point  128 A and/or hardware security module  151  within cloud exchange point  128 A, cloud service provider network  110 A will generally be unable to decrypt the encrypted version of the first set of customer data stored within  110 A. 
     Computing system  150  may also access a second set of customer data ( 705 - 2 ). For example, in  FIG. 1 , computing system  150  may detect input over network service provider  106 A and determine that the input corresponds to a set of customer data from customer computing device  108 B (e.g., operated by a “second customer”). Alternatively, or in addition, computing system  150  may detect input over network service provider  106 A that it determines corresponds to instructions to access customer data within one or more other devices (e.g., devices included within  128 A or cloud service provider networks  110 A). 
     Computing system  150  may generate a second set of processed data ( 706 - 2 ). For example, in  FIG. 1 , computing system  150  may cause hardware security module  151  to perform a cryptographic operation on the second set of customer data. Such an operation may be an encryption operation, a decryption operation, or other type of cryptographic operation. 
     Computing system  150  may output the second set of processed data ( 707 - 2 ). For example, computing system  150  of  FIG. 1  may output the second set of processed data to one or more of cloud service provider networks  110 , or to one or more other devices. 
     For processes, apparatuses, and other examples or illustrations described herein, including in any flowcharts or flow diagrams, certain operations, acts, steps, or events included in any of the techniques described herein can be performed in a different sequence, may be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the techniques). Moreover, in certain examples, operations, acts, steps, or events may be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors, rather than sequentially. Further certain operations, acts, steps, or events may be performed automatically even if not specifically identified as being performed automatically. Also, certain operations, acts, steps, or events described as being performed automatically may be alternatively not performed automatically, but rather, such operations, acts, steps, or events may be, in some examples, performed in response to input or another event. 
     For ease of illustration, only a limited number of devices (e.g., servers  12 , access nodes  17 , storage devices  62 , host networking units  13 , host networking units  18 , host networking units  63 , as well as others) are shown within the Figures and/or in other illustrations referenced herein. However, techniques in accordance with one or more aspects of the present disclosure may be performed with many more of such systems, and collective references to components, devices, modules, and/or systems may represent any number of such components, devices, modules, and/or systems. 
     The Figures included herein each illustrate at least one example implementation of an aspect of this disclosure. The scope of this disclosure is not, however, limited to such implementations. Accordingly, other example or alternative implementations of systems, methods or techniques described herein, beyond those illustrated in the Figures, may be appropriate in other instances. Such implementations may include a subset of the devices and/or components included in the Figures and/or may include additional devices and/or components not shown in the Figures. 
     The detailed description set forth above is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a sufficient understanding of the various concepts. However, these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in the referenced figures in order to avoid obscuring such concepts. 
     Accordingly, although one or more implementations of various systems, devices, and/or components may be described with reference to specific Figures, such systems, devices, and/or components may be implemented in a number of different ways. For instance, one or more devices illustrated in the Figures herein (e.g.,  FIG. 1  and/or  FIG. 2 ) as separate devices may alternatively be implemented as a single device; one or more components illustrated as separate components may alternatively be implemented as a single component. Also, in some examples, one or more devices illustrated in the Figures herein as a single device may alternatively be implemented as multiple devices; one or more components illustrated as a single component may alternatively be implemented as multiple components. Each of such multiple devices and/or components may be directly coupled via wired or wireless communication and/or remotely coupled via one or more networks. Also, one or more devices or components that may be illustrated in various Figures herein may alternatively be implemented as part of another device or component not shown in such Figures. In this and other ways, some of the functions described herein may be performed via distributed processing by two or more devices or components. 
     Further, certain operations, techniques, features, and/or functions may be described herein as being performed by specific components, devices, and/or modules. In other examples, such operations, techniques, features, and/or functions may be performed by different components, devices, or modules. Accordingly, some operations, techniques, features, and/or functions that may be described herein as being attributed to one or more components, devices, or modules may, in other examples, be attributed to other components, devices, and/or modules, even if not specifically described herein in such a manner. 
     The detailed description set forth above is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a sufficient understanding of the various concepts. However, these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in the referenced figures in order to avoid obscuring such concepts. 
     In accordance with one or more aspects of this disclosure, the term “or” may be interrupted as “and/or” where context does not dictate otherwise. Additionally, while phrases such as “one or more” or “at least one” or the like may have been used in some instances but not others; those instances where such language was not used may be interpreted to have such a meaning implied where context does not dictate otherwise. 
     In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored, as one or more instructions or code, on and/or transmitted over a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another (e.g., pursuant to a communication protocol). In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media, which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium. 
     By way of example, and not limitation, such computer-readable storage media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. 
     Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the terms “processor” or “processing circuitry” as used herein may each refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described. In addition, in some examples, the functionality described may be provided within dedicated hardware and/or software modules. Also, the techniques could be fully implemented in one or more circuits or logic elements. 
     The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, a mobile or non-mobile computing device, a wearable or non-wearable computing device, an integrated circuit (IC) or a set of ICs (e.g., a chip set). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a hardware unit or provided by a collection of interoperating hardware units, including one or more processors as described above, in conjunction with suitable software and/or firmware.