Systems and methods for generating network health data and other analytics for multi-cloud environments

Abstract

A distributed cloud computing system is disclosed, including a controller configured to deploy a first gateway in a first cloud computing network and a second gateway in a second cloud computing network. Logic, when executed by one or more processors, causes the following operations, including: receiving, from the controller, metadata related to a plurality of constructs; receiving, from each of the first and second gateways, network data; deriving heat map information detailing network traffic density at a plurality of geographic locations, wherein the network traffic is transmitted across the plurality of cloud computing networks; generating a heat map visualization illustrating the network traffic density, the heat map visualization including a map of a geographic region and an overlay of visual indicators representing the network traffic density; and causing the heat map visualization to be presented on a display screen of a network device.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 013,529, filed April 21, 2020; U.S. Provisional Patent Application No. 63 / 020425, filed May 5, 2020; U.S. Patent Application No. 17 / 127922, filed December 18, 2020; and U.S. Patent Application No. 17 / 127924, filed December 18, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] Embodiments of this disclosure relate to the field of cloud networking. More specifically, one embodiment of this disclosure pertains to a system and method for providing operational visibility across an enterprise network that spans a single public cloud network or multiple public cloud networks. Background Technology

[0004] Until recently, businesses have relied on application software installed on one or more electronic devices in close proximity to their users (hereinafter referred to as "pre-installed electronics"). These pre-installed electronics can correspond to endpoint devices (e.g., personal computers, cellular smartphones, netbooks, etc.), locally maintained mainframes, or even, for example, local servers. Depending on the size of the business, purchasing pre-installed electronics and their corresponding software requires significant upfront capital expenditure, along with substantial ongoing operating costs to keep these pre-installed electronics operational. These operating costs may include the costs of deploying, managing, maintaining, upgrading, repairing, and replacing these electronic devices.

[0005] Recently, more businesses and individuals have begun to rely on public cloud networks (hereinafter referred to as "public cloud") to provide users with a variety of services, from word processing application functionality to network management. A "public cloud" is a fully virtualized environment with a multi-tenant architecture that provides tenants (i.e., users) with the ability to share computing and storage resources while maintaining data isolation within each user's cloud account. The virtualized environment comprises an on-demand cloud computing platform provided by a set of physical data centers, each containing a large number of servers hosted by a cloud provider. Examples of different types of public cloud networks may include, but are not limited to, such as AMAZON WEB SERVICES®, MICROSOFT® AZURE®, GOOGLECLOUD PLATFORM™, or ORACLECLOUD™.

[0006] This increasing reliance on public cloud networks is largely due to the significant cost savings offered by this particular deployment. However, for many types of services, such as network management, network administrators face several challenges, particularly when enterprise operations depend on the operability of a single public cloud or multiple public cloud networks. For example, in cases where an enterprise's network deployment relies on multiple public cloud networks (hereinafter referred to as a "multi-cloud network"), network administrators have consistently struggled to effectively troubleshoot connectivity issues occurring within the multi-cloud network. One reason for this ineffective troubleshooting is the lack of a standard solution available to administrators or users to visualize the connectivity of their multi-cloud network deployment. Another reason is that cloud network providers only allow users access to a limited number of constructs, thus controlling the type and amount of network information available to users. As a result, the type or amount of network information is rarely sufficient for administrators or users to quickly and effectively troubleshoot and correct network connectivity problems.

[0007] Similarly, there is no conventional solution to visually monitor service exchanges between network devices in different public cloud networks (multi-cloud networks) and retain status information associated with network devices in multi-cloud networks to more quickly detect operational anomalies that may indicate an ongoing cyberattack or compromised health of the multi-cloud network. Attached Figure Description

[0008] Embodiments of this disclosure are illustrated by way of example rather than limitation in the accompanying drawings, in which similar reference numerals indicate similar elements, and wherein:

[0009] Figure 1 This is an illustration of an exemplary embodiment of a distributed cloud computing system according to some embodiments, the distributed cloud computing system including a controller that manages a construct spanning multiple cloud networks;

[0010] Figure 2A This is an exemplary illustration of the logical representation of a controller deployed within a cloud computing platform according to some embodiments;

[0011] Figure 2B This is an exemplary illustration of the logical representation of a topological system logic deployed within a cloud computing platform according to some embodiments;

[0012] Figures 3A-3C It is an interface screen that displays a portion of the dashboard of a visualization platform according to some embodiments, and is intended to illustrate information related to network services and infrastructure within a cloud computing environment;

[0013] Figures 4A-4H This is an interface screen that displays a portion of the topology mapping of a visualization platform according to some embodiments, intended to illustrate the structure within a cloud computing environment and the connections between them; and

[0014] Figure 5A-5G This is an exemplary interface screen that displays a portion of one aspect of a visualization platform according to some embodiments, and is intended to illustrate information describing one or more constructed network service flows within a cloud computing environment;

[0015] Figure 6 This is a flowchart illustrating an exemplary communication method between a topology system logic, a controller, and one or more gateways managed by the controller, according to some embodiments.

[0016] Figures 7A-7B It is implemented by the topology system logic according to some embodiments and in Figures 4A-5A The flowcharts for tagging and searching methods are shown in the image; and

[0017] Figure 8 It is implemented by the topology system logic according to some embodiments and in Figure 4G-4H The flowchart illustrates an exemplary method for the replay function. Detailed Implementation

[0018] Embodiments of this disclosure relate to a system configured to provide operational visibility of a network spanning one or more cloud computing environments. According to one embodiment, the system may include software instances operating in one or more cloud computing resources, and these software instances are configured to collect information and present a graphical user interface (GUI) that provides an interactive visual representation of connectivity between constructs of a network spanning multiple (two or more) cloud computing environments (hereinafter referred to as "multi-cloud environments" or "multi-cloud networks"). In other embodiments, the system includes software instances and a controller configured to manage constructs deployed in one or more cloud computing environments (such as within a multi-cloud environment) and communicate with the software instances.

[0019] As will be discussed in further detail below, software instances can use one or more application programming interface (API) calls to query the controller for information to retrieve state information stored by the controller that details each construct managed by the controller. The controller obtains such information from one or more gateways deployed within a multi-cloud network, wherein the gateway(s) are configured to transmit this information to the controller on a periodic (or non-periodic) basis. It should be understood that, as discussed herein, the term "multi-cloud network" refers to multiple cloud networks, where each cloud network may constitute a public cloud network provided by different cloud computing environment resource providers (hereinafter referred to as "cloud providers").

[0020] As is known in the art, a controller can be configured to program each gateway to control the routing of network traffic, such as by providing instructions to the gateways on how network traffic should be routed between various gateways. As an illustrative example, the controller may instruct gateways whether virtual machines (VMs) from one subnet (hereinafter referred to as "subnet") can communicate directly with VMs from another subnet, or how network traffic will flow from source to destination within a cloud computing environment managed by the controller. Furthermore, embodiments of this disclosure discuss instructions provided by software instances to the controller, which are then transmitted by the controller to one or more gateways, and include instructions for transmitting network data from a gateway to a routable address (e.g., an Internet Protocol "IP" address, etc.) of the software instance.

[0021] Therefore, as a general embodiment, the software instance can query the controller for data indicating the status and metadata of each construct managed by the controller, and also receive network data from one or more gateways. The software instance includes logic that generates various visualizations when executed by one or more processors (e.g., as part of a cloud computing resource). These visualizations are combinations of construct status and metadata (collectively, “construct metadata”) and network data. The visualizations can be interactive and provided to users such as network administrators, information technology (IT) professionals, or similar individuals. Furthermore, the visualizations can be configured to receive user input, which causes the software instance's logic (“topology system logic”) to change the visualization. As discussed below and illustrated in the accompanying figures, visualizations can include, but are not limited to, dashboard views providing the overall status and health of the network and specific network parameters; dynamic topology maps that provide a visual representation of each construct and the links identifying communication between constructs; and network flow visualizations that provide various diagrams detailing how network traffic flows through (or has flowed through) the cloud computing environment managed by the controller. Each visualization can provide data across a multi-cloud network.

[0022] In some embodiments, in response to user input, the topology system logic can generate labels for one or more constructs via a topology mapping visualization and store those labels for searching. For example, further user input can be received, causing the topology system logic to search for many constructs managed by the controller and display the tagged constructs and any links between them via the topology mapping. In yet other embodiments, in response to received user input including one or more labels as search terms, the topology system logic can generate a visualization of the network flow of the corresponding tagged construct(s).

[0023] By querying the controller for construct metadata and receiving network data from one or more gateways, the topology system logic can generate the exemplary visualizations described above and shown in the accompanying figures, illustrating network traffic flows associated with one or more tagged constructs. As described throughout, the illustrated network traffic flows can correspond to constructs deployed across multiple cloud networks. This operability provides users with many advantages over existing technologies by enabling them to label one or more gateways residing in different public cloud networks with meaningful tags and search for construct parameters, construct status, link status, and network traffic flows corresponding to those tags.

[0024] An additional function of the topology system logic is to generate visualizations that illustrate changes in the network managed by the controller over time. For example, and as described below, the topology system logic can store network-related data (network data and construction metadata) received for a given point in time (e.g., t1 → ti (where i > 1)). Upon receiving user input corresponding to a request to display the changes between two points in time (e.g., t1 and t2), the topology system logic compares the stored data for t1 and t2 and generates a visual highlighting one or more changes between the network at t1 and t2. The term "highlight" can refer to any visual indicator or combination of visual indicators, such as a color-coded construction with changed parameters, a change in the size of a construction with changed parameters, a graphic displayed around a construction with changed parameters (e.g., a ring), a window or other image (which can span multiple public cloud networks) listing network state changes detected between time t1 and time t2, or other types of visual indicators.

[0025] I. Terminology

[0026] In the following description, certain terms are used to describe the features of the invention. In some instances, the term "logic" represents hardware, firmware, and / or software configured to perform one or more functions. As hardware, the logic may include circuitry with data processing or storage capabilities. Examples of such circuitry may include, but are not limited to, microprocessors, one or more processor cores, programmable gate arrays, microcontrollers, application-specific integrated circuits (ASICs), wireless receivers, transmitter and / or transceiver circuitry, semiconductor memories, or combinational logic.

[0027] Alternatively, or in combination with the hardware circuitry described above, the logic may be software in the form of one or more software modules. These software modules may include executable applications, application programming interfaces (APIs), subroutines, functions, programs, applets, service programs, routines, source code, shared libraries / dynamically loaded libraries, or one or more instructions. These software modules may be stored in any suitable type of non-transitory or transient storage medium (e.g., electrical, optical, acoustic, or other forms of propagated signals, such as carrier waves, infrared signals, or digital signals). Examples of non-transitory storage media may include, but are not limited to, programmable circuitry; semiconductor memory; non-persistent storage devices such as volatile memory (e.g., any type of random access memory "RAM"); persistent storage devices such as non-volatile memory (e.g., read-only memory "ROM", electrically powered RAM, flash memory, phase-change memory, etc.), solid-state drives, hard disk drives, optical disk drives, or portable storage devices. As firmware, executable code may be stored in persistent storage.

[0028] The term "computerized" generally means that any corresponding operation is performed by a combination of hardware, software, and / or firmware.

[0029] The term "construction" can be interpreted as virtual or physical logic for a specific function, such as a gateway, a virtual private cloud network (VPC), a subnet, or the like. For example, as an illustrative example, the construct can correspond to virtual logic in software form (e.g., a virtual machine) that can assign device-specific addresses (e.g., media access control "MAC" addresses) and / or IP addresses within a specific IP subnet's supported IP address range. Alternatively, in some embodiments, the construct can correspond to physical logic, such as an electronic device communicatively coupled to a network and assigned a MAC and / or (one or more) IP address. Examples of electronic devices can include, but are not limited to, personal computers (e.g., desktop computers, laptop computers, tablets, or netbooks), mobile phones, stand-alone appliances, sensors, servers, or information routing devices (e.g., routers, bridging routers ("brouters"), etc.). It is envisioned that each construct can at least constitute logic residing as part of a public network, although some constructs may be deployed as part of a "pre-built" (or local) network.

[0030] The term "gateway" can refer to a software instance deployed within a public cloud network or a virtual private cloud network deployed with a public cloud network, controlling data services (e.g., to one or more remote sites, including computing devices capable of processing, storing, and / or continuing data routing) within and from the public cloud network. In this document, each gateway may operate as a "relay gateway" or a "branch gateway"—gateways with similar architectures but identified differently based on their location / configuration within the cloud computing environment. For example, a "branch" gateway is configured to interact with a target instance, while a "central" gateway is configured to further assist in the propagation of data services (e.g., one or more messages) directed to branch gateways or computing devices within the provisioned network.

[0031] The term "network traffic metric" can refer to the measurement of network traffic transmissions, including quantity, frequency, and / or latency. In some embodiments, network traffic metrics may include the identification of the source and / or destination (e.g., IP address, originating / destination gateway, originating / destination VPC, originating / destination geographic region, etc.). Additionally, in some embodiments, network traffic metrics may also refer to the analysis and / or filtering performed on the measurement of network traffic transmissions.

[0032] The term "controller" can refer to a software instance deployed within a cloud computing environment (e.g., resources on a public cloud network) that manages the operability of certain aspects of one or more cloud computing environments spanning different public cloud networks (multi-cloud networks). For example, a controller can be configured to collect information related to each VPC and / or each gateway instance, and configure one or more routing tables associated with one or more VPCs and / or gateway instances across a multi-cloud network to establish communication links (e.g., logical connections) between different sources and / or destinations. These sources and / or destinations may include, but are not limited to, provisioned computing devices, gateway instances, or other types of cloud resources.

[0033] The term "message" generally refers to information in a prescribed format and transmitted according to a suitable delivery protocol. Therefore, each message can take the form of one or more packets, frames, or any other sequence of bits with a prescribed format.

[0034] The term "link" can generally be interpreted as a physical or logical communication path between two or more constructs. For example, a physical communication path can be a wired and / or wireless interconnection in the form of wires, optical fibers, cables, bus traces, or wireless channels using infrared or radio frequency (RF). A logical communication path includes any communication scheme that enables the exchange of information between multiple constructs.

[0035] Finally, the terms “or” and “and / or” as used herein should be interpreted inclusively, or mean any one or any combination thereof. For example, “A, B, or C” or “A, B, and / or C” means “any one of the following: A; B; C; A and B; A and C; B and C; A, B, and C”. Exceptions to this definition will only occur if the combination of elements, functions, steps, or actions is inherently mutually exclusive in some way.

[0036] Because the invention is susceptible to many different forms of embodiments, it is intended that this disclosure should be regarded as an example of the principles of the invention, and not as a limitation of the invention to the specific embodiments shown and described.

[0037] II. Overall Architecture - Topology

[0038] refer to Figure 1 This illustration shows an exemplary embodiment of a distributed cloud management system 100, wherein the cloud computing system is characterized by a controller 102 for managing constructs residing in multiple cloud networks and software instances 138 for visualizing the managed constructs (hereinafter referred to as "topology system logic"). More specifically, the controller 102 is configured to manage multiple constructs spanning multiple cloud networks, such as cloud (network) A 104 and cloud (network) B 106. In the exemplary illustration, cloud A 104 provides computing resources ("resources") for a transit gateway 114 communicating with gateways 1181-1182 associated with virtual networks (VNETs) 1161-1162. Cloud B 106 provides resources for a transit gateway 120 communicating with gateways 1241-1242 associated with virtual private clouds (VPCs) 1221-1222. Cloud B 106 further provides resources for a local transit hub 126 communicating with VPCs 128 and 130. According to this embodiment of the present disclosure, such as Figure 1 As shown, transit gateways 114 and 120 and local transit hub 126 communicate with each other. Therefore, as should be clearly understood, controller 102 is managing several constructs, such as the gateways illustrated, spanning multiple cloud networks.

[0039] Specifically, the first group 108 of the constructs is deployed within cloud A 104, and the second group 110 and the third group 112 of the constructs are deployed within cloud B 106. Controller 102 utilizes a set of APIs to provide instructions and receive data (status information) associated with each of these constructs and status information (link status) related to each connection between these constructs. The construct metadata returned by the constructs may depend on the type of the construct (e.g., region, VPC, gateway, subnet, instance within a VPC, etc.), where examples of construct metadata may include, but are not limited to, one or more of the following construct parameters (attributes): construct name, construct identifier, encryption enabled, attributes of the VPC associated with the construct (e.g., VPC name, identifier, and / or region, etc.), cloud attributes in which the construct is deployed (e.g., cloud provider, cloud type, etc. in which the construct resides), or similar.

[0040] In addition, the cloud management system 100 includes topology system logic 138 for processing cloud computing resources 136. In some embodiments, topology system logic 138 may be logic hosted on a user's Infrastructure as a Service (IaaS) cloud or multi-cloud environment. As an example, topology system logic 138 may be launched as an instance within a public cloud network (e.g., as an EC2® instance in AWS®). As an alternative example, topology system logic 138 may be launched as a virtual machine in Azure®. Upon launch, topology system logic 138 is assigned a routable address, such as, for example, a static IP address.

[0041] As shown, topology system logic 138 communicates with controller 102 via, for example, an API, enabling topology system logic 138 to transmit queries to controller 102 via one or more API calls. When executed by cloud computing resource 136, topology system logic 138 performs operations including querying controller 102 for constructing metadata in response to specific events via API calls. Specific events can be triggered at periodic or non-periodic intervals, such as user requests for visualizations via user input.

[0042] In some embodiments, in response to receiving a query from topology system logic 138 via an API call, controller 102 accesses data stored on or by controller 102 and returns the requested data to topology system logic 138 via the API. For example, topology system logic 138 may initiate one or more queries to controller 102 to obtain topology information associated with constructs managed by controller 102 (e.g., a list of all gateways managed by controller 102, a list of all VPCs or VNETs managed by controller 102, or other data collected from database tables) along with status information associated with each construct as described above.

[0043] Upon receiving the requested configuration metadata, topology system logic 138 performs one or more analyses to determine whether any additional configuration metadata needs to be requested. For example, topology system logic 138 may provide a first query to controller 102 requesting a list of all gateways managed by controller 102. In response to receiving the requested configuration metadata, topology system logic 102 determines the interconnections between the listed gateways. Subsequently, topology system logic 138 may provide a second query to controller 102 requesting a list of all VPCs managed by the controller. In response to receiving the requested configuration metadata, topology system logic 138 determines the association between each VPC and its corresponding gateway.

[0044] For example, in some embodiments, the received construct metadata provides detailed information for each gateway, enabling the topology system logic 138 to generate data objects representing the gateways, such as database tables for construct metadata. Data objects representing multiple gateways are cross-referenced to construct a topology mapping based on parameters for each gateway. These parameters may include, in particular: cloud network user account name; cloud provider name; VPC name; gateway name; VPC region; sandbox IP address; gateway subnet identifier; gateway subnet CIDR; gateway zone; name of associated cloud computing account; VPC identifier; VPC status; parent VPC name; VPC CIDR; and so on. Similarly, construct metadata is also used to generate data objects representing each VPC object and each subnet object.

[0045] Furthermore, to determine whether a connection within the network exists between two transit gateways, topology system logic 138 can query a list of all transit gateways from controller 102 using a separate API call. Therefore, topology system logic 138 can then determine whether a connection between the first gateway and the second gateway exists between two transit gateways. In some embodiments, as will be discussed below, connections between transit gateways and connections between branch gateways and transit gateways can be visually represented in two different ways.

[0046] In addition to receiving construction metadata from controller 102, topology system logic 138 can also receive network data from one or more gateways managed by controller 102. For example, for each network packet, network data may include, but is not limited to, ingress interface, source IP address, destination IP address, IP protocol, source port of UDP or TCP, destination port of UDP or TCP, ICMP type and code, IP “Type of Service”, etc. In one embodiment, network data can be transmitted from a gateway to topology system logic 138 using an IP protocol (e.g., UDP). In some embodiments, network data is collected and exported via the NetFlow network protocol.

[0047] To configure a gateway to transmit network data to topology system logic 138, topology system logic 138 can provide instructions to controller 102, which in turn provides instructions to each gateway managed by controller 102. These instructions provide the IP address of topology system logic 138, which is used as the IP address for addressing network data transmission.

[0048] As will be discussed in detail below, the topology system logic 138 can generate a visualization platform including one or more interactive displays. These displays can include dashboards, topology maps, and network flow visualizations. Furthermore, the visualization platform can be configured to receive user input that causes filtering of the displayed data.

[0049] For example, and still refer to Figure 1 The topology system logic 138 can generate a topology mapping visualization of the connections detected by the link controller 102, a diagram of the construction within logical region 132 represented by clouds A 104 and B 106. Furthermore, the topology system logic 138 can generate various graphical user interfaces (GUIs) illustrating network traffic flows, traffic heatmaps, packet capture, network health, link latency, encryption, firewalls, etc., of the network flows flowing between constructions managed by the controller 102, as illustrated in the second logical region 134.

[0050] The embodiments disclosed herein offer numerous advantages over current systems, which provide dashboards illustrating controller parameters because they do not provide the ability to visualize connectivity between constructs deployed across multiple cloud networks, the resource status of multiple clouds, connectivity between resources, and network data flow across constructs spanning multiple clouds. As an example, an enterprise network may utilize resources deployed across multiple cloud networks, and the enterprise network administrator may expect visualization of the status of all constructs and connections associated with these resources. However, because the enterprise network spans multiple cloud networks, conventional systems cannot provide such a solution. Administrators cannot obtain a complete view of the entire enterprise network's constructs, their connectivity, and the status of each construct simply by obtaining a textual representation of the status of each construct within a single cloud (e.g., via a command-line interface). Furthermore, the detection of anomalous or malicious network business patterns may be undetectable in the manner provided by current systems.

[0051] As used herein, the visualization (or visual representation) of constructs, their connections, and the state of each construct is referred to as a topology map. Current systems fail to provide topology maps across multiple cloud networks and do not allow administrators to search across multiple cloud networks or visualize how changes in the state of constructs or connections in a first cloud network affect the state of resources or connections in a second cloud network. In some embodiments, the topology map may change automatically as the state of constructs or connections changes, or change automatically in response to certain events, such as receiving updates to construct metadata at periodic time intervals (e.g., “dynamic topology map”).

[0052] In some embodiments, multiple controllers can be used to deploy a network across multiple cloud networks to manage network operability. In some such embodiments, each controller can collect information from the networks and architectures it manages, and a single controller can have access to all such information, enabling a visualization platform to provide visibility across one or more networks that span multiple controllers.

[0053] refer to Figure 2A Exemplary illustrations of the logical representation of a controller 102 deployed within a cloud management system 100 are shown according to some embodiments. As described above, the controller 102 may be a software instance deployed within a cloud network to help manage the operability of constructs within multiple public cloud networks. According to this embodiment, the controller 102 may be configured with certain logical modules, including VPC gateway creation logic 200, communication interface logic 202, and data retrieval logic 204. The controller 102 may also include a routing table database 206.

[0054] In some embodiments, gateway creation logic 200 performs operations to create a gateway within a VPC, including creating a virtual machine within the VPC, providing configuration data to the virtual machine, and prompting the gateway for initialization based on the configuration data. In one embodiment where the cloud computing resource utilized is AWS®, VPC gateway creation logic 200 starts a virtual machine within the VPC, which is an Amazon® EC2 instance. The virtual machine is started using a pre-configured virtual machine image published by controller 102. In a particular embodiment, the virtual machine image is an Amazon Machine Image (AMI). Upon startup, the virtual machine is able to receive and interpret instructions from controller 102.

[0055] Communication interface logic 202 can be configured to communicate with topology system logic 138 via an API. Controller 102 can receive queries from topology system logic 138 via one or more API calls and respond with the requested data via the API.

[0056] Data retrieval logic 204 can be configured to access each construct managed by controller 102 and obtain construct metadata from it. Alternatively or additionally, data retrieval logic 204 can receive such construct metadata transmitted (or “pushed”) from the construct without controller 102 initiating one or more queries (e.g., API calls).

[0057] The routing table database 206 can store VPC routing table data. For example, controller 102 can configure a VPC routing table associated with each VPC to establish communication links (e.g., logical connections) between transit gateways and cloud instances associated with specific instance subnets. VPC routing tables are programmed to support communication links between different sources and destinations, such as provisioned compute devices, cloud instances within specific instance subnets, or the like. Therefore, controller 102 obtains and stores information about certain attributes of resources within controller 102's permissions (e.g., constructs such as gateways, subnets, VPCs, instances within VPCs, etc.), as well as state information related to the connections (communication links) between these resources.

[0058] refer to Figure 2B According to some embodiments, an exemplary illustration of the logical representation of a topology system logic 138 deployed within a cloud computing platform is shown. The topology system logic 138 may be a software instance deployed using cloud computing resources 136 and configured to communicate with controller 102 and each gateway managed by controller 102. The topology system logic 138 is configured with certain logical modules, including tagging logic 208, a tag database 210, interface generation logic 212, communication interface logic 214, and topology snapshot logic 216. Furthermore, the topology system logic 138 may include a snapshot database 218, a construction metadata database 220, and a network data database 222.

[0059] In some embodiments, when the tagging logic 208 is executed by one or more processors, it performs the following... Figures 4A-5A The operations discussed in 7A-7B. In some embodiments, the tags generated by the tagging logic 208 may be stored in the tag database 210.

[0060] In some embodiments, when the interface generation logic 212 is executed by one or more processors, it performs the operations discussed below and causes the generation to be as follows. Figure 4A-5G The exemplary interactive user interface is illustrated in the figure. In some embodiments, tags are generated by tagging logic 208.

[0061] In some embodiments, when executed by one or more processors, communication interface logic 214 performs operations as discussed herein related to querying the controller for configuration metadata, receiving the requested configuration metadata, and receiving network data from one or more gateways managed by the controller. In some embodiments, the received configuration metadata and network data may be stored in configuration metadata database 220 and network data database 222 (which may be separate or combined databases).

[0062] In some embodiments, when the topology snapshot logic 216 is executed by one or more processors, it performs the following: Figure 4G-4H and Figure 8 The operations discussed. In some embodiments, the snapshots (recorded data) generated by the topology snapshot logic 216 may be stored in the snapshot database 218.

[0063] III. Exemplary User Interface – Topology System Visualization Platform

[0064] Figure 3A-5G The exemplary user interface illustrated herein can be configured by topology system logic 138 to be presented and displayed on various displays and via various applications. For example, Figure 3A-5G Each user interface illustrated herein can be configured to be displayed on a computer screen, laptop computer, mobile device, or any other network device including a web browser via a web browser. Furthermore, Figure 3A-5G Each user interface illustrated herein can be configured to be displayed via a dedicated software application installed and configured to execute on any of the network devices described above. For example, topology system logic 138 can be configured to provide the data and user interfaces described herein to a software application (referred to in the art as "app"), which can be installed and configured to execute by one or more processors of the network device. Thus, upon execution, app causes the user interfaces described herein to be displayed on the network device's display screen (or associated display screen).

[0065] 1. Dashboard

[0066] Now for reference Figures 3A-3C According to some embodiments, a graphical user interface (GUI) screen (or “interface screen”) is shown that displays a portion of a dashboard of a topology system visualization platform (“visualization platform”), wherein each portion is configured to illustrate information obtained or determined by the topology system. Figures 3A-3C The interface screens may collectively include a “dashboard” 300, which displays various attributes related to networks deployed across one or more cloud providers, and in particular across multiple cloud providers.

[0067] For example, such as Figure 3AThe dashboard 300 shown includes several display sections 302, 306, and 308. Navigation panel 304 is also shown as part of a visualization platform generated by topology system logic 138. Display section 302 displays information related to the controller (e.g., ...). Figure 1 The controller 102 manages information related to the constructs deployed in one or more cloud networks. The displayed information may include, but is not limited to, the number of deployed gateways, the number of current Virtual Private Network (VPN) users, the number of user accounts, the number of Temporary Gateways (TGWs), the number of network connections (optionally filtered according to cloud computing services), the number of Border Gateway Protocol (BGP) connections, etc.

[0068] Figure 3A The display portion 306 includes a list of virtual data centers, which comprise network resources and optionally span multiple cloud networks. Specifically, the display portion 306 includes user input fields (e.g., checkboxes) configured to receive user input indicating how the content displayed by the dashboard 300 is filtered by one or more specific cloud networks (e.g., AWS®, GOOGLE®, CLOUD PLATFORM® (GCP), AZURE®, ORACLE CLOUD INFRASTRUCTURE® (OCI)). In some embodiments, a virtual data center is a pool of cloud computing resources that may be hosted on a public cloud.

[0069] Additionally, display section 308 illustrates a portion of the world map, including a graphical representation of each virtual data center listed in display section 306, such as icon 309, and its geographical location on a portion of the world map. Display section 308 can be filtered according to the "by cloud filter" option provided in display section 306 and can be configured to receive user input to adjust the map zoom level (e.g., "zoom in" or "zoom out").

[0070] Navigation panel 304 includes each general visualization link provided by the visualization platform, including dashboard 300, ( Figures 4A-4E Topology mapping 400 and ( Figure 5A-5G Network flow visualization 500.

[0071] For reference Figure 3B The diagram illustrates a portion of a dashboard 300 displaying multiple graphs and charts through multiple display sections 310 and 312. Each of the display sections 310 and 312 displays the resource distribution across a multi-cloud deployment.

[0072] For example, as an illustrative embodiment, display portion 310 features multiple bar charts illustrating metrics for resources managed by the controller; however, as should be understood from a review of the accompanying drawings of this disclosure, bar charts are merely one type of illustration that can be used to present data, and this disclosure is not intended to be so limited to the particular type of graphical representation shown. Display portion 310 illustrates, by specifically displaying “accounts by cloud,” “gateways by cloud,” and “relay gateways by cloud,” that the data displayed on the dashboard corresponds to the construction and network traffic across multiple cloud networks. Similarly, display portion 312 provides graphical representations of gateway metrics, including “gateways by type,” “gateways by region,” and “gateways by size.” In some embodiments, gateway metrics include one or more of the following: the total number of deployed gateways, the number of Virtual Private Network (VPN) users, the number of user accounts associated with one or more gateways, the number of relay gateways, the number of gateways deployed by a particular cloud resource provider, the number of Border Gateway Protocol (BGP) connections, or the number of temporary gateway attachments.

[0073] Figures 3A-3B The diagram illustrates various metrics and characteristics of gateways, which may include one or more of the following: total number of gateways deployed, number of Virtual Private Network (VPN) users, number of user accounts, number of transit gateways, number of gateways deployed by a specific cloud resource provider, number of Border Gateway Protocol (BGP) connections, or number of temporary gateway attachments.

[0074] Additionally, one or more metrics may be derived from or based on gateway characteristics, which may include one or more of the cloud computing network in which each gateway is deployed, the type of each gateway, the size of each gateway, or the geographical region in which each gateway is deployed.

[0075] Now for reference Figure 3C This illustration shows another graphical representation of network functionality, operation, or operability, based on data collected and processed by topology system logic 138, and displayed as part of dashboard 300. More specifically, according to this illustrative embodiment, display portion 314 provides a graphical representation of network traffic across resources across multiple cloud networks over an adjustable time period (e.g., 24 hours). This time period can be adjusted by topology system logic 138 based on received user input. For example, user input corresponding to a selection of a portion of a graph shown by the user can be received. In response to such received user input, topology system logic 138 can change the graphical representation for the selected portion, which can now be represented by smaller time intervals (e.g., 15 minutes, 30 minutes, 1 hour, etc.).

[0076] In some embodiments, the dashboard 300 (and Figure 4A-5GOther visualizations discussed above are the result of a user-input request for such a visualization. In some embodiments, in response to receiving a request, the topology system logic 138 requests the construction metadata as discussed above, and stores the construction metadata and the latest network data received from the gateway in a data store (such as a construction metadata database 220 and / or a network data database 222, which, as mentioned above, may be a single database). Furthermore, the topology system logic 138 then generates the requested visualization based on the stored data.

[0077] In some embodiments, the topology system logic 138 will automatically update the visualization at periodic time intervals (e.g., generate an updated visualization and re-render the display). In some embodiments, the updated visualization will be generated and displayed when a triggering event occurs, such as when user input requesting a refresh of the display is received. The updated visualization will be updated based on newly received or acquired construction metadata and / or network data since the previous rendering.

[0078] 2. Topology mapping

[0079] Now for reference Figures 4A-4E According to some embodiments, an interface screen is shown that displays a portion of the topology map 400 of a visualization platform generated by the topology system logic 138. Specifically, Figures 4A-4E The diagram illustrates multiple constructs deployed in one or more cloud networks managed by controller 102, as well as the connections between the various constructs.

[0080] refer to Figure 4A According to some embodiments, an exemplary illustration of a topology map 400 generated by topology system logic 138 is shown. As illustrated, the topology map 400 includes components generated by a controller (e.g., Figure 1 The controller 102) provides a graphical representation of the constructs managed by the topology map 400. The topology map 400 allows users to visualize all known constructs that can be deployed on a single cloud or across multiple cloud networks. In the exemplary illustration, the constructed constructs shown are deployed across multiple cloud networks, including Azure®, GCP, and AWS®.

[0081] The Topology Map 400 is an interactive display screen configured to receive various forms of user input (e.g., dragging and repositioning constructs, selecting one or more constructs to view construct parameters, entering text, selecting settings or activating buttons, etc.). The received user input can be configured to reposition constructs, display construct parameters, apply filters, search for constructs, run diagnostics, apply one or more tabs, etc.

[0082] like Figure 4AAs illustrated, construct 402 (e.g., gateway 402) is depicted as being selected. In the illustrated embodiment, the selection of gateway 402 results in the display of parameters of gateway 402 in display section 422. For example, display section 422 may provide the name of the selected construct, “gateway” (gateway 402), user input buttons 424 and 426 configured to receive user input, and a list 428 of construct parameters—including whether the construct is encrypted, the cloud provider of the construct, the gateway name associated with the construct, the VPC identifier associated with the construct, the cloud type of the construct, the VPC region of the construct, whether the construct is a relay VPC, etc. It should be noted that, as discussed above, construct parameters may correspond to construct metadata received by controller 102 and are not limited to the parameters illustrated in the figures. Instead, this disclosure includes all parameters of the selected construct. As is known in the art, relay VPCs operate to connect multiple VPCs and / or remote networks.

[0083] The topology map 400 also illustrates multiple connections (e.g., illustrated as nodes or vertices) between various structures. Referring to the selected gateway 402, several connections (communication links) are illustrated, including but not limited to: link 412 to gateway 404, link 414 to relay gateway 406, link 416 indirectly linking gateway 402 to relay gateway 410, etc. Furthermore, varying graphical notation can indicate differences in links. For example, in some embodiments, solid links can indicate links between two branch gateways or links from a gateway to a relay gateway. Additionally, in some embodiments, dashed lines can indicate links between two relay gateways. Furthermore, in some embodiments, links can be color-coded to provide a visual indication of link status, e.g., green for active and red for inactive.

[0084] Topology map 400 also illustrates the construction in addition to the gateway, including subnets (such as subnet 418) and virtual data centers (such as virtual data centers 408, 420) (e.g., representing AWS® resources and AZURE® resources, respectively).

[0085] refer to Figure 4B According to some embodiments, an exemplary illustration of a topology map 400 generated by the topology system logic 138 of the illustrated diagnostic function is shown. Figure 4AAs shown, the topology map 400 may display a button 426 (e.g., labeled "Diagnostics") configured to receive user input activating the button 26, which causes the topology system logic 138 to initiate a diagnostic procedure. When button 426 is activated, the topology system logic 138 causes a display box 430 to appear, which includes several input fields 432-438, each configured to receive user input indicating an aspect of the diagnostic procedure. As shown, the topology system logic 138 is configured to perform a diagnostic procedure on the selected construct (gateway 402); however, in other embodiments, the display box 430 may include additional user input fields configured to receive constructs on which (or from which) diagnostic procedures will be performed.

[0086] Furthermore, the topology system logic 138 can be configured to provide indication of being located in or near the topology system. Figure 4A The link latency values ​​for one or more links illustrated in the diagram. Topology system logic 138 can be configured to automatically send data packets (e.g., ping) and determine the time spent in transmission by analyzing the time the data packets are sent and received (including in response packets from the destination of the data packets). The link latency for each link can be updated at periodic intervals (e.g., every 30 seconds, 60 seconds, etc.) or in response to a triggering event (e.g., receiving user input indicating a visual refresh). Although Figure 4A The subset of links illustrated includes an indication of link latency, but this can be provided for all links. Advantageously, network administrators can use the vision of link latency to reconfigure (e.g., terminate and restart virtual machines in different subnets) to improve link latency. Furthermore, the vision of link latency can be used to assess incompatibility with specific Quality of Service (QoS) levels (e.g., as specified in the contract). Additionally, topology system logic 138 can set latency thresholds and monitor link latency, such that when link latency meets or exceeds the latency threshold (which may correspond to the specific QoS level mentioned above), a notification or change to topology mapping 400 is generated.

[0087] refer to Figure 4B Input fields 432-434 are configured to receive user input for the destination and interface, respectively. Buttons 436-438 are configured to be activated via user input, which corresponds to the selection of a diagnostic procedure for ping or tracing the route, respectively. Although not shown, in other embodiments, input fields corresponding to selections of other diagnostic procedures may be provided, such as including TCP dumps and / or link latency checks. Figure 4BAs shown, in response to user input activating button 436 (ping), topology system logic 138 initiates a procedure in which a ping is transmitted from the selected construct (gateway 402) to the destination address (e.g., IP address 8.8.8.8) provided in field 432. The ping result 440 is visualized in real time. Thus, the diagnostic process provided by topology mapping 400 via topology system logic 138 can provide the user with the results of various diagnostic procedures performed on constructs spanning multiple cloud networks (e.g., a ping procedure can be performed between a first gateway deployed in a first cloud and a second gateway deployed in a second cloud), with a visual representation of the results provided by a visualization platform generated via topology system logic 138.

[0088] refer to Figure 4C According to some embodiments, an exemplary illustration of a topology map 400' generated by topology system logic 138 with illustrated search and filtering functions is shown. Another function provided by topology system logic 138 is searching within topology map 400 and filtering displayed constructs based on received user input (e.g., search terms). As shown, display portion 422 may include input field 442, such as a text box, configured to receive user input corresponding to a search term. In response to receiving user input at input field 442, topology system logic 138 performs a search of the constructs displayed in topology map 400. This search may be a search of stored construct metadata, wherein the search includes... Figure 2B One or more queries are performed on the construction metadata database 220. The data returned from the one or more queries is then used to generate a topology map 400', which is a filtered view of the topology map 400 that displays only the constructions associated with the search term. For example, the search term can correspond to any construction parameter discussed above. The topology system logic 138 does not need to receive the specified parameters, but can instead search all construction parameters within the database 220 to obtain the value corresponding to the search term.

[0089] It should be understood that the system disclosed herein can filter based on multiple search terms or parameters. Furthermore, it will be understood that, as discussed throughout, the topology system logic 138 advantageously stores construction metadata for constructions spanning multiple cloud networks. Therefore, the filtered view provided by the topology system logic 138 as a result of receiving one or more search terms can correspond to multiple constructions spanning multiple cloud networks.

[0090] refer to Figure 4DAccording to some embodiments, an exemplary illustration of a topology map 400 generated by topology system logic 138 of illustrated labeled constructs is shown. As shown, display portion 422 includes a user input button 424 (e.g., labeled “Add Label”) corresponding to the labeling function performed by topology system logic 138. In response to receiving user input activating button 424, display box 444 is generated by topology system logic 138 and configured to receive further user input corresponding to a label (e.g., alphanumeric text) to be associated with one or more selected constructs. Figure 4D In the illustrative example, a single node was selected, namely the construct (Gateway 402).

[0091] When the "Add" button is activated via user input included within display box 444, a label "ccdata" is generated and associated with the selected construct (gateway 402). The generation and association of the label with the selected construct includes several operations performed by topology system logic 138. For example, topology system logic 138 generates and stores a table, which can be stored in... Figure 2B The tag database 210 contains the tag "ccdata" and the association between the tag "ccdata" and the unique identifier of each selected construct and the unique identifier of gateway 402. Therefore, and as discussed in more detail below, tagging constructs allows users to search the topology map 400 for constructs via their associated tag(s), which is advantageous because users no longer need to remember or search by unique identifiers, which are typically long strings of alphanumeric characters. Furthermore, when multiple constructs are tagged with the same tag, the user can search for that tag, and the topology system logic 138 will then generate a display showing the multiple constructs associated with the tag provided as a search term. In some embodiments, such as Figure 4E As shown, the topology map 400 can be filtered to display only the constructs associated with the tags provided as search terms. However, in other embodiments, although not shown, the entire construct can be displayed while the constructs associated with the tags provided as search terms are displayed in a visually different manner from those not associated with tags (e.g., highlighted, color-coded, etc.).

[0092] refer to Figure 4E According to some embodiments, the illustrations show... Figure 4D The illustration shows an exemplary topology map 400 generated by the topology system logic 138, which combines the tagging function with the tag search function. As discussed above, the topology system logic 138 performs operations to generate tags based on received user input and associates the tags with one or more selected constructs (e.g., as per the context of...). Figure 4D The discussion relates to gateway 402. Figure 4E The illustration shown assumes that the operation with Figure 4D The similar set of operations discussed herein, and including the construct 450 of gateway 402, has been tagged with the same label, such as "ccdata".

[0093] The topology map 400” illustrates a view of the topology map 400, where the displayed construct has been filtered by the search term “ccdata”, as illustrated by the text 448 provided as user input to the display box 422. Additionally, upon receiving the text 448 as user input, the topology system logic 138 illustrates the search term (e.g., search term 446) in the display box 422 and further filters the topology map 400 to display “Topology map 400”, which illustrates the construct associated with search term 446.

[0094] As described above, assuming that the group of construct 450 has been tagged with "ccdata", then upon receiving the search term 446 as user input, the topology system logic 138 queries the tag database 210 to retrieve the unique identifier of each construct tagged with "ccdata". Subsequently, the topology system logic 138 generates and displays a topology map 400, which includes the constructed group 450.

[0095] also, Figure 4E The illustration shows a second aspect of the labeling function of topology system logic 138, which performs the labeling operation on constructs in a single instance. As shown, the grouping of constructs 450 appears to be selected via user input. Topology system logic 138 is further configured to label the selected constructs using user input provided in display box 452, the display of which, as discussed above, is a result of activating the "Add Label" button 424. Specifically, display box 452 is shown as receiving user input 454 (Company 1). Therefore, in response to the activation of the "Add" button within display box 452, topology system logic 138 generates a label for "Company 1" and associates each construct within group 450 with the label "Company 1".

[0096] It should be noted that, Figure 4E The illustrated example discloses another aspect of the tagging functionality of topology system logic 138, namely, that a construct can be associated with multiple tags. As shown, each construct of group 450 is associated with at least two tags: "ccdata" and "Company 1".

[0097] It should be understood that labeling is not merely changing construct identifiers (such as IP addresses), but also, because multiple resources may have the same label, labeling constructs allows users to visualize the location of a specific subset of the construct deployed throughout the network, potentially spanning multiple cloud networks. For example, in Figure 5A-5G The diagram in the middle and about Figure 5A-5G The discussion focuses on how searching via tags enables users to visualize specific network data constructed in association with tags (one or more).

[0098] refer to Figure 4F According to some embodiments, an exemplary illustration of a topology map 400 generated by the topology system logic 138 of the illustrated active user tracking function is shown. Figure 4F The topology view of the topology mapping 400 includes an input button 454 and a display section 456. The input button 454 (e.g., labeled "Get Active User") can be configured to receive user input corresponding to a user request for visualization of an active user, such as user input associated with a selected gateway, like gateway 452. An active user can be a user logged into a Virtual Private Network (VPN) that has access to resources provided by a cloud network. The display section 456 can be configured to receive user input corresponding to the selection and initiation of a tracing function for a selected active user (e.g., active user 458), and whether the tracing function should track the network traffic of the selected active user, where the selected active user is either a source or a destination.

[0099] More specifically, as part of the construction metadata, topology system logic 138 receives information about active users utilizing resources managed by controller 102. Upon activation of input button 454 via user input, topology system logic 138 can query the construction metadata database 220 for active users associated with the selected gateway. Upon retrieving active users for the selected gateway, topology system logic 138 causes a change in topology mapping 400 by displaying a graphical representation of other markers associated with the active users of the selected gateway. However, in some embodiments, it is not necessary to select a gateway so that topology system logic 138 retrieves active users for each gateway managed by controller 102.

[0100] exist Figure 4F In the exemplary embodiment illustrated herein, it is assumed that gateway 452 has been selected and input button 454 has been activated via user input. Multiple active users are shown logged into the VPN associated with gateway 452, including active user 458. Additionally, Figure 4FThe illustration shows that display portion 456 has received user input corresponding to a selection for tracking network activity, such that network traffic with a destination address of active user 458 will be tracked by topology system logic 138. Tracking network traffic may include monitoring the source IP address or destination IP address of each data packet entering or leaving the selected gateway. In some embodiments, the tracked network traffic may be displayed using a graphical representation adjacent to and / or connected to the graphical representation of active user 458. As shown, tracked network traffic with a destination IP address equal to the IP address of active user 458 is illustrated via graphical representations 4601-4603, where each graphical representation includes the source IP address of the input data packet. In alternative embodiments, the tracked network traffic may be provided in a separate display portion adjacent to the topology map and / or in a log stored by topology system logic 138.

[0101] refer to Figure 4G-4H According to some embodiments, exemplary illustrations of topology maps 400''' and 400'''' generated by topology system logic 138 of the illustration replay function are shown. Topology system logic 138 may be configured to save the state of each construct and connection managed by controller 102 periodically at a given time instance or when user input instructing such a save operation is received. The state records of each construct and connection at a given time instance may be collectively referred to as "snapshots". The state of each construct may include a record of each parameter associated with the construct as discussed herein. Additionally, topology system logic 138 may be configured to determine the state differences (if applicable) between a first snapshot and a second subsequent snapshot of corresponding constructs and corresponding connections. Topology system logic 138 may then generate an interface panel illustrating the state differences.

[0102] Figure 4G The diagram illustrates the time instance t. t A snapshot of topology map 400 (topology map 400''') and Figure 4H The diagram illustrates the interface, topology mapping 400'''', showing the time instance t. t The differences between the topology map 400 and snapshot t2. For example, topology map 400 provides visual distinctions on constructions 466-470, indicating that changes have occurred between the two time instances. Additionally, a display box 464 may be included, providing a list of differences by construction.

[0103] 3. Network Flow Visualization

[0104] Now for reference Figure 5A-5G According to some embodiments, an interface panel illustrating the network service flow generated by topology system logic 138 is shown. Specifically, Figure 5A-5G The illustration shows a visualization of network traffic flows between multiple constructs deployed in one or more cloud networks managed by controller 102 (“Network Flow Visualization 500”) and the connections between the various constructs.

[0105] In a brief recap, the dashboard 300 discussed above is configured to provide visualization of cloud computing environment parameters, such as the number of active gateways, the number of VPN users, details of virtual data centers associated with the cloud computing environment managed by the controller, and the location of the virtual data centers. Furthermore, the topology map 400 is configured to provide visualization of how each construct managed by the controller is connected; thus, a visual representation of the interactions within the entire cloud computing environment managed by the controller is provided. Finally, the network flow visualization 500 is configured to provide visualization of network traffic flowing between constructs managed by the controller. Therefore, the visualization platform generated by the topology system logic 138, including the dashboard 300, the topology map 400, and the network flow visualization 500, provides a holistic view of the entire cloud computing environment managed by the controller, which, as discussed throughout this disclosure, can span multiple cloud networks.

[0106] i. Overview

[0107] Now for reference Figure 5A According to some embodiments, an exemplary illustration of a network flow visualization 500 generated by topology system logic 138 is shown. As illustrated, the network flow visualization 500 includes multiple display portions 502-508, wherein the display portion 508 includes multiple charts 5101-510. i (in Generally speaking, network flow visualization 500 is designed to provide information on how network traffic is flowing (or has flowed) by controllers (such as...). Figure 1 The controller 102) manages various filterable views of the cloud computing environment.

[0108] Display section 502 represents the title of the network flow visualization 500, which is configured to receive user input corresponding to a selection that redirects to a specific aspect of the network flow visualization 500, such as: Overview, Trends, Geographic Location, Flow, and Records, each of which will be discussed further below. In particular, display section 502 indicates that "Overview" is the aspect of the network flow visualization 500 currently being displayed.

[0109] Display section 504 provides several filtering options for time periods during which network traffic flows are displayed through network flow visualization 500. For example, the display section includes an input field that includes a date picker configured to receive user input corresponding to a start and end time. Additionally, buttons that allow for quick selection via clicks can be provided, which, when activated, cause topology system logic 138 to filter the displayed network traffic flows according to predetermined time periods, such as, but not limited to, "last hour," "last day," "last week," "last month," etc.

[0110] Display section 506 is configured to provide additional filtering options, including filtering by specific categories, such as but not limited to source address, destination address, outgoing stream (host), source port, destination portion, etc., and corresponding search terms (“filter terms”). Additionally, display section 506 displays the active filter when applicable. In the illustrated embodiment, the filter currently being applied is the one previously used in… Figure 4E The filter 446 (“ccdata”) discussed in the text corresponds to charts 5101-510 in display section 508. i The data filtering shown in the figure.

[0111] Importantly, such as Figure 5A As illustrated, the tags generated via topology mapping 400 can be used as search terms and applied as filters in network flow visualization 500. Therefore, users can provide user input via topology mapping 400, causing topology system logic 138 to generate tags and associate those tags with one or more selected constructs that can be deployed in multiple cloud networks. Furthermore, after the generation and association of tags (e.g., “ccdata”), topology system logic 138 can receive further user input via network flow visualization 500, allowing it to filter the displayed network traffic flows and display only those flows tagged with “ccdata” (e.g., between, to, and from).

[0112] In addition, such as Figures 5B-5C The diagrams shown are 5101-510 of section 508. i The diagram can be displayed based on input received via the category selection and search term input fields of display section 504 and display section 506 and / or in one or more diagrams 5101-510. i The data displayed can be filtered.

[0113] Now for reference Figure 5BAccording to some embodiments, an exemplary illustration of a network flow visualization 500 generated by topology system logic 138 is shown. As illustrated, the network flow visualization 500 is filtered according to filter 514, which corresponds to selecting... Figure 5A A portion of diagram 5102 (e.g., destination IP address 10.101.0.52). In response to receiving user input corresponding to a selection of destination IP address 10.101.0.52, topology system logic 138 filters the data displayed in each of diagrams 5101-5101 to display network service information related to that selection. As shown, with Figure 5A Compared to chart 5102, chart 5102' is displayed with a changed visual. It should be understood that multiple filters can be applied simultaneously.

[0114] ii. Trend

[0115] refer to Figure 5C According to some embodiments, an exemplary illustration of a network flow visualization 500 generated by topology system logic 138 is shown, which is intended to illustrate the “trends” of network service flows. Figure 5C The diagram illustrates the "trends" aspect of the Network Flow Visualization 500, including information about... Figures 5A-5B The discussion focuses on display sections 504-506. Furthermore, the "Trend" aspect may include display sections 516-518, which include graphs of network traffic in bytes over time based on destination port names, and a graph 5181 illustrating network traffic in bytes for multiple destination port names. Although not shown, additional graphs and charts similar to those in display section 516 may also be displayed for data categories (e.g., Figure 5B The diagram shows elements such as source IP, destination IP, destination port and IP, source port and IP, and source port.

[0116] As shown, the network flow visualization 500 is filtered according to filter 514, which is generated and applied via the "Overview" aspect of the network flow visualization 500, as discussed above. Therefore, the topology system logic 138 is configured to apply filters that persist throughout the network flow visualization 500, meaning that filters applied in one aspect (e.g., "Overview") will be maintained across other aspects (e.g., "Trends"), filtering the data illustrated therein.

[0117] Now for reference Figure 5D According to some embodiments, an exemplary illustration of a network flow visualization 500 generated by topology system logic 138 is shown, which is intended to illustrate... Figure 5C The filtered view of the graph shown. Figure 5CAs shown in the diagram, a portion of the graph of display section 516 is selected via indicator 5D-5D. Figure 5D The diagram illustrates a topology system logic 138 configured to receive user input corresponding to a selection of a portion of a graph, such as 5D-5D, and to change the graph's magnification (e.g., zoom in) to highlight the selected portion. Because... Figure 5C Chart 5181 corresponds to the graph in display section 516, therefore chart 5181 is in Figure 5D The filter version 5181 is shown in the image, which displays network traffic data based on the destination port name selected by the 5D-5D filter.

[0118] iii. Geographical location

[0119] refer to Figure 5E According to some embodiments, an exemplary illustration of a network flow visualization 500 generated by topology system logic 138 is shown, which is intended to illustrate the "geographical location" of network service flows. Figure 5E The diagram illustrates the "geographical location" aspect of the Network Flow Visualization 500, which includes at least information about... Figures 5A-5B The discussion focuses on display portion 506 (and in some embodiments, display portion 504 may also be included). Furthermore, the "geographical location" aspect may include display portions 520-522. Display portion 520 illustrates a "heatmap," which includes a map of a geographic region, such as a portion of a world map, that includes visual indicators of network traffic density at various locations on the map. Figure 5E As shown in the illustrative embodiment, heatmap 520 includes visual indicators representing the heatmap to illustrate the varying density of network traffic flowing between constructs managed by controller 102, wherein the density of network traffic flowing between constructs may include heatmap information. Additionally, charts 5241-5243 provide supplementary graphical representations of the network traffic data shown in heatmap 520 (e.g., network traffic in bytes per country and / or city, network traffic in bytes per destination port and source port, network traffic in bytes per destination IP and source IP). It should be understood that although three (3) charts are illustrated, alternative numbers, such as one (1), two (2), or more than three (3), may be illustrated. Furthermore, the heatmap information may include the results of applying various filters to the network traffic, at least such as... Figure 5E As shown in the diagram.

[0120] Specifically, the topology system logic 138 determines the density of network traffic flowing between structures based on structure metadata and network data received from the controller 102 and the gateways managed by the controller 102, respectively. In some embodiments, Figure 5EThe illustration shown can be updated on a periodic or non-periodic basis (e.g., in response to a triggering event, such as receiving user input that initiates a refresh).

[0121] In relation to the above Figure 3A-5D In a similar manner to the user interface discussed, the charts of heatmap 520 and display section 522 can be filtered in various ways, such as by receiving user input via display section 506, selecting any part of the chart of display section 522, or by applying persistent filters to different “aspects” of visualization 500 via network stream.

[0122] iv. Flow

[0123] refer to Figure 5F According to some embodiments, an exemplary illustration of a network flow visualization 500 generated by topology system logic 138 is shown, which is intended to illustrate the “flow” aspect of network services. Figure 5F The diagram illustrates the "geographical location" aspect of the Network Flow Visualization 500, which includes at least information about... Figures 5A-5B The discussion focuses on display portion 506 (which may also include display portion 504 in some embodiments). Furthermore, the "stream" aspect may include display portions 526, 530, and 532. Display portion 526 illustrates multiple graphs 5281-5282, which may be similar to the graphs in display portion 522, but display content such as network traffic in bytes per source address and network traffic in bytes per destination address. It should be understood that although two (2) graphs are illustrated, an alternative number, such as one (1) or more than two (2), may be illustrated.

[0124] Display section 530 may be a visual representation of the number of source IPs and destination IPs managed by controller 102. Furthermore, display section 532 illustrates a graphical representation of network traffic flowing from source IPs to destination IPs. In some embodiments, such as Figure 5F In one embodiment, the graphical representation can display a series of flows from a source IP address to a destination IP address, where each flow is illustrated in a visually distinct manner (e.g., a different color for each flow). The graphical representation can be configured to receive user input selecting a source or destination IP address, and in response to receiving such user input, the topology system logic 138 is configured to change the graphical representation to emphasize (or individually display) one or more flows associated with the selected IP address. Furthermore, the content displayed in each of the display sections 524 and 520 can be filtered and adjusted according to the selected IP address to provide network data corresponding to the selected IP address.

[0125] v. to record

[0126] refer to Figure 5G According to some embodiments, an exemplary illustration of a network flow visualization 500 generated by topology system logic 138 is shown, which is intended to illustrate the “recording” aspect of network traffic. Figure 5F The diagram illustrates the "record" aspect of the Network Flow Visualization 500, which includes at least information about... Figures 5A-5B The discussion is shown in sections 504-506.

[0127] In addition, the "recording" aspect of the network flow visualization 500 includes a display section 534, which illustrates the information about... Figure 5F The diagram illustrates a detailed graphical representation of network traffic flows, such as in a tabular format. For example, the table may include columns providing data related to: timestamp, host, destination IP address, source IP address, number of bytes in the time stream indicated by the timestamp, direction of the network traffic flow (ingress or egress), number of data packets transmitted at the time indicated by the timestamp, etc.

[0128] IV. Logical Flow

[0129] Now for reference Figure 6 According to some embodiments, flowcharts of exemplary communication methods between topology system logic, controllers, and one or more gateways managed by the controllers are shown. Figure 6 Each box in the diagram represents an operation performed in method 600 involving exchanging communication with the controller and receiving data from one or more gateways managed by the controller. Prior to the initiation of method 600, it can be assumed that gateways such as... Figure 1 The diagram illustrates a distributed cloud management system. When the topology system logic (such as...) Figure 1 The topology system logic 138) directs data to the controller (such as...) Figure 1 When the controller 102 queries the construction metadata, it initiates method 600 (box 602). As discussed above, the query can be made via one or more API calls. Subsequently, the topology system logic 138 receives the requested construction metadata and stores the received data in a database, such as... Figure 2B The metadata database 220 is constructed (box 604).

[0130] Additionally, the topology system logic receives network data from one or more gateways managed by the controller (Box 606). The topology system logic then proceeds to store the received network data in a database (such as...). Figure 2B In the network data database 222).

[0131] After receiving the construction metadata and network data, the topology system logic generates one or more visualizations (box 608) based on the received data. Figure 3A-5GThe diagram illustrates exemplary visualizations that can be generated; however, visualizations that can be generated from the topology system logic are not limited to those illustrated.

[0132] refer to Figures 7A-7B According to some embodiments, it is shown that the topology system logic is implemented and... Figures 4A-5A The flowchart in the middle illustrates the tagging and search methods. Figures 7A-7B Each box in the diagram represents an operation performed in method 700, which involves tagging and searching operations implemented by the topology system logic. Before initiating method 700, it can be assumed that features such as... have already been deployed. Figure 1 The diagram illustrates a distributed cloud management system. When the topology system logic (such as...) Figure 1 When the topology system logic 138 generates a topology map visualization and makes it available for presentation via a user interface, method 700 is initiated (box 702). After generating the topology map visualization, the topology system logic receives user input via the topology map visualization corresponding to the selection of one or more constructs, and further indicates the label name (box 704). In response to the received user input, the topology system logic generates a table that associates the unique identifiers of the selected one or more constructs with the label names (box 706).

[0133] After generating the table, method 700 can proceed to boxes 708 and / or 714. Referring to box 708, the topology system logic receives further user input indicating a tag name as a search term via a topology mapping visualization. In response to receiving a search term, the topology system logic queries a tag database storing the previously generated table to retrieve a unique identifier for each of one or more tagged constructs associated with the search term (box 710). After retrieving the unique identifier, the topology system logic performs an operation that causes a change to the topology mapping visualization, visually distinguishing one or more tagged constructs associated with the search term from those not associated with the search term (box 712). For example, the change could include providing a visualization that displays only graphical representations of the tagged constructs associated with the search term and corresponding network data including links between them. However, other alternatives have been considered, such as increasing the size of the tagged constructs (and corresponding network data) associated with the search term (or decreasing the size of the untagged constructs) relative to other constructs and network data.

[0134] Now for reference Figure 7BFollowing table generation, the topology system logic generates a visualization of network traffic flows (between, to, and / or from) one or more constructs managed by the controller, as per box 714. It should be noted that in some embodiments, the operation of box 714 may be performed before table generation. The topology system logic receives further user input via the visualization of network traffic flows, which indicates label names as filter items (box 716).

[0135] In response to receiving a filter item, the topology system logic queries the tag database to retrieve a unique identifier for each of the one or more constructs associated with the filter item (box 718). After retrieving the unique identifier, the topology system logic performs an operation that causes a change in the visualization of network traffic flows to display only a diagram of the network traffic flows between the one or more constructs associated with the filter item (box 720). For example, Figure 5A An exemplary visualization is shown in the figure.

[0136] Now for reference Figure 8 According to some embodiments, it is shown that the topology system logic is implemented and... Figure 4G-4H The flowchart illustrates an exemplary method for the replay function. Figure 8 Each box in the diagram represents an operation performed in method 800, which is an operation implemented by the topology system logic including replay functionality. Before initiating method 800, it can be assumed that features such as... have been deployed. Figure 1 The diagram illustrates a distributed cloud management system. When the topology system logic (such as...) Figure 1 The topology system logic 138 initiates method 800 (box 802) when it first instantiates and records at least a portion of the construction metadata and optionally network data of all constructs managed by the controller. Additionally, the topology system logic records at least a portion of the construction metadata and optionally network data of all constructs managed by the controller at a second subsequent instantiate (box 804).

[0137] Records in the first and second time instances (e.g., stored in a database such as...) Figure 2B After the data in the snapshot database 218) is processed, and in response to a user input instructing a comparison between the states of the structures (and links therein) managed by the controller, the topology system logic performs a comparison between the data recorded in the first time instance and the data recorded in the second time instance (box 806).

[0138] In response to user input, the topology system logic generates a topology mapping visualization of one or more differences (if any) between the data recorded in the first and second time instances, and makes it available for presentation via the user interface (boxes). Figure 4G-4H An exemplary visualization is shown; however, the visualizations that can be generated are not limited to those shown.

[0139] In the foregoing description, the invention has been described with reference to specific exemplary embodiments thereof. However, it will be apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims.

Claims

1. A distributed cloud computing system comprising: a controller configured to (i) deploy and manage a first gateway in a first cloud computing network and a second gateway in a second cloud computing network, and (ii) manage a plurality of constructs; and logic stored on a non-transitory computer readable medium that, when executed by one or more processors, causes performance of operations comprising: receiving, from the controller, metadata relating to the plurality of constructs, receiving, from each of the first gateway and the second gateway, network data, wherein a combination of the metadata and the network data identifies each of the plurality of constructs, a communication path between each construct, and in which cloud computing network each construct is deployed, deriving gateway metrics across a plurality of cloud computing networks including at least the first cloud computing network and the second cloud computing network, wherein the gateway metrics are derived from at least the metadata and the network data of each of the first gateway and the second gateway, generating a dashboard visualization that illustrates the gateway metrics, wherein the gateway metrics relate to characteristics of each gateway and deployed constructs associated with each gateway, causing presentation of the dashboard visualization on a display screen of a network device, in response to receiving a user input, performing a latency check procedure comprising the operations of: (i) transmitting a data packet from a selected construct to a destination address, (ii) monitoring a transmission path taken by the data packet, wherein the transmission path includes a series of at least two constructs, and (iii) detecting a latency value of the transmission path between adjacent constructs within the series of at least two constructs, and causing presentation of an updated visualization on the display screen including an illustration of the transmission path taken by the data packet and the latency value between the adjacent constructs within the transmission path.

2. The distributed cloud computing system of claim 1, wherein the characteristics of the first gateway include one or more of a cloud computing network in which the first gateway is deployed, a type of the first gateway, a size of the first gateway, or a geographic region in which the first gateway is deployed.

3. The distributed cloud computing system of claim 1, wherein the gateway metrics include one or more of a total number of deployed gateways, a number of virtual private network (VPN) users, a number of user accounts associated with one or more gateways, a number of transit gateways, a number of gateways deployed by a particular cloud computing resource provider, or a number of border gateway protocol (BGP) connections.

4. The distributed cloud computing system of claim 1, wherein the visualization includes a plurality of display sections, wherein a first display section includes region and cloud computing resource provider information for each virtual data center associated with the controller.

5. The distributed cloud computing system of claim 4, wherein a second display section illustrates one or more icons on an illustration of a geographic region, each icon representing a virtual data center.

6. A computerized method of informing a user of network metrics, the computerized method comprising: receiving, from a controller, metadata related to a plurality of constructs, wherein the controller (i) deploys and manages a first gateway in a first cloud computing network and a second gateway in a second cloud computing network, and (ii) manages the plurality of constructs; receiving, from each of the first gateway and the second gateway, network data, wherein a combination of the metadata and the network data identifies each of the plurality of constructs, a communication path between each construct, and in which cloud computing network each construct is deployed; deriving gateway metrics across a plurality of cloud computing networks including at least the first cloud computing network and the second cloud computing network, wherein the gateway metrics are derived from at least the metadata and the network data of each of the first gateway and the second gateway; generating a dashboard visualization that illustrates the gateway metrics, wherein the gateway metrics relate to characteristics of each gateway and deployed constructs associated with each gateway; causing the dashboard visualization to be presented on a display screen of a network device; in response to receiving a user input, performing a latency check procedure including the following operations: (i) transmitting a data packet from a selected construct to a destination address, (ii) monitoring a transmission path taken by the data packet, wherein the transmission path includes a series of at least two constructs, and (iii) detecting a latency value of the transmission path between adjacent constructs within the series of at least two constructs, and causing an updated visualization to be presented on the display screen including an illustration of the transmission path taken by the data packet and the latency value between the adjacent constructs within the transmission path.

7. The computerized method of claim 6, wherein the characteristics of the first gateway include one or more of a cloud computing network in which the first gateway is deployed, a type of the first gateway, a size of the first gateway, or a geographic region in which the first gateway is deployed.

8. The computerized method of claim 6, wherein the visualization comprises a plurality of display portions, wherein a first display portion comprises a region of each virtual data center and cloud computing resource provider information associated with a controller, wherein a second display portion illustrates one or more icons on an illustration of a geographic region, each icon representing a virtual data center, wherein the computerized method further comprises: receiving a user input corresponding to a selection of a cloud computing resource provider, filtering the gateway metrics illustrated on the dashboard visualization based on the selected cloud computing resource, and causing the filtered dashboard visualization to be presented on a display screen of a network device.

9. The computerized method of claim 8, wherein the third display portion includes network traffic metrics of network traffic transmitted between constructs deployed in the plurality of cloud computing networks and associated with the first gateway or the second gateway.

10. The computerized method of claim 6, wherein a first subset of the plurality of constructs is associated with the first gateway and deployed in the first cloud computing network, and a second subset of the plurality of constructs is associated with the second gateway and deployed in the second cloud computing network.

Images