Screaming in the Cloud - Cloud Governance Made Easy with David Boeke

Episode Date: June 23, 2020

About David BoekeDavid Boeke is the CTO and VP Services for Turbot. David has 25+ years of experience in IT and is recognized as a transformational leader that has enabled some of the world's largest enterprise organizations to make the transition to public cloud. Prior to joining Turbot, David was the Global Head of Enterprise Architecture and led the cloud transformation for a Fortune 50 life sciences company."LinksTurbot: https://turbot.com/

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist 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 company. Turbot's interesting to me because it targets an area that is very near and dear to my heart, specifically helping organize cloud resources in a way that you can understand them. But it does weigh more. What do you folks do? We believe that we're really the first true governance platform.

There are a lot of tools out there. There's a lot of things that will audit what you're doing and give you reporting on kind of what you're not doing well. But we really designed Turbot from the ground up as a governance platform as tooling for people who like to build things in the cloud, right? And one of the things I always like to tell customers is if you love cloud native, you're going to love Turbot because we're kind of multi-cloud native. We're a single platform that you install and run and can discover resources across all of your clouds.

And then we have a ton of built-in automations within the tool that help you do interesting things with that data. Once you have a complete CMDB and change history of all of your cloud resources that's updated in real time, the idea of then writing automations against that data and understanding it better, maybe for the purposes of security, maybe for the purposes of finding where there's cost and waste. Maybe it's something simple like tagging resources. There's so much that you can do in that space once you have the data, and that's really what we excel at. One of the problems I've always had with the idea of building a tool or getting any tool that purports to solve these problems is it's not a tool. It more or less is a few hundred or thousands of tools.

So when I was digging into Turbot, it's, oh, you actually have 6,000, I think was the number that your marketing pages quote, number of things that can be adjusted or monitored inside of a given cloud environment. Am I roughly accurate with that? Yeah. So there's, I think, roughly right now about 6,000 policies. We're adding a few hundred every week. So a lot of those based on customer requests, some things that we see, a lot of it driven by the actual acceleration of the cloud. So you've got Amazon, you've got Azure GCP all pushing new things, new services, new

capabilities for existing services on a daily basis now. So it takes a lot to keep up with that. And then think about that in terms of an enterprise mindset and how might an enterprise want to use that service or do something with that service. One thing that I find compelling about tooling that solves for this is, first, it's not something that's exciting. I've got to be blunt with you. It's just not to most people. I get excited about it. When I talk to people, they look at me like I've skipped a circuit somewhere. The idea of governance and seeing what's going on across your estate is not resonant with people who are building these small apps and they're just setting out for their first time in the cloud. You generally only appreciate

the value of this either after having done it a few times, or in the more common case, you are an enterprise who has compliance obligations placed upon you where understanding what is in the environment is of critical importance. And I've got to be honest, humans suck at this. It's something that you need tooling to solve for you. It's neat to see that there's a vendor out there, in your case, who at least seems to understand aspects of this, rather than, oh, we built the same dashboard everyone else is, but we're going to compete on better customer service, for example. Right. No, that's totally true. I have led large enterprise IT organizations in the past.

One of the things that always stuck in my craw, because early in my career, I went from being the business unit IT guy, right, where I was building solutions or purchasing solutions and deploying them and configuring them for customer need. And then at some point in my career, I decided that these guys at corporate don't know what they're doing, and they're preventing me from doing what I want to do all the time. So I'm going to go up to corporate and I'm going to fix those things. So I shifted my career and I'm, you know, the move into the corporate environment. And then I became like the Borg and started like preventing people from doing the things that they want to do because in a large organization, you have a million people spending hundreds of millions of dollars all doing the same thing in different ways. So I've seen the problem from both sides

on the enterprise IT side. One of the things that always stuck with me, and I think very early on when we were originally looking to move to AWS as a platform for large enterprise applications, was we would spend literally hundreds of millions of dollars a year on new IT capabilities, whether that's in the data center, deploying disk, deploying virtualized compute, networking equipment, et cetera, and as well, apps. And as soon as you deploy them and put them in place, you would lose them forever. No one could ever find that asset again if it killed them. And then you'd spend hundreds of millions of dollars more implementing something like ServiceNow

so you could put human processes around tracking all those assets and what changed on them, etc. And the thing that jumped out at me very early on, and really who brought it to my attention, is our CEO, Nathan Wallace, who used to work with me in that enterprise environment, was that with the cloud, you basically, you know, you have an accessible, you can search and find those resources. It's a programmable environment. And you now have this ability to discover things, but also query your existing environment and see what you have. You don't have to lose those assets anymore. And so one of the things I'm really proud about Turbot is that we do that discovery. We monitor all the real-time events. I have a customer who has a thousand AWS accounts. And if you imagine the Kinesis stream of event flow from a thousand AWS accounts of all the changes happening across all those accounts. Oh yeah. It takes your entire microservices architecture and makes it worse.

And let's not kid ourselves. A lot of AWS services have trouble even communicating with instances of themselves in other regions, let alone different accounts. Yeah, no, totally. And the idea of now, okay, I have a thousand different accounts and I have a dashboard that I can go in and I can search for an instance ID, I can search for a bucket name and instantly find out what that is, who deployed it, how did it change its configuration over time, what is it currently doing? Like all of that information is like at your fingertips. And if I had that 15 years ago

as an enterprise IT guy, we would have felt like we were ruling the world. You always go back to your 15-year-old self when we were working on Apple IIs and things like that with 16k of RAM and now looking at how much power you have on your phone. It's kind of the same thing, which is that this migration to cloud and moving all your workloads there gives you this real visibility to what you're doing and how you're spending and what are your assets that are deployed in the environment.

So I really love that aspect of it. One thing that resonates with what you folks do is that it's separated from the typical case in this arena, which I have an unfortunate amount of personal experience with. Hi, we're a new startup, and we're going to tell your bank how to properly run your IT department. It's condescending. It sounds like a bunch of people who have no experience in this space who are basically storming in to tell companies they're doing it wrong, and here's what they should do instead without any conception of what life in that environment is like. And what makes you folks interesting is, yeah,

if you squint hard enough, you look like that. You've been around six years. You're definitely a startup. But the people who started your company have come out of that world. You were at Johnson and Johnson for years yourself, for example. Yeah. And all of our core team, both engineering and on the management side, all came out of large IT, either in the financial industry or in pharmaceuticals and the life sciences industry. And those are two very highly regulated industries that spent a lot of time early thinking about these problems of if you move to the cloud, how do you do that in a regulated environment? And so there was actually a ton of really great people out there that were frustrated because their day-to-job was essentially doing PowerPoint presentations to people that really didn't understand what they were talking about. And we have, over time, come out ourselves and said, hey, look, we want to do something different. We want to take this experience that we have in doing these large-scale cloud transformations and move that into tooling

that we can then accelerate other organizations. By ourselves, we can only ever make an impact at kind of one organization at the time. But collectively as a team and building a product, we can have that same impact across hopefully hundreds, if not thousands of other organizations that are going through that same pain. That's partly, I think, where a lot of folks get it wrong. The things that work for Netflix, quote unquote, where they get on stage and talk about these amazing and transformative things that they've built. There are a few problems there. One, you folks stream movies. Let's not kid ourselves. Two, you have enormous amounts of resources that, to be very blunt, most traditional corporate IT departments do not have full stop. So trying to retrofit solutions that work in a radically different culture into an environment where you don't have the same freedom and you have serious regulatory burdens that may not exist elsewhere mean that a lot of the first attempts at things like this come across as, to be honest, kind of a sad joke.

They do. And I really feel for, you know, a lot of people that are in those situations understand the trade-offs, understand a lot of the technical approach that needs to be taken in order to solve these problems. But unfortunately, because their management chain is focused on a different business, they're not focused on a technology business, it's difficult to raise those things in a way that can get you the resources that you need to do it effectively.

So many of our customers are working in a resource-constrained environment where they have a few internal people that really understand it and get it, but there's no way that over time they could actually hire and maintain and keep the talent that would be necessary in order to build the tooling that they need. One of the things that was really intriguing to me, because I've been at reInvent almost every year since its initial inception, is that Capital One, a large, large financial institution has been, you know, platinum sponsor of reInvent for a number of years,

mainly because they were looking for people to bring into their organization. It's essentially a recruiting mechanism to go find people who love this stuff and that they can bring in because as a company, even a huge financial institution, a huge,

you know, life sciences institution like Johnson & Johnson, it's hard to find and attract technical talent that wants to come to a large IT organization, a traditional IT organization, and do this type of work. And I believe that's changing. I do believe that, you know, the years and years that a lot of IT departments have spent outsourcing more and more technical work, that is coming full circle. The ability to move workloads to cloud and cloud transformation, along with the transformation of data science and companies seeing the value in technology again, means that IT departments are going to be refunded. Business leaders are hearing it from the McKenzie's of the world, et cetera, that they need to reinvest in these areas and build out the technical expertise that they have. And so I think there's going to be an opportunity.

And over time, we'll see larger internal IT teams going. But I work with customers that have like one guy who gets it and he has no ability to hire any other resources to help him with this problem. And he needs automation and tooling that's already done so he can roll that out and achieve value. And then we also work with enterprises that have, you know, two dozen software developers who write their own guardrails and their own controls on top of Turbot and deploy those and manage large fleets of AWS accounts and Azure subscriptions

and Google projects. So it's really a mixed bag right now. But I see more people moving in that direction, especially those that are getting large return from their cloud investments and going more cloud native in their workload migrations. One thing that is a universal truth, and I don't care how big your company is or small, is when you look at how things are set up from a governance perspective, and I don't care how big your company is or small, is when you look at how things are set up from a governance perspective, from a tagging perspective, which is my personal hobby horse, it's always the same answer, which is you haven't been doing

it properly and there's a giant gap between where you should be and where you are today. And I don't know that that gap ever gets closed, but you can always do better than you are. But it leads down the path of the first thing people do when they see these things is feel bad. I hate that model because first, it's not your fault. There's a lot of things that go into this. And secondly, you're never going to get to 100%, but automated systems are the only way forward.

Telling humans to tag things the right way all the time does not work because we're humans. We suck at doing the same thing over and over repeatedly and consistently. So how do you approach that? How does that inform how you go to market? Yeah, I love that analogy because it is a microcosm of kind of what happens in a real environment, right? Which is that some smart people get in a room early on and say, okay, we need to have a tagging standards. And, you know, you come out with the tablets of the, you know, the eight tags that every resource must be tagged with. And you kind of go down that path. And the first thing you do is you just, you know, you publish that, you write it up,

you send it to everybody, you say, okay, by whatever it is, July 1st, all project teams must have all the resources tagged and we're going to go forward. And of course it doesn't happen, right? And you do some reporting on that. You pull out data and then you're frustrated, right? Like you were saying, you feel bad. The management feels bad that, hey, we spent some time, we decided on this, we came to a consensus across the organization, we rolled it out, we communicated it and no one did anything, right? And no one did anything, not because they don't want to or whatever. Everyone's got a full stack of work on their plate and they're keeping their applications running, et cetera, and running around and tagging things is probably the least sexy thing to do in that space. The next kind of phase of that, that I normally see, then people

go down the road of, okay, well, you know, if we can't get people to do this stuff manually, let's automate that tagging process, right? And then that sends you down a software development path. We're going to build tooling to do that. We're going to build, you know, serverless lambdas that are going to run in each region and each account and look for resources and tag them based on a central repository of metadata that we're keeping, et cetera. It's a lot of work. You get all that done. You're super happy. you've got that running across you know all 25 amazon regions and you go to reinvent and you sit in the keynote and then you know jassy comes out and goes oh we're launching a new outpost in los angeles and it

has a different arm than everything every other region that we have and it's kind of like you're constantly in this software development mindset in order to kind of achieve any value there and you're still like you said you're still not feeling good about it. I think one of the things that Turbot does in that space, or a few things Turbot does in that space, is that the automation to tag the resources, but to discover that the resources are created, that tags have changed over time, et cetera,

that's all built into the product. So without having to do anything, just turning us on and running it, all the event model of all those events, all the resources that exist, what their current tags are, et cetera, is flowing into your system. And you have a place that you can interrogate that and report on it across many, many accounts, across subscriptions, across clouds, et cetera. So all that's in. But I think the other thing that's interesting is the way that we approached our dashboarding, which is we avoided the trope of, you know, the red, green, yellow stoplight, right? There's so many things that will just tell you everything is wrong. Like you have one resource that's out there that isn't tagged and your environment is, your entire environment is red. Your entire AWS environment is now a stoplight red and everyone feels bad because of that. One of the things that we did is

we turned all of our dashboard reporting into, you know, shades of that, right? So our standard view is a bar chart of how many resources are red versus how many resources are green, right? So you can roll up and instantly see, hey, like 1 percent of my environment is red and ninety nine percent of my environment is green and that's good. And I'm getting better over time and and reducing that. And I think that's one thing that we can do to kind of help drive that, which is that it becomes more about how do I solve these things over time? How do I get better? How do I get less tickets this week than I had last week? I think that's our key mantra, which is kind of kill the ticket, do that, and measure your performance over time. It's the idea of continuous

improvement. I think that's something that people tend to forget sometimes because you look at this monstrous amount of work. I mean, we talk about Turbot. There are 6,000 some odd controls that it can wind up applying or influencing. And great, where do you even start with something like that? The idea of it is almost overwhelming, and it's great. Pick one. It almost doesn't matter which. Pick something that solves a painful problem you have now and get started. Again, I tend not to view this through the lens of any particular tool.

I've done similar things in the past with, you talked about Capital One, their cloud custodian open source project that came out of it is, in some ways, able to do some of these things. And that wound up being a decent way to get started too. Find something, anything, but don't just sit there and feel sorry for yourself. Fix it. Yeah, absolutely. And I think that whole idea of do one thing and get that going and feeling good about it, that is key to the developer mindset, right? It's like you're programming something, it's like 2 a.m. and you know, you're on your, you know, fifth diet Mountain Dew or whatever it is, and you get that thing to run and it passes the unit test

and that feels good and you go, okay, what's the next? What's the next, what's the next thing? And I think for cloud operations team, it needs to be the same thing. If you look at the entirety of, I have companies that come to me and say, hey, I want to enable NIST 800-53 for my environment, right? Which is six years of work, of constant kind of work and driving there. And you'll never reach that goal line. You need to pick up something,

whether it's tagging, whether it's public access, whether it's, you know, encryption, pick one thing, pick one control, roll that out, have that be successful. And then if that's automated, you don't have to think about that anymore, right? So I can build that out. I can get all my accounts compliant with that. Occasionally someone's going to do something, you know, off the beam, but those are going to be onesie twosie. But if you put that to bed, you can really feel good and then roll in the next day and start, okay, now we're going to be onesie twosie. But if you put that to bed, you can really feel good and then roll in the next day and start, okay, now we're going to start on the next thing. We're going to look at making sure that our route tables are not being changed over time or whatever it is, right?

The whole point there is that I love that philosophy. And I can almost tell when I work with a new customer, whether they're going to be successful or not based on that mindset, right? Are they coming in saying, hey, look, I've got a laundry list of 300 different controls in a spreadsheet that I want you guys to go implement in the next 90 days? Or am I taking an approach of what's the minimal viable product that we're going to deploy here? And then let's kind of improve over time. It's a real litmus test as to whether you're going to be successful or not. One thing that I really appreciate about Turbot is on the one hand, yes,

you are positioning yourself as a multi-cloud offering. My argument has always been that multi-cloud as a strategy is dumb. That said, there are ways to approach it that isn't. And you tend to offer a solution that works regardless of platform, which from your perspective is genius. One, it meets customers where they are, which is always a good thing rather than yelling at them that they're doing it wrong.

Two, the fact that you are able to service customers on different clouds absolutely broadens the appeal. And three, which is really what I want to dig into, is you have solved one of the big problems of building a software product aimed at the cloud. Because everyone worries about AWS releasing something at reInvent. Andy Jassy gets on stage. And in my fantasies, he will start talking about tagging and how to do governance. In practice, I sort of think that's not the interesting sort of stuff that gets keynote time. And then you don't have a business. But instead, it wouldn't be a feature release that causes you problems. It would have to be thousands of feature releases that most of us are growing old and are pretty much expecting are never going to happen within our lifetimes. And you're across multiple providers as well.

Yeah, it's interesting. Everyone's anxious. I think everyone that sells tooling in this space is anxious going into re-invent time about what's going to be announced or whatever. But it's funny, like Turbot has been around for six years. So we're a startup, I'll put in quotes, but it's a fairly long time for this space. And Turbot as tooling pre-existed before AWS organizations existed, right? And so I had customers at that time telling me, oh, AWS is coming out with this thing. It's called organizations. You guys should be worried and doing all these things. And the

bottom line is, is that the more the cloud providers deploy, like, you know, the more services that are created creates more things that the enterprise has to do. And that means that there's more value that we can bring to the table. Now, sometimes things that we were doing, like we had, you know, for one of our big early controls was the idea of finding unused resources and auto-stopping instances, things like that. So, you know, a big thing some of our early customers were using was the ability for Turbot to essentially for dev environments to turn off EC2 instances at the end of the day, right? So everyone goes home at, you know, 6, 7 o'clock. And then they basically had Turbot configured to stop those instances at the end of the day and then start them back up around 7 a.m. before everybody got back in the office, which is a big cost savings. It's even a cost savings over spot in some cases, just depending on what kind of instances you're using.

Now, AWS came out with that capability and built it in in the last year or the year before. That's great. Always lean into cloud native, right? Like we're not about abstracting you. Far from the opposite, I think one of the key things that Turbot does is we say, we never want to abstract you from using the cloud. If you like using the AWS console, if you like using the CLI, if you like using Terraform or CloudFormation or whatever the tooling is that you like to interact with your environment, we don't want to intercept. We don't want to be in the middle of that with you because that's what makes you productive and what makes your team productive. What we really want to do is give you great tooling on the back end to evaluate those changes that are occurring in real time, regardless of

how they're doing that, and do that in a way that doesn't take away value from the developer or doesn't slow the developer down in any way. That's part of the value where the idea of, oh, there's now a native way to do it. Terrific. There are two problems with this. One, not everyone keeps up with every release. In fact, most people don't know that you can stop these events. And two, great. The fact that you have that as a capability also exposes ways for you to either extend it yourself or leverage it for some of the things that your tooling does or ultimately have it replaced by that native offering. And that's great because it's not the only thing that your company does. And that's where people tend to get stuck. It's great. Oh, you're just the thing that turns down my development environments at night. Well, that's kind of a limiting experience and offering that really helps folks out. I do have a question about that particular use case, though. Often I'll talk to companies who really care about exactly that

problem, but then analysis shows that 3% of their spend is development environments and they haven't bought an RI in 12 months. So that doesn't seem to be the biggest area of concern. Secondly, there's always the outliers that seem to cut things like this to pieces. And this probably is a larger concern across the entirety of what you do. It works out super well until one day there's a big release and people are trying to get something out the door. They're working late for a deployment or whatnot. And then the system turns off their instances. So because, well, it's quit in time, go home, and it causes a disruption. How do you handle that? Yeah, it was a use case that we had to worry about early on.

I actually had a situation where Turbot was competing with a autoscaling configuration. And so the autosc, I kept launching instances and TurboBot kept terminating them because they weren't encrypted or something. But in terms of starting up instances and starting them and things like that, we took a very TurboBot-y approach, I'll say to that, which is that we only try to stop the instance once. So if we stop the instance, if you say stop all instances at 8 p.m. and we stop it at 8 p.m. and you start it back up at like 8.15, we don't try and stop it again. So that was how we landed on that to create some value, but not get in the way in terms of someone that's, you know, trying to do productive work where the automation might be

fighting with them. And that's, I think, the biggest challenge is people wind up fighting with the automation, at least in the world of cost. The first time that your cost savings attempt causes an outage, you're not usually allowed to try to save money anymore. When the world of governance, where you're trying to make sure that there is something holistic across the board that feeds into compliance programs, yeah, it caused a problem, so we're turning it off. That's not really an option unless you're basically Enron. So at some point, you need to learn to live with it. And building out things that are user-friendly and not user-hostile in that approach is one of the things that I think,

to be blunt, differentiates you. Yeah, very much so. Early on, early versions of the product wouldn't even terminate things if Turbot didn't see them spin up and they were an older than X minutes, like say 30 minutes, right? So the guardrails that would do

destructive things only operate on resources that were newly created so that we didn't have a situation where an internal bad actor could configure Turbot in a way that would destroy someone's entire multi-account environment and just wipe out everything. Over the last couple years, as cost has become more and more of a factor, we started to encounter use cases. I have a customer who really cool use case, which is that they give every internal IT employee, I think it's 50 or $100 in AWS credits. And they're allowed to spin up an account and take whatever training classes that they want and try out resources, try out automations and things like that. Basically a sandbox for each individual. They go out to a website internally.

They sign up for it. Their manager approves. They get this environment, and it's deployed for them, and they can play around with it. Great use case. I love it. I love the fact that they're giving their employees tools to learn this space and to do things and to transform from old skills to new skills. The problem was that those $50 sandboxes, the person would stop using it and then they would

still sit out there and still churn cost. So we actually built specific controls in for them that would take enforcement action in this particular instance on the sandbox environments. And so when they reach their cost limit of spend or when they reached a specific time value, 90 days, et cetera, Turbot would actually go and start terminating all resources within the account and shutting it down, getting it ready

for the next person that needed a sandbox to basically kind of reset the account and put it back in the hopper to be available for the next person to come along. So that's a very interesting use case. It's something that initially we didn't consider because we were thinking of those enterprise use cases, dev environments, QA environments, etc. But that idea of kind of time-limited sandboxes and doing that is a unique proposition. And we had to do some custom things for that customer in order to achieve it. It really is one of those areas that is underappreciated.

The idea of building out sandbox environments, that's one of those things I've been asking for AWS for years. I would love to be able to spin up an account and say, great, everything in this account is fine, but after a certain date, I want the whole account terminated to solve that problem and then have a positive pressure style system where I have to keep explicitly, proactively renewing that account as a developer to continue working on things

is the right answer. Especially if you look at where this world came out of. When you used to have to wait six weeks to get an environment spun up and now because it's cloud, you can do it with only four weeks of approvals. Once you get that, you're never going to give it up because it's painful to do that. If you can automate that and get out of people's way, you're never going to give it up because it's painful to do that. If you can automate that and get out of people's way, you're never going to succeed there by chasing people that turn things off by hand. It has to be done automatically. Building tooling that makes this happen as the default rather than something that a human has to remember is the only way forward. Totally. And I don't know if you can hear me smiling on the other side of the microphone here, but two of my really favorite controls that we have are associated with this,

right? So Turbot has its own built-in CASB solution that is very similar to AWS Single Sign-On, where you can grant someone access to an account and they have that access. They go to a website and they log in with their SAML identity and their two-factor authentication. And then they can just click and get single button access to any AWS account that they have access to. So if you're on the security team and you've got metadata level access across every AWS account in your environment, you have a single page you can go to and just log into it. A lot of people have this. There's been some default out-of-the-box solutions from AWS Professional Services for a while. And then they rolled out Single Sign-On recently, which is a great product and very much aligned to what we do there as well.

But one of the things that we do that's kind of fun with that is you can grant access for a specific amount of time. And when I was at Johnson & Johnson, one of the things that was always a pain point for us was periodic review of access, right? So your manager has to review whatever access that you have on a yearly basis. Some organizations do this every 90 days, but every 90 days, every year, whatever it is, your manager has to go through and review all your access for all systems and re-approve it on that yearly basis, right? And if you don't do it, you're not meeting Sarbanes-Oxley requirements and your financial reporting system is deemed insecure. So if you think about that use case, there's two ways to do that.

One is that you provision all access centrally through a central system and you record all that. And then you have some sort of website that you have to build that shows the manager all the access that you have in a way that they can evaluate whether it's appropriate for you to still have that or not and click that it's okay to do, et cetera.

And it was just kind of like a very minor tweak that we did, which is within Turbot, you can grant access for a specific amount of time. So you can grant access for 364 days. And so you know that if an auditor comes in and looks at anyone's access within the environment, every bit of access within the environment has been granted within the last X days. Because if it's over that, it will have been revoked.

And it's a great kind of hack for not having to do periodic review. If you never grant access over that amount of time, that whatever your periodic review time is, so 89 days or 364 days or whatever it is, you can be assured that you're audit ready 100% of the time because there is not going to be anyone in the system that has access that's growing. And in the same way, we do the same thing with our policies. So of those 6,000 policies that we were talking about, if you say, hey, I want to enforce encryption on all my S3 buckets and I want to use this very

specific customer managed key, regardless of the policy type setting that you're doing, the setting can be time limited. So for that team that wants to try out that brand new AWS service that just came out, but you don't want to give them permanent access to that, you can essentially enable that service for them for 30, 60, 90 days, whatever it might be. And then at the end of that, basically Turbot revokes their access. And the next time they go to the console and try and use it, they're going to have to re-request extending that period of review time for themselves in order to continue to have that access. So both those use cases in terms of doing things in a time-limited way are a really great way in hacks to solve some of these problems of there's not enough people in the world to manually go up and follow up on all these things, right? But if when you're providing

the thing, you're limiting the timeframe for that, it just kind of solves that problem. Yeah. It's, it feels to me like it's the only sensible way to solve these issues. I do want to thank you for taking so much time out of your day to speak with me. If people want to learn more about Turbot, where can they find it? Yeah. Best place to go is turbot.com, our website. We have a ton of resources out there and getting started guides. If you're interested in kicking the tires and getting things going, there's call to actions on that page

to sign up for a free trial account, import one of your AWS accounts. Hey, run the entire CIS benchmark for AWS, Azure, GCP, whatever you want to do against your account, do a report out, see how things are working. Maybe better, just do one thing, right? Maybe you said like, let's, you know, pick out one thing and do

that within Turbot and then see if it helps you. I think I might actually try that myself, but that is a topic for another time. Thanks once again for taking the time to speak with me. Thanks, Corey. Really enjoyed it. David Boeke, CTO and VP of Services for Turbot. I am cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. Whereas if you didn't enjoy this podcast, please leave a five-star review on Apple Podcasts,

along with a comment explaining why it's better to do all of your governance and tagging work by hand. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever Fine Snark is sold. This has been a humble pod production stay humble