This gets old fast - it’s hard to do quickly and certainly doesn’t scale. They must search through various tables, browse different application UIs, and learn the local query language to search through storage buckets or data lakes - all while manually keeping mental track of what IP addresses correlate to VM instance names, VPC IDs, etc. To operate in hybrid cloud networks or cloud environments with a growing number of VPC interconnections using siloed information, engineers have to collate data from multiple sources. It is very difficult to answer these questions, or gain any insight on the traffic path using native-cloud monitoring, SIEM, or legacy network monitoring tools.
Was the traffic blackholed by a route being withdrawn from an adjacent device?.Does it go through a site-to-site VPN attached to the Transit Gateway?.How is the traffic routed through a Transit Gateway on the way to the destination host? Does it take an additional hop through a peered Transit Gateway before being forwarded to a Direct Connect connection to the on-premises network?.How does the data leaving the ENI (of the EC2 instance) reach the application client?.Is the network the cause or a contributing factor?.For instance, in a case when a client application that uses data from the cloud shows delays, some questions come up immediately: Cloud Monitoring Tools Were Not Designed for Network MonitoringĪs mentioned in the previous section, Transit Gateways are central constructs to cloud networking, and yet, no visibility on their traffic is provided. As a consequence, most organizations run in the dark - enduring high MTTR, costs, and risks. Managing cloud networking using current tools such as CloudWatch or third-party SIEM solutions is not scalable, viable, or even effective. Unfortunately, Transit Gateways are natively a black box in the cloud. After all, how can networkers know what applications require connectivity without the ability to see the traffic? And how will they know when they can deactivate the old peering connections? However, moving from ad hoc, one-to-one peering connections to a planned and optimized architecture with Transit Gateways cannot be achieved without visibility. How can networkers know what applications require connectivity without the ability to see the traffic? There’s a typical pattern in cloud environments: developers usually start with a one-to-one tactical approach to connect workloads in their applications, peering one VPC with another, for instance. (Check out The Network Pro’s Guide to the Public Cloud ebook for a quick tutorial on AWS cloud networking.) Each construct addresses specific networking capabilities, security, capacity, and performance requirements. Networking in public clouds can be done via different constructs: gateways, endpoints, direct connections, VPNs, VPC peerings, subnet routing tables, etc. From the naive initial thought of one VPC per organization, we now see organizations deploying hundreds and thousands of these virtual networks. Cloud migrations, microservices architectures, third-party services, and business growth, among other factors, are causing an increase in the number of VPCs deployed - and increasing the need for cloud network visibility. VPC and Workload Interconnectivity Requires PlanningĪpplications often need connectivity between workloads in different VPCs and regions as well as to and from on-premises environments (e.g., data centers, offices, branches, etc.).
#VPN MONITOR NETWORK TRAFFIC HOW TO#
In this post, we’ll offer insight into how to monitor your traffic through Transit Gateways by understanding routing and traffic dynamics through every hop on the end-to-end path. Without knowing who, what, where, and how, network and cloud engineers have no good way to plan, troubleshoot, or migrate cloud networks. However, AWS offers no easy way to gain visibility into traffic that crosses these devices - unless you know how to monitor Transit Gateways.
The end result is complex and often brittle networking environments, and cloud professionals are left in the dark.įor AWS cloud networks, the Transit Gateway provides a way to route traffic to and from VPCs, regions, VPNs, Direct Connect, SD-WANs, etc. This is a direct reflection of business strategy and explosive growth in workloads and third-party services accessed by multiple user, consumer, and device types.
Cloud traffic is expanding in every direction: east-west, north-south, inter-regions, across-clouds, to the edge, sites, and more.
0 kommentar(er)
