Amazon Technologies, Inc.

Emc Corporation

Ethan Joseph Torretta

Upendra Bhalchandra Shevade

Joseph Elmar Magerramov

Kirk Arlo Petersen

Schuyler David Thompson

James Michael Lamanna

Jose De Jesus Camacho Ruiz

Aaron Graydon Bannert

Gowtham Kumar Puligundla

Sydney Benjamin Melhuish

Manish Gilani

Mathew Lehwess

Diwakar Gupta

Kiran Kumar Edara

Ishwardutt Parulkar

Shane Ashley Hall

Kaixiang Hu

Igor A Kostic

Stephen Callaghan

Shuai Ye

Shovan Kumar Das

David James Goodell

Stewart Allen

Matthew B Barr

Andrey Alexseyevich Pyatkov

Nathan Edward Dire

Justin Davies

Bharadwaj Avva

Scott Douglas Morrison

Young Ha Jung

Michael Weyandt

Chaithan Mysore Prakash

Shakeel Ahmad

Akshay Choudhry

In response to a programmatic request, configuration information representing a multi-network-segment gateway established on behalf of a customer is stored at a networking service. In response to another programmatic request, a communication session is established between a route signaling node of the gateway and a routing information source located at a customer premise. In response to additional programmatic input, the networking service stores an indication that the gateway is to be used to transfer packets between a cloud-side virtual network and a customer-side virtual network. The routing information exchanged in the session pertains to the cloud-side and customer-side virtual network, and is used to transfer data packets between the two virtual networks.

Custom configuration of cloud-based multi-network-segment gateways

A network connection is established between a client program and a particular request handler of a network-accessible service. The request handler is selected by a load balancer using an algorithm whose input includes configuration information of the service. The load balancer does not store flow state information for messages transmitted via the network connection. A networking manager of a host at which the client program runs stores the flow state information, including identification information of the particular request handler. Using the identification information, the networking manager causes additional messages directed to the service from the client program to be received at the particular request handler without using the load balancer as an intermediary.

Low-latency stateful load-balanced connections using stateless load balancers

Packets received at a routing intermediary and directed to a resource are transmitted to a data plane node of a partition of a traffic management service. The data plane node transmits an indication of a high-arrival-rate destination group, identified based on a metric of network packets received at the data plane node, to a control plane node of the service. A resource is identified at the control plane node as a rate limiting target based on high-arrival-rate group information from several data plane nodes. A limit is applied to the rate at which packets are received at the target. The control plane node changes the number of data plane nodes in the partition based on a triggering condition.

Scalable network traffic shaping service with dynamically configured partitions

A network function execution intermediary obtains a result of execution of a set of network functions on a particular packet directed to a service from a client program running at a first host. Using the result, the packet is delivered to a request handler of the service, running at a second host; the path used for delivering the particular packet includes the network function execution intermediary. A networking manager of the first host obtains a rule for determining results of the set of network functions with respect to additional packets directed from the client program to the service. The networking manager causes, using the rule, another packet originating at the client program to be delivered to the request handler via a different path which does not include the network function execution intermediary.

Low-latency paths for data transfers between endpoints which utilize intermediaries for connectivity establishment

Techniques for resource-based network traffic management are described. A service of a cloud provider network receives a traffic policy, the traffic policy identifying a path to a gateway to an external network, the path identifies at least one network function in the path by a resource identifier of the cloud provider network. Traffic policy association data is received, the traffic policy association data associating the traffic policy with one or more virtual networks hosted by the cloud provider network. A network configuration of the cloud provider network is updated to route network traffic from a first virtual network to the gateway to the external network through the network function.

Resource-based network traffic management

Route tables may be associated with ingress traffic for logically isolated networks. A routing device at the edge of a logically isolated network may receive a route to include in a route table that is associated with ingress traffic to the logically isolated network, where the ingress traffic is destined for a block of public or private IP addresses. The route instructs the edge routing device to forward such ingress traffic to a network interface of a network appliance hosted in the logically isolated network. Network packets received at the edge routing device may have a destination of one or more public or private IP addresses in the block of public/private IP addresses. The edge routing device may identify the route in the route table that forwards the ingress network traffic destined for the block of public or private IP addresses to the network interface for the network appliance.

Routing ingress traffic for logically isolated networks destined for IP blocks without any network address translation

A first set of network addresses of a first address family, and a second set of network addresses of a second address family, are assigned to a virtual machine. At a routing device, respective routing information entries for the two sets of network addresses are stored, without storing routing information entries for individual addresses of the sets. A first packet with a destination address within the first set, routed using the routing information entry for the first set, is obtained at the virtual machine. A second packet with a destination address within the second set, routed using the routing information entry for the second set, is obtained at the virtual machine.

Efficient propagation of routing information for compute instances with network address ranges of multiple address families

During a communication session established with a customer-premise routing information source, a route signaling node of a multi-network-segment gateway of a cloud provider network obtains respective sets of labeled routing information pertaining to multiple customer-side network segments of a customer. The route signaling node propagates the routing information to data plane nodes of the gateway. The data plane nodes utilize the routing information to forward data packets to destinations associated with particular customer-side network segments.

Software-defined multi-network-segment gateways for scalable routing of traffic between customer-premise network segments and cloud-based virtual networks

Disclosed are various embodiments that provide highly available data-processing network functions for radio-based networks. In one embodiment, a tunnel host consistently routes network traffic associated with a range of network addresses in a radio-based network to a first instance of a data-processing network function instead of a second instance of the data-processing network function. A problem with the first instance of the data-processing network function is then detected. Additional network traffic associated with the range of network addresses is redirected from the first instance of the data-processing network function to the second instance of the data-processing network function.

Highly available data-processing network functions for radio-based networks

Respective destination groups are provided to routing intermediaries associated with a packet processing application. The destination group comprises a set of fast-path packet processing nodes of a packet processing service to which the routing intermediaries are to transmit packets to be processed. After a determination is made that the set of fast-path nodes to be included in the destination groups has changed, the destination groups are modified gradually during an update propagation interval.

Packet processing service configuration change propagation management

Embodiments are directed towards managing an impact of a plurality of system and/or maintenance tasks distributed across a plurality of nodes. At least one initiator node may provide at least one disk request to at least one disk on at least one participant node. Each disk on each participant node with a workload, such as request wait time, above a maximum threshold and/or below a minimum threshold may be determined. If a disk is determined to have a workload above a maximum threshold and/or below a minimum threshold, then an impact of respective tasks on initiator nodes that provided requests to the determined disks may be reduced and/or increased, respectively. In some embodiments, an initiator node may reduce or increase an impact of a task by reducing or increasing a number of threads executing on that initiator node for that task.

Impact management of system tasks

Embodiments are directed towards coordinating parallel execution of tasks. An ordered priority for each of a plurality of tracks may be established. Furthermore, each of a plurality of tasks may be assigned a native priority. A track for executing a task may be identified based on a match of the task native priority and a track priority. The task can execute at the identified track if the track is available. If the identified track is not available, then another track with a next higher priority than the previously identified track maybe iteratively identified. Next higher priority tracks may be iteratively identified until an available track is identified. If an available track is identified then the task can execute at the available track; otherwise, the task may be put into a wait mode before re-attempt to execute at the track with a priority that matches the task native priority.

System for iteratively identifying available next higher priority tracks when identified track matching the task's native track priority is unavailable

Growing community of inventors

Edmonds, WA, United States of America

Ethan Joseph Torretta