Save 80% on Cloud Monitoring Costs. No, this Isn’t Vendor BS.

Whenever I talk to customers, partners, and analysts and tell them we help customers save up to 80 percent or more on cloud infrastructure costs to run tools, they are often thinking to themselves - and sometimes tell me outright - "That sounds like vendor BS." To which I just smile, because it's not BS. It's just math.

To be honest, I don't think they are challenging whether Gigamon can help customers save money. After all, we have been helping customers save money for well over ten years, with numerous customer case studies to back it up. What they are challenging is the amount of cost savings. Eighty percent is a lot - that's disruption territory - and it sounds too good to be true. I get it. If a vendor said that to me, I'd probably challenge it, too.

But if you are willing to spend just a little more time with me, I'd like to walk you through the math involved for each of the three public cloud platforms so you can see and decide for yourself.

First Some Background: What Type of Cloud Deployment Are We Talking About Here?

We are focusing on deployments of security or performance tools in public cloud that receive packets, such as a cloud NDR security tool.

If you know Gigamon, you will know that Gigamon acquires data from networks and delivers it to tools like network security tools and application performance tools. You may also know that Gigamon delivers data to tools in one of two forms, either packets or metadata, based on what the tool needs and supports. For packet-based tools, Gigamon filters, decrypts, and/or optimizes the packet feed, while for metadata-based tools, Gigamon transforms the packet flows into summary records enriched with metadata attributes from the network.

For the 80 percent savings in question, the largest cloud cost savings will come from packet-based tools simply because they're working with higher data volumes. And while there are many packet-based tools that run in public cloud, the most prominent packet-based cloud tool is NDR (network detection and response), so for the remainder of this blog, we'll talk about these cost savings using the example of cloud NDR. These are familiar names like ExtraHop, Vectra, Corelight, and others; each has a native version of its NDR that runs in public cloud.

These NDR tools need packets. They can get those packets one of two ways: They can either use a native packet mirroring service from the public cloud provider, or they can use GigaVUE Cloud Suite™ with the GigaVUE^®Universal Cloud Tap (UCT).

Let's examine these two options for each of the three public cloud platforms on which GigaVUE Cloud Suite is supported.

Amazon Web Services (AWS)

Let's consider a deployment using the native packet mirroring service from AWS, known as VPC Mirroring. It works well, and it carries a moderate expense, charging a nominal per-instance rate for every workload being mirrored. But it's often only a small part of the cost picture. In fact, there are many expenses that make up the total cost to run NDR sensors. Rather than go through each one and plunk you into the tedious minutiae, a reasonable simplification is to focus on the network volume per-GB costs, which carry the vast majority of the costs for all but the tiniest of deployments.

So, where do network volume costs come into play? The answer is with data transport.

Many NDR deployments either prefer to have, or in some cases must have, their NDR sensors deployed in a separate virtual private cloud (VPC) from the workloads being monitored. When using a deployment with multiple VPCs, one must transport data between VPCs to get data from the mirroring source to the NDR sensor. And to perform this transport function, a load balancer is needed. AWS provides a couple of choices of load balancers to use, but both carry a substantial cost based on volume - 0.75 cents per GB for the gateway load balancer variety, or 0.6 cents for the network load balancer.

0.75 cents per GB may not sound like much, but 1,500 workloads generating 25 Mbps each adds up to over $1M/year.

The alternative is to use the GigaVUE Cloud Suite from Gigamon. With this deployment, one can use the GigaVUE UCT instead of VPC Mirroring and the GigaVUE V Series virtual packet broker instead of an AWS load balancer. Together, this little duo handles both the mirroring and transport functions. It also packs additional GigaSMART^® functionalities such as load-balancing, de-duplication, replication, and auto-scaling. When it comes to costs, the GigaVUE Cloud Suite is also volume-based, but the volume cost ranges between 0.04 and 0.25 cents per GB. The specific amount depends on a few factors like total volume and feature set, but the typical average is on the lower end - around 0.1 cents per GB.

So that's the major comparison: 0.75 cents per GB versus 0.1 cents per GB.

Figure 1 illustrates how that comparison looks in a scenario of 1,500 workloads generating 25 Mbps each. This includes all costs, not just the volume costs, but you can see the outsized role the volume costs play with the load balancer.

[Link]Figure 1. Cost savings scenario comparing NDR + AWS default vs. NDR + Gigamon. (Click on the image for larger size.)

Google Cloud Platform

Google Cloud Platform (GCP) also offers a native packet mirroring service, and that service by itself is free, but it requires the use of a specific load balancer, regardless of whether multiple VPCs or zones are used. This TCP/UDP Passthrough Load Balancer is not free. It carries an even higher volume cost, adding up to 1.80 cents per GB.

But when using GigaVUE Cloud Suite instead, the cost is effectively the same as with AWS, at 0.1 cents per GB.

Comparison: 1.8 cents per GB versus 0.1 cents per GB.

In Figure 2, let's look at the same example scenario, a cloud NDR deployment monitoring 1,500 workloads generating 25 Mbps each. Here, too, you can witness the high-volume costs of the load balancer.

[Link]Figure 2. Cost savings scenario comparing NDR + GCP default vs. NDR + Gigamon. (Click on the image for larger size.)

Azure

Unlike the previous two cloud providers, Azure does not presently offer any packet mirroring service, so there is not much to compare it with here. If you want packet visibility at all on Azure, you have to get Gigamon or build your own mirroring agent. However, the Gigamon costs don't change. The costs in Figure 3 for GigaVUE Cloud Suite will effectively be the same affordable price as with the first two platforms.

[Link]Figure 3. Cost scenario for NDR + Azure default vs. NDR + Gigamon. (Click on the image for larger size.)

Okay, That Math Checks Out. But Are There Any Gotchas?

It depends. Public cloud deployments can be complex, and there are many ways to design deployments with tools. In order to help you develop your own opinion on the central question, I'd like to illuminate parts of the story that aren't as easily told by the simple charts above.

1. Transfer costs.
   Transporting packets across availability zones carries a substantial volume cost - 1.0 cent per GB for both AWS and GCP. If the deployment is designed in such a way that the NDR tool sensor is in a different zone than the monitored workloads, these costs would have to be added in. This added cost will apply to a Gigamon deployment, a deployment using GCP default mirroring, and a deployment using AWS default mirroring with a network load balancer. For AWS with a gateway load balancer, there are no transfer costs between zones, which can make that attractive but doesn't really solve the cost challenge. In either case, Gigamon would recommend a deployment design whereby the NDR tool sensors are always in the same zone as the monitored workloads.

1. Transit Gateways.
   The Transit Gateway is an AWS network construct that gives admins much more control over network data flow between VPCs in their public cloud environment. It also carries one of the highest volume charges you can find - 2.0 cents per GB. Gigamon can help in one of two ways. First, to fully optimize costs, Gigamon would generally recommend putting both Gigamon and the NDR tool sensor inside the same VPC as the monitored workloads. While you'll end up with a little extra compute cost, you'll save a small fortune in Transit Gateway costs. But if a Transit Gateway is truly required for transporting mirrored packets to tools, Gigamon can help reduce these costs by prefiltering some data prior to hitting the Transit Gateway.

1. Tap deployment.
   Customers are often initially concerned about deploying the GigaVUE UCT, as it can be perceived as adding a third-party agent into their workloads. The concern is understandable, as agents have a history of causing problems, from deployability to interference to slowdowns. But most of the time, once customers learn more about how UCT is designed, these concerns diminish, because UCT is designed to be as independent as possible.
   • For container-based environments, UCT is an independent pod living on the same worker node, so the production container workloads would be oblivious to UCT's existence. You might even say that UCT for containers is agentless.
   • For VM environments, UCT does have to run inside the VM, but it's designed to be as independent as possible, for example, by having a separate upgrade path with separate config management and by not directly handling the packets, instead intelligently programming the kernel to safely and efficiently perform the mirroring. UCT does not interfere with other applications' functions, and the VM does not have to contend for resources.

You can learn more about UCT here.

1. Tap performance cost.
   Deploying UCT to perform packet mirroring in software will indeed require CPU. And in some cases, that extra CPU could mean that monitored workloads would need to be scaled up in order to compensate. This wouldn't typically be the case for every workload, just the ones that are already running at or near maximum capacity. But it can, and probably will, happen to some extent. The good news is UCT leverages cutting-edge eBPF technology to intelligently program the kernel to perform the mirroring and tunneling capability. This makes UCT itself extremely lightweight, or even dormant most of the time, since it's not handling the packets directly. It also means the kernel, which is doing the heavy lifting, can do so using low-level, high-performance constructs like memory registers. Hence, UCT with eBPF will perform mirroring in the fastest and most efficient way.

See the Cloud Costs Savings for Yourself

You can see how this model would apply to your environment. Gigamon offers a free, no-obligation assessment where you can meet with one of our experts, discuss your environment, and we will model cloud cost savings customized for your environment.

Results may vary depending on the infrastructure and solution deployment.

Public link

Please use the above public link if you want to share this noodl on another website.