SHARED RESOURCE USE BETWEEN CLOUD-HOSTED VIRTUAL NETWORKS

Abstract

Techniques for sharing resources between cloud-hosted networks are described. A first network address of a first virtual network is assigned to a resource connected to a second virtual network, where both the first and second virtual networks reside within a cloud provider network. A service on the cloud provider network receives a message intended for the first network address. The service translates the first network address to a second network address for the resource in the second virtual private network. The service then sends the message to the resource at the second network address in the second virtual network.

Description

GENERAL STATE OF THE ART

[0001] Cloud computing environments often provide consumers with managed computing resources on demand. Such computing resources (e.g., computing and storage capacity) are frequently provided from large capacity pools installed in data centers. Customers can request computing resources from the "cloud," and the cloud can provide these consumers with computing resources. Technologies such as virtual machines and containers are commonly used to enable consumers to securely share the capacity of computer systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various examples according to the present disclosure are described with reference to the drawings, for which the following applies: Fig. Figure 1 illustrates an environment for shared resource utilization between virtual networks of a cloud provider network, according to some examples. Fig. Figure 2 illustrates an environment for sharing a resource in a virtual network of a cloud provider network, according to some examples. Fig. Figure 3 illustrates an environment for accessing a shared resource in a virtual network of a cloud provider network, according to some examples. Fig. Figure 4 illustrates an environment for shared resource use in a virtual network that has subnetworks, according to some examples. Fig. Section 5 illustrates the processes of a procedure for shared resource utilization between virtual networks of a cloud provider network according to some examples. Fig. Figure 6 illustrates an exemplary provider network environment according to some embodiments. Fig. Figure 7 illustrates an exemplary provider network that provides a storage service and a hardware virtualization service to customers, according to some embodiments. Fig. Figure 8 illustrates an example computer system that can be used in some examples. DETAILED DESCRIPTION

[0003] This disclosure relates to a private link endpoint, referred to herein as a "resource endpoint," which enables private and secure connectivity from one virtual network (such as a virtual private cloud (VPC)) to specific resources (e.g., databases, clusters, virtual machine instances) in another virtual network. For example, a consumer of a cloud provider network can use a resource endpoint to connect to cloud services as well as to third-party services hosted in the cloud. If both virtual networks are part of the same larger network environment, such as a cloud provider network, connectivity via a resource endpoint can be advantageously established without routing traffic to the internet.This includes implementations where a consumer has a direct connection between their local computing environment and the cloud provider's region(s). Bypassing the internet can be particularly beneficial for certain types of workloads, such as storing sensitive data where security and compliance requirements preclude the use of internet gateways or virtual network peering. Resource endpoints enable a private and secure connection to such data stores across user account and virtual network boundaries. Resource endpoints can also help achieve low-latency use cases across user account boundaries, in some cases with sub-millisecond latency.

[0004] Examples include methods, devices, systems, and non-transient machine-readable storage media for sharing resources between virtual networks hosted in the cloud. According to some examples, a linking service of a virtual network introduces resource endpoints into virtual networks to share a resource with other virtual networks or to access a shared resource in another virtual network. More specifically, a consumer of a cloud provider network can introduce an "owner" resource endpoint into their virtual network and selectively configure which resources in the virtual network are shared by these resource owner endpoints and with whom each resource is shared.The same or a different consumer can introduce a resource endpoint of a "consumer" into another virtual network and selectively configure which resources shared with that virtual network are accessible within the virtual network. The resource consumer endpoint is associated with a network address prefix, within which individual network addresses can be assigned to each accessible shared resource. The virtual network's linking service translates address data from the resource consumer endpoint to the resource owner endpoint to enable the transmission of messages received by the resource consumer endpoint to the appropriate resource owner endpoint and ultimately to the shared resource.

[0005] Consumers of cloud provider networks often distribute resources (e.g., databases, clusters, etc.) across a virtual network hosted in the cloud. However, due to internal or external security or compliance requirements, these consumers may sometimes want to provide restricted sharing across virtual networks instead of the typical "general" cross-network access, such as through an internet gateway or virtual network peering (where, for example, all devices connected to one virtual network can connect to devices in another virtual network (and vice versa)).As consumers move to environments with multiple user accounts and multiple virtual networks, and require access to resources across user accounts or virtual networks, or even for their consumers with separate virtual networks, the virtual network linking service described herein provides private and secure connectivity to resources across virtual network boundaries. There are several use cases for resource endpoints, such as cross-VPC access to resources, private access to VPC resources from local networks, and one-to-many access scenarios that require access to multiple resources 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 central VPCs owned by security teams need to scan instances of virtual machines in multiple VPCs without requiring VPC peering or gateways to connect the VPCs.

[0006] The disclosed technology provides a number of technical advantages. For example, resource endpoints provide a private, secure connection to individual resources in other VPCs. Resource endpoints can offer resource consumers the ability to engage in unidirectional (consumer-initiated) communication with the shared resource, access multiple resources in different VPCs through a single endpoint, access resources across a resource endpoint from local networks via VPN and direct connection, establish connectivity to resources across VPCs with overlapping / non-overlapping CIDR, and provide sub-millisecond latency for latency-sensitive use cases such as database access.Resource endpoints can provide resource owners with improved security and privacy by allowing access to specific resources only to specific user accounts, users, roles, organizational units, organizations, and the like; they enable owners to quickly share resources without additional infrastructure such as load balancing modules, the ability to unilaterally terminate an existing connection to a resource, and the ability to share multiple resources through a single endpoint.

[0007] Fig. Figure 1 illustrates an environment for shared resource utilization between virtual networks of a cloud provider network, according to some examples. As shown, a cloud provider network 100 includes a linking service 101 of the virtual network, which provides connectivity between virtual networks 102A, 102B, 102C, and 102D, as described below. A cloud provider network (or simply "cloud") typically refers to a large pool of accessible virtualized computing resources (such as compute, storage, and network resources, applications, and services). A cloud can provide convenient, on-demand network access to a shared pool of configurable computing resources that can be provisioned programmatically and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adapt to varying loads.Cloud computing can therefore be viewed both as applications that are offered as services via a publicly accessible network (e.g. the internet, a mobile network), and as the hardware and software in data centers of cloud providers that provide these services.

[0008] A cloud provider network enables users to utilize one or more of a variety of compute-related resources, such as compute resources (e.g., running instances and / or containers of virtual machines (VMs), running batch jobs, executing code without a provisioning server), data / storage resources (e.g., object storage, block storage, data archive storage, databases and database tables, etc.), network-related resources (e.g., configuring virtual networks including groups of compute resources, content delivery networks (CDNs), domain name services (DNS)), application resources (e.g., databases, services for building / deploying applications), access policies or roles, identity policies or roles, machine images, routers, and other data processing resources, etc.These and other computing resources can be provided as services, such as a hardware virtualization service that can run computing instances, a storage service that can store data objects, etc.

[0009] Users (or "consumers") of cloud provider networks can use one or more user accounts associated with a consumer account, although these terms can be used somewhat interchangeably depending on the context of use. Users can interact with a cloud provider network through one or more intermediary networks (e.g., the internet) via one or more interfaces, such as by using application programming interface (API) calls, through a console implemented as a website or application, and so on. An API refers to an interface and / or communication protocol between a client and a server, such that when the client makes a request in a predefined format, it should receive a response in a specific format or initiate a defined action.In the context of the cloud provider network, APIs provide consumers with a gateway to access the cloud infrastructure by enabling them to retrieve data from the cloud provider network or initiate actions within it. This facilitates the development of applications that interact with the resources and services hosted within the cloud provider network. APIs can also allow different services within the cloud provider network to exchange data with each other. The interface(s) can be part of a control plane of the cloud provider network or serve as a front end to it, containing "backend" services that support and enable services that can be offered more directly to consumers.

[0010] A cloud provider network can be structured as a number of regions, where a region is a geographic area in which the cloud provider clusters data centers. Each region contains multiple (e.g., two or more) availability zones (AZs) connected via a private, high-speed network, such as a fiber optic connection. An AZ (also known as a "zone") provides an isolated failover domain containing one or more data center facilities with separate power, network, and cooling from those in another AZ. A data center is a physical building or site that houses, powers, and cools the servers of the cloud provider network.Preferably, the AZs within a region are positioned far enough apart that a natural disaster (or other outage-causing event) does not affect or take offline more than one AZ at a time.

[0011] Users can connect to an Access Point (AZ) of the cloud provider's network via a publicly accessible network (e.g., the internet, a mobile network), for example, through a Transit Center (TC). TCs are the primary backbone locations that link users to the cloud provider's network and can be located in the facilities of other network providers (e.g., internet service providers (ISPs), telecommunications providers) and securely connected to the AZs (e.g., via a VPN or a direct connection). Each region can operate two or more TCs for redundancy. The regions are connected to a global network that includes a private network 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 points of presence (or "POPs") outside these regions, but connected to them, via edge locations and regional edge cache servers. This isolation and geographic distribution of computing hardware enables the cloud provider network to provide users globally with low-latency resource access and a high degree of fault tolerance and stability.

[0012] To provide these and other computing resource services, cloud provider networks often rely on virtualization techniques. For example, virtualization technologies can provide users with the ability to control or use computing resources (e.g., a "computing instance," such as a virtual machine (VM) using a guest operating system (OS) running under a hypervisor, which may further run on an underlying host OS; a container that may run within a VM; or a computing instance that can run on "bare-metal" hardware without an underlying hypervisor), where one or more computing resources can be implemented using a single electronic device. Thus, a user can directly use a computing resource hosted by the provider network (provided, for example, by a hardware virtualization service) to perform a variety of computing tasks.Additionally or alternatively, a user can indirectly use a computing resource by submitting code to be executed by the provider network (e.g., via an on-demand code execution service), which in turn uses one or more computing resources to execute the code—typically without the user having control over or knowing the underlying computing instance(s).

[0013] 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 can be defined at a minimum by its address space, its internal structure (e.g., the compute resources comprising 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.

[0014] A VPC can provide the fundamental network layer for a cloud service, such as a compute cloud or an edge cloud, or for a consumer application or workload running in the cloud. A VPC can be dedicated to a specific consumer account (or a group of related consumer accounts, such as different consumer accounts belonging to the same business organization). Consumers can deploy resources, such as compute instances, to their VPC(s). When creating a VPC, a consumer can specify an IP address range for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block. After creating a VPC, a consumer can add one or more subnets in each availability zone or edge location associated with its region.

[0015] VPCs / VNs often have virtualized components analogous to those of physical computer networks. Such components can include virtual network interfaces (VNIs) to attach a virtualized instance to the VN (sometimes called elastic network interfaces), a virtual router to handle the routing of traffic between connected virtualized instances, virtual gateways to provide connectivity to or from resources outside the virtual network, and so on.

[0016] The traffic traversing a virtual network is typically encapsulated within the traffic traversing the underlying physical network substrate of the cloud provider's network. In this way, a virtual network can be thought of as an overlay network running on top of the physical network of the cloud provider.

[0017] The Virtual Network Linking Service 101 provides private and secure connectivity to resources across virtual network boundaries. To this end, the Virtual Network Linking Service 101 introduces resource endpoints within the virtual network. Resource endpoints provide a starting point for traffic between individual virtual networks and the Virtual Network Linking Service 101 and are typically implemented as virtual network interfaces that provide a communication path between the Virtual Network Linking Service 101 and various consumer virtual networks. In the examples illustrated and described herein, resource endpoints are divided into two types: resource owner endpoints and resource consumer endpoints.

[0018] In some examples, the virtual network linking service 101 described herein may be distributed across one or more subservices of the cloud provider network.

[0019] A resource owner endpoint allows a user to share one or more resources within their virtual network (VN) and to specify with whom each shared resource is shared. Thus, a single resource owner endpoint enables many different entities in many other VNs to connect to many resources within the user's VN. A resource consumer endpoint allows a user to create a network address within their VN for each shared resource in other VNs that the user wishes to access. Thus, a single resource consumer endpoint provides entities within the user's VN with access to shared resources in many other VNs.

[0020] In some examples, units in a VN with a resource-consuming endpoint can initiate connections to shared resources in other VNs. At the same time, units in a VN with a shared resource cannot automatically connect to units in another VN with which the resource is shared (unless there is explicit resource sharing via an endpoint, as described herein). In this way, the virtual network linking service 101 provides unidirectional connectivity.

[0021] The virtual network linking service 101 can provide address translation and forwarding of traffic between VNs via resource consumer endpoints and resource owner endpoints.

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

[0023] "Instance" refers to a generic resource hosted by the cloud provider's network, such as compute resources (e.g., running instances and / or containers of virtual machines (VMs), running batch jobs, executing code without a provisioning server), data / storage resources (e.g., object storage, block storage, data archive storage, databases and database tables, etc.), network-related resources (e.g., configuring virtual networks including groups of compute resources, content delivery networks (CDNs), domain name service (DNS)), application resources (e.g., databases, services for building / deploying applications), access policies or roles, identity policies or roles, machine images, routers, and other data processing resources, etc.

[0024] In the illustrated example, an administrator of virtual network 102A created a resource consumer endpoint 104A within virtual network 102A using the virtual network's linking service 101. Virtual network 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. When creating resource consumer endpoint 104A, the virtual network's linking service 101 assigned endpoint 104A an endpoint identifier, VNE-A245, which the virtual network's linking service 101 can use for endpoint management and forwarding operations.

[0025] The administrator of VN 102A also granted access to the shared resources of instances 108A and 108B via resource consumer endpoint 104A. To this end, the virtual network link service 101 assigned addresses within the prefix of resource consumer endpoint 104A to instances 108A and 108B. Specifically, the virtual network link service 101 assigned the network address 10.100.0.0 to the shared resource of instance 108A and the network address 10.100.0.1 to the shared resource of instance 108B. Based on the allocated addresses, the linking service 101 of the virtual network updates a service 110A for virtual names of VN 102A so that it includes records to reflect the availability of the domain names of the shared resources via their newly allocated addresses within VN 102A (e.g., database1.db.com -> 10.100.0.0 and database2.db.com -> 10.100.0.1).

[0026] In some examples, the virtual network's linking service 101 manages various metadata to describe and track connectivity between virtual networks. For instance, the virtual network's linking service 101 can manage mapping data 150, which can be used for routing between virtual networks. In the illustrated resource-sharing arrangement from virtual network 102B to virtual network 102A, the mapping data 150 includes an entry to route traffic received at the resource-consuming endpoint 104A (with the identifier VNE-A245), destined for the network address 10.100.0.0 associated with instance 108A, via the resource-owning endpoint 106A (with the identifier VNE-2C33) to the actual network address 10.0.0.1 of instance 108A within virtual network 102B.The mapping data 150 also includes an entry to route traffic received at the resource-consuming endpoint 104A (with the identifier VNE-A245), destined for the network address 10.100.0.1 associated with instance 108B, via the resource-owning endpoint 106A (with the identifier VNE-2C33) to the actual network address 10.0.0.2 of instance 108B within VN 102B. The virtual network linking service 101 can also store other metadata, such as endpoint data 160, endpoint configuration data 170, and lookup data 180, which are described below.

[0027] After endpoints 104A and 106A were configured, instances in VN 102A can now send messages to the shared resources 108A and 108B in VN 102B. An example of a message sent from instance 108D to instance 108A is described below. Instance 108D can obtain the associated network address of the domain name database1.db.com from name server 110A (10.100.0.0). Instance 108D can then send a message (e.g., a data packet) with the destination network address 10.100.0.0 to a port on the resource being accessed (3306 in this example), and a source network address of the instance (10.0.0.1) and a port specified by the instance (1234 in this example). A virtual router (not shown) forwards the data packet to resource consumer endpoint 104A based on the destination network address 10.100.0.0, which is within the assigned prefix.Resource consumer endpoint 104A sends the data packet to the linking service 101 of the virtual network.

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

[0029] In some examples, the virtual network's Link 101 service evaluates a security policy associated with the target resource owner endpoint before forwarding the request from a resource consumer endpoint to the resource owner endpoint. The security policy may include a list of allowed or prohibited ports or protocols that can traverse the resource owner endpoint. If the traffic received from a resource consumer endpoint is allowed or not prohibited by a security policy associated with the target resource owner endpoint in the mapping data, the virtual network's Link 101 service can forward the traffic to the resource owner endpoint. Otherwise, the virtual network's Link 101 service can block the request.Security policies associated with resource owner endpoints can be stored in endpoint data 160 as described below.

[0030] In some examples, the virtual network linking service 101 can also modify the source address and port of a message. Because many different instances (in potentially many different virtual networks) can access a shared resource, the virtual network linking service 101 can use port mapping to track where data packets received by the resource-owner endpoint should be sent back from the shared resource. In the forward direction (for example, for traffic traveling from a resource-consuming endpoint to a resource-owner endpoint), the virtual network linking service 101 can map the source network address, port, and an identifier of the original virtual network (for example, using a virtual network identifier or an identifier of the resource-consuming endpoint) to an available port at the resource-owner endpoint.In the illustrated example, the virtual network linking service 101 maps the data 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 the network address 10.200.0.1, and stores the mapping. Using this mapping, the virtual network linking service 101 changes the source address of the data packet from 10.0.0.1:1234 to 10.200.0.1:2345.

[0031] In the reverse direction (e.g., for traffic flowing from a resource owner endpoint back to a resource consumer endpoint), the virtual network link service 101 can obtain the destination address, port, and identifier of the resource consumer endpoint using the destination address port. For example, for a data packet received from instance 108A with destination address 10.200.0.1:2345, the virtual network link service 101 determines the destination network address 10.0.0.1 and port 1234 using the previously stored mapping for port 2345. The virtual network link service 101 changes the destination address of the data packet from 10.200.0.1:2345 to 10.0.0.1:1234 and sends the data packet via VNE-A245 (also determined from the stored mapping).

[0032] In this example, the administrator of VN 102B has shared instances 108A and 108B with VN 102A. Such 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) cannot be accessed. The administrator of VN 102B has not shared instances 108A or 108B with VN 102D. Therefore, communication from instances (not shown) of VN 102D to VN 102B is not possible.

[0033] With reference to VN 102C, an administrator of VN 102C created a resource owner endpoint 106B within VN 102C via the linking service 101 of the virtual network and shared a resource of VN 102C corresponding to instance 108C. VN 102C has a network address block of 172.31.0.0 / 16. Instance 108C has a network address of 172.31.0.1 and a domain name of c1.compute.com. Resource owner endpoint 106B has a network address prefix of 172.31.1.0 / 28, which is assigned to it within VN 102C. To limit the likelihood of port exhaustion, a network prefix can be assigned to a resource owner endpoint. When creating the resource owner endpoint 106B, the virtual network link service 101 assigned an endpoint identifier VNE-F885 to endpoint 106B, which the virtual network link service 101 can use for endpoint management and forwarding operations.

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

[0035] The administrator of VN 102A granted access to the shared resource of instance 108C via resource consumer endpoint 104A. To this end, the linking service 101 of virtual network instance 108C assigned an address within the prefix of resource consumer endpoint 104A. Specifically, the linking service 101 assigned the network address 10.100.0.3 to the shared resource of instance 108C. Based on the assigned address, the linking service 101 updates a virtual name service 110A of VN 102A to include records reflecting the availability of the shared resource's domain name via its newly assigned address within VN 102A (e.g., c1.compute.com -> 10.100.0.3).

[0036] An administrator of virtual network 102D created a resource consumer endpoint, 104B, within virtual network 102D using the virtual network's link service 101. Virtual network 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. When creating resource consumer endpoint 104B, the virtual network's link service 101 assigned endpoint 104B an endpoint identifier, VNE-D772, which the virtual network's link service 101 can use for endpoint management and forwarding operations.

[0037] The administrator of VN 102D has also granted access to the shared resource of instance 108C via resource consumer endpoint 104B. To this end, the linking service 101 of virtual network instance 108C has assigned an address within the prefix of resource consumer endpoint 104B. Specifically, the linking service 101 of virtual network instance 102D has assigned the network address 10.50.0.1 to the shared resource of instance 108C. Based on the assigned address, the linking service 101 of virtual network instance 102D updates a virtual name service 110B to include records reflecting the availability of the shared resource's domain name via its newly assigned address within VN 102D (e.g., c1.compute.com -> 10.50.0.1).

[0038] In the illustrated arrangement for shared resource use from VN 102C to VN 102A and 102D, the mapping data 150 includes an entry to direct the traffic received at the resource consumer endpoint 104A (with the identifier VNE-A245), which is directed to the network address 10.100.0.3 assigned to instance 108C, via the resource owner endpoint 106B (with the identifier VNE-F885) to the actual network address 172.31.0.1 of instance 108C within VN 102C. The mapping data 150 also includes an entry to direct the traffic received at the resource consumer endpoint 104B (with the identifier VNE-D772), which is directed to the network address 10.50.0.1 assigned to instance 108C, via the resource owner endpoint 106B (with the identifier VNE-F885) to the actual network address 172.31.0.1 of instance 108C within VN 102C.It should be noted that the “local” network address may differ within different VNs of a shared resource (e.g., the network address 10.100.0.3 is assigned to instance 108C in VN 102A, while the network address 10.50.0.1 is assigned to instance 108C in VN 102D).

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

[0040] In some examples, the different ones can be seen in Fig. The components illustrated in Figure 1 can be implemented as software processes executed by one or more computer systems of the cloud provider network. For example, instances 108 might be virtual machine or container processes running in host environments of host systems used to virtualize consumer resources. The resource endpoints 104 and 106, the name servers 110, other virtual network components such as virtual routers (not shown), and the virtual network linking service 101 might be run by a separate set of host systems used for control plane operations.

[0041] One advantage of the virtual network linking service 101 described herein is that virtual networks (VNs) sharing resources can have partially or fully overlapping network address ranges (e.g., CIDR blocks). For example, VN 102A and VN 102B each have CIDR blocks 10.0.0.0 / 16. Overlapping address ranges are possible because the virtual network linking service 101 maps an available network address in the VN with the resource-consuming endpoint of a shared resource and translates this mapped network address to the actual network address of the shared resource in the VN with the resource-owning endpoint.

[0042] Another advantage of the virtual network linking service 101 examples described herein is the direct intra-VPC connectivity from a resource owner endpoint to an associated shared resource. Apart from VPC-native components, such as a virtual router, "direct" here refers to the absence of any other device within the VPC between the resource owner endpoint and the shared resource (e.g., there is no load balancer). For example, traffic from resource owner endpoint 106A traverses the VPC directly to instance 108A.

[0043] While the illustrated and described examples demonstrate only one type of resource endpoint per VN, multiple resource endpoints of the same or different types can be created per VN. For example, a VN can contain multiple resource-consuming endpoints with different network address prefix delegations (e.g., because the available prefix sizes are smaller than the number of shared resources to be accessed). As another example, a VN can contain a resource-consuming endpoint to access a shared resource in another VN and also a resource-owner endpoint to share a resource with other VNs. As yet another example, a VN can contain multiple resource-owner endpoints (e.g., to prevent port exhaustion).

[0044] While the illustrated and described examples provide for a division of resource endpoints into resource owner endpoints and resource consumer endpoints, other examples can combine the functionality into a generic endpoint type that provides both the targeted sharing of resources within a VN with other VNs and access to shared resources in other VNs.

[0045] Often, a virtual network interface (VN) encrypts and decrypts the traffic traversing that VN. For example, a virtual network interface attached to instance 108D (not shown) would encrypt traffic destined for resource-consuming endpoint 104A, which would then decrypt it. Similarly, resource-owning endpoint 106A would encrypt traffic destined for a virtual network interface attached to instance 108A (not shown), which would then decrypt it. In some examples, the virtual network's linking service 101 includes a VN that encrypts traffic.As part of the forwarding of messages between VNs, the virtual network's Link Service 101 encrypts traffic entering the Link Service 101 of the virtual network from a resource consumer endpoint and decrypts traffic exiting the Link Service 101 of the virtual network to a resource owner endpoint (and vice versa, once a communication session is established).

[0046] In some examples, inter-VN connectivity can be extended to on-premises (or "local") equipment, provided that forwarding between such equipment and a VN is possible. For example, a local computer system (not shown) with connectivity to VN 102A could access instance 108A via the resource consumer endpoint 104A. As another example, a local computer system (not shown) that devices in VN 102B can access could be shared via the resource owner endpoint 106A. Techniques for providing forwarding capability between a local network or a local device include a virtual private network connection to the cloud-based virtual network and a virtual gateway for traffic entering or exiting the virtual network from a local network.

[0047] While the description of the examples herein uses Internet Protocol version 4 (IPv4) addressing, other examples may use Internet Protocol version 6 (IPv6) addressing or a combination of IPv4 and IPv6 addressing.

[0048] Fig. Figure 2 illustrates an environment for sharing a resource in a virtual network of a cloud provider network, using several examples. Specifically, it describes various exemplary configuration operations related to sharing a resource, referred to by the circled letters A through G. In this example, an administrator of VN 102B interacts with the linking service 101 of the virtual network via an electronic device 201 and one or more interfaces, such as by using application programming interface (API) calls issued by a program or website, commands issued via a web-based console or application, and so on.

[0049] At Circle A, the virtual network's link service 101 receives a request to create a resource owner endpoint (requests can also be called commands). The request to create a resource owner endpoint allows the virtual network's link service 101 to create a starting point within a specified VN using a resource owner endpoint. Here, the request to create a resource owner endpoint includes identifying VN 102B using a VN identifier assigned to the VN, VN-1157. The request to create a resource owner endpoint can include one or more parameters, such as an identification of the virtual network (or one or more of its subnets, if it is subdivided into subnets). In some examples, an optional parameter, `--assign-prefixes`, indicates the type of virtual network. <n>The request to create a resource owner endpoint specifies whether N prefixes should be assigned to the resource owner endpoint. Such prefixes can be explicitly identified or automatically assigned by another service based on available network addresses within the virtual network (VN). As mentioned above, assigning a network address prefix with an address block (e.g., a / 28 block) to a resource owner endpoint can reduce the likelihood of port exhaustion during operation. The request to create a resource owner endpoint may default to assigning a single network address if the prefix assignment parameter is not specified, in which case the specified number of prefixes will be assigned to the resource owner endpoint.

[0050] In some examples, an optional parameter -securitypolicy is enabled.<policy_document> The request to create a resource owner endpoint requires the administrator to specify a security policy for the resource owner endpoint. An example security policy can be specified in an editable format, such as JavaScript Object Notation (JSON), and can include an allow list to specify which ports or protocols are permitted to traverse the resource owner endpoint, and / or a block list to specify which ports or protocols are not permitted to traverse the resource owner endpoint.

[0051] In some examples, an optional parameter endpoint-permissions-policy is enabled.<policy_document> The request to create a resource owner endpoint instructs the administrator to specify an authorization policy for the resource owner endpoint. An example authorization policy can be specified in an editable format, such as JSON, and typically includes an allow list to explicitly identify certain entities (e.g., other virtual networks based on their virtual network identifier) ​​that can access resources shared through the resource owner endpoint. Entity identification can be specified at various levels of identity and access management (IAM), such as user account, role, organizational unit, organization, or other identity dimensions.

[0052] As part of processing the request to create a resource owner endpoint, the virtual network linking service 101 issues a request to create a network interface to a VM management service 202 of the cloud provider network, as specified at Circle BA. This 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 to assign one address, multiple addresses, one prefix, or multiple prefixes to the VNI). The VM management service 202 provides VN management, including operations such as creating, configuring, and deleting VNIs; updating route tables for a VN's virtual router; adding, configuring, and removing gateways to route inbound and outbound VN traffic; and so on.As described for district 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 the Dynamic Host Configuration Protocol (DHCP)). The VM management service 202 returns the identifier and an indication of the assigned network address(es) to the linking service 101 of the virtual network. Here, the VNI is assigned the identifier VNE-2C33 and the address 10.200.0.1.

[0053] As described in Circle CA, the virtual network link service 101 issues a request to the VM management service 202 to attach a network interface. This request includes a VNI identifier and a destination identifier to which the identified VNI should be attached. Attaching a VNI to a virtualized resource, such as an endpoint or instance, typically involves routing network device I / O between the virtualized environment (e.g., virtual machine process, container process, etc.) and the virtual network. The request includes a destination identifier associated with the virtual network link service 101 to provide the link service with an attachment (or starting point) to the VN 102B. As described in Circle CB, the VM management service 202 creates the attachment between the VNI and the virtual network link service 101.In this way, the VNI 106A serves as a resource endpoint based on its connectivity between the VN 102B and the linking service 101 of the virtual network.

[0054] As indicated in Circle D, the virtual network linking service 101 updates the endpoint data 160. The virtual network linking service 101 uses the endpoint data 160 to track the resource consumer endpoints as well as the resource owner endpoints that have been set up in the cloud provider network's virtual network (VN). Here, the virtual network linking service 101 updates the endpoint data 160 based on the creation of the resource owner endpoint 106A. In the sample 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), and the address(es) assigned to the endpoint (here, 10.200. ...1) and one or more policies associated with the endpoint, such as a security policy and / or an endpoint permissions policy, which are included in the request to create a resource owner endpoint.

[0055] As described in Circle E, the virtual network's linking service 101 receives a request to create a resource configuration. This request initiates the creation of a forwardable path between a virtual network's (VN) resource owner endpoint and a specific resource within that VN that will be shared through the resource owner endpoint. The resource configuration request can 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 will be shared.The shared resource can be identified by a resource name that is unique to the resource within the cloud provider network, a domain name, or a network address, all of which can typically be used to identify the others via other administrative data of the cloud provider network. The resource owner endpoint can be identified by its associated endpoint identifier. Here, the request identifies the resource database1.db.com and the resource owner endpoint VNE-2C33.

[0056] In some examples, an optional parameter -resource-permissions-policy enables<policy_document> The request to create a resource configuration requires the administrator to specify a permissions policy applicable to the shared resource. An example permissions policy can be specified in an editable format, such as JSON, and typically includes an allowlist to explicitly identify certain entities that can access resources shared through the resource owner endpoint. Entity identification can be specified at various IAM levels, such as user account, role, organizational unit, organization, or other identity dimensions.In contrast to an endpoint permissions policy, a resource permissions policy allows an administrator to identify which entities can access a specific resource (subject to the endpoint permissions policy).

[0057] As described in Circle FA, the virtual network link service 101 updates owner endpoint configuration data 270 (for example, a portion of endpoint configuration data 170). The virtual network link service 101 uses owner endpoint configuration data 270 to track which resources have been shared through a resource owner endpoint. Here, the virtual network link service 101 updates owner endpoint configuration data 270 based on a request to create a resource configuration. In the sample owner endpoint configuration data 270, the entry created for the request to create a resource configuration for VNE-2C33 includes an identification of the shared resource (for example, database1.db.com or another resource identifier) ​​and the resource permissions policy, if any.The entry in the owner endpoint configuration data 270 enables a redirectable path between the resource owner endpoint VNE-2C33 and the shared resource database1.db.com, as specified by Circle FB.

[0058] In some examples, the virtual network link service 101 can support a resource owner endpoint modification request that identifies a resource owner endpoint to be modified and the modification(s) to be made. For example, the administrator can use the resource owner endpoint modification request to change the endpoint security policy and / or the endpoint permissions policy. Upon receiving a resource owner endpoint modification request, the virtual network link service 101 can update the endpoint data 160.

[0059] In some examples, the virtual network link service 101 can support a request to modify a resource configuration, identifying a resource owner endpoint, a shared resource to be modified, and the modification(s) to be made. For example, the administrator can use the request to modify a resource configuration to change the resource permissions policy. Upon receiving a request to modify a resource configuration, the virtual network link service 101 can update the owner endpoint configuration data 270.

[0060] In some examples, when the virtual network linking service 101 updates either the endpoint data 160 or the owner endpoint configuration data 270, it may also update the lookup data 180, as shown in Circle G. The lookup data 180 facilitates the discovery of shared resources at the resource-consuming endpoints. The lookup data 180 can be indexed in one or more identity dimensions. For example, the lookup data 180 may include a dimension associated with user accounts, roles, organizational units, organizations, and / or other identity dimensions. When an entity (such as an administrator of a VN with a resource-consuming endpoint) initiates the discovery of shared resources (for example, by creating a new account), the lookup data 180 is updated accordingly.(via an API request to describe endpoint resources, described below), the virtual network's Linking Service 101 can quickly identify any shared resource permitted for that entity based on one or more identity dimensions of the entity. For example, if a user has an associated user account, role, and organization, the virtual network's Linking Service 101 can identify which resources are shared with that user account, role, and organization.

[0061] The virtual network linking service 101 can generate lookup data 180 based on endpoint and resource permission policies specified by administrators who share resources through resource owner endpoints. For example, if an endpoint permission policy allows entities within Organization A to access shared resources through the associated resource owner endpoint, the virtual network linking service 101 can add an entry to an Organization data structure for Organization A that generally identifies any resources shared through that resource owner endpoint. When an entity associated with Organization A initiates shared resource discovery, the resources shared through that resource owner endpoint are returned.When a resource permissions policy adds a user account to a specific shared resource configuration, the virtual network linking service 101 can add an entry to a user account data structure for the user account that identifies the specific shared resource being shared via the resource owner endpoint.

[0062] In some examples, the virtual network linking service 101 can support a request to delete a resource owner endpoint, which identifies a resource owner endpoint to be deleted. Upon receiving a request to delete a resource owner endpoint, the virtual network linking service 101 can delete the entry associated with the identified resource owner endpoint from the endpoint data 160, delete any resource configurations associated with the identified resource owner endpoint from the owner endpoint configuration data 270, delete any lookups associated with the identified resource owner endpoint from the lookup data 180, and delete any mappings targeting the identified resource owner endpoint in the mapping data 150.

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

[0064] Fig. Figure 3 illustrates an environment for accessing a shared resource in a virtual network of a cloud provider network, using several examples. Specifically, it describes various exemplary configuration operations related to accessing a shared resource, referred to by the circled letters A through H. In this example, an administrator of VN 102A interacts with the linking service 101 of the virtual network via an electronic device 301 and one or more interfaces, such as by using application programming interface (API) calls issued by a program or website, commands issued via a web-based console or application, and so on.

[0065] At circuit A, the virtual network's linking service 101 receives a request to create a resource consumer endpoint. This request enables linking service 101 to establish a starting point within a specified virtual network (VN) using a resource consumer endpoint. Here, the request includes identifying VN 102A using the VN identifier VN-A243 assigned to it. The request can include one or more parameters, such as identifying the virtual network (or one or more of its subnetworks, if it is subdivided into subnetworks).Assuming that the resource consumer endpoint provides access to more than one shared resource, the request typically includes a parameter -assign-prefixes . <n>, to assign N prefixes to the resource-consuming endpoint. For example, a / 28 block allows addressing of up to 16 different shared resources.

[0066] In some examples, an optional parameter -security-policy enables<policy_document> The request to create a resource consumer endpoint requires the administrator to specify a security policy for the resource consumer endpoint. An example security policy can be specified in an editable format, such as JSON, and can include an allow list to specify which ports or protocols are permitted to traverse the resource consumer endpoint, and / or a block list to specify which ports or protocols are not permitted to traverse the resource consumer endpoint.

[0067] In some examples, an optional parameter endpoint-permissions-policy is enabled.<policy_document> The request to create a resource consumer endpoint requires the administrator to specify an authorization policy for the resource consumer endpoint. An example authorization policy can be specified in an editable format, such as JSON, and typically includes an allow list (rather than a block list) to explicitly identify certain entities (e.g., other virtual networks based on their virtual network identifier) ​​that can access resources shared through the resource consumer endpoint. Entity identification can be specified at various IAM levels, such as user account, role, organizational unit, organization, or other identity dimensions.

[0068] As part of processing the request to create a resource consumer endpoint, the virtual network linking service 101 issues a network interface creation request to the cloud provider network's VM management service 202, as described in Circle BA. This network interface creation 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 to assign one address, multiple addresses, a prefix, or multiple prefixes to the VNI). As described in Circle BB, the VM management service 202 creates the VNI in VN 102A, assigns it an identifier, and obtains one or more VN network addresses to assign to the VNI (e.g., using DHCP).The VM management service 202 returns the identifier and an indication of the assigned network address(es) to the linking service 101 of the virtual network. Here, the VNI is assigned the identifier VNE-A245 and the address prefix 10.100.0.0 / 28.

[0069] As described in Circle CA, the virtual network link service 101 issues a request to the VM management service 202 to attach a network interface. This request includes a VNI identifier and a destination identifier to which the identified VNI should be attached. The request includes a destination identifier associated with the virtual network link service 101 to provide the link service with an attachment (or starting point) to VN 102A. As described in Circle CB, the VM management service 202 creates the attachment between the VNI and the virtual network link service 101. In this way, VNI 104A serves as a resource endpoint based on its connectivity between VN 102A and the virtual network link service 101.

[0070] As indicated in Circle D, the virtual network linking service 101 updates the endpoint data 160. Here, the virtual network linking service 101 updates the endpoint data 160 based on the creation of the resource consumer endpoint 104A. In the sample endpoint data 160, the entry associated with the resource consumer endpoint 104A includes a VN identifier (VN-A243), an endpoint identifier (VNE-A245), an endpoint type (e.g., owner or consumer), the address(es) 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 an endpoint permissions policy, which are included in the request to create a resource consumer endpoint.

[0071] As described in Circle E, the virtual network's Link Service 101 receives an Endpoint Resource Describe request. This request enables the discovery of resources available for access via resource-consuming endpoints by providing a response listing those available resources. To this end, the Endpoint Resource Describe request returns an identification of available resources shared by the same or a different administrator via resource-owner endpoints in other virtual networks. In some examples, the request may include identity data, such as a specification of one of the identity dimensions described above, which the virtual network's Link Service 101 can verify through another service on the cloud provider network, such as an IAM service (not shown).Alternatively, the request can include the identification of a VN, and the virtual network's Linking Service 101 can obtain identity data associated with that VN. For example, the identity data can identify a user account, a role, an organizational unit, an organization, and / or another identity dimension. Using the Lookup Data 180, the virtual network's Linking Service 101 can identify any shared resource available for one or more of these identity dimensions. Continuing the example of... Fig. 2. Assuming that the administrator who configured the resource owner endpoint 106A shared instance 108A with an identity associated with the resource consumer endpoint 104A, the response would include an identification of database1.db.com available through the resource owner endpoint VNE-2C33. The resource identification could be provided in the form of one or more parts of the resource's domain name, a unique identifier assigned to the resource, and / or a network address of the resource within its VN.

[0072] As described in Circle F, the virtual network's linking service 101 receives a request to add a resource to an endpoint. This request initiates the creation of a forwardable path to a resource shared via a resource owner endpoint through the resource consumer endpoint. The request to create a resource configuration can include one or more parameters, such as identifying the resource and the resource consumer endpoint to which the identified resource should be added. For example, the request might include identifying VNE-2C33 and identifying the resource database1.db.com by its domain name (or alternatively, by a unique resource identifier, network address, or other identifier).

[0073] The virtual network link service 101 can select one of the available network addresses assigned to the resource-consuming endpoint to associate with the identified shared resource. For example, if the resource-consuming endpoint has been assigned a / 28 address block, and five of those addresses are used for other resources in other virtual networks, the virtual network link service 101 can select one network address from the remaining eleven available addresses to associate with the shared resource. The virtual network link service 101 can track whether addresses assigned to a resource-consuming endpoint have been associated with a shared resource. In this example, the virtual network link service 101 associates the address 10.100.0.0 with the identified shared resource.

[0074] As described in Circle GA, the linking service 101 of the virtual network issues a request to the VM management service 202 to create a DNS record. The request includes an identification of the local VN address selected to map to the shared resource and the domain name of the shared resource. As described in Circle GB, the VM management service 202 updates the name server 110A of VN 102A to contain a record that maps the domain name database1.db.com to the mapped 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 passed to the VN containing the resource-consuming endpoint, provided that devices within that VN access the shared resource using the mapped network address.

[0075] As indicated for districts HA and HB, the virtual network's linking service 101 updates consumer endpoint configuration data 370 (e.g., a portion of endpoint configuration data 170) and mapping data 150. The virtual network's linking service 101 uses the consumer endpoint configuration data 370 to track which shared resources have been added to a VN via a resource consumer endpoint. Here, the virtual network's linking service 101 updates the consumer endpoint configuration data 370 based on the request to create a resource configuration. In the sample consumer endpoint configuration data 370, the entry created for the request to create a resource configuration for VNE-A245 includes an 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 network linking service 101 also creates an entry in the mapping data 150 to link the shared resource from the resource consumer endpoint and its associated network address to the resource owner endpoint and its actual network address. Here, this 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) via the resource consumer endpoint 104A and the resource owner endpoint 106A (not shown), which have the endpoint identifiers VNE-A245 and VNE-2C33, respectively.

[0076] In some examples, the virtual network link service 101 can support a request to modify a resource consumer endpoint, identifying a resource owner endpoint to be modified and the modification(s) to be made. For example, the administrator can use the request to modify the resource consumer endpoint to change the endpoint security policy and / or the endpoint permissions policy. Upon receiving a request to modify the resource consumer endpoint, the virtual network link service 101 can update the endpoint data 160.

[0077] In some examples, the virtual network linking service 101 can support a request to delete a resource consumer endpoint, which identifies a resource consumer endpoint to be deleted. Upon receiving a request to delete a resource consumer endpoint, the virtual network linking service 101 can delete the entry associated with the identified resource owner endpoint from the endpoint data 160, delete any resource configurations associated with the identified resource owner endpoint from the consumer endpoint configuration data 370, delete any lookups associated with the identified resource owner endpoint from the lookup data 180, and delete all mappings of the identified resource consumer endpoint in the mapping data 150.

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

[0079] Fig. Figure 4 illustrates a resource-sharing environment in a virtual network that has subnetworks, according to some examples. As illustrated, a VN 400 has a network address block of 10.0.0.0 / 16. The VN is divided into two subnetworks, subnetwork 402A and 402B, respectively, which have the identifiers VN-A243-SN-123 and VN-A243-SN-123 and assigned CIDR blocks of 10.0.0.0 / 17 and 10.0.128.0 / 17. In some examples with subnetted VNs, the virtual network's linking service 101 can create a resource endpoint (whether owner or consumer) in one or more of the VN subnetworks. The identification can be based on one or more parameters received with either the request to create a resource owner endpoint or the request to create a resource consumer endpoint.In some examples, identifying a subnetted virtual network (VN) in the request can implicitly cause the virtual network's linking service 101 to create a resource endpoint within each of the VN subnets. For example, a request that identifies VN-A243 can implicitly create resource endpoints in each subnet. In other examples, the request may require the explicit identification of one or more subnets of a subnetted VN in which to create resource endpoints. For example, a request might include the identification of subnets VN-A243-SN123 and VN-A243-SN123. In both cases, the virtual network's linking service 101 creates a resource endpoint 404A within subnet 402A and a resource endpoint 404B within subnet 402B.However, if the request to the virtual network link service 101 requires explicit identification of subnets, a request that identifies only one of the subnets VN-A243-SN123 and VN-A243-SN123 would result in the creation of a resource endpoint only in the identified subnet (not shown).

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

[0081] In some examples, network addresses are assigned to endpoints individually rather than as prefix groups. For instance, as part of a request to create an endpoint, an administrator might specify a set of network addresses to be assigned to that endpoint.

[0082] Fig. Figure 5 is a flowchart illustrating Operations 500 of a procedure for sharing resources between virtual networks of a cloud provider network, according to some examples. Some or all of the Operations 500 (or other processes or variations and / or combinations thereof described herein) may be 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 runs together on one or more processors. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising instructions that can be executed by one or more processors. The computer-readable storage medium is non-transient.In some examples, one or more (or all) of the operations 500 are performed by the linking service 101 of the virtual network of the other figures.

[0083] Operations 500, specifically block 502, involve mapping a first network address of a first virtual network to a resource connected to a second virtual network, where both the first and second virtual networks are part of the cloud provider's network. Operations 500, further, involve receiving a message destined for the first network address at block 504. Operations 500, further, involve translating the first network address to a second network address of the resource in the second virtual network at block 506. Operations 500, further, involve sending the message to the resource at the second network address in the second virtual network at block 508.

[0084] Fig. Figure 6 illustrates an exemplary environment of a provider network (or “service provider system”) according to some examples. A provider network 600 can provide customers with resource virtualization through one or more virtualization services 610, which enable customers to purchase, rent, or otherwise obtain instances 612 of virtualized resources, including, but not limited to, compute and storage resources deployed on devices within the provider network or in networks in one or more data centers. The resource instances 616 can be assigned local Internet Protocol (IP) addresses 612; the local IP addresses are the internal network addresses of the resource instances 612 in the provider network 600. In some examples, the provider network 600 can also use public IP addresses 614 and / or public IP address ranges (e.g.,Provide Internet Protocol Version 4 (IPv4) or Internet Protocol Version 6 (IPv6) addresses that customers can obtain from the provider 600.

[0085] Traditionally, the provider network 600, through the virtualization services 610, can enable 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) to dynamically map at least some of the customer’s assigned or allocated public IP addresses 614 to specific customer-assigned resource instances 612. The provider network 600 can also enable the customer to remap a public IP address 614, previously mapped to a customer-assigned virtualized computing resource instance 612, to a different customer-assigned virtualized computing resource instance 612.Using the virtualized computing resource instances 612 and public IP addresses 614 provided by the service provider, a customer of the service provider, such as the operator of the customer network(s) 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 units 620 in the intermediate network 640 can then generate traffic to a public destination IP address 614, which is published by the customer networks 650A-650C; the traffic is forwarded to the service provider's data center and, in the data center, via a network substrate, to the local IP address 616 of the virtualized computing resource instance 612, which is currently mapped to the public destination IP address 614.Similarly, response traffic from the virtualized computing resource instance 612 can be forwarded via the network substrate back to the intermediate network 640 to the source unit 620.

[0086] Local IP addresses, as used herein, refer to the internal or "private" network addresses of, for example, resource instances within a provider network. Local IP addresses may be within address blocks reserved by Internet Engineering Task Force (IETF) Request for Comments (RFC) 1918 and / or conform to an address format specified by IETF RFC 4193 and may be modifiable within the provider's network. Network traffic originating from outside the provider's network is not routed directly to local IP addresses; instead, it uses public IP addresses that are mapped to the local IP addresses of the resource instances. The provider's network may include network devices or equipment that provide network address translation (NAT) or similar functionality to perform the mapping of public IP addresses to local IP addresses and vice versa.

[0087] Public IP addresses are changeable network addresses on the internet, assigned either by the service provider or by the customer to resource instances. Traffic forwarded to a public IP address is translated, for example via 1:1 NAT, and routed to the respective local IP address of a resource instance.

[0088] Some public IP addresses can be assigned by the network provider's infrastructure to specific resource instances; these public IP addresses can be referred to as default public IP addresses or simply default IP addresses. In some examples, mapping a default IP address to a local IP address of a resource instance is the default startup configuration for all types of resource instances.

[0089] At least some public IP addresses can be allocated to or obtained by customers of the provider's 600 network; a customer can then assign their allocated public IP addresses to specific resource instances assigned to them. These public IP addresses can be referred to as the customer's public IP addresses or simply as customer IP addresses. Unlike standard IP addresses, which are allocated to resource instances by the provider's 600 network, customer IP addresses can also be allocated to resource instances by the customers themselves, for example, via an API provided by the service provider. Furthermore, unlike standard IP addresses, customer IP addresses are assigned to customer accounts and can be mapped to different resource instances by the respective customers as needed or desired.A customer IP address is assigned to a customer account, not a specific resource instance, and the customer controls this IP address until they choose to release it. Unlike traditional static IP addresses, customer IP addresses allow the customer to mask resource instance or availability zone failures by remapping the customer's public IP addresses to any resource instance associated with the customer's account. For example, customer IP addresses allow a customer to work around issues with resource instances or their software by remapping the customer IP addresses to the backup resource instances.

[0090] Fig. Figure 7 is a block diagram of an example environment of a provider network that provides customers with a storage service and a hardware virtualization service, as shown in some examples. A hardware virtualization service 720 provides customers with multiple compute resources 724 (e.g., compute instances 725, such as VMs). The compute resources 724 can be provided, for example, as a service to customers of a provider network 700 (e.g., to a customer implementing a customer network 750). Each compute resource 724 can be provided with one or more local IP addresses. The provider network 700 can be configured to forward data packets from the local IP addresses of the compute resources 724 to public Internet destinations and from public Internet sources to the local IP addresses of the compute resources 724.

[0091] The provider network 700 can provide the customer network 750, which is connected, for example, via a local network 756 to an intermediate network 740, with the ability to implement virtual computing systems 792 via the hardware virtualization service 720, which is connected to the intermediate network 740 and the provider network 700. In some embodiments, the hardware virtualization service 720 can provide one or more APIs 702, such as a web service interface, through which the customer network 750 can access functions provided by the hardware virtualization service 720, for example, via a console 794 (e.g., a web-based application, stand-alone application, mobile application, etc.) of a customer device 790.In some examples, in the provider network 700, each virtual computing system 792 in the customer network 750 can correspond to a computing resource 724 that is leased, rented, or otherwise made available to the customer network 750.

[0092] From an instance of the virtual computing system(s) 792 and / or another customer device 790 (e.g., via the console 794), the customer can access the functionality of a storage service 710, e.g., via one or more APIs 702, to access or store data from storage resources 718A-718N of a virtual data storage 716 provided by the provider network 700 (e.g., a folder or a "bucket", a virtualized volume, a database, etc.).In some examples, a virtualized data storage gateway (not shown) may be deployed in the customer network 750. This gateway can locally cache at least some data, such as frequently accessed or critical data, and communicate with the storage service 710 via one or more communication channels to upload new or modified data from a local cache, thus preserving the primary data storage (the virtualized data storage 716). In some examples, a user can load and access virtual data storage 716 via the virtual computing system 792 and / or another customer device 790 through the storage service 710, which acts as a storage virtualization service. These volumes can then be presented to the user as local (virtualized) storage 798.

[0093] Although in Fig. Although not shown in Figure 7, the virtualization service(s) can also be accessed from resource instances within the provider network 700 via API(s) 702. For example, a customer, device service provider, or other entity can access a virtualization service via API(s) 702 from within a given virtual network in the provider network 700 to request an allocation of one or more resource instances within that virtual network or within another virtual network. Illustrative systems

[0094] In some examples, a system implementing some or all of the techniques described herein may include a general-purpose computer system, such as the one described in Fig. Figure 8 illustrates a computer system 800, which includes or is configured to access one or more computer-accessible media. In the illustrated embodiment, the computer system 800 includes one or more processors 810, which are coupled to a system memory 820 via an input / output (I / O) interface 830. The computer system 800 further includes a network interface 840, which is coupled to the I / O interface 830. While Fig. 8. Where Computer System 800 is shown as a single computing device, Computer System 800 can, in various examples, include one computing device or any number of computing devices configured to work together as a single Computer System 800.

[0095] In various examples, the Computer System 800 can be a single-processor system with one Processor 810 or a multi-processor system with multiple Processors 810 (e.g., two, four, eight, or any other suitable number). The Processor(s) 810 can be any suitable processor capable of executing instructions. For example, in various examples, the Processor(s) 810 can be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs), such as the x86, ARM, PowerPC, SPARC, or MIPS ISA, or any other suitable ISA. In multi-processor systems, each of the Processors 810 can typically, but not necessarily, implement the same ISA.

[0096] System memory 820 can store instructions and data that can be accessed by the processor(s) 810. In various examples, system memory 820 can be implemented using any suitable memory technology, such as random-access memory (RAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash memory, or any other type of memory. In the illustrated example, program instructions and data that implement one or more desired functions, such as the procedures, techniques, and data described above, are represented as code 825 for the virtual network linking service (e.g., executable to implement all or part of the virtual network linking service 101) and data 826 stored in system memory 820.

[0097] 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 all 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, time, 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, 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, the function of the 830 I / O interface can be divided into two or more separate components, such as a north bridge and a south bridge. Furthermore, in some examples, some or all functions of the 830 I / O interface, such as an interface to the 820 system memory, can be integrated directly into the 810 processor.

[0098] The network interface 840 can be configured to allow data exchange between the computer system 800 and other devices 860 that are attached to one or more networks 850, such as other computer systems or devices, as described in Fig. Figure 1 illustrates this. In various examples, the 840 network interface can support communication over any suitable wired or wireless general-purpose data network, such as types of Ethernet networks. Furthermore, the 840 network interface can support communication over telecommunications / telephony networks, such as analog voice networks or digital fiber optic communication networks, over storage area networks (SANs), such as Fibre Channel SANs, and / or over any other suitable network type and / or protocol.

[0099] In some examples, the Computer System 800 includes one or more 870A or 870B offload cards (including one or more 875 processors and possibly one or more 840 network interfaces) connected using the 830 I / O interface (e.g., a bus implementing a version of the PCI-E (Peripheral Component Interconnect - Express) standard, or some other interconnection such as a QuickPath interconnect (QPI) or an UltraPath interconnect (UPI)). For example, in some examples, the Computer System 800 can function as an electronic host device (e.g.,(operated as part of a hardware virtualization service) that hosts computing resources, such as compute instances, and the one or more 870A or 870B offload cards run a virtualization manager that can manage compute instances running on the electronic host device. For example, in some examples, the 870A or 870B offload cards can perform compute instance management operations, such as pausing and / or resuming compute instances, starting and / or stopping compute instances, performing memory transfer / copy operations, and so on. In some examples, these management operations can be performed by the 870A or 870B offload cards in coordination with a hypervisor (for example, at the request of a hypervisor) running by the other 810A-810N processors of the Computer System 800.In some examples, however, the virtualization manager implemented by the 870A or 870B offload card(s) can process requests from other units (e.g., from the compute instances themselves) and cannot coordinate with (or service) a separate hypervisor.

[0100] In some examples, the 820 system memory can be an example of a computer-accessible medium configured to store program instructions and data as described above. In other examples, however, program instructions and / or data can be received, sent, or stored on other types of computer-accessible media. Generally speaking, a computer-accessible medium can include any non-transient data storage medium or storage medium, such as magnetic or optical media, for example, a floppy disk or DVD / CD coupled to the 800 computer system via the 830 I / O interface. A non-transient, computer-accessible storage medium can also include any volatile or non-volatile media, such as RAM (e.g., SDRAM, Double Data Rate (DDR) SDRAM, SRAM, etc.), read-only memory (ROM), etc.This includes, in some embodiments of the Computer System 800, system memory 820 or other types of memory. Furthermore, a computer-accessible medium may include transmission media or signals, such as electrical, electromagnetic, or digital signals, transmitted over a communication medium, such as a network and / or a wireless link, as may be implemented, for example, via the Network Interface 840.

[0101] The various examples discussed or proposed herein can be implemented in a wide 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 run any one of a number of applications. User or client devices may include any number of personal general-purpose computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless, and portable devices running mobile software and capable of supporting a range of networking and messaging protocols.Such a system may also include a number of workstations running any of a variety of commercially available operating systems and other well-known applications for purposes such as development and database management. These devices may also include other electronic equipment, such as dummy terminals, thin clients, gaming systems, and / or other devices capable of communicating over a network.

[0102] Most examples use at least one network known to those skilled in the art to support communications using a variety of widely used 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 networks 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.

[0103] In examples that use a web server, the web server can run a variety of server or mid-tier applications, including HTTP servers, File Transfer Protocol (FTP) servers, Common Gateway Interface (CGI) servers, data servers, Java servers, business application servers, and so on. The server(s) can also be capable of executing programs or scripts in response to requests from user devices, such as by running one or more web applications, which can be implemented as one or more scripts or programs written in any programming language, such as Java®, C, C#, or C++, or any scripting language, such as Perl, Python, PHP, or TCL, and combinations thereof. The server(s) can also include database servers, including, without limitation, those commercially available from Oracle®, Microsoft®, Sybase®, IBM®, and so on. The database servers can be relational or non-relational (e.g.,"NoSQL"), distributed or not distributed, etc.

[0104] The environments disclosed herein can include a variety of data storage devices and other storage media, as discussed above. These can be located in a variety of places, such as on a storage medium that is local to (and / or located within) one or more of the computers, or remote from any or all of the computers across the network. In a specific set of examples, the information can be located in a Storage Area Network (SAN) known to those skilled in the art. Likewise, all the files required to perform the functions assigned to the computers, servers, or other network devices can be stored locally and / or remotely, as needed.If a system includes computerized devices, each such device may include hardware elements that may be electrically coupled via a bus, the elements being, for example, at least one central processing unit (CPU), at least one input device (e.g., a mouse, keyboard, controller, touchscreen, or keypad), and / or at least one output device (e.g., a display, printer, or loudspeaker). Such a system may also include one or more data storage devices, such as disk 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 cards, etc.

[0105] Such devices may also include a computer-readable data storage media reader, a communication device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and working memory, as described above. The computer-readable data storage media reader may be connected to or configured to receive a computer-readable storage medium, which may be remote, local, fixed, and / or removable storage devices and storage media for the temporary and / or permanent containment, storage, transmission, and retrieval of computer-readable information.The system and its various devices typically include a number of software applications, modules, services, or other elements located within at least one memory device, including an operating system and application programs such as a client application or a web browser. It is understood that alternative examples may exhibit numerous variations from the one described above. For example, customized hardware might be used, and / or specific elements might be implemented in hardware, software (including portable software such as applets), or both. Furthermore, a connection to other computing devices, such as network input / output devices, may be employed.

[0106] Storage media and computer-readable media containing code or parts of code may include any suitable media known or used in the field, including storage and communication media such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting 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 any other storage technology, compact disc read-only memory (“CD-ROM”), digital versatile disc (DVD), or any other optical storage medium, magnetic cartridges, magnetic tape, magnetic disk storage, or any other magnetic storage device, or any other medium that can be used for this purpose.to store the desired information, and which can be accessed by a system device. Based on the disclosure and the teachings provided here, the average person skilled in the art understands that other possibilities and / or procedures exist to implement the various examples.

[0107] The preceding description presents various examples. For illustrative purposes, specific configurations and details are provided to ensure a comprehensive understanding of the examples. However, it is also apparent to those skilled in the art that the examples can be implemented without these specific details. Furthermore, well-known features can be omitted or simplified to avoid obscuring the described example.

[0108] Text in brackets and blocks with dashed borders (e.g., capitals, dashes, semicolons, and dots) are used here to illustrate optional aspects that add extra functionality to some examples. However, such notation should not be interpreted as meaning that these are the only options or optional operations, and / or that blocks with solid borders are not optional in certain examples.

[0109] Reference designators with appended letters (e.g., 718A-718N) can be used to indicate that there may be one or more instances of the referenced unit in different embodiments. If multiple instances exist, they need not all be identical but may instead share some general characteristics or act in a common manner. Furthermore, the suffixes used do not imply that a specific quantity of the unit exists unless explicitly stated otherwise. Therefore, two units using the same or different suffix letters may or may not have the same number of instances in different examples.

[0110] References to "an example," etc., indicate that the described example may include a specific feature, structure, or property, but not every example necessarily includes that specific feature, structure, or property. Furthermore, such formulations do not necessarily refer to one and the same example. It should also be noted that when a specific feature, structure, or property is described in connection with an example, it is within the skilled person's knowledge to understand how such a feature, structure, or property can be influenced in connection with other examples, whether explicitly stated or not.

[0111] Furthermore, in the various examples described above, unless explicitly stated otherwise, disjunctive language such as the phrase "at least one of A, B, or C" is to be understood as meaning either A, B, or C, or any combination thereof (e.g., A, B, and / or C). Likewise, expressions such as "at least one or more of A, B, and C" (or "one or more of A, B, and C") are to be understood as meaning A, B, or C, or any combination thereof (e.g., A, B, and / or C). Thus, such disjunctive language is not intended to express that a given example requires the presence of at least one of A, at least one of B, and at least one of C.

[0112] The term "based on" (or similar) is an open term used to describe one or more factors that influence a decision or other action. This term does not exclude additional factors that may influence a decision or action. For example, a decision may be based solely on the listed factor(s) or on the factor(s) and one or more additional factors. Thus, if action A is "based on B," it is understood that B is a factor that influences action A, but this does not preclude the action from also being based on one or more other factors, such as factor C. In some cases, however, action A may be based entirely on B.

[0113] Unless explicitly stated otherwise, articles such as "a" or "an" should generally be interpreted as including one or more of the described elements. Accordingly, expressions such as "a device configured for this purpose" or "a computing device" should include one or more of the named devices. These single or multiple devices may be configured together to perform the specified operations. For example, "a processor configured to perform operations A, B, and C" may include a first processor configured to perform operation A working in conjunction with a second processor configured to perform operations B and C.

[0114] Furthermore, the terms "can" or "may" are used in a permissible sense (i.e., in the sense of "possible") and not in a compelling sense (i.e., in the sense of "must"). The terms "contain," "inclusive," and "contains" are used to denote open relationships and therefore mean "inclusive" but not limited to. Likewise, the words "exhibit," "exhibiting," and "exhibits" also denote open relationships and thus mean "exhibit" but not limited to. The terms "first," "second," "third," etc., used herein are employed as labels for the nouns they precede and do not represent any kind of order (e.g., spatial, temporal, logical, etc.) unless such order is explicitly stated.Likewise, the values ​​of such numerical designations are generally not used to indicate a required quantity of a specific noun in the claims set forth herein, and therefore a “fifth” element generally does not imply that four further elements are present unless such elements are expressly included in the claim or it is otherwise clearly made clear that they are present.

[0115] At least some embodiments of the disclosed technologies can be described with regard to the following paragraphs: 1. Computer-implemented method, including: through a service of a cloud provider network: Assigning a resource with a first network address in a first virtual network to a resource owner endpoint, wherein the resource owner endpoint has a second network address in the first virtual network, and wherein the resource owner endpoint is a virtual network interface of the service to the first virtual network; Assigning a network address prefix of a second virtual network to a resource consumer endpoint of the second virtual network, where the resource consumer endpoint is a virtual network interface of the service to the second virtual network; Assigning a third network address within the network address prefix to the resource; Receiving a message from the resource-consuming endpoint, where the message is destined for the third network address; Translating the third network address to the first network address in the first virtual network; and Sending the message to the resource at the first network address in the first virtual network via the resource owner endpoint. 2. A computer-implemented method according to paragraph 1, wherein the resource has an associated domain name, and further comprising: Updating a name server of the second virtual network with a record to map a resource domain name to the third network address. 3. Computer-implemented method as defined in paragraphs 1-2, further comprising: Receiving a policy to assign to the resource, where the policy grants access to the resource to at least one user account, role, organizational unit, or organization associated with the second virtual network. 4. Computer-implemented method, including: through a service of a cloud provider network: Assigning a first network address of a first virtual network to a resource that is connected to a second virtual network, where the first virtual network and the second virtual network are part of the cloud provider network; Receiving a message intended for the first network address; Translating the first network address to a second network address of the resource in the second virtual network; and Sending the message to the resource at the second network address in the second virtual network. 5. Computer-implemented procedure according to paragraph 4, further comprehensively by the Service: Receiving an initial request to create a virtual network interface between the service and the second virtual network in order to share resources of the second virtual network with other virtual networks; and Creating the virtual network interface between the service and the second virtual network, whereby the message is sent by the service to the resource via the virtual network interface. 6. Computer-implemented procedure according to paragraph 5, further comprehensively by the Service: Receiving a second request to assign the resource to the virtual network interface, wherein the second request includes an identification of the resource and a specification of the virtual network interface; and Update the service metadata to map the virtual network interface resource. 7. Computer-implemented method according to paragraph 6, wherein the identification of the resource in the second request is at least one of a resource name that is unique for the resource within the cloud provider network, a domain name or a network address. 8. Computer-implemented method according to one of paragraphs 6-7, wherein the second requirement further includes an authorization policy that identifies at least one user account, role, organizational unit or organization associated with the first virtual network as having permission to access the resource. 9. Computer-implemented procedure according to paragraph 4, further comprehensively by the Service: Receiving an initial request to create a virtual network interface between the service and the first virtual network to access shared resources in other virtual networks; and Creating the virtual network interface between the service and the first virtual network, whereby the message destined for the first network address is received by the service via the virtual network interface. 10. Computer-implemented procedure according to paragraph 9, further comprehensively by the Service: Receiving a request to identify resources shared with an identity, where the identity is at least one of a user account, role, organizational unit, or organization of the first virtual network; Providing an identification of one or more resources shared with the identity, which includes an identification of the resource connected to a second virtual network; and Receiving a request to add the resource to the virtual network interface, wherein the first network address of the first virtual network is mapped to the resource connected to the second virtual network, at least partially, based on the request to add the resource to the virtual network interface. 11. Computer-implemented procedure according to paragraph 10, further comprehensively by the Service: Updating a name server of the first virtual network with a record to map a domain name of the resource connected to the second virtual network to the first network address. 12. Computer-implemented method according to any of paragraphs 9-11, further encompassing the service: Storing a mapping of the virtual network interface, a source network address of the message, and a source port of the message to a port of another virtual network interface between the service and the second virtual network; where sending the message to the resource at the second network address in the second virtual network involves replacing the source network address of the message with a 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, wherein the second message has 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 the 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 Sending the second message to the first virtual network via the virtual network interface in the saved mapping. 13. System, comprehensive: one or more first electronic devices for implementing a linking service of a virtual network in a cloud provider network, wherein the linking service of the virtual network includes instructions which, when executed, cause the linking service of the virtual network to do the following: Assigning a first network address of a first virtual network to a resource that is connected to a second virtual network, where the first virtual network and the second virtual network are part of the cloud provider network; Receiving a message intended for the first network address; Translating the first network address to a second network address of the resource in the second virtual network; and Sending the message to the resource at the second network address in the second virtual network; and one or more second electronic devices for hosting the resource connected to the second virtual network. 14. System according to paragraph 13, wherein the virtual network linking service includes further instructions which, when executed, cause the virtual network linking service to do the following: Receiving an initial request to create a virtual network interface between the service and the second virtual network in order to share resources of the second virtual network with other virtual networks; and Creating the virtual network interface between the service and the second virtual network, whereby the message is sent by the service to the resource via the virtual network interface. 15. System according to paragraph 14, wherein the virtual network linking service includes further instructions which, when executed, cause the virtual network linking service to do the following: Receiving a second request to assign the resource to the virtual network interface, wherein the second request includes an identification of the resource and a specification of the virtual network interface; and Update the service metadata to map the virtual network interface resource. 16. System according to paragraph 15, wherein the identification of the resource in the second request is at least one of a resource name that is unique for the resource within the cloud provider network, a domain name or a network address. 17. System according to one of paragraphs 15-16, the second requirement further including an authorization policy that identifies at least one user account, role, organizational unit or organization associated with the first virtual network as having permission to access the resource. 18. System according to paragraph 13, wherein the virtual network linking service includes further instructions which, when executed, cause the virtual network linking service to do the following: Receiving an initial request to create a virtual network interface between the service and the first virtual network to access shared resources in other virtual networks; and Creating the virtual network interface between the service and the first virtual network, whereby the message destined for the first network address is received by the service via the virtual network interface. 19. System according to paragraph 18, wherein the virtual network linking service includes further instructions which, when executed, cause the virtual network linking service to do the following: Receiving a request to identify resources shared with an identity, where the identity is at least one of a user account, role, organizational unit, or organization of the first virtual network; Providing an identification of one or more resources shared with the identity, which includes an identification of the resource connected to a second virtual network; and Receiving a request to add the resource to the virtual network interface, wherein the first network address of the first virtual network is mapped to the resource connected to the second virtual network, at least partially, based on the request to add the resource to the virtual network interface. 20. System according to paragraph 19, wherein the virtual network linking service includes further instructions which, when executed, cause the virtual network linking service to do the following: Updating a name server of the first virtual network with a record to map a domain name of the resource connected to the second virtual network to the first network address.

[0116] The description and drawings are therefore to be understood in an illustrative and non-restrictive sense. However, it is evident that various modifications and changes can be made to them without deviating from the scope of the disclosure set forth in the patent claims. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] VN 102B [0022, 0052] VN 102A [0024, 0025, 0035, 0074] VN 102C

[0034] < / n> < / n>

Claims

[1] Computer-implemented method, comprising: through a service of a cloud provider network: Assigning a first network address of a first virtual network to a resource that is connected to a second virtual network, where the first virtual network and the second virtual network are part of the cloud provider network; Receiving a message intended for the first network address; Translating the first network address to a second network address of the resource in the second virtual network; and Sending the message to the resource at the second network address in the second virtual network. [2] Computer-implemented method according to claim 1, further comprising the service: Receiving an initial request to create a virtual network interface between the service and the second virtual network in order to share resources of the second virtual network with other virtual networks; and Creating the virtual network interface between the service and the second virtual network, whereby the message is sent by the service to the resource via the virtual network interface. [3] Computer-implemented method according to claim 2, further comprising the service: Receiving a second request to assign the resource to the virtual network interface, wherein the second request includes an identification of the resource and a specification of the virtual network interface; and Update the service metadata to map the virtual network interface resource. [4] Computer-implemented method according to claim 3, wherein the identification of the resource in the second request is at least one of a resource name that is unique for the resource within the cloud provider network, a domain name or a network address. [5] Computer-implemented method according to one of claims 3-4, wherein the second requirement further includes an authorization policy that identifies at least one user account, role, organizational unit or organization associated with the first virtual network as having permission to access the resource. [6] Computer-implemented method according to claim 1, further comprising the service: Receiving an initial request to create a virtual network interface between the service and the first virtual network to access shared resources in other virtual networks; and Creating the virtual network interface between the service and the first virtual network, whereby the message destined for the first network address is received by the service via the virtual network interface. [7] Computer-implemented method according to claim 6, further comprising the service: Receiving a request to identify resources shared with an identity, where the identity is at least one of a user account, role, organizational unit, or organization of the first virtual network; Providing an identification of one or more resources shared with the identity, which includes an identification of the resource connected to a second virtual network; and Receiving a request to add the resource to the virtual network interface, wherein the first network address of the first virtual network is mapped to the resource connected to the second virtual network, at least partially, based on the request to add the resource to the virtual network interface. [8] Computer-implemented method according to claim 7, further comprising the service: Updating a name server of the first virtual network with a record to map a domain name of the resource connected to the second virtual network to the first network address. [9] Computer-implemented method according to any one of claims 6-8, further comprising the service: Storing a mapping of the virtual network interface, a source network address of the message, and a source port of the message to a port of another virtual network interface between the service and the second virtual network; where sending the message to the resource at the second network address in the second virtual network involves replacing the source network address of the message with a 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, wherein the second message has 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 the 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 Sending the second message to the first virtual network via the virtual network interface in the saved mapping. [10] System, encompassing: one or more first electronic devices for implementing a linking service of a virtual network in a cloud provider network, wherein the linking service of the virtual network includes instructions which, when executed, cause the linking service of the virtual network to do the following: Assigning a first network address of a first virtual network to a resource that is connected to a second virtual network, where the first virtual network and the second virtual network are part of the cloud provider network; Receiving a message intended for the first network address; Translating the first network address to a second network address of the resource in the second virtual network; and Sending the message to the resource at the second network address in the second virtual network; and one or more second electronic devices for hosting the resource, which is connected to the second virtual network. [11] System according to claim 10, wherein the linking service of the virtual network includes further instructions which, when executed, cause the linking service of the virtual network to do the following: Receiving an initial request to create a virtual network interface between the service and the second virtual network in order to share resources of the second virtual network with other virtual networks; and Creating the virtual network interface between the service and the second virtual network, whereby the message is sent by the service to the resource via the virtual network interface. [12] System according to claim 11, wherein the linking service of the virtual network includes further instructions which, when executed, cause the linking service of the virtual network to do the following: Receiving a second request to assign the resource to the virtual network interface, wherein the second request includes an identification of the resource and a specification of the virtual network interface; and Update the service metadata to map the virtual network interface resource. [13] System according to claim 12, wherein the identification of the resource in the second request is at least one of a resource name that is unique for the resource within the cloud provider network, a domain name or a network address. [14] System according to one of claims 12-13, wherein the second requirement further includes an authorization policy that identifies at least one user account, role, organizational unit or organization associated with the first virtual network as having permission to access the resource. [15] System according to claim 10, wherein the linking service of the virtual network includes further instructions which, when executed, cause the linking service of the virtual network to do the following: Receiving an initial request to create a virtual network interface between the service and the first virtual network to access shared resources in other virtual networks; and Creating the virtual network interface between the service and the first virtual network, whereby the message destined for the first network address is received by the service via the virtual network interface.

Images