Resource sharing between cloud hosted virtual networks

Abstract

Techniques for resource sharing between cloud hosted virtual networks are described. A first network address of a first virtual network is associated with a resource connected to a second virtual network, the first virtual network and the second virtual network being within a cloud provider network. A service of the cloud provider network receives a message to the first network address. The service translates the first network address to a second network address of the resource in the second virtual network. The service sends the message to the resource at the second network address in the second virtual network.

Description

Background Art

[0001] Cloud computing systems typically provide customers with on-demand, managed computing resources. These computing resources (e.g., compute and storage capacity) are typically provided by large pools of capacity installed in data centers. Customers can request computing resources from the "cloud," and the cloud can provide them to those customers. Technologies such as virtual machines and containers are often used to allow customers to securely share the capacity of a computer system. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various examples according to the present disclosure will now be described with reference to the accompanying drawings, in which:

[0003] Figure 1 An environment illustrating resource sharing between virtual networks of a cloud provider network according to some examples.

[0004] Figure 2 An environment illustrating resources in a virtual network sharing a cloud provider network according to some examples.

[0005] Figure 3 An environment for accessing shared resources in a virtual network of a cloud provider network is shown according to some examples.

[0006] Figure 4 An environment of resource sharing in a virtual network with subnetworks according to some examples is illustrated.

[0007] Figure 5 Operations of a method of resource sharing between virtual networks of a cloud provider network are illustrated according to some examples.

[0008] Figure 6 An example provider network environment is shown according to some examples.

[0009] Figure 7 An example provider network is shown that provides storage services and hardware virtualization services to customers according to some examples.

[0010] Figure 8 An example computer system is shown that may be used for some examples. DETAILED DESCRIPTION

[0011] The present disclosure relates to private link endpoints (referred to herein as "resource endpoints") that enable private and secure connections from a virtual network (such as a virtual private cloud (VPC)) to specific resources (e.g., databases, clusters, virtual machine instances) in another virtual network. As an example, customers of a cloud provider network can use resource endpoints to connect to cloud services and third-party services hosted on the cloud. When both virtual networks are part of the same larger network environment (such as a cloud provider network), connections through resource endpoints can advantageously be made without routing any traffic to the internet. This includes implementations where customers have a direct connection between their on-premises computing environment and the cloud provider's region. Bypassing the internet can be particularly useful for certain types of workloads (such as the storage of sensitive data) that have security and compliance requirements that prevent the use of internet gateways or virtual network peering. Resource endpoints allow private and secure connections to such data stores across account boundaries and virtual network boundaries. Resource endpoints can also help enable low-latency use cases across account boundaries, delivering sub-millisecond latencies in some cases

[0012] Examples relate to methods, devices, systems, and non-transitory computer-readable storage media for resource sharing between cloud-hosted virtual networks. According to some examples, a virtual network interconnection service introduces a resource endpoint into a virtual network for sharing resources with other virtual networks or accessing shared resources in another virtual network. More specifically, a customer of a cloud provider network can introduce a resource "owner" endpoint into its virtual network and selectively configure both which resources in the virtual network are shared by the resource owner endpoint and with whom each resource is shared. The same or another customer can introduce a resource "consumer" endpoint into a different virtual network and selectively configure which resources already shared with the virtual network are accessible within the virtual network. The resource consumer endpoint is associated with a network address prefix, where a respective network address can be associated with each accessible shared resource. The virtual network interconnection service converts addressing data from the resource consumer endpoint into addressing data for the resource owner endpoint to provide for forwarding messages received by the resource consumer endpoint to the corresponding resource owner endpoint and ultimately to the shared resource.

[0013] Cloud provider network customers typically deploy resources (e.g., databases, clusters, etc.) into cloud-hosted virtual networks. However, sometimes these customers may want to provide limited cross-virtual network sharing due to internal or external security or compliance requirements, rather than typical "universal" cross-network access such as via a gateway to the Internet or through a peered virtual network (e.g., where all devices connected to one virtual network can connect to devices on another virtual network (and vice versa)). As customers move to a multi-account and multi-virtual network environment and want to provide access to resources across accounts or virtual networks, or even to customers with separate virtual networks, the virtual network interconnection services described herein provide private and secure connectivity to resources across virtual network boundaries. There are several use cases for resource endpoints, such as accessing resources across VPCs, private access to VPC resources from a premises network, and one-to-many access use cases where multiple resources need to be accessed from a single endpoint (one-to-many). As an example of the latter, resource endpoints can be used for use cases where network monitoring tools in a central VPC owned by a security team need to scan virtual machine instances in multiple VPCs without the need for VPC peering or gateways to interconnect the VPCs.

[0014] The disclosed technology provides many technical benefits. For example, resource endpoints provide private, secure connections to resources in other VPCs. For resource consumers, resource endpoints can provide the ability to have one-way (consumer-initiated) communication with shared resources, the ability to access multiple resources in different VPCs through a single endpoint, the ability to access resources across resource endpoints from the on-premises network through VPN and direct connection, the ability to establish connections to resources across VPCs with overlapping / non-overlapping CIDRs, and provide sub-millisecond latency for highly latency-sensitive use cases such as database access. For resource owners, resource endpoints can provide enhanced security and privacy by exposing specific resources only to specific accounts, users, roles, organizational units, organizations, etc., allowing owners to quickly share resources without the need for additional infrastructure (such as load balancers), the ability to unilaterally terminate existing connections to resources, and the ability to share multiple resources through a single endpoint.

[0015] Figure 1An environment of resource sharing between virtual networks of a cloud provider network according to some examples is shown. As shown, the cloud provider network 100 includes a virtual network interconnection service 101, which provides connections between virtual networks 102A, 102B, 102C and 102D, as described below. A cloud provider network (or just "cloud") generally refers to a large pool of accessible virtualized computing resources (such as computing, storage and networking resources, applications and services). A cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adjust to variable loads. Therefore, cloud computing can be considered to be both applications delivered as services over publicly accessible networks (e.g., the Internet, cellular communication networks) and the hardware and software in the cloud provider data centers that provide these services.

[0016] A cloud provider network provides users with the ability to use one or more of various types of computing-related resources, such as computing resources (e.g., executing virtual machine (VM) instances and / or containers, executing batch jobs, executing code without provisioning servers), data / storage resources (e.g., object storage, block-level storage, data archive storage, databases and database tables, etc.), network-related resources (e.g., configuring virtual networks (including computing resource groups), content delivery networks (CDNs), domain name services (DNS)), application resources (e.g., databases, application build / deployment services), access policies or roles, identity policies or roles, machine images, routers, and other data processing resources. These and other computing resources can be provided as services, such as hardware virtualization services that can execute computing instances, storage services that can store data objects, etc.

[0017] A user (or "customer") of a cloud provider network may use one or more user accounts associated with a customer account, although these terms may be used somewhat interchangeably depending on the context of use. A user may interact with the cloud provider network via one or more interfaces across one or more intermediary networks (e.g., the Internet), such as by using application programming interface (API) calls, via a console implemented as a website or application, and the like. An API refers to an interface and / or communication protocol between a client and a server such that if a client issues a request in a predefined format, the client should receive a response in a specific format or initiate a defined action. In the context of a cloud provider network, an API provides a gateway for customers to access the cloud infrastructure by allowing them to obtain data from the cloud provider network or to initiate actions within the cloud provider network, thereby enabling the development of applications that interact with resources and services hosted in the cloud provider network. An API may also enable different services of the cloud provider network to exchange data with each other. An interface may be part of or act as a front-end to the cloud provider network's control plane, which includes "back-end" services that support and implement services that can be provided more directly to customers.

[0018] A cloud provider network may be formed into multiple regions, where a region is a geographic area in which a cloud provider clusters data centers. Each region includes multiple (e.g., two or more) availability zones (AZs) connected to each other via a private high-speed network (e.g., a fiber optic communication connection). An AZ (also called a "region") provides an isolated failure domain that includes one or more data center facilities that have separate power, separate networking, and separate cooling relative to data center facilities in another AZ. A data center refers to the physical building or enclosure that houses and provides power and cooling to the servers of the cloud provider network. Preferably, the AZs within a region are located far enough apart from each other that a natural disaster (or other event that causes failure) does not affect more than one AZ simultaneously or take more than one AZ offline.

[0019] Users can connect to the AZs of the cloud provider network via publicly accessible networks (e.g., the Internet, cellular communication networks), such as through a transit center (TC). The TC is the main backbone location that links users to the cloud provider network and can be co-located at other network provider facilities (e.g., Internet service providers (ISPs), telecommunications providers) and securely connected to the AZs (e.g., via VPN or direct connection). Each region can operate two or more TCs for redundancy. The regions are connected to a global network that includes private networking infrastructure (e.g., fiber optic connections controlled by the cloud provider) that connects each region to at least one other region. The cloud provider network can deliver content from access points (or "POPs") located outside of these regions but networked to these regions through edge locations and regional edge cache servers. This partitioning and geographical distribution of computing hardware enables the cloud provider network to provide users with low-latency resource access on a global scale with a high degree of fault tolerance and stability.

[0020] To provide these and other computing resource services, cloud provider networks typically rely on virtualization technology. For example, virtualization technology can provide users with the ability to control or use computing resources (e.g., "compute instances," such as VMs using a guest operating system (O / S) that operates using a hypervisor that may or may not further operate on top of an underlying host O / S; containers that may or may not operate within a VM; compute instances that can execute on "bare metal" hardware without an underlying hypervisor), where a single electronic device can be used to implement one or more computing resources. Thus, users can directly use computing resources hosted by the provider network (e.g., provided by hardware virtualization services) to perform various computing tasks. Additionally or alternatively, users can indirectly use computing resources by submitting code to be executed by the provider network (e.g., via an on-demand code execution service), which in turn executes the code using one or more computing resources, typically without the user having any control or knowledge of the underlying computing instances involved.

[0021] A virtual private cloud (VPC) (also referred to in various implementations as a virtual network (VNet or VN), virtual private network, or virtual cloud network) is a custom virtual network within another network, such as a cloud provider's network. A VPC is defined by at least its address space, internal structure (e.g., compute resources including the VPC, security groups), and transit paths, and is logically isolated from other virtual networks in the cloud. A VPC can span all availability zones in a specific region.

[0022] A VPC can provide the underlying network layer for cloud services (e.g., compute cloud or edge cloud) or customer applications or workloads running on the cloud. A VPC can be dedicated to a specific customer account (or a set of related customer accounts, such as different customer accounts belonging to the same business organization). Customers can put resources such as compute instances into their VPC. When creating a VPC, customers can specify the range of IP addresses for the VPC in the form of Classless Inter-Domain Routing (CIDR) blocks. After creating a VPC, customers can add one or more subnets in each Availability Zone or edge location associated with its region.

[0023] A VPC / VN typically has virtualization components similar to those of a physical computer network. Such components may include a virtual network interface (VNI) (sometimes called an elastic network interface) for attaching a virtualized instance to the VN, a virtual router for handling traffic routing between connected virtualized instances, a virtual gateway for providing connectivity to or from resources outside the virtual network, and so on.

[0024] Traffic traversing the virtual network is typically encapsulated within traffic traversing the underlying physical network infrastructure of the cloud provider network. In this way, the virtual network can be thought of as an overlay network operating on top of the physical network of the cloud provider network.

[0025] The virtual network interconnection service 101 provides private and secure connections to resources across virtual network boundaries. To this end, the virtual network interconnection service 101 introduces resource endpoints within the VN. Resource endpoints provide a foothold for traffic transfer between each VN and the virtual network interconnection service 101, and are typically implemented as virtual network interfaces, providing communication paths between the virtual network interconnection service 101 and each customer VN. In the examples shown and described herein, resource endpoints are divided into two types: resource owner endpoints and resource consumer endpoints.

[0026] In some examples, the virtual network interconnection service 101 described herein can be partitioned across one or more sub-services of a cloud provider network.

[0027] The resource owner endpoint allows a user to share one or more resources in their VN and, for each shared resource, specify with whom the resource is shared. Thus, a single resource owner endpoint allows many different entities in many other VNs to connect to many resources in the user's VN. The resource consumer endpoint allows a user to create a network address in their VN for each shared resource that users in other VNs want to access from within their VN. Thus, a single resource consumer endpoint provides entities in the user's VN with access to the shared resources of many other VNs.

[0028] In some examples, an entity in a VN with a resource consumer endpoint can initiate a connection to a shared resource in another VN. At the same time, an entity in a VN with a shared resource cannot automatically connect to an entity in another VN with which it shares the resource (absent the explicit resource sharing via endpoints described herein). In this way, the virtual network interconnection service 101 provides one-way connections.

[0029] The virtual network interconnection service 101 can provide address translation and traffic routing between VNs through resource consumer endpoints and resource owner endpoints.

[0030] In the illustrated example, an administrator (sometimes also referred to as an owner, manager, or administrator) of VN 102B has created resource owner endpoint 106A within VN 102B via virtual network interconnect service 101 and shared two resources of VN 102B corresponding to instances 108A and 108B. VN 102B has a network address block 10.0.0.0 / 16 (in Classless Inter-Domain Routing (CIDR) notation). Instance 108A has a network address 10.0.0.1 and a domain name database1.db.com. Instance 108B has a network address 10.0.0.2 and a domain name database2.db.com. Resource owner endpoint 106A has a network address 10.200.0.1 within VN 102B. In creating the resource owner endpoint 106A, the virtual networking service 101 has assigned the endpoint 106A an endpoint identifier VNE-2C33, which the virtual networking service 101 can use for endpoint management and routing operations.

[0031] "Instance" refers to general resources hosted by a cloud provider network, such as computing resources (for example, executing virtual machine (VM) instances and / or containers, executing batch jobs, executing code without provisioning servers), data / storage resources (for example, object storage, block-level storage, data archive storage, databases and database tables, etc.), network-related resources (for example, configuring virtual networks (including computing resource groups), content delivery networks (CDNs), domain name services (DNS)), application resources (for example, databases, application build / deployment services), access policies or roles, identity policies or roles, machine images, routers, and other data processing resources.

[0032] In the example shown, an administrator of VN 102A has created a resource consumer endpoint 104A within VN 102A via virtual networking service 101. VN 102A has a network address block of 10.0.0.0 / 16. Resource consumer endpoint 104A has an assigned address prefix of 10.100.0.0 / 28. In creating resource consumer endpoint 104A, virtual networking service 101 has assigned endpoint 104A an endpoint identifier of VNE-A 245, which virtual networking service 101 can use for endpoint management and routing operations.

[0033] The administrator of VN 102A has also been granted access to the shared resources of instances 108A and 108B via resource consumer endpoint 104A. In doing so, virtual networking service 101 has associated addresses within the prefix of resource consumer endpoint 104A with instances 108A and 108B. Specifically, virtual networking service 101 has associated network address 10.100.0.0 with the shared resources of instance 108A and network address 10.100.0.1 with the shared resources of instance 108B. Based on the associated addresses, virtual networking service 101 updates virtual name service 110A of VN 102A to include records reflecting the availability of the domain names of the shared resources via their newly associated addresses within VN 102A (e.g., database1.db.com -> 10.100.0.0 and database2.db.com -> 10.100.0.1).

[0034] In some examples, the virtual network interconnection service 101 maintains various metadata to describe and track connections between virtual networks. For example, the virtual network interconnection service 101 may maintain mapping data 150 that can be used for inter-VN routing. Given the resource sharing arrangement shown from VN 102B to VN 102A, the mapping data 150 includes an entry for: directing traffic received at resource consumer endpoint 104A (with identifier VNE-A245) and destined for network address 10.100.0.0 associated with instance 108A to the actual network address 10.0.0.1 of instance 108A within VN 102B via resource owner endpoint 106A (with identifier VNE-2C33). The mapping data 150 further includes an entry for directing traffic received at the resource consumer endpoint 104A (having identifier VNE-A 245) destined for the network address 10.100.0.1 associated with the instance 108B to the actual network address 10.0.0.2 of the instance 108B within the VN 102B via the resource owner endpoint 106A (having identifier VNE-2C 33). The virtual networking service 101 may also store other metadata, such as endpoint data 160, endpoint configuration data 170, and lookup data 180, described below.

[0035] With endpoints 104A and 106A established, instances in VN 102A can now send messages to shared resources 108A and 108B in VN 102B. An example of a message sent from instance 108D to instance 108A is now described. Instance 108D can obtain the network address (10.100.0.0) associated with the database1.db.com domain name from name server 110A. Instance 108D can transmit a message (e.g., a packet) with the destination network address 10.100.0.0 to the port of the resource being accessed (3306 in this example) along with the source network address of the instance (10.0.0.1) and the port determined by the instance (1234 in this example). A virtual router (not shown) routes the packet to resource consumer endpoint 104A based on the destination network address 10.100.0.0 falling within the assigned prefix. Resource consumer endpoint 104A sends the packet to virtual network interconnection service 101.

[0036] Using the mapping data 150, the virtual network interconnection service 101 can route traffic directed to the resource consumer endpoint of one VN to the corresponding shared resource of another VN via the resource owner endpoint. Specifically, the virtual network interconnection service 101 can use the destination address and associated endpoint identifier of the message received by the resource consumer endpoint to identify the actual address of the shared resource on its VN and the associated resource owner endpoint that provides the connection to the VN. In the example shown, the mapping data maps a packet received at VNE-A245 destined for 10.100.0.0 to the destination address 10.0.0.1 via VNE-2C33. The virtual network interconnection service 101 changes the destination addressing of the packet from 10.100.0.0:3306 to 10.0.0.1:3306.

[0037] In some examples, the virtual networking service 101 evaluates the security policy associated with the target resource owner endpoint before routing a request from the resource consumer endpoint to the resource owner endpoint. The security policy may include a list of ports or protocols that are permitted or prohibited for traversing the resource owner endpoint. If the traffic received from the resource consumer endpoint is permitted or not prohibited by the security policy associated with the target resource owner endpoint in the mapping data, the virtual networking service 101 may route the traffic to the resource owner endpoint. Otherwise, the virtual networking service 101 may block the request. The security policy associated with the resource owner endpoint may be stored in the endpoint data 160, as described below.

[0038] In some examples, the virtual network interconnection service 101 may also modify the source address and port of the message. Since many different instances (potentially in many different VNs) may be accessing a shared resource, the virtual network interconnection service 101 may use port mapping to keep track of where to send packets received by the resource owner endpoint from the shared resource. In the forward direction (e.g., for traffic forwarded from a resource consumer endpoint to a resource owner endpoint), the virtual network interconnection service 101 may map the source network address, port, and identifier of the original VN (e.g., using a VN identifier or a resource consumer endpoint identifier) to an available port at the resource owner endpoint. In the example shown, the virtual network interconnection service 101 maps a packet received at VNE-A245 with a source network address of 10.0.0.1 and port 1234 to port 2345 of the resource owner endpoint 106A with a network address of 10.200.0.1, and stores the mapping. Using this mapping, virtual networking service 101 changes the source addressing of the packet from 10.0.0.1:1234 to 10.200.0.1:2345.

[0039] In the reverse direction (e.g., for traffic forwarded from the resource owner endpoint back to the resource consumer endpoint), the virtual networking service 101 can use the destination address port to obtain the destination address, port, and resource consumer endpoint identifier. For example, for a packet received from instance 108A with a destination address of 10.200.0.1:2345, the virtual networking service 101 uses the previously stored mapping for port 2345 to determine that the destination network address is 10.0.0.1 and port 1234. The virtual networking service 101 changes the destination address of the packet from 10.200.0.1:2345 to 10.0.0.1:1234 and sends the packet through VNE-A 245 (also determined based on the stored mapping).

[0040] In this example, the administrator of VN 102B has shared instances 108A and 108B with VN 102A. This sharing is typically explicitly specified in one or more permission policies defined by the administrator of VN 102B, as described below. Therefore, while instances in VN 102A can access instances 108A and 108B, other instances in VN 102B (not shown) remain inaccessible. The administrator of VN 102B has not yet shared either instance 108A or 108B with VN 102D. Therefore, communication from instances in VN 102D (not shown) to VN 102B is not possible.

[0041] Referring to VN 102C, the administrator of VN 102C has created resource owner endpoint 106B within VN 102C through virtual network interconnection service 101 and shared the resources of VN 102C corresponding to instance 108C. VN 102C has a network address block 172.31.0.0 / 16. Instance 108C has a network address 172.31.0.1 and a domain name c1.compute.com. Resource owner endpoint 106B is assigned a network address prefix 172.31.1.0 / 28 within VN 102C. Network prefixes can be assigned to resource owner endpoints to limit the possibility of port exhaustion. In creating resource owner endpoint 106B, virtual network interconnection service 101 has assigned endpoint 106B an endpoint identifier VNE-F885, which virtual network interconnection service 101 can use for endpoint management and routing operations.

[0042] In this example, the administrator of VN 102C has shared instance 108C with both VNs 102A and 102D.

[0043] The administrator of VN 102A has also been granted access to the shared resources of instance 108C via resource consumer endpoint 104A. In doing so, virtual networking service 101 has associated an address within the prefix of resource consumer endpoint 104A with instance 108C. Specifically, virtual networking service 101 has associated network address 10.100.0.3 with the shared resources of instance 108C. Based on the associated address, virtual networking service 101 updates virtual name service 110A of VN 102A to include a record reflecting the availability of the domain name of the shared resource via its newly associated address within VN 102A (e.g., c1.compute.com -> 10.100.0.3).

[0044] The administrator of VN 102D has created resource consumer endpoint 104B within VN 102D via virtual networking service 101. VN 102D has a network address block of 10.0.0.0 / 16. Resource consumer endpoint 104B has an assigned address prefix of 10.50.0.0 / 28. In creating resource consumer endpoint 104B, virtual networking service 101 has assigned endpoint 104B an endpoint identifier of VNE-D 772, which virtual networking service 101 can use for endpoint management and routing operations.

[0045] The administrator of VN 102D has also been granted access to the shared resources of instance 108C via resource consumer endpoint 104B. In doing so, virtual networking service 101 has associated an address within the prefix of resource consumer endpoint 104B with instance 108C. Specifically, virtual networking service 101 has associated network address 10.50.0.1 with the shared resources of instance 108C. Based on the associated address, virtual networking service 101 updates virtual name service 110B of VN 102D to include a record reflecting the availability of the domain name of the shared resource via its newly associated address within VN 102D (e.g., c1.compute.com -> 10.50.0.1).

[0046] Given the illustrated resource sharing arrangement from VN 102C to VNs 102A and 102D, mapping data 150 includes an entry for directing traffic received at resource consumer endpoint 104A (having identifier VNE-A 245) destined for network address 10.100.0.3 associated with instance 108C to actual network address 172.31.0.1 of instance 108C within VN 102C via resource owner endpoint 106B (having identifier VNE-F 885). Mapping data 150 further includes an entry for directing traffic received at resource consumer endpoint 104B (having identifier VNE-D 772) destined for network address 10.50.0.1 associated with instance 108C to actual network address 172.31.0.1 of instance 108C within VN 102C via resource owner endpoint 106B (having identifier VNE-F 885). It is important to note here that the "local" network addresses within different VNs of a common shared resource may be different (e.g., network address 10.100.0.3 in VN 102A is associated with instance 108C, while network address 10.50.0.1 in VN 102D is associated with instance 108C).

[0047] In the illustrated example of establishing endpoints 104A, 104B, and 106B, an instance in VN 102A or 102D can now send a message to shared resource 108C in VN 102D. The detailed forwarding of messages from such an instance to a shared resource is described above. In short, instance 108E can obtain the network address of c1.compute.com from name server 110A and send a message with a destination address (10.100.0.3) of the obtained network address. Because this address falls within the prefix assigned to resource consumer endpoint 104A, a virtual router (not shown) routes the message to resource consumer endpoint 104A, which sends the message to virtual networking service 101. Using mapping data 150, virtual networking service 101 changes the destination addressing from 10.100.0.3:9870 to 172.31.0.1:9870. The virtual networking service 101 may also store the port mapping data and change the source addressing from 10.0.0.2:5555 (of the instance 108E) to 172.31.1.0:7777 (of the resource owner endpoint 106B).

[0048] In some examples, Figure 1The various components shown in the figure can be implemented as software processes executed by one or more computer systems of the cloud provider network. For example, instance 108 can be a virtual machine or container process executed within the host environment of a host system used for customer resource virtualization. Resource endpoints 104, 106, name server 110, other virtual network components such as virtual routers (not shown), and virtual network interconnection services 101 can be executed by a separate set of host systems for control plane operations.

[0049] One advantage of the examples of the virtual network interconnection service 101 described herein is that VNs that share resources can have partially or completely overlapping network address ranges (e.g., CIDR blocks). For example, VN 102A and VN 102B each have CIDR block 10.0.0.0 / 16. Overlapping address ranges are possible because the virtual network interconnection service 101 associates available network addresses in the VNs with resource consumer endpoints with the shared resources and translates the associated network addresses into the actual network addresses of the shared resources in the VNs with resource owner endpoints.

[0050] Another advantage of the examples of virtual networking services 101 described herein is direct intra-VPC connectivity from resource owner endpoints to associated shared resources. Setting aside VPC-native components such as virtual routers, "direct" here means that there are no other devices (e.g., no load balancers) between the resource owner endpoint and the shared resources on the VPC. For example, traffic from resource owner endpoint 106A is directly forwarded through the VPC to instance 108A.

[0051] While the examples shown and described illustrate only one type of resource endpoint per VN, each VN may create multiple resource endpoints of the same or different types. For example, a VN may include multiple resource consumer endpoints with different network address prefix delegations (e.g., because the available prefix size is less than the number of shared resources to be accessed). As another example, a VN may include a resource consumer endpoint to access shared resources in another VN and also include a resource owner endpoint to share resources with other VNs. As another example, a VN may include multiple resource owner endpoints (e.g., to prevent port exhaustion).

[0052] While the examples shown and described consider dividing resource endpoints into resource owner endpoints and resource consumer endpoints, other examples may combine functionality into a general endpoint type that provides both sharing of resources within a VN with targets of other VNs and access to shared resources in other VNs.

[0053] Typically, the virtual network interface of a VN encrypts and decrypts traffic passing through the VN. For example, a virtual network interface (not shown) attached to instance 108D will encrypt traffic to the resource consumer endpoint 104A, which in turn will decrypt the traffic. Similarly, the resource owner endpoint 106A will encrypt traffic to the virtual network interface (not shown) attached to instance 108A, which in turn will decrypt the traffic. In some examples, the virtual network interconnection service 101 includes a VN across which traffic is encrypted. Therefore, as part of routing messages between VNs, the virtual network interconnection service 101 encrypts traffic entering the virtual network interconnection service 101 from the resource consumer endpoint and decrypts traffic leaving the virtual network interconnection service 101 to the resource owner endpoint (and vice versa once a communication session is established).

[0054] In some examples, inter-VN connectivity can be extended to on-prem (or "on-prem") devices, as long as there is routability between such devices and the VN. For example, an on-prem computer system (not shown) connected to VN 102A can access instance 108A via resource consumer endpoint 104A. As another example, an on-prem computer system (not shown) accessible to devices on VN 102B can be shared via resource owner endpoint 106A. Examples of technologies that provide routability between on-prem networks or devices include virtual private network connections to cloud-based virtual networks, and virtual gateways for traffic entering or leaving a virtual network from an on-prem network to an on-prem network.

[0055] Although the description of the examples herein relies on Internet Protocol version 4 (IPv4) addressing, other examples may use Internet Protocol version 6 (IPv6) addressing or a combination of IPv4 and IPv6 addressing.

[0056] Figure 2 An environment illustrating resources in a virtual network of a shared cloud provider network according to some examples is shown. Specifically, various exemplary configuration operations associated with shared resources are described with reference to circled letters A through G. In this example, an administrator of VN 102B interacts with virtual network interconnection service 101 via electronic device 201 and one or more interfaces, such as by using application programming interface (API) calls issued through a program or website, by issuing commands via a web-based console or application, and the like.

[0057] At circle A, the virtual network interconnect service 101 receives a create-resource-owner-endpoint request (a request may also be referred to as a command). The create-resource-owner-endpoint request allows the virtual network interconnect service 101 to establish a foothold within the specified VN using a resource owner endpoint. Here, the create-resource-owner-endpoint request includes identifying the VN using the VN identifier VN-1157 assigned to VN 102B. The create-resource-owner-endpoint request may include one or more parameters, such as an identifier of the virtual network (or identifiers of one or more of its subnets, if subnetting is performed). In some examples, the optional parameter --assign-prefixes in the create-resource-owner-endpoint request <n>Whether to assign N prefixes to the resource owner endpoint. Such prefixes can be explicitly identified or automatically assigned by another service based on available network addresses within the VN. As described above, assigning network address prefixes with address blocks (such as / 28 blocks) to the resource owner endpoint can reduce the possibility of port exhaustion during operation. The create-resource-owner-endpoint request may default to a single network address assignment unless the assign-prefixes parameter is specified (in which case the specified number of prefixes will be assigned to the resource owner endpoint).

[0058] In some examples, the optional parameter --security-policy in the create-resource-owner-endpoint request<policy_document> Allows administrators to specify security policies for resource owner endpoints. Exemplary security policies can be specified in a writable format such as JavaScript Object Notation (JSON) and can include an allow list to specify which ports or protocols are permitted to transit the resource owner endpoint and / or a block list to specify which ports or protocols are prohibited to transit the resource owner endpoint.

[0059] In some examples, the optional parameter --endpoint-permissions-policy in the create-resource-owner-endpoint request<policy_document> Allows administrators to specify permission policies for resource owner endpoints. Exemplary permission policies can be specified in a writable format such as JSON and typically include an allow list to explicitly identify certain entities (e.g., other virtual networks identified by a virtual network identifier) that can access resources shared through the resource owner endpoint. Entity identities can be specified at various Identity and Access Management (IAM) levels, such as user accounts, roles, organizational units, organizations, or other identity dimensions.

[0060] As part of processing the create-resource-owner-endpoint request, the virtual network interconnection service 101 issues a create-network-interface request to the VM management service 202 of the cloud provider network, as indicated by circle BA. The create-network-interface request includes an identification of the VN or subnet identified in the request received at circle A, as well as addressing information (e.g., whether an address, multiple addresses, a prefix, or multiple prefixes are assigned to the VNI). The VM management service 202 provides management of the VN, including through operations such as creating, configuring, and deleting VNIs; updating the routing table of the VN's virtual router; adding, configuring, and removing gateways to route VN ingress and egress traffic; and so on. As indicated by circle BB, the VM management service 202 creates the VNI in VN 102B, assigns it an identifier, and obtains one or more VN network addresses to be assigned to the VNI (e.g., using Dynamic Host Configuration Protocol (DHCP)). The VM management service 202 returns the identifier and an indication of the assigned network address to the virtual network interconnection service 101. Here, the VNI is assigned the identifier VNE-2C33 and the address 10.200.0.1.

[0061] As indicated by circle CA, the virtual network interconnection service 101 issues an attach-network-interface request to the VM management service 202, which includes a VNI identifier and a target identifier of the identified VNI to be attached. The attachment of a VNI to a virtualized resource (such as an endpoint or instance) typically includes routing network device I / O between a virtualized environment (e.g., a virtual machine process, a container process, etc.) and a virtual network. The request includes a target identifier associated with the virtual network interconnection service 101 to provide the virtual network interconnection service with an attachment (or foothold) to VN 102B. As indicated by circle CB, the VM management service 202 creates an attachment between the VNI and the virtual network interconnection service 101. In this way, VNI 106A acts as a resource endpoint based on its connection between VN 102B and the virtual network interconnection service 101.

[0062] As indicated by circle D, the virtual networking service 101 updates endpoint data 160. The virtual networking service 101 uses endpoint data 160 to track each of the resource consumer endpoints and resource owner endpoints that have been established in the VN of the cloud provider network. Here, the virtual networking service 101 updates endpoint data 160 based on the creation of the resource owner endpoint 106A. In the exemplary endpoint data 160, the entry associated with the resource owner endpoint 106A includes a VN identifier (VN-1157), an endpoint identifier (VNE-2C33), an endpoint type (e.g., owner or consumer), an address assigned to the endpoint (here, 10.200.0.1), and one or more policies associated with the endpoint, such as a security policy and / or endpoint permission policy included with the create-resource-owner-endpoint request.

[0063] As indicated by circle E, the virtual network interconnect service 101 receives a create-resource-configuration request. The create-resource-configuration request initiates the creation of a routable path between a resource owner endpoint of a VN and a specific resource in the VN to be shared through the resource owner endpoint. The create-resource-configuration request may include one or more parameters, such as an identification of the resource to be shared and an identification of the resource owner endpoint through which the identified resource is to be shared. The resource to be shared may be identified by a resource name, domain name, or network address that is unique to the resource within the cloud provider network, each of which may typically be used to identify the other through other cloud provider network management data. The resource owner endpoint may be identified by its associated endpoint identifier. Here, the request identifies the resource database1.db.com and the resource owner endpoint VNE-2C33.

[0064] In some examples, the optional parameter --resource-permissions-policy in the create-resource-configuration request<policy_document> Allows administrators to specify permission policies that apply to shared resources. Exemplary permission policies can be specified in a writable format such as JSON and typically include an allow list to explicitly identify certain entities that can access resources shared through the resource owner's endpoint. Entity identities can be specified at various IAM levels, such as user accounts, roles, organizational units, organizations, or other identity dimensions. In contrast to endpoint permission policies, resource permission policies allow administrators to identify which entities can access specific resources (subject to the endpoint permission policy).

[0065] As indicated by circle FA, the virtual networking service 101 updates the owner endpoint configuration data 270 (e.g., a portion of the endpoint configuration data 170). The virtual networking service 101 uses the owner endpoint configuration data 270 to track which resources have been shared through the resource owner endpoint. Here, the virtual networking service 101 updates the owner endpoint configuration data 270 based on the create-resource-configuration request. In the exemplary owner endpoint configuration data 270, the entry created for the create-resource-configuration request to VNE-2C33 includes an identification of the resource to be shared (e.g., database1.db.com or other resource identifier) and the resource permission policy, if any. The entry in the owner endpoint configuration data 270 allows a routable path between the resource owner endpoint VNE-2C33 and the shared resource database1.db.com, as indicated by circle FB.

[0066] In some examples, the virtual networking service 101 can support a modify-resource-owner-endpoint request, which identifies the resource owner endpoint to be modified and the modifications to be made. For example, an administrator can use a modify-resource-owner-endpoint request to change endpoint security policies and / or endpoint permissions policies. Upon receiving the modify-resource-owner-endpoint request, the virtual networking service 101 can update the endpoint data 160.

[0067] In some examples, the virtual networking service 101 can support a modify-resource-configuration request that identifies the resource owner endpoint and the shared resource to be modified, along with the modifications to be performed. For example, an administrator can use the modify-resource-configuration request to change a resource permission policy. Upon receiving the modify-resource-configuration request, the virtual networking service 101 can update the owner endpoint configuration data 270.

[0068] In some examples, when the virtual networking service 101 updates endpoint data 160 or owner endpoint configuration data 270, it may also update lookup data 180, as indicated by circle G. Lookup data 180 facilitates discovery of shared resources at resource consumer endpoints. Lookup data 180 may be indexed in one or more identity dimensions. For example, lookup data 180 may include dimensions associated with user accounts, roles, organizational units, organizations, and / or other identity dimensions. When an entity (e.g., such as an administrator of a VN with a resource consumer endpoint) initiates shared resource discovery (e.g., via a describe-endpoint-resources API request described below), the virtual networking service 101 may quickly identify each shared resource permitted to the entity based on the entity's one or more identity dimensions. For example, if a user has an associated account, role, and organization, the virtual networking service 101 may identify which resources are shared with the account, with the role, and with the organization.

[0069] The virtual networking service 101 can construct the lookup data 180 based on the endpoint and resource permission policies specified by the administrator for sharing resources through the resource owner endpoint. For example, if the endpoint permission policy permits entities within organization A to access shared resources through the associated resource owner endpoint, the virtual networking service 101 can add an entry to the organization data structure for organization A, which generally identifies any resources shared through the resource owner endpoint. When an entity associated with organization A initiates shared resource discovery, the resources shared through the resource owner endpoint will be returned. If the resource permission policy adds a user account to a specific shared resource configuration, the virtual networking service 101 can add an entry to the user account data structure for that user account, which identifies the specific shared resource shared through the resource owner endpoint.

[0070] In some examples, the virtual networking service 101 can support a delete-resource-owner-endpoint request that identifies a resource owner endpoint to be deleted. Upon receiving the delete-resource-owner-endpoint request, the virtual networking service 101 can delete the entry associated with the identified resource owner endpoint from the endpoint data 160, delete any resource configuration associated with the identified resource owner endpoint from the owner endpoint configuration data 270, delete any lookup associated with the identified resource owner endpoint from the lookup data 180, and delete any mapping for the identified resource owner endpoint in the mapping data 150.

[0071] In some examples, the virtual networking service 101 can support a delete-resource-configuration request that identifies a resource owner endpoint and a shared resource to be deleted from the resource owner endpoint. Upon receiving the delete-resource-configuration request, the virtual networking service 101 can delete the associated shared resource entry from the resource owner endpoint in the owner endpoint configuration data 270 and delete any mappings in the mapping data 150 to the identified shared resource.

[0072] Figure 3 An environment for accessing shared resources in a virtual network of a cloud provider network is shown according to some examples. Specifically, various exemplary configuration operations associated with accessing shared resources are described with reference to circled letters A through H. In this example, an administrator of VN 102A interacts with virtual network interconnection service 101 via electronic device 301 and one or more interfaces, such as by using application programming interface (API) calls issued through a program or website, by issuing commands via a web-based console or application, and the like.

[0073] As shown in circle A, the virtual network interconnect service 101 receives a create-resource-consumer-endpoint request. The create-resource-consumer-endpoint request allows the virtual network interconnect service 101 to establish a foothold within the specified VN using the resource owner endpoint. Here, the create-resource-consumer-endpoint request includes identifying the VN using the VN identifier VN-A243 assigned to VN 102A. The create-resourc e-consumer-endpoint request may include one or more parameters, such as the identity of the virtual network (or the identity of one or more of its subnets, if subnetting is performed). Assuming that the resource consumer endpoint will provide access to more than one shared resource, the request typically includes the parameter –assign-prefixes <n>N prefixes can be assigned to resource consumer endpoints. For example, a / 28 block provides addressing to up to 16 different shared resources.

[0074] In some examples, the optional parameter --security-policy in the create-resource-consumer-endpoint request<policy_document> Allows administrators to specify security policies for resource consumer endpoints. Exemplary security policies can be specified in a writable format such as JSON and can include an allow list to specify which ports or protocols are permitted to transit the resource consumer endpoint and / or a block list to specify which ports or protocols are prohibited to transit the resource consumer endpoint.

[0075] In some examples, the optional parameter --endpoint-permissions-policy in the create-resource-consumer-endpoint request<policy_document> Allows administrators to specify permission policies for resource consumer endpoints. Exemplary permission policies can be specified in a writable format such as JSON and typically include allow lists (rather than block lists) to explicitly identify certain entities accessible through the resource consumer endpoint (e.g., other virtual networks identified by a virtual network identifier). Entity identifiers can be specified at various IAM levels, such as user accounts, roles, organizational units, organizations, or other identity dimensions.

[0076] As part of processing the create-resource-consumer-endpoint request, the virtual network interconnection service 101 issues a create-network-interface request to the VM management service 202 of the cloud provider network, as indicated by circle BA, which includes an identification of the VN or subnet identified in the request received at circle A and addressing information (e.g., whether to assign an address, multiple addresses, a prefix, or multiple prefixes to the VNI). As indicated by circle BB, the VM management service 202 creates a VNI in VN 102A, assigns it an identifier, and obtains one or more VN network addresses to be assigned to the VNI (e.g., using DHCP). The VM management service 202 returns the identifier and an indication of the assigned network address to the virtual network interconnection service 101. Here, the VNI is assigned the identifier VNE-A245 and the address prefix 10.100.0.0 / 28.

[0077] As indicated by circle CA, virtual network interconnect service 101 issues an attach-network-interface request to VM management service 202, the request including a VNI identifier and a target identifier to which the identified VNI is to be attached. The request includes the target identifier associated with virtual network interconnect service 101, thereby providing the virtual network interconnect service with an attachment (or foothold) to VN 102A. As indicated by circle CB, VM management service 202 creates an attachment between the VNI and virtual network interconnect service 101. In this way, VNI 104A acts as a resource endpoint based on its connection between VN 102A and virtual network interconnect service 101.

[0078] As indicated by circle D, the virtual networking service 101 updates the endpoint data 160. Here, the virtual networking service 101 updates the endpoint data 160 based on the creation of the resource consumer endpoint 104A. In the exemplary endpoint data 160, the entry associated with the resource consumer endpoint 104A includes a VN identifier (VN-A 243), an endpoint identifier (VNE-A 245), an endpoint type (e.g., owner or consumer), an address assigned to the endpoint (here, 10.100.0.0 / 28), and one or more policies associated with the endpoint, such as a security policy and / or endpoint permission policy included with the create-resource-consumer-endpoint request.

[0079] As indicated by circle E, the virtual network interconnect service 101 receives a describe-endpoint-resources request. The describe-endpoint-resources request enables discovery of resources available for access through a resource consumer endpoint by providing a response that lists those available resources. To this end, the describe-endpoint-resources request returns identification of available resources shared by the same or different administrators through resource owner endpoints in other VNs. In some examples, the request may include identity data, such as an indication of one of the identity dimensions described above, which the virtual network interconnect service 101 may verify through another service of the cloud provider network, such as an IAM service (not shown). Alternatively, the request may include an identification of the VN, and the virtual network interconnect service 101 may obtain identity data associated with the VN. For example, the identity data may identify a user account, a role, an organizational unit, an organization, and / or other identity dimensions. The virtual network interconnect service 101 may use the lookup data 180 to identify each shared resource that is available for those one or more identity dimensions. Continued from Figure 2 For example, and assuming that the administrator of the resource owner endpoint 106A configures the identity sharing instance 108A associated with the resource consumer endpoint 104A, the response will include an identification of database1.db.com available through the resource owner endpoint VNE-2C33. The identification of the resource may be provided as one or more of a domain name of the resource, a unique identifier assigned to the resource, and / or a network address of the resource within its VN.

[0080] As indicated by circle F, virtual network interconnect service 101 receives an add-resource-to-endpoint request. The add-resource-to-endpoint request initiates the creation of a routable path through a resource consumer endpoint to a resource shared through a resource owner endpoint. The create-resource-configuration request may include one or more parameters, such as an identification of a resource and an identification of a resource consumer endpoint to which the identified resource is to be added. For example, the request may include an identification of VNE-2C33 and an identification of the database1.db.com resource by a domain name (or alternatively, by a unique identifier, network address, or other identifier of the resource).

[0081] The virtual networking service 101 may select one of the available network addresses associated with the resource consumer endpoint to associate with the identified shared resource. For example, if a / 28 address block is assigned to the resource consumer endpoint and five address blocks are used for other resources in other VNs, the virtual networking service 101 may select a network address from one of the remaining eleven available network addresses to associate with the shared resource. The virtual networking service 101 may track whether an address associated with the resource consumer endpoint is already associated with a shared resource. In this example, the virtual networking service 101 associates the address 10.100.0.0 with the identified shared resource.

[0082] As indicated by circle GA, virtual network interconnection service 101 issues a create-dns-record request to VM management service 202, which includes an identification of the local VN address selected to be associated with the shared resource and the domain name of the shared resource. As indicated by circle GB, VM management service 202 updates name server 110A of VN 102A to include a record associating the domain name database1.db.com with the associated address of the shared resource, or 10.100.0.0. In other examples, the domain name of the shared resource does not need to be propagated to the VN with the resource consumer endpoint, as long as the devices within the VN access the shared resource through the associated network address.

[0083] As indicated by circles HA and HB, the virtual networking service 101 updates the consumer endpoint configuration data 370 (e.g., a portion of the endpoint configuration data 170) and the mapping data 150. The virtual networking service 101 uses the consumer endpoint configuration data 370 to track which shared resources have been added to the VN via the resource consumer endpoint. Here, the virtual networking service 101 updates the consumer endpoint configuration data 370 based on the create-resource-configuration request. In the exemplary consumer endpoint configuration data 370, the entry created for the create-resource-configuration request for VNE-A245 includes the identification of the shared resource to be accessed (here, database1.db.com) and the network address associated with the shared resource (here, 10.100.0.0). The virtual networking service 101 also creates an entry in the mapping data 150 to link the shared resource from the resource consumer endpoint and the associated network address to the resource owner endpoint and the actual network address. Here, the entry links the associated network address 10.100.0.0 in VN 102A to the actual network address 10.0.0.1 of the shared resource in VN 102B (not shown) through resource consumer endpoint 104A and resource owner endpoint 106A (not shown) having endpoint identifiers VNE-A245 and VNE-2C33, respectively.

[0084] In some examples, virtual networking service 101 can support a modify-resource-consumer-endpoint request that identifies the resource owner endpoint to be modified and the modifications to be made. For example, an administrator can use a modify-resource-consumer-endpoint request to change endpoint security policies and / or endpoint permissions policies. Upon receiving a modify-resource-consumer-endpoint request, virtual networking service 101 can update endpoint data 160.

[0085] In some examples, virtual networking service 101 can support a delete-resource-consumer-endpoint request that identifies a resource consumer endpoint to be deleted. Upon receiving the delete-resource-consumer-endpoint request, virtual networking service 101 can delete the entry associated with the identified resource owner endpoint from endpoint data 160, delete any resource configuration associated with the identified resource owner endpoint from consumer endpoint configuration data 370, delete any lookup associated with the identified resource owner endpoint from lookup data 180, and delete any mapping from the identified resource consumer endpoint in mapping data 150.

[0086] In some examples, the virtual networking service 101 can support a delete-resource-configuration request that identifies a resource consumer endpoint and a shared resource to be deleted from the resource consumer endpoint. Upon receiving the delete-resource-configuration request, the virtual networking service 101 can delete the associated shared resource entry from the resource consumer endpoint in the consumer endpoint configuration data 370 and any mappings in the mapping data 150 to the identified shared resource.

[0087] Figure 4 An environment of resource sharing in a virtual network with subnets according to some examples is shown. As shown, VN 400VN has a network address block 10.0.0.0 / 16. The VN is divided into two subnets, subnet 402A and 402B, having identifiers VN-A243-SN-123 and VN-A243-SN-123, respectively, and assigned CIDR blocks 10.0.0.0 / 17 and 10.0.128.0 / 17. In some examples involving subnetted VNs, the virtual network interconnection service 101 may create a resource endpoint (whether owner or consumer) in one or more of the VN subnets. The identification may be based on one or more parameters received with a create-resource-owner-endpoint or create-resource-consumer-endpoint request. In some examples, the identification of the subnetted VN in the request may implicitly cause the virtual network interconnection service 101 to create a resource endpoint within each of the VN subnets. For example, a request identifying VN-A243 may implicitly create a resource endpoint in each subnet. In other examples, a request may require the explicit identification of one or more subnets of a subnetted VN in which the resource endpoint is to be created. For example, a request may include the identification of subnets VN-A243-SN123 and VN-A243-SN123. In either case, the virtual network interconnection service 101 will create resource endpoint 404A within subnet 402A and resource endpoint 404B within subnet 402B. However, if the virtual network interconnection service 101 request requires the explicit identification of subnets, a request identifying only one of subnets VN-A243-SN123 and VN-A243-SN123 will result in the creation of resource endpoints only in the identified subnet (not shown).

[0088] In some examples, resource endpoints in different subnets of a VN can be treated as a group (e.g., the endpoint_id in the owner endpoint configuration data 270 or the customer endpoint configuration data 370 includes multiple entries corresponding to each of the subnets). In other examples, each resource endpoint in a different subnet can be managed independently, allowing an administrator to share resources in one subnet but not in another subnet (again, whether as an owner or a consumer).

[0089] In some examples, network addresses are assigned to endpoints individually rather than as prefix groups. For example, an administrator might specify a group of network addresses to associate with an endpoint as part of an association create endpoint request.

[0090] Figure 5 is a flow chart illustrating operations 500 of a method for sharing resources between virtual networks of a cloud provider network according to some examples. Some or all of operations 500 (or other processes, variations, and / or combinations thereof described herein) are performed under the control of one or more computer systems configured with executable instructions and implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that executes collectively on one or more processors. The code is stored, for example, in the form of a computer program including instructions executable by one or more processors on a computer-readable storage medium. The computer-readable storage medium is non-transitory. In some examples, one or more (or all) of operations 500 are performed by the virtual network interconnection service 101 of other Figures.

[0091] Operation 500 includes, at block 502, associating a first network address of a first virtual network with a resource connected to a second virtual network, wherein the first virtual network and the second virtual network are part of a cloud provider network. Operation 500 further includes, at block 504, receiving a message addressed to the first network address. Operation 500 further includes, at block 506, translating the first network address to a second network address of the resource in the second virtual network. Operation 500 further includes, at block 508, sending the message to the resource at the second network address in the second virtual network.

[0092] Figure 6 An example provider network (or "service provider system") environment is shown, according to some examples. Provider network 600 can provide resource virtualization to customers via one or more virtualization services 610, which allow customers to purchase, lease, or otherwise obtain instances 612 of virtualized resources (including, but not limited to, computing resources and storage resources) implemented on devices within one or more provider networks in one or more data centers. A local Internet Protocol (IP) address 616 can be associated with resource instance 612; the local IP address is the internal network address of the resource instance 612 on provider network 600. In some examples, provider network 600 can also provide public IP addresses 614 and / or public IP address ranges (e.g., Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) addresses) that customers can obtain from provider 600.

[0093] Conventionally, provider network 600 can allow a customer of the service provider (e.g., a customer operating one or more customer networks 650A-650C (or "client networks") including one or more customer devices 652) via virtualization service 610 to dynamically associate at least some public IP addresses 614 assigned or allocated to the customer with a specific resource instance 612 assigned to the customer. Provider network 600 can also allow a customer to remap a public IP address 614 previously mapped to one virtualized computing resource instance 612 assigned to the customer to another virtualized computing resource instance 612 also assigned to the customer. Using the virtualized computing resource instances 612 and public IP addresses 614 provided by the service provider, customers of the service provider, such as operators of customer networks 650A-650C, can, for example, implement customer-specific applications and present the customer's applications on an intermediate network 640 (such as the Internet). Other network entities 620 on intermediary network 640 can then generate traffic to destination public IP address 614 published by customer networks 650A through 650C; the traffic is routed to the service provider data center, and there, via the network substrate, to the local IP address 616 of virtualized computing resource instance 612, which is now mapped to destination public IP address 614. Similarly, response traffic from virtualized computing resource instance 612 can be routed back onto intermediary network 640 via the network substrate to source entity 620.

[0094] As used herein, a local IP address refers to an internal or "private" network address of a resource instance, for example, in a provider network. The local IP address may be within the address block reserved by Request for Comments (RFC) 1918 of the Internet Engineering Task Force (IETF) and / or have an address format specified by IETF RFC 4193, and may be variable within the provider network. Network traffic originating outside the provider network is not routed directly to the local IP address; instead, the traffic uses a public IP address that is mapped to the local IP address of the resource instance. The provider network may include networking equipment or devices that provide network address translation (NAT) or similar functionality to perform mappings from public IP addresses to local IP addresses and from local IP addresses to public IP addresses.

[0095] A public IP address is a mutable network address on the Internet assigned to a resource instance by a service provider or customer. Traffic routed to a public IP address is translated, for example, via 1:1 NAT, and forwarded to the corresponding local IP address of the resource instance.

[0096] Some public IP addresses may be assigned to specific resource instances by the provider network infrastructure; these public IP addresses may be referred to as standard public IP addresses, or simply standard IP addresses. In some examples, the mapping of standard IP addresses to the local IP addresses of resource instances is the default launch configuration for all resource instance types.

[0097] At least some public IP addresses may be allocated to or obtained by customers of the provider network 600; the customers may then assign their allocated public IP addresses to specific resource instances assigned to the customers. These public IP addresses may be referred to as customer public IP addresses, or simply customer IP addresses. Rather than being assigned to resource instances by the provider network 600 as in the case of standard IP addresses, customer IP addresses may be assigned to resource instances by the customer, for example, via an API provided by the service provider. Unlike standard IP addresses, customer IP addresses are assigned to customer accounts and may be remapped to other resource instances by the respective customers as needed or desired. Customer IP addresses are associated with customer accounts rather than specific resource instances, and the customer controls the IP address until the customer chooses to release it. Unlike conventional static IP addresses, customer IP addresses allow customers to mask resource instance or availability zone failures by remapping the customer's public IP address to any resource instance associated with the customer account. For example, customer IP addresses enable customers to resolve issues with the customer's resource instances or software by remapping the customer IP address to an alternative resource instance.

[0098] Figure 7 7 is a block diagram of an example provider network environment that provides storage services and hardware virtualization services to customers, according to some examples. Hardware virtualization service 720 provides multiple computing resources 724 (e.g., computing instances 725 such as VMs) to customers. Computing resources 724 can be provided as a service to customers of provider network 700 (e.g., customers implementing customer network 750). Each computing resource 724 can be provided with one or more local IP addresses. Provider network 700 can be configured to route packets from the local IP addresses of computing resources 724 to public internet destinations, and to route packets from public internet sources to the local IP addresses of computing resources 724.

[0099] The provider network 700 can provide a customer network 750, coupled to the intermediary network 740 via, for example, a local network 756, with the ability to implement a virtual computing system 792 via a hardware virtualization service 720 coupled to the intermediary network 740 and the provider network 700. In some examples, the hardware virtualization service 720 can provide one or more APIs 702, such as web service interfaces, via which the customer network 750 can access functionality provided by the hardware virtualization service 720, such as via a console 794 (e.g., a web-based application, a standalone application, a mobile application, etc.) of a customer device 790. In some examples, at the provider network 700, each virtual computing system 792 at the customer network 750 can correspond to a computing resource 724 that is leased, rented, or otherwise provided to the customer network 750.

[0100] From an instance of a virtual computing system 792 and / or another client device 790 (e.g., via a console 794), a client can access functionality of a storage service 710, for example, via one or more APIs 702, to access and store data from storage resources 718A through 718N of a virtual data repository 716 (e.g., folders or "buckets," virtualized volumes, databases, etc.) provided by a provider network 700. In some examples, a virtualized data storage gateway (not shown) can be located at the client network 750, which can cache at least some data (e.g., frequently accessed data or critical data) locally and can communicate with the storage service 710 via one or more communication channels to upload new or modified data from the local cache, thereby maintaining a master data repository (the virtualized data repository 716). In some examples, a user, via the virtual computing system 792 and / or another client device 790, can mount and access volumes of the virtualized data repository 716 via the storage service 710 acting as a storage virtualization service, and these volumes can appear to the user as local (virtualized) storage 798.

[0101] Although Figure 7 Although not shown, the virtualization service may also be accessed from a resource instance within the provider network 700 via the API 702. For example, a customer, equipment service provider, or other entity may access the virtualization service via the API 702 from within a corresponding virtual network on the provider network 700 to request allocation of one or more resource instances within the virtual network or within another virtual network.

[0102] Descriptive System

[0103] In some examples, a system implementing part or all of the techniques described herein may include a general-purpose computer system (such as Figure 8 The computer system 800 shown in FIG. 8 is a general purpose computer system that includes or is configured to access one or more computer-accessible media. In the example shown, the computer system 800 includes one or more processors 810 coupled to a system memory 820 via an input / output (I / O) interface 830. The computer system 800 further includes a network interface 840 coupled to the I / O interface 830. Although Figure 8 Computer system 800 is shown as a single computing device, but in various examples, computer system 800 may include one computing device or any number of computing devices configured to work together as a single computer system 800 .

[0104] In various examples, the computer system 800 may be a uniprocessor system including one processor 810 or a multiprocessor system including several processors 810 (e.g., two, four, eight, or another suitable number). The processor 810 may be any suitable processor capable of executing instructions. For example, in various examples, the processor 810 may be a general-purpose or embedded processor that implements any of a variety of instruction set architectures (ISAs), such as the x86, ARM, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISAs. In a multiprocessor system, each of the processors 810 may often, but not necessarily, implement the same ISA.

[0105] The system memory 820 may store instructions and data that may be accessed by the processor 810. In various examples, the system memory 820 may be implemented using any suitable memory technology, such as random access memory (RAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash-type memory, or any other type of memory. In the illustrated example, program instructions and data that implement one or more desired functions (such as those methods, techniques, and data described above) are shown as stored within the system memory 820 as virtual networking service code 825 (e.g., executable to fully or partially implement the virtual networking service 101) and data 826.

[0106] In some examples, the I / O interface 830 can be configured to coordinate I / O traffic between the processor 810, the system memory 820, and any peripheral devices in the device, including the network interface 840 and / or other peripheral interfaces (not shown). In some examples, the I / O interface 830 can perform any necessary protocol, timing, or other data transformations to convert data signals from one component (e.g., the system memory 820) into a format suitable for use by another component (e.g., the processor 810). In some examples, for example, the I / O interface 830 can include support for devices attached via various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. In some examples, for example, the functionality of the I / O interface 830 can be split into two or more separate components, such as a northbridge and a southbridge. Additionally, in some examples, some or all of the functionality of the I / O interface 830 (such as the interface to the system memory 820) can be incorporated directly into the processor 810.

[0107] For example, the network interface 840 may be configured to allow the computer system 800 to communicate with other devices 860 attached to one or more networks 850 (such as Figure 1 In various examples, network interface 840 may support communication via any suitable wired or wireless general-purpose data network, such as various types of Ethernet networks, for example. Additionally, network interface 840 may support communication via a telecommunications / telephone network, such as an analog voice network or a digital fiber-optic communications network, via a storage area network (SAN), such as a Fibre Channel SAN, and / or via any other suitable type of network and / or protocol.

[0108] In some examples, the computer system 800 includes one or more offload cards 870A or 870B (including one or more processors 875 and possibly one or more network interfaces 840) connected using an I / O interface 830 (e.g., a bus implementing a version of the Peripheral Component Interconnect Express (PCI-E) standard or another interconnect such as Quick Path Interconnect (QPI) or Ultra Path Interconnect (UPI)). For example, in some examples, the computer system 800 may act as a host electronic device hosting computing resources such as computing instances (e.g., operating as part of a hardware virtualization service), and the one or more offload cards 870A or 870B may execute a virtualization manager that may manage computing instances executing on the host electronic device. As an example, in some examples, the offload card 870A or 870B may perform computing instance management operations such as pausing and / or unpausing computing instances, starting and / or terminating computing instances, performing memory transfer / copy operations, etc. In some examples, these management operations may be performed by offload card 870A or 870B in cooperation with hypervisors (e.g., pursuant to requests from the hypervisors) executed by other processors 810A through 810N of computer system 800. However, in some examples, the virtualization manager implemented by offload card 870A or 870B may adapt to requests from other entities (e.g., from the compute instances themselves) and may not cooperate with (or serve) any individual hypervisor.

[0109] In some examples, system memory 820 may be an example of a computer-accessible medium configured to store program instructions and data as described above. However, in other examples, program instructions and / or data may be received, sent, or stored on different types of computer-accessible media. Generally speaking, computer-accessible media may include any non-transitory storage medium or memory medium, such as magnetic or optical media, for example, a disk or DVD / CD coupled to computer system 800 via I / O interface 830. Non-transitory computer-accessible storage media may also include any volatile or non-volatile medium that may be included in some examples of computer system 800 as system memory 820 or another type of memory, such as RAM (e.g., SDRAM, double data rate (DDR) SDRAM, SRAM, etc.), read-only memory (ROM), etc. In addition, computer-accessible media may include transmission media or signals transmitted via a communication medium (such as a network and / or wireless link), such as electrical signals, electromagnetic signals, or digital signals, which may be implemented via network interface 840.

[0110] The various examples discussed or proposed herein can be implemented in a variety of operating environments, which in some cases may include one or more user computers, computing devices, or processing devices that can be used to operate any of a number of applications. A user device or client device may include any of a number of general-purpose personal computers, such as a desktop or laptop computer running a standard operating system, and a cellular device, wireless device, and handheld device running mobile software and capable of supporting a number of networking and messaging protocols. Such a system may also include a number of workstations running various commercially available operating systems and any of other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and / or other devices capable of communicating via a network.

[0111] Most examples use at least one network familiar to those skilled in the art to support communications using any of a variety of widely available protocols, such as Transmission Control Protocol / Internet Protocol (TCP / IP), File Transfer Protocol (FTP), Universal Plug and Play (UPnP), Network File System (NFS), Common Internet File System (CIFS), Extensible Messaging and Presence Protocol (XMPP), AppleTalk, etc. The network may include, for example, a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), the Internet, an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network, and any combination thereof.

[0112] In an example using a web server, the web server may run any of a variety of server or middle-tier applications, including an HTTP server, a File Transfer Protocol (FTP) server, a Common Gateway Interface (CGI) server, a data server, a Java server, a business application server, etc. The server may also be capable of executing programs or scripts in response to requests from user devices, such as by executing a program that can be implemented in any programming language (such as The server may further include one or more web applications that are written in one or more scripts or programs in C, C#, or C++, or any scripting language such as Perl, Python, PHP, or TCL, or any combination thereof. The server may also include a database server, including but not limited to commercially available database servers from Oracle(R), Microsoft(R), Sybase(R), IBM(R), etc. The database server may be relational or non-relational (e.g., "NoSQL"), distributed or non-distributed, etc.

[0113] The environment disclosed herein may include various data repositories and other memories and storage media as discussed above. These may reside in various locations, such as on (and / or reside in) a storage medium local to one or more computers, or on a storage medium remote from any or all computers on a network. In a specific set of examples, information may reside in a storage area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing functions attributed to a computer, server, or other network device may be stored locally and / or remotely as appropriate. In the case where the system includes a computerized device, each such device may include hardware elements electrically coupled via a bus, including, for example, at least one central processing unit (CPU), at least one input device (e.g., a mouse, keyboard, controller, touch screen, or keypad), and / or at least one output device (e.g., a display device, printer, or speaker). Such a system may also include one or more storage devices, such as hard drives, optical storage devices, and solid-state storage devices such as random access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash memory cards, etc.

[0114] Such devices may also include a computer-readable storage medium reader, a communication device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.) and a working memory as described above. The computer-readable storage medium reader may be connected to a computer-readable storage medium or configured to receive a computer-readable storage medium, which represents a remote, local, fixed and / or removable storage device and storage medium for temporarily and / or longer-term accommodating, storing, transmitting and retrieving computer-readable information. The system and various devices will typically also include a number of software applications, modules, services or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or a web browser. It should be understood that alternative examples may have many variations different from those described above. For example, custom hardware may also be used, and / or specific elements may be implemented in hardware, software (including portable software, such as applets), or both. In addition, connections to other computing devices such as network input / output devices may be employed.

[0115] The storage media and computer-readable media used to hold the code or code portions may include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile media, removable and non-removable media implemented in any method or technology to store and / or transmit information (such as computer-readable instructions, data structures, program modules or other data), including RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk-read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by the system device. Based on this disclosure and the teachings provided herein, those skilled in the art will understand other ways and / or methods to implement the various examples.

[0116] In the foregoing description, various examples have been described. For purposes of explanation, specific configurations and details have been set forth to provide a thorough understanding of the examples. However, it will be apparent to those skilled in the art that the examples can be practiced without these specific details. Furthermore, well-known features may be omitted or simplified to avoid obscuring the described examples.

[0117] Bracketed text and boxes with dashed borders (e.g., large dashes, small dashes, dot dashes, and dots) are used herein to illustrate optional aspects that add additional features to some examples. However, this notation should not be taken to mean that these are the only options or optional operations, and / or that in some examples, boxes with solid borders are not optional.

[0118] Reference numerals with suffix letters (e.g., 718A through 718N) may be used to indicate that there may be one or more instances of the referenced entity in various examples, and when multiple instances exist, each instance need not be identical but may share some general characteristics or function in a common manner. Furthermore, unless expressly indicated to the contrary, the use of a particular suffix is not intended to imply the presence of a particular number of entities. Thus, in various examples, two entities using the same or different suffix letters may or may not have the same number of instances.

[0119] References to "one example," "an example," and the like indicate that the described example may include a particular feature, structure, or characteristic, but not every example may include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same example. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an example, it should be understood that it is within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other examples, whether or not explicitly described.

[0120] Furthermore, in the various examples described above, unless specifically noted otherwise, disjunctive language such as the phrase "at least one of A, B, or C" is intended to be understood to mean A, B, or C, or any combination thereof (e.g., A, B, and / or C). Similarly, language such as "at least one or more of A, B, and C" (or "one or more of A, B, and C") is intended to be understood to mean A, B, or C, or any combination thereof (e.g., A, B, and / or C). Thus, disjunctive language is neither intended nor should be understood to imply that a given example requires that at least one of A, at least one of B, and at least one of C each be present.

[0121] As used herein, the term "based on" (or similar) is an open-ended term used to describe one or more factors that influence a determination or other action. It should be understood that this term does not exclude additional factors that may influence the determination or action. For example, a determination may be based solely on the listed factors or on the factors and one or more additional factors. Thus, if action A is "based on" B, it should be understood that B is one factor that influences action A, but this does not exclude that the action is also based on one or more other factors, such as factor C. However, in some cases, action A may be based entirely on B.

[0122] Unless expressly stated otherwise, articles such as "a" or "an" should generally be construed to include one or more of the described items. Thus, phrases such as "a device configured to" or "computing device" are intended to include one or more of the recited devices. Such one or more recited devices may be collectively configured to perform the recited operations. For example, "a processor configured to perform operations A, B, and C" may include a first processor configured to perform operation A working together with a second processor configured to perform operations B and C.

[0123] In addition, the words "may" or "could" are used in a permissive sense (i.e., meaning having some possibility), rather than in a mandatory sense (i.e., meaning must). The words "include", "including", and "includes" are used to indicate an open relationship, and therefore mean including but not limited to. Similarly, the words "have", "having", and "has" also indicate an open relationship, and therefore mean having but not limited to. As used herein, the terms "first", "second", "third", etc. are used as labels for the nouns that follow them, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless such ordering is otherwise explicitly indicated. Similarly, the values of such numerical labels are generally not used to indicate the required quantity of a particular noun in the claims recited herein, and therefore a "fifth" element generally does not mean that the other four elements are present, unless such elements are explicitly included in the claim or their presence is otherwise sufficiently clearly indicated.

[0124] At least some embodiments of the disclosed technology can be described in terms of the following:

[0125] 1. A computer-implemented method comprising:

[0126] Services via the cloud provider network:

[0127] associating a resource having a first network address on a first virtual network with a resource owner endpoint having a second network address on the first virtual network, wherein the resource owner endpoint is a virtual network interface of the service to the first virtual network;

[0128] assigning a network address prefix of a second virtual network to a resource consumer endpoint of the second virtual network, wherein the resource consumer endpoint is a virtual network interface of the service to the second virtual network;

[0129] associating a third network address within the network address prefix with the resource;

[0130] receiving a message from the resource consumer endpoint, the message being directed to the third network address;

[0131] translating the third network address into the first network address on the first virtual network; and

[0132] The message is sent through the resource owner endpoint to the resource at the first network address on the first virtual network.

[0133] 2. The computer-implemented method of clause 1, wherein the resource has an associated domain name, and the method further comprises:

[0134] A name server of the second virtual network is updated with a record associating the domain name of the resource with the third network address.

[0135] 3. The computer-implemented method of any of clauses 1-2, further comprising:

[0136] A policy is received for association with the resource, the policy granting access to the resource to at least one of an account, a role, an organizational unit, or an organization associated with the second virtual network.

[0137] 4. A computer-implemented method comprising:

[0138] Services via the cloud provider network:

[0139] associating a first network address of a first virtual network with a resource connected to a second virtual network, wherein the first virtual network and the second virtual network are part of the cloud provider network;

[0140] receiving a message addressed to the first network address;

[0141] translating the first network address into a second network address of the resource in the second virtual network; and

[0142] The message is sent to the resource at the second network address in the second virtual network.

[0143] 5. The computer-implemented method of clause 4, further comprising, by the service:

[0144] receiving a first request to create a virtual network interface between the service and the second virtual network to share resources of the second virtual network with other virtual networks; and

[0145] The virtual network interface is created between the service and the second virtual network, wherein the message is sent by the service to the resource through the virtual network interface.

[0146] 6. The computer-implemented method of clause 5, further comprising, by the service:

[0147] receiving a second request to associate the resource with the virtual network interface, the second request comprising an identification of the resource and an indication of the virtual network interface; and

[0148] Service metadata is updated to associate the resource with the virtual network interface.

[0149] 7. The computer-implemented method of clause 6, wherein the identification of the resource in the second request is at least one of a resource name, a domain name, or a network address, the resource name being unique to the resource within the cloud provider network.

[0150] 8. A computer-implemented method as described in any of clauses 6-7, wherein the second request further includes a permission policy that identifies at least one of a user account, role, organizational unit, or organization associated with the first virtual network as having permission to access the resource.

[0151] 9. The computer-implemented method of clause 4, further comprising, by the service:

[0152] receiving a first request to create a virtual network interface between the service and the first virtual network to access shared resources in other virtual networks; and

[0153] The virtual network interface is created between the service and the first virtual network, wherein the message to the first network address is received by the service through the virtual network interface.

[0154] 10. The computer-implemented method of clause 9, further comprising, by the service:

[0155] receiving a request to identify a resource to be shared with an identity, wherein the identity is at least one of a user account, a role, an organizational unit, or an organization of the first virtual network;

[0156] providing identification of one or more resources shared with the identity, the identification including an identification of the resource connected to the second virtual network; and

[0157] A request to add the resource to the virtual network interface is received, wherein the first network address of the first virtual network is associated with the resource connected to the second virtual network based at least in part on the request to add the resource to the virtual network interface.

[0158] 11. The computer-implemented method of clause 10, further comprising, by the service:

[0159] A name server of the first virtual network is updated with a record associating a domain name of the resource connected to the second virtual network with the first network address.

[0160] 12. The computer-implemented method of any of clauses 9-11, further comprising, by the service:

[0161] storing a mapping of the virtual network interface, the source network address of the message, and the source port of the message to a port of another virtual network interface between the service and the second virtual network;

[0162] wherein sending the message to the resource at the second network address in the second virtual network comprises: replacing the source network address of the message with the network address of the other virtual network interface, and replacing the source port with the port of the other virtual network interface;

[0163] receiving a second message from the resource, the second message having a destination network address of the network address of the other virtual network interface and a destination port of the port of the other virtual network interface; and

[0164] identifying a stored mapping based on the destination port of the second message; and

[0165] replacing the destination network address of the second message with the source network address of the message in the stored mapping, and replacing the destination port of the second message with the source port of the message in the stored mapping; and

[0166] The second message is sent to the first virtual network through the virtual network interface in the stored mapping.

[0167] 13. A system comprising:

[0168] One or more first electronic devices configured to implement a virtual network interconnection service in a cloud provider network, the virtual network interconnection service comprising instructions that, when executed, cause the virtual network interconnection service to:

[0169] associating a first network address of a first virtual network with a resource connected to a second virtual network, wherein the first virtual network and the second virtual network are part of the cloud provider network;

[0170] receiving a message addressed to the first network address;

[0171] translating the first network address into a second network address of the resource in the second virtual network; and

[0172] sending the message to the resource at the second network address in the second virtual network; and

[0173] A second one or more electronic devices for hosting the resources connected to the second virtual network.

[0174] 14. The system of clause 13, the virtual networking service comprising further instructions that, when executed, cause the virtual networking service to:

[0175] receiving a first request to create a virtual network interface between the service and the second virtual network to share resources of the second virtual network with other virtual networks; and

[0176] The virtual network interface is created between the service and the second virtual network, wherein the message is sent by the service to the resource through the virtual network interface.

[0177] 15. The system of clause 14, the virtual networking service comprising further instructions that, when executed, cause the virtual networking service to:

[0178] receiving a second request to associate the resource with the virtual network interface, the second request comprising an identification of the resource and an indication of the virtual network interface; and

[0179] Service metadata is updated to associate the resource with the virtual network interface.

[0180] 16. The system of clause 15, wherein the identification of the resource in the second request is at least one of a resource name, a domain name, or a network address, the resource name being unique to the resource within the cloud provider network.

[0181] 17. The system of any one of claims 15-16, wherein the second request further comprises a permission policy identifying at least one of a user account, a role, an organizational unit, or an organization associated with the first virtual network as having permission to access the resource.

[0182] 18. The system of clause 13, the virtual networking service comprising further instructions that, when executed, cause the virtual networking service to:

[0183] receiving a first request to create a virtual network interface between the service and the first virtual network to access shared resources in other virtual networks; and

[0184] The virtual network interface is created between the service and the first virtual network, wherein the message to the first network address is received by the service through the virtual network interface.

[0185] 19. The system of clause 18, the virtual networking service comprising further instructions that, when executed, cause the virtual networking service to:

[0186] receiving a request to identify a resource to be shared with an identity, wherein the identity is at least one of a user account, a role, an organizational unit, or an organization of the first virtual network;

[0187] providing identification of one or more resources shared with the identity, the identification including an identification of the resource connected to the second virtual network; and

[0188] A request to add the resource to the virtual network interface is received, wherein the first network address of the first virtual network is associated with the resource connected to the second virtual network based at least in part on the request to add the resource to the virtual network interface.

[0189] 20. The system of clause 19, the virtual networking service comprising further instructions that, when executed, cause the virtual networking service to:

[0190] A name server of the first virtual network is updated with a record associating a domain name of the resource connected to the second virtual network with the first network address.

[0191] The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader scope of the disclosure as set forth in the claims.< / n> < / n>

Claims

1. A computer-implemented method comprising: Services via the cloud provider network: associating a first network address of a first virtual network with a resource connected to a second virtual network, wherein the first virtual network and the second virtual network are part of the cloud provider network; receiving a message addressed to the first network address; Converting the first network address to a second network address of the resource in the second virtual network; as well as The message is sent to the resource at the second network address in the second virtual network.

2. The computer-implemented method of claim 1 , further comprising, by the service: receiving a first request to create a virtual network interface between the service and the second virtual network to share resources of the second virtual network with other virtual networks; and The virtual network interface is created between the service and the second virtual network, wherein the message is sent by the service to the resource through the virtual network interface.

3. The computer-implemented method of claim 2, further comprising, by the service: receiving a second request to associate the resource with the virtual network interface, the second request comprising an identification of the resource and an indication of the virtual network interface; and Service metadata is updated to associate the resource with the virtual network interface.

4. The computer-implemented method of claim 3, wherein the identification of the resource in the second request is at least one of a resource name, a domain name, or a network address, the resource name being unique to the resource within the cloud provider network.

5. The computer-implemented method of any one of claims 3-4, wherein the second request further comprises a permission policy identifying at least one of a user account, a role, an organizational unit, or an organization associated with the first virtual network as having permission to access the resource.

6. The computer-implemented method of claim 1 , further comprising, by the service: receiving a first request to create a virtual network interface between the service and the first virtual network to access shared resources in other virtual networks; and The virtual network interface is created between the service and the first virtual network, wherein the message to the first network address is received by the service through the virtual network interface.

7. The computer-implemented method of claim 6, further comprising, by the service: receiving a request to identify a resource to be shared with an identity, wherein the identity is at least one of a user account, a role, an organizational unit, or an organization of the first virtual network; providing identification of one or more resources shared with the identity, said identification including an identification of said resource connected to a second virtual network; as well as A request to add the resource to the virtual network interface is received, wherein the first network address of the first virtual network is associated with the resource connected to the second virtual network based at least in part on the request to add the resource to the virtual network interface.

8. The computer-implemented method of claim 7, further comprising, by the service: A name server of the first virtual network is updated with a record associating a domain name of the resource connected to the second virtual network with the first network address.

9. The computer-implemented method of any one of claims 6-8, further comprising, by the service: storing a mapping of the virtual network interface, the source network address of the message, and the source port of the message to a port of another virtual network interface between the service and the second virtual network; wherein sending the message to the resource at the second network address in the second virtual network comprises: replacing the source network address of the message with the network address of the other virtual network interface, and replacing the source port with the port of the other virtual network interface; receiving a second message from the resource, the second message having a destination network address of the network address of the other virtual network interface and a destination port of the port of the other virtual network interface; and identifying a stored mapping based on the destination port of the second message; and replacing the destination network address of the second message with the source network address of the message in the stored mapping, and replacing the destination port of the second message with the source port of the message in the stored mapping; and The second message is sent to the first virtual network through the virtual network interface in the stored mapping.

10. A system comprising: One or more first electronic devices configured to implement a virtual network interconnection service in a cloud provider network, the virtual network interconnection service comprising instructions that, when executed, cause the virtual network interconnection service to: associating a first network address of a first virtual network with a resource connected to a second virtual network, wherein the first virtual network and the second virtual network are part of the cloud provider network; receiving a message addressed to the first network address; Converting the first network address to a second network address of the resource in the second virtual network; as well as sending the message to the resource at the second network address in the second virtual network; as well as A second one or more electronic devices for hosting the resources connected to the second virtual network.

11. The system of claim 10, the virtual network interconnection service comprising further instructions that, when executed, cause the virtual network interconnection service to: receiving a first request to create a virtual network interface between the service and the second virtual network to share resources of the second virtual network with other virtual networks; and The virtual network interface is created between the service and the second virtual network, wherein the message is sent by the service to the resource through the virtual network interface.

12. The system of claim 11, the virtual network interconnection service comprising further instructions that, when executed, cause the virtual network interconnection service to: receiving a second request to associate the resource with the virtual network interface, the second request comprising an identification of the resource and an indication of the virtual network interface; and Service metadata is updated to associate the resource with the virtual network interface.

13. The system of claim 12, wherein the identification of the resource in the second request is at least one of a resource name, a domain name, or a network address, the resource name being unique to the resource within the cloud provider network.

14. The system of any one of claims 12-13, wherein the second request further comprises a permission policy identifying at least one of a user account, a role, an organizational unit, or an organization associated with the first virtual network as having permission to access the resource.

15. The system of claim 10, the virtual network interconnection service comprising further instructions that, when executed, cause the virtual network interconnection service to: receiving a first request to create a virtual network interface between the service and the first virtual network to access shared resources in other virtual networks; and The virtual network interface is created between the service and the first virtual network, wherein the message to the first network address is received by the service through the virtual network interface.

Images