Screaming in the Cloud - Creating an API Security Solution at FireTail with Jeremy Snyder

Episode Date: June 20, 2023

Jeremy Snyder, Founder of FireTail, joins Corey on Screaming in the Cloud to discuss his career journey and what led him to start FireTail. Jeremy reveals what’s changed in cloud since he was an AE and AWS, and walks through how the need for customization in cloud security has led to a boom in the number of security companies out there. Corey and Jeremy also discuss the costs of cloud security, and Jeremy points out some of his observations in the world of cloud security pricing and packaging. About JeremyJeremy is the founder and CEO of FireTail.io, an end-to-end API security startup. Prior to FireTail, Jeremy worked in M&A at Rapid7, a global cyber leader, where he worked on the acquisitions of 3 companies during the pandemic. Jeremy previously led sales at DivvyCloud, one of the earliest cloud security posture management companies, and also led AWS sales in southeast Asia. Jeremy started his career with 13 years in cyber and IT operations. Jeremy has an MBA from Mason, a BA in computational linguistics from UNC, and has completed additional studies in Finland at Aalto University. Jeremy speaks 5 languages and has lived in 5 countries. Once, Jeremy went 5 days without seeing another human, but saw plenty of reindeer.Links Referenced:Firetail: https://firetail.ioEmail: [e-mail]

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.

My guest today is Jeremy Snyder, who's the founder at Firetail. Jeremy, thank you for joining me today. I appreciate you taking the time from your day to suffer my slings and arrows. My pleasure, Corey. I'm really happy to be here. So we'll get to a point where we talk about what you're up to these days. But first, I want to dive into the jobs of yesteryear. Because over a decade ago, you did a stint at AWS doing sales. And not to besmirch your hard work, but it feels like at the time that must have been a very easy job

because back then it really felt across the board. Like the sales motion was basically responding to, well, why should we do business with you? And the response is, oh, you misunderstand. You have 87 different accounts scattered throughout your organization. I'm just here to give you visibility, governance, and possibly some discounting over that.

It feels like times have changed in a lot of ways since then. Is that accurate? Well, yeah, but I will correct a couple things in there. In my days, almost nobody had more than one account. I was in the one account, no VPCs, you only separate your workloads by tagging days of AWS. So our job was a lot actually harder at the time because people couldn't wrap their heads around the lack of subnetting, the lack of workload segregation. All of that was really like brand new to people. And so you're trying to tell them like, hey, you're going to be launching

something on an EC2 instance that's in the same subnet as everybody else's EC2 instance. And people were really worried about lateral traffic and sniffing and what could their neighbors or other customers on AWS see. And by the way, I mean, this was the customers who even believed it was real. You know, a lot of the conversations we went into with people was, oh, so Amazon bought too many servers and you're trying to sell us excess capacity. That legend refuses to die. And, you know, it is a legend that is not at all the genesis of AWS. And, you know, the genesis is pretty well publicized at this point. You can go just Google, how did AWS start? And

you can find accurate stuff around that. I did it a few years ago with multiple Amazon execs and published it. And they said definitively that that story was not true. And you can say a lot about AWS folks. And I assure you, I do. But I also do not catch them lying to my face ever. And as soon as that changes, well, now we're going to have a different series of conversations that are a lot more pointed. But they've earned some trust there. Yeah, I would agree. And I mean, look, I saw it internally, the way that Amazon built stuff was at such a breakneck pace, that challenge that they had that was, you know, the published version of events for why AWS got created, developers needed a place to test code. And that was something that they could not get

until they got EC2 or could not get in a reasonably enough timeframe for it to be, you know, real-time valid or relevant for what was going on with the company. So, you know, that really is the genesis of things. And, you know, the early services, SQS, S3, EC2, they all really came out of that journey. But yeah, in our days at AWS, there was a lot of ease in the sense that lots of customers had pent up frustrations with their data center providers or their colo providers. And lots of customers would experience bursts, and they would have capacity constraints, and they would need a lot of the features that AWS offered. But we had to overcome a lot of technical misunderstandings and trust issues. And, you know, oh, hey, Amazon just wants to sniff our data and they want to see what we're up to and

explain to them how encryption works and why they have their own keys and all these things. We had to go through a lot of that. So it wasn't super easy, but there was some element of it where just demand actually did make some aspects easy. What have you seen change since, I guess, 10 years ago and change now? And let's be clear, you don't work in AWS sales, but you also are not oblivious to what the market is doing. For sure, for sure. I left AWS in 2011, and I've stayed in the cloud ecosystem pretty much ever since. I did spend some time working for a system integrator, where all we did was migrate customers to AWS. And then I spent about five, six years working on cloud security, primarily focused on AWS, a lot of GCP, a little bit of Azure. So yeah, I mean, I certainly stay

up to date with what's going on in the state of cloud. I mean, look, cloud has evolved from this kind of, you know, developer centric, very easy to launch type of platform into a fully fledged enterprise IT platform. And all of the management structures and all of the kind of bells and whistles that you would want, that you probably wanted from your old VMware networks, but never really got, they're all there now. It is a very different ballgame in terms of what the platform actually enables you to do. But fundamentally, a lot of the core building block constructs and the primitives are still kind of driving the heart of it. It's just a lot of nicer packaging. What I think is really interesting is actually how customers' usage of cloud platforms has changed over time. And it kind of I always think of it in kind of like the going back to my days, what did I see

from my customers? And it was kind of like the month zero, I just don't believe you. Like this thing can't be real. I don't trust it, etc. Month one is I'm going to assign some developer to work on some very low priority, low risk workload. In my days, that was SharePoint, by the way, like nine times out of 10. The first workload that customers stood up was a SharePoint instance that they had to share across multiple locations. It falls over all the time anyway.

May as well put it in the cloud where it can do so without taking too much else down with it. Was that the thinking or? Well, and the other thing about it at the time, Corey, was that like so many customers weren't in this like remote first world, right? And so SharePoint was inevitably hosted at somebody's office. And so the workers at that office were so privileged

over the workers everywhere else. The performance gap between consuming SharePoint in one location versus another was like night and day. So, you know, employees in headquarters were like, yeah, SharePoint's great. Employees in branch offices were like, this thing is terrible. You know, it's so slow. I hate it. I hate it. I hate it. And so cloud actually became like this neutral location to move SharePoint to that kind of had equal performance for every office. And so that was, I think, one of the reasons. And it was also, you know, had capacity problems and customers were right at that point, uploading tons of static documents to it, like Word documents, Office attachments, et cetera. And so they were starting to have some of these like real disk sprawl problems with SharePoint. So that was kind of the month one

problem. And only after they get through kind of month two, three, and four, and they go through, I don't understand my bill and help me understand security implications. Then they think about like, should we go back and look at how we're running that SharePoint stuff and maybe do it more efficiently and like move those static Office documents onto S3 and so on and so on. And that's kind of one of the big things that I've changed that I would say is very different from like 2011 to now is there's enough sophistication around understanding that like you don't just translate what you're doing in your office or in your data center to what you're doing on cloud. Or if you do, you're not getting the most out of your investment.

I'm curious to get your take on how you have seen cloud adoption patterns differ, specifically tied to geo. I mean, I tend to see it from a world where there's a bifurcation between born-in-the-cloud SaaS-type companies where one workload is 80% of their bill or whatnot, and the big enterprises where the largest single component is 3%. So it's a very different slice there.

But I'm curious what you would see from a sales perspective, looking across a lot of different geographic boundaries, because we're all on some level biased based upon where we tend to spend our time doing business. I'm in San Francisco, which is its very own strange universe that has a certain perspective about itself that is occasionally accurate, but not usually. But it's a big world out there. It is. And one thing that I would say is interesting, I spent my AWS days based in Singapore, living in Singapore at the time, and I was working with customers across Southeast Asia. And to your point, Corey, one of the most interesting things was this little bit of a leapfrog effect. Data centers in Asia, especially in places like the Philippines,

were just terrible. The Philippines had the second highest electricity rates in Asia at the time, only behind Japan, even though the GDP per capita gap between those two countries is really large, and yet you're paying these super high electricity rates. Secondarily, data centers in the Philippines were prone to flooding. And so a lot of companies in the Philippines never went the data center route. You know, they just hosted servers in their offices. You know, they had a bunch of desktop machines in a cubicle, that kind of situation, because like data centers themselves were cost prohibitive. So you saw this effect a little bit like cell phones in a lot of the developing world. Landline infrastructure was too expensive or never got done for whatever

reason, and people went straight to cell phones. So actually what I saw in a lot of emerging markets in Asia was, screw the data center, we're going to go straight to cloud. So I saw a lot of Asia pack get a little bit ahead of places like Europe, where you had, for instance, a lot of long-term data center contracts, and you had customers really locked in. And we saw this over the next, let's say, between, let's say, 2014 and 2018, when I was working with a systems integrator and then started working on cloud security. We saw that US customers and Asia-Pac customers didn't have these obligations. European customers, a lot of them were still working off their't have these obligations, European customers, a lot of them were still working off their lease.

And still, you know, I'm locked into, let's just say, Equinix Frankfurt for another five years before I can think about cloud migration. So that's definitely one aspect that I observed. Second thing I think is like, the earlier you started, the earlier you reach the point where you realize that actually there is value in a lot of managed services. And there actually is value in getting away from the kind of server mindset around EC2. It feels like there's a lot of, I want to call it legacy thinking in some ways, except that's unfair because legacy remains a condescending engineering term for something that makes money. The problem that you have is that you get bound by choices you didn't necessarily realize you were making, and then something becomes revenue-bearing. And now there's a different way to do it, or you learn more about

the platform, or the platform itself evolves. And, oh, I'm going to rewrite everything to take advantage of this, isn't happening. So it winds up feeling like, yay, we're treating the cloud like a data center. And sometimes that's right. Sometimes that's a problem. But ultimately, it still becomes a significant challenge. I mean, there's no way around it. And I don't know what the right answer is. I don't know what the fix is going to be. But it always feels like I'm doing something wrong somewhere.

I think a lot of customers go through that same set of feelings and they realize that they have the active runway problem where, you know, how do you do maintenance on an active runway? You kind of can't because you've got flights going in and out. And I think you're seeing this in your part of the world at SFO with a lot of the work that got done in like 2018, 2019, where they kind of had to close down a runway and had like near misses because they consolidated all flights onto the one active runway, right? It is a challenge.

And I actually think that some of the evolution that I've seen our customers go through over the last two, three years is starting to get away from that challenge. So to your point, when you have revenue-bearing workloads that you can't really modify and things are pretty tightly coupled, it is very hard to make change. But when you start to have it where things are broken down into more microservices, it makes it a lot easier to cycle out service A for service B,

or let's say more accurately, service A1 with service A2, where you can kind of just like plug and play different APIs and maybe, you know, repoint services at the new stuff as they come online. But getting to that point is definitely a painful process. It does require architectural changes. And often those architectural changes aren't at the infrastructure level. They're actually inside the application or they're between things like applications and third-party dependencies where the customers may not have full control over the dependencies.

And that does become a real challenge for people to break down and start to attack. and third-party dependencies where the customers may not have full control over the dependencies. And that does become a real challenge for people to break down and start to attack. You've heard of the Strangler methodology? Oh, yes. Both in terms of the Boston Strangler as well as the Strangler design pattern. Yeah, yeah. But I think getting to that is challenging. And so once you understand that you want to do that, it makes a lot of sense.

But getting to the starting point for that journey can be really challenging for a lot of customers because it involves stakeholders that are often not involved on infrastructure conversations. And organizational dysfunction can really creep in there, where you have teams that don't necessarily play nice together, not for any particular reason, but just because historically, they haven't had to. So that's something that I've seen and definitely takes a little bit of cultural work to overcome. When you take a look across the board of cloud adoption, it's interesting to have seen the patterns that wound up unfolding. Your career path, though, seemed to have gotten away from the selling cloud and into some strange directions, leading you to what you're doing now, where you founded Firetail. What do you folks do?

We do API security. And it really is kind of the culmination of the last several years and what we saw. I mean, to your point, we saw customers going through kind of phase one, two, three of cloud adoption. Phase one, the, you know, for lack of a better phrase, lift and shift. And phase two, the kind of first step on the path towards quote unquote enlightenment, where they start to see that like, actually we can get better operational efficiency if we, you know, move our databases off of EC2

and onto RDS and we move our static content on S3. And then phase three, where they realize actually EC2 kind of sucks. And it's a lot of management overhead. It's a lot of attack surface. I hate having to bake AMIs. What I really want to do is just drop some code on a platform and run my application. And that might be serverless, that might be containerized, etc. But one path or the other where we pretty much always see customers ending up is with an API sitting on a network. And that API is doing two things. It front ends a data set and it front ends a set of functionality in most cases. And so what that really means is that the thing that sits on the network that does represent the attack surface, both in terms of

accessing data or in terms of, let's say, abusing an application is an API. And that's what led us to where I am today, what led me and my co-founder, Riley, to start the company and try to make it easier for customers to build more secure APIs. So yeah, that's kind of the change that I've observed over the last few years that really, as you said, led to what I'm doing now. There's a lot of, I guess, challenge in the entire space when we bound that to even API security, though as soon as you start going down the security path, it starts seeming like there's a massive problem,

just in terms of proliferation of companies that each do different things, that each focus on different parts of the story. It feels like everything winds up spitting out huge amounts of security focused, or at least security adjacent telemetry. Everything has findings on top of that, at least in the AWS universe.

Oh, we have a service that spits out a lot of that stuff. We're going to launch another service on top of it that, of course, costs more money that then winds up organizing it for you. And then another service on top of that that does the same thing yet again. And it feels like we're building a tower of these things that are just, shouldn't this all just be a feature in the original underlying thing that turns down the noise? Well, yes, but then we couldn't sell you three more

things around it. Agree? Disagree? I don't entirely disagree. I think there is a lot of validity in what you just said there. I mean, if you look at like the proliferation of even the security services and you see GuardDuty and Config and Security Hub or things like log analysis with Athena or log analysis with an Elk stack or OpenSearch, et cetera. I mean, you see all these proliferation of services around that. I do think the thing to bear in mind is that for most customers, like security is not a one size fits all. Security is fundamentally kind of a risk management exercise, right? If it wasn't a risk management exercise, then all security would really be about is like keeping your data off of networks and making sure that like none of your data could ever leave. But that's not how companies work. They do interact with the outside world. And so then you kind of always have this decision

and this trade-off to make about how much data you expose. And so when you have that decision, then it leads you down a path of determining what data is important to your organization and what would be most critical if it were breached. And so the point of all that is honestly that security is not the same for you as it is for me.

Right. And so to that end, you might be all about security hub and config and a set of basic checks across all your accounts and all your active regions. And I might be much more about, let's say I'm quote unquote, digital native, cloud native, blah, blah, blah. I really care about detection and response on top of events. And so I only care about log aggregation and let's say guard duty or Athena analysis on top of that because I feel like I've got all of my security configurations and infrastructure

as code. So there's not a right and wrong answer. And I do think that's part of why there are a gazillion security services out there. On some level, I've been of the opinion for a while now that the cloud providers themselves should not necessarily be selling security services directly because on some level that becomes an inherent conflict of interest. Why make the underlying platform more secure or easier to use from a security standpoint when you can now turn that into a revenue source? I used to make comments that Microsoft Defender was a classic example of getting this right because they didn't charge for it.

And a bunch of antivirus companies screamed and whined about it. And then, of course, Microsoft's like, oh, Corey's saying nice things about us. We can't have that. And they started charging for it. So, OK, that more or less completely subverts my entire point, but it still feels squeaky. I mean, I kind of doubt that's why they started charging for it, but. Oh, I refuse to accept that I'm not that influential, but there we are. Fair enough. Yeah, I just can't get away from the idea that it feels squeaky when the company providing the

infrastructure now makes doing the secure thing on top of it into an investment decision. Yeah. Do you want the crappy, insecure version of what we build? Or do you want the top-of-the-line, secure version? That shouldn't be a choice people have to make. Because people don't care about security until right after. They really should have cared about security. Yeah.

Look, and I think the changes to S3 configuration, for instance, kind of bear out your point. Like, it shouldn't be the case that you have to go through a lot of extra steps to not make your S3 configuration, for instance, kind of bear out your point. Like it shouldn't be the case that you have to go through a lot of extra steps to not make your S3 data public. It should always be the case that like you have to go through a lot of steps if you want to expose your data. And then you have explicitly made a set of choices on your own to make some data public, right? So I kind of agree with that, with the underlying logic. I think the counter argument, if there is one to be made, is that it's not up to them to define what is and is not right for your organization. Because again, going back to my example, what is secure for you may not be

secure for me because we might have very different modes of operation. We might have very different modes of building our infrastructure, deploying our infrastructure, et cetera. And I think every cloud provider would tell you, hey, we're just here to enable customers. Now, do I think that they could be doing more? Do I think that they could have more secure defaults, you know, in general? Yes, of course, they could. And really, like, the fundamentals of what I worry about are people building insecure applications, not so much people deploying infrastructure with bad configurations.

It's funny we talk about this now. Earlier today, I was lamenting some of the detritus from some of my earlier builds where I've been running some of these things in my old legacy single account for a while now. And the build service is dramatically overscoped, just because trying to get the security permissions right was an exercise in frustration at the time. It was, nope, that's not it. Nope, blocked again. So I finally said to hell with it,

overscope it massively, and then with a to-do, fix this later, which of course never happened. And if there's ever a breach on something like that, I know that I'll have AWS wagging its finger at me and talking about the shared responsibility model. But it's really kind of a disaster plan of their own making because there's not a great way to say easily and explicitly or honestly by default the way Google Cloud does of, okay, by default, everything in this project can talk to everything in this project, but the outside world can't talk to any of it, which I think is where a lot of people start off. And the security purists love to say, that's terrible. That won't work at a bank. You're right, it won't. But a bank has a dedicated security apparatus internally that can address those things, whereas your

individual student learner does not. And that's how you wind up with open S3 bucket monstrosities left and right. And I think a lot of security fundamentalists would say that what you just described about that Google project structure defeats zero trust. And, you know, that on its own is actually a bad thing. I might counter argue and say that, like, hey, you can have a GCP project as a zero trust, like first principle, you know, that can be the building block of zero trust for your organization. And then it's up to you to explicitly create these trust relationships to other projects and so on. But the thing that I think in what you said that really kind of does resonate with me

in particular as an area that AWS, and really in this case, just AWS, should have done better or should do better is IAM permissions. Because every developer in the world that I know has had that exact experience that you described, which is they get to a point where they're like, okay, this thing isn't working.

It's probably something with IAM. And then they try one thing, two things, and usually on the third or fourth try, they end up with a star permission. And maybe a comment in that IAM policy or maybe a JIRA ticket that gets filed into backlog of review those permissions at some point in the future, which pretty much never happens.

So IAM in particular, I think, is one where Amazon should do better or should at least make it easy for us to kind of graphically build an IAM policy that is scoped to least permissions required, etc. That one, I 100% agree with your comments and your statement. As you take a look across the largest, I guess, environments you see, and as well as some of the folks

who are just getting started in this space, it feels like on some level, it's two different universes. Do you see points of commonality? Do you see that there is an opportunity to get the individual learner who's just starting on their cloud journey to do things that make sense without breaking the bank that they then can basically have instilled in them as they start scaling up as they enter corporate environments where security budgets are different orders of magnitude? Because it seems to me that

my options for everything that I've looked at start at tens of thousands of dollars a year, or are a bunch of crappy things I find on GitHub somewhere. And it feels like there should be something between those two. In terms of training or in terms of like tooling? In terms of security software across the board, which I know is sort of a vague term. I first discovered this when trying to find something to make sense of CloudTrail logs. It was a bunch of sketchy things off of GitHub or a bunch of very expensive products. Same thing with VPC flow logs. Same thing with trying to parse other security alerting and aggregate things in a sensible way. Like very often it's, oh, there's a few very damning log lines surrounded by a million lines of nonsense

that no one's going to look through. It's a needle in a haystack problem. Yeah. Well, I'm really sorry if you spent much time trying to analyze VPC flow logs, because that is just an exercise in futility. First of all, the level of information that's in them is pretty useless. And the SLA on actually like log delivery, A, whether it'll actually happen, and B, whether it'll happen in a timely fashion is just pretty much non-existent. So from a security perspective, I agree wholeheartedly. But remember, I'm coming from a billing perspective where it's fair. We're taking a petabyte in and moving 300 petabytes between availability zones.

It's great. It's a fun game called find whatever's chatty, because on some level, it's like run two of whatever that is or three rather than having it replicate. What is the deal here? And just trying to identify, especially in the Godforsaken hellscape that is Kubernetes, what is that thing that's talking? And sometimes flow logs are the only real tool you've got other than oral freaking tradition.

But God forbid you forgot to tag your ENI so that the flow log can actually be attributed to what workload is responsible for it behind the scenes. So yeah, I mean, I think that's a, boy, that's a case study in like a miserable job that I don't think anybody would really want to have in this day and age. The timing of this is apt. I sent out my newsletter for the week a couple hours before this recording.

And in the bottom section, I asked anyone who's got an interesting solution for solving what's talking to what with DPC flow logs, please let me know. Because I found this original thing that AWS put up as part of their workshops in a lab to figure this out. But other than that, it's more or less guess and check. What is the hotness? It's been a while since I explored the landscape. And now we see if the audience is helpful or disappoints me. It's all on you, folks.

Isn't the hotness to segregate every microservice into an account and run it through a load balancer so then it's much more properly tagged and it's also consumable on an account by account basis for better attribution. And then everything you see winds up incurring a direct fee when passing through that load balancer instead of the same thing within the same subnet being able to talk to one another for free. Yeah. So it's scale. So yes, for visibility, you're absolutely right. From a, I would like to spend less money giving it directly to Amazon, not so much. Does she spend more money for the joy of attribution of workload? Not to mention as well that coming into an environment that exists and is scaled out,

which is sort of a prerequisite for me going in on a consulting project and saying, oh, you should rebuild everything using serverless and microservice principles is a great way to get thrown out of the engagement in the first 20 minutes. Because yes, in theory, anyone can design something great that works, that solves a problem on a whiteboard, but most of us don't get to throw the old thing away and build fresh.

And when we do, great, I'm greenfielding something. There's always constraints and challenges down the road that you don't see coming. So you finally wind up building the most extensible thing in the universe that can handle all these things, and your business dies before you get to MVP because that takes time, energy, and effort. There are many more companies that have died due to failure to find product market fit than have died because, oh yeah, your software architecture was terrible. If you hit the market correctly, there is budget to fix these things down the road, whereas your code could be pristine

and your company's still dead. Yeah. I don't really have a solution for you on that one, Corey. I will come back to your one question. I was hoping you did. Yeah, sorry. I will come back to the question about, you know, how should people kind of get started

in thinking about assessing security? And, you know, how should people kind of get started in thinking about assessing security? And, you know, to your point, look, I mean, I think config is a low-ish cost, but should it cost anything? Probably not, at least for like basic CIS foundation benchmark checks. I mean, if the best practice that Amazon tells everybody is turn on these 40-ish checks at last count, you know, maybe those 40-ish checks should just be free and included and on in everybody's account for any account that you tag as production, right? Like I will wholeheartedly agree with that sentiment. And it would be a trivial thing for Amazon to do with one kind of caveat.

And this is something that I think a lot of people don't necessarily understand. Collecting all the required data for security is actually really expensive. Security is an extremely data-intensive thing at this day and age. And I have a former coworker who used to hate the expression that security is data science, but there is some truth in it at this point. Although the kind of the magic around it is not actually that big because there's not a lot of, let's say, heuristic analysis or magic that goes into what queries, et cetera. A lot of security is very rule-based. It's a lot of just binary checks. Is this bit set to zero or one?

And some of those things are relatively simple. But what ends up inevitably happening is that customers want more out of it. They don't just want to know, is my security good or bad? They want to know things like, is it good or bad now relative to last week? Has it gotten better or worse over time? And so then you start accumulating

lots of data and time series data, and that becomes really expensive. And secondarily, the thing that's really starting to happen more and more in the security world is correlation of multiple layers of data, infrastructure with applications, infrastructure with operating system, infrastructure with OS and app vulnerabilities, infrastructure plus vulnerabilities, plus Kubernetes configurations, plus APIs sitting at the edge of that. Because realistically, like so many organizations that are built out at scale, the truth of the matter is, is just like on their operating system vulnerabilities, they're going to have tens of thousands, if not millions of individual items

to deal with. And no human can realistically prioritize those without some context around it. And that is where the data kind of management becomes really expensive. I hear you. Particularly the complaints about AWS Config, which many things like Control Tower set up for you. And on some level, it is a tax on using the cloud as the cloud should be used, because it charges for evaluation of changes to your environment. So if you're spinning things up all the time and then turning them down when they're not in use, that incurs a bunch of config charges.

Whereas if you treat it like a big dumb version of your data center, where you just spin different things forever, your config charge is nice and low. When you start seeing that entering the top 10 of your spend on services, something is very wrong somewhere. Yeah, I would actually say like a good compromise

in my mind would be that that should be included with something like business support. If you pay for support with AWS, why not include config or some level of config for all the accounts that are in scope for your production support?

That would seem like a very reasonable compromise. For a lot of folks, they have it enabled, but they don't see any direct value from it either. So it's one of those things where not knowing how to turn it off becomes a tax on what you're doing in some cases. And SCPs, often with control tower, don't allow you to do that. So you're training people who are learning this in their test environments to avoid it,

but you want them to be using it at scale in enterprise environments. I agree with you. There has to be a better way to deliver that value to customers because, yeah, this thing is now, you know, three or four percent of your cloud bill. It's not adding that much value, folks. Yeah. One thing I will say, just on a point, and like it's a super small semantic nitpick that I have, I hate when people talk about security as a tax because I think it tends to kind of engender the wrong types of relationships to security. Because if you think about taxes, two things about them, I mean, one is that they're kind of prescribed for you. And so in some sense,

this kind of control tower implementation is similar because like, you know, it's hard for you to turn off, et cetera. But on the other hand, like you don't get to choose how that tax money is spent. And really, like you get to set your security budget as an organization. Maybe this control tower config scenario is a slight outlier on that side. But, you know, there are ways to turn it off, etc. The other thing, though, is that like people tend to relate to tax like this thing that they really, really hate. It comes once a year. You should really do everything you can to minimize it and to like not spend any time on it or on getting it right. And in fact, like there's a lot of people who kind of like to cheat on taxes, right? And so like you don't really want people to have that kind of mindset of like pay as little as possible, spend as little time as possible. And yes, let's cheat on it.

Like that's not how I hope people are addressing security in their cloud environments. I agree wholeheartedly. But if you have a service like Config, for example, that's what we're talking about, and it isn't adding value to you, and you don't know what it does, how it works, and more or less how to turn it off,

then it does effectively become directly in line of tax regardless of how people want to view the principle of taxation. It's a, yeah, security should not be a tax. I agree with you wholeheartedly. It should be an enabler. The relationship between config and security in many cases is fairly attenuated in a lot of people's minds. Yeah, I mean, I think if you don't have kind of ideas in mind

for how you want to use it or consume it or how you want to use it, let's say, as an assessment against your own environment, then it's particularly vexing. So if you don't know, like, hey, I'm going to use config, I'm going to use config for this set of rules. This is how I'm going to consume that data and how I'm going to then pass the results on to people to make change in the organization, then it's particularly useless. Yeah. I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you? Easy breezy. We are just firetail.io. That's fire like the, you know, flammy substance and tail like the tail of an animal, not like a story. But yeah, just firetail.io. And if you come now, we've actually got like a white paper that

we just put out around API security and kind of analyzing 10 years of API-based data breaches and trying to understand what actually went wrong in most of those cases. And you're more than welcome to grab that offer of our website. And if you have any questions, just reach out to me. I'm just jeremy at firetail.io. And we will put links to all of that in the show notes. Thank you so much for your time. I appreciate it. My show notes. Thank you so much for your time. I appreciate it. My pleasure, Corey. Thanks so much for having me. Jeremy Snyder, founder and CEO at Firetale. 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 pointing out that listening to my nonsense is a tax on you going about your day. 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.