Auto-Scaling Network Visibility in AWS Cloud

Amazon Web Services (AWS) launched the new Gateway Load Balancing (GWLB) services feature that has lots of significance for cPacket cCloud (cloud visibility suite) offering in AWS. Before we dive into how, let’s first understand what AWS GWLB actually is.

What is AWS Gateway Load Balancing?

The AWS GWLB is a new managed service in AWS which allows customers to seamlessly deploy and manage multiple inline virtual network appliances in a scalable manner. In addition to that a Virtual Private Cloud (VPC) end-point for GWLB, called the GWLB endpoint (GWLBE) is also being released which allows customers to scale and manage their network services in a centralized manner having a common administrative domain, similar to your existing on-prem deployments. This has many use-cases including deploying network service centrally as-a-services for internal and external customers, thus reducing time, cost and risk.

cPacket cCloud Visibility with AWS Gateway Load Balancer

Existing in-line appliance architectures have many different challenges like single point of failure (high-availability clusters have to be layer-2 adjacent), limited scale (cannot scale beyond a pair) and redundant administrative domains. The AWS GWLB service takes care of all these challenges and provides a full fault tolerant, auto-scalable, bump-in-the-wire service. GWLB works in a transparent way (i.e. layer-3[1]  auto-scaling information in the original packet headers is preserved) which eliminates the need for making any changes to the application stack.


Specifically, GWLB allows – (a) on-demand scalability of virtual appliances offering deployment flexibility as traffic volume changes, (b) high availability with automatic rerouting of traffic to healthy appliances using health probes, (c) graceful failover across virtual appliances which is needed for many purposes including when doing upgrades or patching, and (d) deployment of multi-tenant managed services for traffic filtering/steering.

Request a demo today to learn how cPacket and Amazon Web Services’ (AWS) Gateway Load Balancing is a better alternative to traditional models, and why it’s better visibility into network traffic in the cloud

How cPacket cCloud Solution Leverages GWLB?

The AWS GWLB service load balances traffic across multiple cPacket’s cCloud cVu-V network packet broker virtual appliances allowing transparent insertion and scaling of cVu-V instances. Under the hood, the GWLB service sends traffic to the cVu-V instances in the load-balanced group encapsulated in GENEVE.

The cVu-V instances then mirror packets to downstream tools for further analysis. To complete the solution, cPacket’s cCloud cStor-V packet capture and cClear-V analytics virtual appliances are available to capture, analyze and visualize mirrored traffic.

How is the Solution Deployed?

(A) Ingress/Egress traffic monitoring for multiple VPCs with cVu-V as a shared service:

This architecture scales very well in scenarios where an IT operations team wants to provide visibility-as-a-service to its internal businesses and departments. This use-case describes ingress and egress traffic monitoring from multiple VPCs.

cPacket cVu-V sits as a scalable network packet broker appliance behind the GLB service in a fault tolerant load-balanced group mirroring traffic to cStor-V packet capture and analysis appliance which works with cPacket’s cClear-V analytics and management solution. cVu-V instances can be added or removed as needed without effecting the monitoring state or as capacity or traffic needs increase.

Traffic arrives to the VPC via AWS Internet Gateway (IGW) and is routed to the GWLB end-point which forwards the traffic to GWLB service in a shared VPC (each VPC has its own GWLBE). The GWLB without modifying the layer-3 header creates a GENEVE tunnel specific to each GWLB end-point and forwards the traffic to cVu-V. The cVu-V, in turn, replicates the traffic for monitoring and analysis purposes and then returns the traffic to the GWLB service so that it can complete original communication flow.

(B) Traffic originating in the VPC can also be monitored. In this case, traffic is first routed to the GWLB end-point in the VPC which then forwards it to the GWLB service where it is load balanced across the cVu-V appliances. cVu-V appliances mirror the traffic to downstream tools as above, and then forwards it to the IGW and to the destination via the GWLB and GWLBE endpoint.

Additional topologies are also supported based on organization’s needs. For instance, traffic monitoring between VPCs traversing via AWS Transit Gateway (TGW), while visibility and analytics services are provided via shared VPC in a similar way.

A scalable and highly available cloud monitoring, visibility and analytics solution is now possible with the offering of cPacket cCloud products and Amazon AWS GWLB service.

Request a demo today to learn how cPacket and Amazon Web Services’ (AWS) Gateway Load Balancing is a better alternative to traditional models, and why it’s better visibility into network traffic in the cloud

About The Author

Muhammad Haseeb is Director of Product Management at cPacket Networks. Muhammad has held various product management positions at company’s including Cisco, HPE and Juniper Networks where he has worked with many large enterprise and service provider/Telco accounts. He has product management and technical expertise in the areas of data center switching, network virtualization and cloud solutions, secure SD-WAN, enterprise security and advanced threat detection and mitigation solutions.