Screaming in the Cloud - Exciting Times in Cloud Security with Chris Farris

Episode Date: March 21, 2023

Chris Farris, Cloud Security Nerd at Turbot, joins Corey on Screaming in the Cloud to discuss the latest events in cloud security, which leads to an interesting analysis from Chris on how legal departments obscure valuable information that could lead to fewer security failures in the name of protecting company liability, and what the future of accountability for security failures looks like. Chris and Corey also discuss the newest dangers in cloud security and billing practices, and Chris describes his upcoming cloud security conference, fwd:cloudsec. About ChrisChris Farris has been in the IT field since 1994 primarily focused on Linux, networking, and security. For the last 8 years, he has focused on public-cloud and public-cloud security. He has built and evolved multiple cloud security programs for major media companies, focusing on enabling the broader security team’s objectives of secure design, incident response and vulnerability management. He has developed cloud security standards and baselines to provide risk-based guidance to development and operations teams. As a practitioner, he’s architected and implemented multiple serverless and traditional cloud applications focused on deployment, security, operations, and financial modeling.Chris now does cloud security research for Turbot and evangelizes for the open source tool Steampipe. He is one of the organizers of the fwd:cloudsec conference (https://fwdcloudsec.org) and has given multiple presentations at AWS conferences and BSides events.When not building things with AWS’s building blocks, he enjoys building Legos with his kid and figuring out what interesting part of the globe to travel to next. He opines on security and technology on Mastodon, Twitter and his website https://www.chrisfarris.comLinks Referenced:Turbot: https://turbot.com/fwd:cloudsec: https://fwdcloudsec.org/Mastodon: https://infosec.exchange/@jcfarrisPersonal website: https://chrisfarris.com

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. Welcome to Screaming in the Cloud. I'm Corey Quinn, and we are here today to learn exciting things, steal exciting secrets,

and make big trouble for moose and squirrel. Maybe that's the podcast. Maybe that's the KGB. We're not entirely sure. But I am joined once again by Chris Farris, cloud security nod at Turbot, which I will insist on pronouncing as Turbo. Chris, thanks for coming back. Thanks for having me. So it's been a little while, and it's been an uneventful time in cloud security, with nothing particularly noteworthy happening, not a whole lot of things

to point at, and honestly, we're just sort of scraping the bottom of the barrel for news, is what I wish I could say. But it isn't true. Instead, it's, oh, let's see what disastrous tire fire we have encountered this week. What's top of mind for you as we record this? I think the most interesting one I thought was, you know, going back and seeing the guilty plea from Nicholas Sharp, who formerly was an employee at Ubiquity and apparently had like came out in the press releases were he was leveraging root keys. He was leveraging lifecycle policies to suppress the CloudTrail logs. And then, of course, just doing dumb things like exfiltrating all of this data from his home IP address or exfiltrating it from his home through a VPN, which have accidentally dropped and then exposed his home IP address. Oops.

There's so much to dive into there because I am not in any way, shape or form saying that what he did was good or I endorse any of those things. And yeah, I think he belongs in prison for what he did. Let's be very clear on this. But I personally did not have a business relationship with him. I am, however, Ubiquity's customer. And after, whether it was an insider threat or whether it was someone external breaching them, Krebs on Security wound up doing a whole write-up on this

and was single-sourcing some stuff from the person who, it turned out, did this. And they made a lot of hay about this. They sued him at one point via some terrible law firm that entire brand is suing media companies. And yeah, just wonderful, wonderful optics there and brilliant plan. But I don't care about the sourcing. I don't care about the exact accuracy of the reporting, because what I'm seeing here is that what is not disputed is that this person who, whether they were an employee or not, was beside the point, deleted all of the audit logs. And then as a customer of Ubiquity, I received an email saying, we have no indication

or evidence that any customer data was misappropriated. Yeah, you turn off your logs and yeah, you could say that always and forever and save money on logging costs. Well, do best practice just dropped, I guess. Clowns. So, yeah, and there's definitely, like, compliance and standards and everything else that say you turn on your logs and you protect your logs. And service control policies should have been able to detect that. If they had a security operations center, you know, the fact that somebody was using root keys should have been setting off red flags and causing escalations to occur. And that wasn't happening. My business partner and I have access to our AWS org. And when I was

setting this stuff up for what we do here at a very small company, neither of us can log in with root credentials without alarms going off that alert the other. Not that I don't trust the man. Let's be very clear here. We both own the company. In business together, yes. Exactly. It is in many ways like a marriage in that one of us can absolutely ruin the other without a whole lot of effort. But there's still the idea of separation of duties, visibility into what's going on, and we don't use root API keys. Let me further point out that we are not pushing anything that requires you to send data to us.

We're not providing a service that is software-powered to people, much less one that is built around security. So how is it that I have a better security posture than Ubiquiti? You understand AWS and in-depth cloud better. It really comes down to how do you as a AWS customer understand all of the moving parts, all of the security tooling, all of the different ways that something can happen. And Amazon will say, well, it's in the documentation, but they have, what, 357 services?

Are you reading the security pages of all of those? So user education, I agree. You should have, and I have, on all of my accounts, if anything pops up, if any IAM change happens, I'm getting text messages, which is great if my account got compromised, but is really annoying when I'm actually making a change and my phone is blowing up. Yeah, it's worth pointing out as well that, yes, Ubiquity is publicly traded. That is understood and accepted. However, 93% of it is owned by their CEO founder, God King. So it is effectively one person's personal fiefdom. And I tend to take a very dim view as a direct result. When you're in cloud and you have

suffered a breach, you have severely screwed something up somewhere. These breaches are never someone stole a whole bunch of drives out of an AWS data center. They're that you have misconfigured something somewhere. And lashing out at people who reported on it is just a bad look. Definitely. Only error. Now, of course, part of the problem here is that our legal system encourages people to not come forward and say, I screwed up. anything. Don't say anything. Don't even tell the government. Don't say anything. Whereas we all need to learn from these errors, which is why I think every time I do see a breach or I do see an indictment, I start diving into it to learn more. I did a blog post on some of the things that happened with Drizzly and GitHub. And I think the most interesting thing that came out of the Drizzly case was the ex-CEO of Drizzly and GitHub. And, you know, I think the most interesting thing that came out of the Drizzly case was the ex-CEO of Drizzly, who was CEO at the time of the breach, now has following him for the

rest of his life, a FTC order that says he must implement a security program wherever he goes and works. You know, I don't know what happens when he becomes a Starbucks barista or whatever, but that is on him. That is not on the company. That is on him. And I do think that we will start seeing more and more chief executive officers, chief security or information security officers becoming accountable to or for the breaches and being personally accountable or professionally accountable for it. And I think we kind of need it, even though, you know, it's, there's only so much a CISO can do. One of the things that I did when I started consulting independently on AWS Bells back in 2016 was while I was looking at customer environments, I also would do a quick check for a few security baseline things. And I stopped doing it because I kept encountering a bunch of things that needed attention, and it completely derailed the entire stated purpose of the engagement.

And frankly, I don't want to be running a security consultancy. There's a reason I focus on AWS bills, and people think I'm kidding, but I swear to you I'm not, when I say that the reason is in part because no one has a middle-of-the-night billing emergency. It is strictly a business hours problem. Whereas with security, wake up. In fact, the one time I have been woken up in the

middle of the night by a customer phone call, they were freaking out because it was a security incident and their bill had just pegged through the stratosphere. It's cool. Fix the security problem first. Then we'll worry about the bill during business hours. Bye. And then I stopped leaving my phone off of Do Not Disturb at night. Your AWS bill is one of your indicators of compromise. Keep an eye on it. Oh, absolutely. We've had multiple engagements discover security issues on that. So what are these instances in Australia doing? We don't have anything there. I believe you are being sincere when you say this. Yes. However, last month you were at $1,000 and this month you're at $50,000. And oh, by the way, it's the ninth. So you might want to go look at that. Here's the problem that you start seeing

in large-scale companies, though. You or I wind up posting our IAM credentials on GitHub somewhere in public. And I do this from time to time intentionally with absolutely no permissions attached to a thing. And I just look at the timeline of, okay, three, two, one, go with the push. And now I start counting what happens at what time does the quarantine policy apply? When do I get an email alert? When do people start trying to exploit it from where are they trying to exploit it? It's a, it's a really interesting

thing to look into just from the position of how this stuff all fits together and works. And that's great. But there's a, there's a whole nother piece to it where if you or I were to do such a thing and actually give it admin credentials, okay, my, I don't know what, $50, $100 a month account that I use for a lot of my test stuff now starts getting charged enormous piles of money that, that winds up looking like a mortgage in San Francisco, I'm going to notice that. But if you have a company that's spending, I don't know, between $10 and $20 million a month, do you have any idea how much Bitcoin you've got to be mining in that account to even make a slight dent in the overall trajectory of those accounts?

In the overall bill, a lot. And a particularly mismanaged account, my experience is, is you will notice it if you're monitoring billing anomalies on a per-account basis. I think it's important to note, you talked about that quarantine policy. If you look at what actually Amazon drops a deny on, it's effectively start EC2 instances and change IAM policies. It doesn't prevent anybody from listing all your buckets and exfiltrating all your data. It doesn't prevent anybody from firing up Lambdas and other less commonly used resources. Don't assume, oh, Amazon dropped the quarantine policy, I'm safe. I was talking to someone who spends $4 a month on S3 and they wound up suddenly getting 60 grand a day in

Lambda charges because max out the Lambda concurrency in every region and set it to mine crypto for 15 minutes apiece. Yeah, you'll spend $60,000 a day to get, what, $500 in crypto, but it's super economical as long as it's in someone else's account. And then Amazon hits them with a straight face on these things where, please pay the bill, which is horrifying when there's several orders of magnitude difference between your normal bill and what happens post breach. But when I did my whole post on 17 ways to run containers on AWS, followed by 17 more ways to run containers on AWS, and I'm about three services away from having a third one ready to go on that. The point is not too many ways to run containers, because yes, that is true, and it's also amusing

to me, less so to the containers team at AWS, which does not have a sense of humor or sense of self-awareness of which they have been alerted. And fine, but every time you're running a container, it is a way to turn it into a crypto mining operation in some way, shape, or form, which means there are almost 40 some odd services now that can reasonably be used to spin up cryptocurrency mining. And that is the best case breach scenario in a bunch of ways. It costs a bunch of money and things to clean up, But we lost customer data that can destroy companies. Here's the worst part. Crypto mining is no longer profitable even when I've got stolen API keys because Bitcoin's in the toilet. So now they are going after different things. Actually,

the most recent one is they look to see if your account is out of the SES sandbox. And if so, they go back to the tried and true way of doing internet scams, which is email spam. For me, having worked in operations for a very long time, I've been in situations where I worked at Expansify and had access to customer data there. I have worked in other finance companies. I worked at BlackRock, where I work now. I have access to customer billing data. And let me be serious here for a second. I take all of these things seriously, but I also, in all of those roles, slept pretty well at night. The one that kept me up was a brief

stint I did as the director of tech ops at Grindr over 10 years ago. Because unlike the stuff where I'm spending the rest of my career and my time now, it's not just money anymore. Whereas today, if I get popped, someone can get access to what a bunch of companies are paying AWS. It's scandalous, and I will be sued into oblivion, and my company will not exist anymore, and I will have a cloud hanging over my head forever. So I have to be serious about it. Nobody will die. Nobody dies. Whereas, oh, this person is on Grindr and they're not out publicly or they live in a jurisdiction where that is punishable by imprisonment or death. You have blood on your hands on some level. And I have never wanted that kind of responsibility. Yeah, it's reasonably scary. I've always been happy to say that, you know, the worst thing that I had to do was keep the Russians off

CNN and my friends from downloading Rick and Morty. Exactly. It's, oh, heavens, you're winding up costing some giant conglomerate somewhere theoretical money on streaming subscriptions. It's not material to the state of the world. And part of it too is what's always informed my approach to things is I'm not a data hoarder in the way that it seems our entire industry is. For the last week in AWS newsletter, the data that I collect and track is pretty freaking small. It's you want to sign up for the last week in AWS.com newsletter. Great. I need your email address. I don't need your name. I don't need the company you work at. You want to give me a tagged email address. Fine. You want to give me some special

address that goes through some anonymizing thing. Terrific. I need to know where I'm sending the newsletter. And then I run a query on that for metrics sometimes, which is this really sophisticated database query called a count. How many subscribers do I have at any given point? Because that matters to our sponsors. But can we get you give us any demographic? No, I cannot. I can't. I have people who follow out surveys sometimes and that's it. And you're able to make money doing cannot. I can't. I have people who follow up surveys sometimes and that's it. And you're able to make money doing that. You don't have to collect, okay, you know, Chris's zip code is this and Bob's zip code is that and Frank's zip code is the other thing. Exactly. Or job titles or, you know, our mother's maiden name or anything else like that.

I talk about what's going on in the world of AWS. So it sort of seems to me that if you're reading this stuff every week, either because of the humor or in spite of the humor, you probably are in a position where services and goods tied to that ecosystem would be well-received by you or one of the other 32,000 people who happen to be reading the newsletter or listening to the podcast or et cetera, et cetera, et cetera. It's an old timey business model. It's okay. I want to wind up selling, I don't know, expensive wristwatches. Well, maybe I'll advertise in a magazine that caters to people who have an interest in wristwatches or caters to a demographic that traditionally buys those wristwatches.

And OK, we'll run an ad campaign and see if it works. It's been traditional advertising, not the micro targeting stuff. And, you know, television was the same way back in the broadcast era. You know, you watched a particular show. People of that demographic who watch that particular show had certain advertisers they wanted. And part of the challenge I've seen, too, from sponsors of this show, for example, is they know it works, but they're trying to figure out how to do any form of attribution

on this. And my answer, which sounds self-serving, but it's true, is there's no effective way to do it. Because every time you try, like, enter this coupon code. Yeah, I assure you, some of these things wind up costing millions of dollars to deploy at large companies at scale, and they provide value for doing it. No one's going to punch in a coupon code to get 10% off of something like that. Procurement is going to negotiate custom contracts, and it's going to be brought up maybe by someone who heard the podcast ad. Maybe it just

sits in the back of their mind until they hear something, and it just winds up contributing to a growing awareness of these things. You're never going to do attribution that works on things like that. People try sometimes to, oh, you'll get $25 in credit, or we'll give you a free t-shirt if you fill out the form. Yeah, but now you're biasing for people who find that a material motivator. When I'm debating what security suite I'm going to roll out at my enterprise, I don't want a free t-shirt for that. In fact, if I get a free t-shirt and I wear

that shirt from the vendor around the office while I'm trying to champion bringing that thing in, I look a little compromised. Yeah. Yeah. I got no response to that. No, no. I hear you. One thing I do want to talk about is when last time we spoke, you mentioned you were involved in getting Forward CloudSec, a conference off the ground. Like all good cloud security conferences, it's named after an email subject line. It is co-located with Reinforce this year in Anaheim, California. Somewhat ominously enough, I used to live a block and a half away from the venue, but I don't anymore.

And in fact, because nobody checks the global event list when they schedule these things, I will be on the other side of the world officiating a wedding the same day. So yet again, I will not be at Reinforce. So yes, Forward CloudSec is deliberately actually named after a subject line because all of the other Amazon conferences seem to be that way. And we didn't want to be going backwards and thinking, you know, past tense. We were looking forward to our conference. Yeah, so we're effectively a vendor-neutral cloud security conference. We like the idea of being able to take the talks that Amazon PR would never allow on stage at Reinforce and run with it. I would question that. I do want to call that out because I gave a talk at Reinvent one year about a vulnerability I found and reported with the help of two other people, Scott Piper and

Brendan Sherman, to the AWS security team. And we were able to talk about that on stage with Zach Glick, who at the time was one of basically God's own prototypes working over in the AWS environment next to Dan Erson. Now Dan remains the salt of the earth. And if he ever leaves, basically just short the entire US economy, it's easier. He is amazing. I digress. The point being is that they were very open about talking about an awful lot of stuff that I would never have expected that they would be okay with. And last year at Reinforce, they had an excellent, excellent chalk talk, but it was a chalk talk, not recorded, on how ransomware attacks operate. And they actually revealed some internal,

very anonymized patterns of how attacks are working. So they're starting to realize what we've been saying in the cloud security community for a while, which is we need more legitimate threat intelligence. On the other hand, they don't want to call it threat intelligence because the word threat is threatening and therefore we're going to just call it, you know, patterns or whatever. And our conference is, again, also multi-cloud, a concept that until recently, AWS, you know, didn't really want to acknowledge that there were other clouds and that people would use both. Multi-cloud security is a nightmare. It's just awful. Yeah, I don't like multicloud, but I've come to realize that it is a thing. That you will either start at a company that

says, we're AWS and we're unicloud, and the next thing you know, either some rogue developer out there has gone and spun up an Azure subscription or you acquire somebody who's in GCP or, heaven forbid, you have to go into some, you know, tin horn dictator's jurisdiction, and they require you to be on-prem or leverage Oracle Cloud or something. And suddenly, congratulations, you're now multi-cloud. So yes, our goal is really to be the things that aren't necessarily on stage or aren't all just, it's great. Even your talk was how great the incident response and vulnerability remediation process was.

How great my experience with it was at the time, to be clear. Because I also have gotten to a point where I am very aware that in many cases when dealing with AWS, my reputation precedes me. So when I wind up tweeting about a problem or opening a support case, I do not accept as a given that my experience is what everyone is going to experience. But a lot of the things they did made a lot of sense. And I was frankly impressed that they were willing to just talk about anything that they did internally. Because previously that had not been a thing that they did in open forums like that. But you go back to the Glue incident, where somebody found a bug, and they literally went and went to every single CloudTrail event, going back to the dawn of the service,

to validate that, okay, the only two times we ever saw this happen were between the two researchers' accounts who disclosed it. And so kudos to them for that level of forward communication to their customers, because yeah, I think we still haven't heard anything out of Azure for last year's or a year and a half ago's whiz findings. Well, they did do a broad blog post about this that they put out, which I thought, okay, that was great. More of this, please. Because until they start talking about security issues

and culture and the remediation thereof, I don't give a shit what they have to say about almost anything else because it all comes back to security. The only things I use Azure for, which admittedly has some great stuff, the computer vision API, brilliant. But the things I use them for are things that I start from a premise of security is not important to that service. The thing I use it for on the soon to be pivoted to Mastodon Twitter thread client that I

built, it writes alt text for images that are about to be put out publicly. Yeah, there's no security issue from that perspective. I am very hard-pressed to imagine a scenario in which that were not true. I can come up with a couple, but you know. It feels really contrived. And honestly, that's the thing that concerns me too. The fact that I finally read somewhat recently an AWS white paper talking about, was it a white paper or was it a blog post? I forget the exact media that it took, but it was about how they're seeing ransomware attacks on S3, which was huge because before that, I assumed it was something that was being made up by vendors to sell me something. So that was the chalk talk. They finally got the chalk talk from Reinforce. They gave it again at Reinvent because it was so well received.

And now they have it as a blog post out there so that, you know, it's not just for people who show up in the room. They can hear it. It's actually now documented out there. And so kudos to the Amazon security team for really getting that sort of threat intelligence out there to the community. Now it's in writing, and that's something that I can cite as opposed to, well, I was at reInvent and I heard, yeah, we saw the drink tab. We know what you might have thought you heard or saw at reInvent. Give us something we can take to the board. There were a lot of us on that bar tab, so it's not all you.

Exactly. And it was my pleasure to do it, to be board. There were a lot of us on that bar tab, so it's not all you. Exactly. And it was my pleasure to do it, to be clear. But getting back to forward CloudSec, I'm going to do you a favor, whether it's an actual favor or the word favor belongs in quotes. The way that I submit CFPs or conference talks is optimized because I don't want to build a talk that is never going to get picked up. Why bother to go through all the work until I have to give it somewhere? So I start with a catchy title and then three to five sentences. And if people accept it, great. Then I get to build the talk. This is a forcing function in some ways, because if you get a little delayed, they will not move the conference for you. I've checked. But the title of a talk that I think someone should submit for Forward CloudSec is, I am smarter than you, so cloud security is easy. And the format and the conceit of the talk is presented with sort of a stand it up, take it down level of approach, where you are overconfident in the fact that you are smarter than everyone else and best practices don't apply to you. And

so much of this stuff is just security theater designed as a revenue extraction mechanism, as opposed to something you should actually be doing. And talk about why none of these things matter because you use good security and you know it's good because you came up with it. And there's no way that you could come up with something that you couldn't break because you're smart. That says so right in the title and you're on stage and you have a microphone. They don't turn that into something. I feel like there's a great way to turn that in a bunch of different directions. I'd love to see someone give that talk. I think Nicholas Sharp thought that too. Exactly. In fact, that would be a great way to bring it back around at the end. And it's like, and that's why I am better

at security than you are. If you have any questions beyond this, you can reach me at whatever correctional institute I go in on Thursday. Exactly. There's ways to make it fun and engaging. Because from my perspective, talks have to be entertaining or people don't pay attention. They're either entertaining or they're so new and advanced. We are definitely an advanced cloud security practice thing. We're 500 levels. Not to brag or anything, but you want the 200 to 300 level stuff,

you can go see CJ up the street. We're hitting and going above and beyond what a lot of the... I am not as advanced on that path as you are. I want to be very clear on this. You speak, I listen. You're one of those people when it comes to security. Because again, no one's life is hanging in the balance with

respect to what I do. I am confident in our security posture here, but nothing's perfect. Everything is exploitable on some level. It's also not my core area of focus. It is yours. And if you are not better than I am at this, then I have done something sort of strange, or so have you, in the same way that it is a near certainty, but not absolute, that I am better at optimizing AWS bills than you are. Specialists exist for a reason, and to discount that expertise is the peak of hubris. Put that in your talk. Yeah. Yeah, so one talk I really want to see, and I've been threatening to give it for a while, is, okay, if there's 17 ways, or sorry, 17 times 2, soon to be 17 times 3 ways to run containers in AWS, there is how credentials can be exfiltrated so that we then as defenders can go figure out, okay, how do we build detections and mitigations for this? I'm a huge fan of canary tokens myself for that exact purpose. There are many devices I

have where the only credentials in plain text on disk are things that as soon as they get used, I wind up with a bunch of things screaming at me that there's been a problem and telling me where it is. I'm not saying that my posture is impenetrable, far from it. But you're going to have to work for it a little bit harder than running some random off-the-shelf security scanner against my AWS account and finding, oops, I forgot to turn on a bucket protection. And the other area that I think is getting really interesting is all of the things that have credentials into your cloud account, whether it's something like CircleCI or GitHub. I was having a conversation with somebody just this morning, and we were talking about roles anywhere. And I was like, roles anywhere is great if you've got a good, strong PKI solution and can keep that private certificate or that certificate you need safe.

If you just put it on a disk, like you would have put your AKIA and Secret on a disk, congratulations, you haven't really improved security. You've just gotten rid of the IAM users that are being flagged in your CSPM tool, and congratulations, you have in fact achieved security theater. It's obnoxious on some level. And part of the problem is constant security are aligned in that people care about them right after they really should have cared about them. The difference is, is you can beg, cry, whine, et cetera, to AWS for concessions. You can raise another round of funding.

There are solutions with money, but security, that ship has already sailed. Yeah. Once the data's out, the data's out. Now, I will say on the bill, you get reminded of it every month about three or four days after. It's like, oh, crap. Yeah, I should have turned off that EC2 instance. I just burned $100. Or, oh, hey, we didn't turn off that application. I just burned $100,000. That doesn't happen on security. Security events tend to be few and far between. They're just much bigger when they happen. I really want to thank you for taking the time to chat with me. I'm sure I'll have you back on between now and Reinforce slash Forward Cloud SAC or anything else we come up with that resembles an email subject line. If people

want to learn more and follow along with your adventures as they should, where's the best place for them to find you these days? So I am now pretty much living on Mastodon on the InfoSec Exchange. And my website, chrisfarris.com is where you can find the link to that because it's not just at, you know, whatever you have to give a whole big long URL in Mastodon. It's no longer. Yeah. So it's like a-on email address with weird domains. Exactly, yes. Find me at http://infosec.exchange slash at jcferris or just hit Chris Ferris and follow

the links. For Forward CloudSec, we are conveniently located at forwardcloudsec.org, which is fwdcloudsec.org. No colons because I don't think those are valid in Whois. Excellent choice. And of course, links to that go in the show notes, so click the button. It's easier.

Thanks again for your time. I really appreciate it. Thank you. Chris Ferris, cloud security nerd at Turbot slash Turbo. I'm cloud 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, along with an angry comment that resembles a lawsuit being filed and then have it process served to me because presumably you work at Ubiquity. 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.