Screaming in the Cloud - Secure Your Environment in One ExtraHop with Guy Raz

Episode Date: June 10, 2021

About GuyGuy Raz is a Sr. Systems Engineer at ExtraHop with previous experience as a Network Engineer and Solution Architect. Guy is one of the SMEs leading the unique ExtraHop approach to cloud-native NDR for the hybrid multi-cloud enterprise. Before joining the Sales Engineer team, Guy was one of the ExtraHop Solution Architects, responsible for conducting deep technical and business discovery sessions, assisting in troubleshooting and problem resolution during war-room and security/network investigations, and developing strategies for acquiring high-value data from the wire; requiring in-depth technical understanding of L2-L7 networking principles.Links:https://www.extrahop.com/https://extrahop.com/demo

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me.

I linked against an early version of their tool, canarytokens.org, in the very early days of my newsletter. And what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to. It gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It's an awesome approach. I've used something similar for years. Check them out. But wait, there's more. They also have an enterprise option that you should be very much aware of. Canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets NMAP scanned or someone attempts to log into it or access files on it, you get instant alerts.

It's awesome. If you don't do something like this, you're likely to find out that you've gotten breached the hard way. Take a look at this. It's one of those few things that I look at and say, wow, that is an amazing idea. I love it. That's canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y.

Take a look. I'm a big fan of this. More from them in the coming weeks. This episode is sponsored in part by our friends at Lumigo. If you've built anything from serverless, you know that if there's one thing that can be said universally about these applications, it's that it turns every outage into a murder mystery. Lumigo helps make sense

of all of the various functions that wind up tying together to build applications. It offers one-click distributed tracing so you can effortlessly find and fix issues in your serverless and microservices environment. You've created more problems for yourself? Make one of them go away. To learn more, visit Lumigo.io. Welcome to Screaming in the Cloud. I'm Corey Quinn. Once a year in San Francisco, if I find myself being overly cheerful, all I have to do is walk up and down the RSA Expo Hall and look at a bunch of vendors talking about how their on-premises product kind of sort of works in the cloud, and then I'm not overly cheerful anymore. One notable exception to this is a company called

ExtraHop. I've spoken about them before, and on this promoted episode, we're going to dive a little bit deeper. Today, my guest is senior systems engineer Guy Raz. Guy, thanks for taking the time to speak with me. Thanks, Corey. Happy to be here. So for those who have not caught previous episodes or heard me ranting from the rooftop about it, at a very basic level for folks who have not even, I guess, dipped their toes in the RSA space because they, you know, want to be happy with their lives. What is ExtraHop? ExtraHop's a cloud-native approach for analyzing wired data.

Historically, customers have kind of looked at taps, spans, but with cloud, there's a ton of way of getting this natively. You know, AWS, GCP, Azure give us ways of collecting this data. ExtraHop's a platform for analyzing that network traffic and in real time providing context to application and security teams. So when you take a look at it from a, I guess, the perspective of security, it's easy to sit here and say, oh, so how do you wind up thinking about security in a place or time of cloud? Because there's an awful lot of ways to view it. You can go down the path

of, ah, I'm going to just use all the first-party tooling from my provider, and that's it, which, that could be fair. Alternately, you could go down a different path of, I'm going to just go ahead and buy whatever they'll sell me at RSA, which is great, because the hardest part there is the booth attendees not making actual cash register sounds with their mouths when you walk past with an open checkbook. But security always feels like a thing that's kind of an afterthought. It's something that is tied too closely on some level to this idea that you're never going to be secure, so you may as well just give up. It's also something people only care about after it's been a little too late where they really should have been caring about it. How do you see that?

It's a really unfortunate space, but you're absolutely right, Corey. What we end up seeing is a lot of customers and just the industry as a whole tends to be an afterthought when it comes to cloud. They assume cloud-native solutions or built-in free solutions have their best foot forward, have their best instance in mind. And that's not always the case. There's a lot of, like you mentioned, built-in solutions that these cloud providers can give us. And while a lot of them are kind of scratching the surface of what security in the cloud can provide, there's a lot that it kind of leaves unanswered. And the unfortunate thing is the cloud journey isn't always the easiest. There's a lot of lift and shift. There's a lot of refactor. And sometimes the security portion of that gets put on the

side street until it becomes a priority or an event happens. So given that you can effectively not even swing a dead cat anymore without hitting 15 different security vendors all claiming to do everything you'd want start to finish, what makes ExtraHop different? How do you approach security that's differentiated from the rest of the, I guess, entire security industry? Yeah, that's a really good question. I think my favorite part and one of the reasons I love our product is the data stream that we collect. Network data is a huge source of information that's just sitting there silently kind of waiting to be consumed and analyzed. In the old on-premise environment, there were legacy packet capture solutions or ways of grabbing this information from a span or a tap, but it's still the same data stream as we go to the cloud. It's just a slightly different way of collecting it. So the biggest thing that I would kind of encourage people is

use the data that's there. The network traffic is passing your infrastructure. It's EC2s hitting your S3 buckets. It's RDS instances going through a load balancer to a Lambda function. It's all just traversing through infrastructure that you just don't own anymore. But getting that information is a huge differentiator. You're talking about every packet of every transaction being analyzed in real time at a cloud scale, which you need a smaller instance today. It's smaller today. You need a bigger instance tomorrow. It just auto scales up. Now, back in the world of data centers, I agreed an awful lot with what you're saying as far as looking at the network as the first point of,

I guess, the arbiter of truth, for lack of a better term. And on some level in cloud, I feel like I've drifted away from that. Now, back in our days at data centers, you don't know what's running on these systems. You don't know what various engineers have shoved onto them. But generally speaking, you can mostly trust the network. Please don't email me. So once you move into a cloud world, everything sort of changes a bit. You don't really have to think about any of the layer two networking and most of the layer three networking sort of goes away too. Plus, let's be very realistic, from the perspective of the virtual machines you're running in a cloud environment, everything beyond that is kind of a lie. There's a bunch of encapsulation, you're higher up the stack, you're not on hardware

anymore. So on some level, it always felt that networking is not really the same thing in the cloud environment. I can ignore it. And I have to admit, back when I first started talking to you folks, I was something of a skeptic. And then you more or less made me change my perspective through a very sneaky approach of spinning up a test account for me with ExtraHop, and now I get it in a way I never did before. Is that aha moment common to the, I guess, the cloud-native set? Or do most people come into this with a much more rational and reasoned approach to networking in the cloud? I would say it's both. You know, we have customers who are familiar with the type of information we can provide

and are going through their cloud journey or, you know, are starting their cloud journey and they want the same type of visibility. But for our net new customers, when we hit that white space, that aha moment comes in and it's so much fun to see someone who had no idea what this type of data can provide. They're used to legacy telemetry or log information. So that aha moment is something that as someone who gets to interact with customers is one of my favorite parts of the job. And I would say it's fun to play with and show that. Now, I want to be clear that, again, in the interest of full disclosure, now, since I have put this in my test account,

ExtraHop is now the second most expensive consumer of AWS services, but it's not as bad as folks might think. It's using a VPC mirror in order to look at traffic, and that costs me the princely sum of somewhere between $10 and $11 a month. And that doesn't really vary regardless of how much traffic I show through this thing. It's not doing a whole lot in the AWS account. If I didn't know that was there and that's what it was doing, I would ignore the spend line entirely. How does this work? What are you doing in order to get access to seeing what is happening on the wire, quote unquote, in a cloud environment?

So just kind of focusing on AWS for a second, since that's what you called out, it's using a native built-in functionality that Amazon provides. It's called VPC Packet Mirroring. It's super simple. You deploy an extra hop collector into your VPC. You set that up as a destination of your traffic, and then you configure what's called a monitoring session in VPC, you set that up as a destination of your traffic, and then you configure what's called a monitoring session in VPC. You can say, I want it to do based on these tags, I want it to send traffic based on this subnet or any their combination of, and it just kind of works. You know, it's beautiful. And where we're kind of taking this to the next step is using some

intelligent Lambda automation to ensure that anytime a new instance gets spun up, whether it's tagged, untagged, deployed into a different VPC or is a different instance size, it gets automatically added into this data feed. So you talk about the ephemerality of the cloud and how instances can spin up and spin down almost instantaneously. As soon as an instance is up before it even gets any traffic sent to it, traffic is coming to the extra hop, right? We'll see IMDS traffic, we'll see instance metadata, we'll get the ENI information all kind of just by sitting there passively listening. One of the things that I found particularly, I guess, appreciated about your

entire approach is I didn't have to change anything about what was actually running in this account. I didn't have to teach the EC2 instances that something else was going on. I didn't have to reconfigure anything on an application basis. This was purely done in the underlying VPC configuration. It was done without any downtime whatsoever. And I feel like that is an understated benefit for an awful lot of tooling. Oh, just go ahead and roll this thing out to all of your environment. Yeah, there are tens of thousands of instances in VM scattered throughout our entire estate. Exactly how long do you think we're going to spend on this? You don't have that problem here. And it's kind of nice.

It is really nice. And not to take anything away from some agent solutions, because, you know, they do have their presence. Oh, I will, but please go on. But this approach to security and monitoring in the cloud, to your point, Corey, is seamless. Application owners don't know it's there. It doesn't add any added load. I'm a former network engineer troubleshooting different instances or different virtual machines, the first thing I used to do is turn off those agents, right? Is this consuming CPU resources? Is this slowing down my agent? That's no longer the case in cloud. That's no longer the case with this network-based approach. I'll also point out that it always feels like there's a false dichotomy when we're talking about security vendors. And it either feels like, oh, you're in a bunch of data center style environments,

you're migrating into the cloud, but basically today your environment is a bunch of VMs and maybe a load balancer or an object store. And a lot of tooling speaks super well to that use case. But then if you take a step back and look at, well, the lie that all these companies love to tell themselves, And I'm no more immune to this than they are, to be very clear here. But we all tell ourselves this beautiful lie, which is, after this next sprint ends, then, then we're going to go ahead and pay off all of our technical debt and things are going to be done properly with a capital P. And it never happens, but it's the lie we tell ourselves. And we make financial decisions in some cases tied to that false vision of,

well, why would I wind up embracing something that is aimed at that particular use case? Because once we wind up going full-on cloud-native and embracing our provider of choice, all of this stuff is going to change. What I like about ExtraHop is, all right, assume you're in that mythical born-in-the-cloud world where you have a significant estate that everything runs on top of these higher-level services. ExtraHop is still there, still working, and still doing exactly the sorts of things we're talking about here. No matter where you are on that transformational journey, it feels like there's an answer here. Is that accurate? Have I been gargling the marketing tea too heavily? What's the story here?

No, that's pretty accurate. And it doesn't really matter where you are on your cloud journey. Security can't be foregone for the sake of this cloud instance. We see this day in, day out. If you subscribe to as many news alerts as I do, it's a scary world. Just even recently, this past weekend, we had not our customer, but there was an attack against an oil pipeline that came through a cloud vulnerability. IAM account leakage and service accounts and OpenS3 buckets. It's a scary part of this cloud journey. We want to make sure that

we're scaling. We want to reduce our physical footprint, but we can't forego the security and the trust that our customers have in our applications. And that means that having an approach to security in the cloud needs to be top of mind, regardless of where you are in that cloud journey. I think one of the, I guess, biggest concerns is in the security space is very similar to what I deal with in the cost optimization space, which is people care about it only after they really, really, really should have cared about it on some level. Now, over in the billing world that I live in, people generally have a failure mode of, well, we spent a little too much money. And that is generally a very survivable thing. I used to say tongue in cheek, only I was being completely

serious. One of the reasons I went with AWS billing as my direction of choice was that no one is going to come and call me at two o'clock in the morning with a billing emergency. It is strictly a business hours problem. Security is a very different world. But if you screw up the bill, you spend too much money. If you screw up security, well, your company's name is mud. You could try and pull a SolarWinds with a ring of ablative interns to wind up trying to pass the buck off onto, but in practice, you're probably losing a CISO and a few other high-level execs as a sort of token offering to the market gods. And it's painful, and I'm hard-pressed to name a company

these days that has not suffered at least some form of data breach somewhere. It almost feels like it's a losing game. It's not a losing game, but it is a post-breach world, right? It's not a question of if you get breached. It's more a question of what security holes have been left open and what can they collect from these holes. And minimizing that attack surface is obviously critical, but understanding the damage and reacting to it as fast as possible is just as important. And honestly, that's kind of my

favorite parts about the cloud. I can see something like a suspicious transaction or a large increase in web traffic and then fire off an API to Lambda that says, deploy the security group onto this instance. That whole process takes milliseconds. So the reaction time that we have with the cloud vastly surpasses what we ever had in the data center. And yeah, you're right. Maybe that adds up costing a little bit more or creates a slightly higher bill because we called a couple Lambda functions, but no exfiltration of data, no loss of customer information. You know, you can't trade that off at the end of the day. The thing that always, I guess, sort of bothered me about various breaches or various security reports is whenever

companies will say definitively, we have never suffered a security breach. That might mean that they are absolutely on point, though you always have this probabilities question, but it could also mean that they have no effective visibility or effective logging. And that is the dangerous part. It's similar to this idea back once upon a time in the early days of unbreakable Linux, when Oracle was pushing that and they said, it is unhackable. The entire internet proved them wrong within hours, because everything can be broken into at some point. It's just a question of how high do you raise that bar? Ideally, a little bit above random people just scanning S3 buckets. Yeah, and it's, you know, that's really scary, kind of the data that we get to

see when, you know, you called this earlier, that aha moment. Because we're an always-on solution, we get to see the hygiene of the network too. I can tell you when someone hit an insecure S3 bucket or an IAM role logged in at 2 in the morning that it never has before, or someone sent an API command to Lambda to spin up another instance at 2 in the morning using a service account that has admin permissions. It's a scary world in the cloud, and making sure you have that surface covered kind of gets you to those aha moments quicker. This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the enterprise, not the starship. On-prem security doesn't translate well to cloud or multi-cloud environments, and that's not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35%

faster, and helps you act immediately. Ask for a free trial of Detection and Response for AWS today at extrahop.com slash trial. One thing that I do want to draw a little bit of attention to as well, having kicked the tires on ExtraHop for a for that attachment to the VPC that I see on my bill when I go over that thing with a fine-tooth comb because of who I am and what I do. My point being is that I have instances in that account that are doing a bunch of relatively strange things from time to time. And the behavior is not consistent from day to day. One of them has an IRC bouncer hanging out on it because I used to spend a disproportionate amount of my time on Freenode. It does a whole bunch of different things that look super weird.

Every time I wind up pointing a typical security product at it, it starts shrieking its head off, if it can even get that far into it, of this thing is clearly exploited, shut it down, shut it down, shut it down. None of that happens. This thing looks very weird on the network. I'm not going to deny otherwise. This is my development box when I'm on the road. Remember back when we used to travel places and I would just be connecting

from an iPad and remoting into this thing. And then I would have it do all of the things I would normally do on a desktop computer, but it doesn't make noise. Now, to be clear, I also have a somewhat decent security posture on this thing, so it's not a story of it getting actively exploited, and it should be making noise, but it just doesn't say anything. It just sort of sits there quietly in the background, and it works. Whenever I log in, I have to click around to make sure it actually is still working, because there's nothing on the dashboard where it's just giving you noise to talk about noise. Why is this such a rarity? So your environment is probably pretty secure. I imagine you're not deploying, you know, hundreds and thousands of containers and EC2s and spinning up all this type of data, but...

No, it's tiny. I spend 50 bucks a month on this account. So it's not atypical, the behavior you see. I've been in POCs and proof of values where we deploy the extra hop and it doesn't see too much. And so one thing I've kind of started doing for a lot of my customers is deploying a lab for them. Do you trust that something like an extra hop will see ransomware? Do you trust that extra hop will see credential harvesting and lateral movement and exfiltration, or are you using your extra hop to troubleshoot your web applications? Let me spin up a lab for you, throw some workloads in there. We'll drop a Kali instance or a Kubernetes cluster and

show you what an attack surface can look like. Not to scare or kind of build on what customers are experiencing, but knock on wood, I don't want any of my customers to be attacked. But I also have to build that confidence that if or when something happens, they're covered. Back when I first had ExtraHop demoed for me, I was convinced it was going to be garbage. Let me be very honest with you. And the reason was that the dashboard looked like it was demo where it was well-designed, well-executed. It had a very colorful interface. It felt like bossware, if I'm being perfectly honest. My belief has always been that you either get a good interface that works and is easy to use and navigate within, or you get something that looks super flashy when

you do a demo on stage somewhere. But it is almost impossible to wind up effectively nailing both of those use cases. And then I started using this and I am having to eat those words because you actually did it. You wound up building something that looks great and is easy to navigate. How much work did that actually take? I mean, is that where all the engineering on this product is gone? We really appreciated our UX team and our engineering group work very, very hard. We spend more on R&D and research than we do on a lot of our marketing and front-end sectors, and it shows.

The product kind of speaks for itself, and the experience that you're kind of describing with the easy-to-consume UI, with the data to support that experience behind it, is our goal, and I'm happy to hear that you're enjoying it in your lab. Yeah, I just did a little poking around while I have you on the phone. If I dig deep enough, it does tell me that there are some weak ciphers in use, and every single one of these things is talking to an AWS-owned endpoint, which is, first, a little bit on the hilarious side, since I keep this thing current. Awesome. Secondly, the fact that I had to dig for that, and it wasn't freaking out about it. There are no alerts. It doesn't show up on the dashboard. I had to really start diving into this, because, yeah, it's good to know if I'm doing some sort of audit activity. It's good to know

if I need to dive in and look at these things. but it doesn't need to wake me up at two in the morning because holy crap, the Boto 3 library isn't quite using the latest Cypher suite. How much tuning did this take? Not much. So there is a learning period, as with any application that has a backend on behavioral analytics. But most of my customers, usually two to three weeks after we start seeing a data feed, are in a state of excellent tuning. Very little manual tuning required. The system will learn normalities. It'll learn behaviors, and it'll flag anomalies kind of on its own. So the same experience that you're having where if you're running a compliance scan or you're running an audit or you're trying to look for, in this world where I'm going to make a joke here, we all have free time and you have the time to go look at, you know, how do I clean up some of

these hygienic issues that are not currently causing me heartache? The data's there. You know, that's the beauty of the network is some of your users may be familiar with Wireshark or something like a TCP dump. There's boatloads of data in there. Thousands and thousands of data points you can analyze. So if you want the data, it's there. But like you said, no reason to wake you up at two in the morning unless we see things that are super critical. Encrypt everything sort of becomes the theme, especially when Amazon's CTO slaps it on a t-shirt and then in some cases charges extra for it.

But that's a diversion. What is the story as you start seeing more and more traffic wind up being encrypted at a bunch of different levels? In fact, I'll take it a step further. With the rise of customer managed keys and things like KMS in the AWS world, does that mean that ExtraHop is effectively losing visibility beyond just the typical TCP flow? So ExtraHop is unique in the space that we have the ability to decrypt TLS 1.3 data. It came out a couple years ago, and it's a way of encrypting traffic between servers and clients in a manner that isn't as breakable as historic kind of encryption mechanisms were. We can parse that data. We can ingest those decryption mechanisms. We can, in real time,

without being a man in real time, without being a man in the middle, so we're not breaking any of this trust chain that you have to explicitly build to the internet in a lot of cases, or you don't have to upload any of your private keys to the extra hub. So it's a super unique approach for how we can unpack that envelope. This kind of goes back to when we were kids and we all got those Christmas presents and you shake the box and you try to guess what's inside. And maybe you're right, maybe you're not. But until you open that wrapper, you can't really know what's being said. So something like a hidden database transaction underneath a web call just shows up as a web

call when you're not unpacking the envelope. So decryption is an underrated feature, in my opinion, and I would, you, and a true security posture team should probably have something where they can look inside those payloads. This is where it starts to get a little weird, too, because on some level, great, the whole premise of TLS is that my application talks to something far away or nearby, doesn't really matter. But there's a bit of a guarantee that from the point it leaves that application and hits the encryption side on the instance to the other end, there should be no decryption there. The only way I've ever seen that get around that is effectively man-in-the-middling these things, which in some level, oh, decrypt all of your secure traffic in the name of security

always felt a little on the silly side. Not only is it silly, it's a little harder to manage when we talk about cloud because those man-in-the-middle decryption mechanisms typically involve building explicit trust so that they can decrypt the traffic and then the client and the server both agree that, you know, yeah, sure, you can read my information. You use your own certificate. I don't care. That gets harder to do as you start talking about containers, as you start talking about ephemeral instances. Sure, you can build a golden image of a container and make it trust your IPS, which most people should have. But you still have to have the ability to see this traffic when you're bypassing certain metrics. If you're bypassing traffic back to your data center so you can consume your point of sale application,

or if maybe you're a multi-cloud environment where you have to pass from cloud to cloud to consume all of your data space. You still have to be able to see that data to understand what's really being said during a conversation without always being able to break that trust chain. One thing that I want to make very clear I call out, because otherwise I am going to get letters on this. This is a promoted episode. You folks have paid to sponsor it. Thank you. It is appreciated. But I want to be very clear. You buy my attention, not my opinion. I know I've been sort of gushing about what ExtraHop does and how it works and how I view these things, but that's not because you're paying me to do that. I am legitimately excited about the product itself. This is one of those things where it finally is giving me visibility into something

that I understand from my old and sysadmin network admin days, combined with how I know the cloud works today. And I'm looking at this and the strange spots that I see, ooh, I would improve that a bit. There aren't that many and they're not that big. This is something that is legitimately awesome. And I would encourage people to kick the tires and see what they think. Yeah, we appreciate that feedback, Corey. Where a lot of us are previous users, I myself came, you know, before coming to ExtraHop, used ExtraHop at a previous job.

And that was one of the big reasons I came to work for the company is I believe in the software. A lot of our people here and, you know, our long-time term employees believe in what we do. And our goal is to build this partnership and trust with our customers to, so that they have the same experience that you do. It's a fun product to play with and, you know, kicking around the tires is fun. We'd love to show you. When you start talking to folks who are going through their, I guess, extra hop journey of

discovery, don't ever use that term. It sounds awful. What do you find that they are getting the most confused about? What do they misunderstand that would be helpful for them to have more clarity around? There's a lot of what Xdrop can provide when it comes to data ingestion and data collection and even data aggregation. But where a lot of my customers kind of fall in the confusion space tends to be in, do I care about this data? You know, should I care about this information? And that really falls down to the individual user's responsibility. A security team cares about all of it, whereas an application team may only care about the

website's performance or the network latency or the error rates. And it kind of spans the gambit. So one thing that I do with a lot of my customers is weekly training sessions or give them access to videos that we've recorded in advance so they can kind of self-teach. As an engineer myself, I hate when people talk me into things. I like to play and I like to see. So let me give you a guide. You want to play with it, kind of poke the toes, kick the tires, have fun. That seems to get customers excited.

And again, back to that aha moment a lot quicker. There's so much data that gets exposed. And sometimes it can be overwhelming. But when it comes to visibility, it's all stuff that's useful at the end of the day. If people want to learn more, where could they go next? How do they begin this journey? And of course, mention me, just because every time someone talks to a sponsor and brings my name up, the reflexive wince is just my favorite look in the world.

Yeah, so definitely mention Corey's name. We have we have online demos where people can play with the lab. It's you go to xdrop.com slash demo. We also offer AWS trials if you want to actually deploy one and see what it looks like in your environment for a period of time. And we have teams all over the world from the United States and me at APAC

that are happy to help answer questions, help deploy, and kind of help automate a lot of this, whether it be through something like a CloudFormation template or Terraform scripts, whatever infrastructure as code language you choose to use. Excellent.

Thank you so much for taking the time to speak with me today. I really do appreciate it. Yeah, Corey, it's been a pleasure talking to you and looking forward to maybe having another one with you in the future. Oh, I would expect so. I'm curious to see what happens next. Guy Raz, Senior Systems Engineer at ExtraHop.

I'm Cloud Econom economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice

and an insulting comment that will no doubt get flagged by ExtraHop as being something that shouldn't be on the network. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

This has been a humble pod production stay humble