Screaming in the Cloud - Navigating Continuous Change in Cloud Security with Brandon Sherman

Episode Date: July 11, 2023

Brandon Sherman, Cloud Security Engineer at Temporal Technologies Inc., joins Corey on Screaming in the Cloud to discuss his experiences at recent cloud conferences and the ongoing changes in cloud computing. Brandon shares why he enjoyed fwd:cloudsec more than this year’s re:Inforce, and how he’s seen AWS events evolve over the years. Brandon and Corey also discuss how the cloud has matured and why Brandon feels ongoing change can be expected to be the continuing state of cloud. Brandon also shares insights on how his perspective on Google Cloud has changed, and why he’s excited about the future of Temporal.io.About BrandonBrandon is currently a Cloud Security Engineer at Temporal Technologies Inc. One of Temporal’s goals is to make our software as reliable as running water, but to stretch the metaphor it must also be *clean* water. He has stared into the abyss and it stared back, then bought it a beer before things got too awkward. When not at work, he can be found playing with his kids, working on his truck, or teaching his kids to work on his truck.Links Referenced:Temporal: https://temporal.io/Personal website: https://brandonsherman.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. In the cloud, ideas turn into innovation at virtually limitless speed and scale. To secure innovation in the cloud, you need Runtime Insights to prioritize critical risks

and stay ahead of unknown threats. What's Runtime runtime insights, you ask? Visit sysdig.com slash screaming to learn more. That's S-Y-S-D-I-G dot com slash screaming. My thanks as well to Sysdig for sponsoring this ridiculous podcast. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by my friend who I am disappointed to say I have not dragged onto this show before.

Brandon Sherman is a cloud security engineer over at Temporal. Brandon, thank you for finally giving in. Thanks, Corey, for finally pestering me enough to convince me to join. Happy to be here. So a few weeks ago, as of this recording, I know that time is a flexible construct when it comes to the podcast production process. You gave a talk at Forward CloudSec, the best cloud security conference named after an email subject line. Yes, I know Reinforce also qualifies. This one's better. Tell me about what you talked about. Yeah, definitely agree on this being the better of the two conferences. I gave a talk about how the ground shifts underneath us, kind of touching on how these cloud services that we operate, and

I'm mostly experienced in AWS, and that's the kind of references that I can give. But these services work as a contract basis, right? We use their APIs APIs and we don't care how they're implemented behind the scenes. At this point, S3 has been rewritten I don't know how many times. I'm sure that other AWS services, especially the longer lived ones, have gone through that same sort of rejuvenation cycle. But as a security practitioner, these implementation details that get created as sort of byproducts of releasing an API or releasing a managed service can have big implications to how you can either secure that service or respond to actions or activities that happen in that service. And when I say actions and activities, I'm kind of focused on security incidents, breaches, your ability to do incident response from that. One of the reasons I've always felt that cloud providers have been cagey around how these services work under the hood is not because they don't want to talk about it so much as they

don't want to find themselves committed to certain patterns that are not guaranteed as a part of the definition of the service. So if, yeah, this is how it works under the hood and you start making plans and architecting in accordance with that, and they rebuild the service out from under you, like they do with S3, then very often those things that you depend upon being true could very easily no longer be true. And there's no announcement around those things. No, it's very much Amazon is, they're building a service to meet the needs of their customers. And they're trying to grow these services as the customers grow along with them. And it's absolutely within their right to act that way, to not have to tell us when they make a change, because in some contexts, Amazon's

feature update might be me as a customer, a breaking change. And Amazon wants to try and keep that, what they need to tell me as small as possible, probably not out of malice, but just because there's a lot of people out there using their services and trying to figure out what they've promised to each individual entity through either literal contracts or their API contracts is hard work. And that's not the job I would want. No, it seems like it's one of those thankless jobs where you don't get praise for basically anything. Instead, all you get to do is deal with the grim reality that people either view as invisible or a problem. Yeah, sort of feels like documentation. Everyone wants more and better documentation,

but it's always an auxiliary part of the service creation process. The best documentation always starts out when you write the documentation first and then kind of build backwards from that. But that's rarely how I've seen software get made. No, I feel like it lets them off the hook on some level when we say this,

but I also believe in being fair. I think there's a lot of things that cloud providers get made. I feel like it lets them off the hook on some level when we say this, but I also believe in being fair. I think there's a lot of things that cloud providers get right. And by and large, with any of the large cloud providers, they are going to do a better job of securing the fundamentals than you are yourself. I know that that is a controversial statement to some folks who spend way too much time in the data centers, but I stand by it.

Yeah, I agree. I've had to work in both environments. And some of the easiest, best wins in security is just what do I have? So that way I know what do I have to protect? What data is there? But even just that asset inventory, that's the sort of thing that back in the days

of data centers and still today, there's data centers all over the place. To do an inventory, you might need to go and send an actual human with an actual clipboard or iPad or whatever to the actual physical location and hope that they read the labels on hundreds of thousands of servers correctly and get their serial numbers and know what you have. And that doesn't even tell you what's running on them, what ports are open, what stuff you have to care about. In AWS, I can run a couple of described calls or list calls,

and that forms the backbone of my inventory. There's no server that got built into a wall or lost behind some long-forgotten migration. A lot of the basic stuff that really, really helps, not to mention then if you use a managed service like S3, you never have to care about patch notes or what an update might do. Plenty of times I've hesitated upgrading a software package because I didn't know what was going to happen.

Control Tower, I guess, is kind of an exception to that where you do have to care the version of your cloud service. But stuff like these other services is absolutely right. The undifferentiated heavy lifting, it's taken care of. And hopefully, we always kind of hope that the undifferentiated heavy lifting doesn't become differentiated and heavy and lands on us. So now that we've done the obligatory be nice to cloud providers thing, let's potentially be a little bit harsher. While you were speaking at Forward CloudSec, did you take advantage of the fact that you were in town to also attend Reinforce? I did because I was given a ticket and I wanted to go see some people who didn't have tickets to Forward CloudSec.

Yeah, we've been nice to cloud providers, but I haven't found I've learned a lot from the Reinforce sessions. They're all recorded anyway. There's not even an open call for papers, right? For talking about at a reinforced session, Hey, like this would be important information, things that I would be wanting to share. And that's, that's not the sort of thing that Amazon does with their conferences. And that's something that I think would be really interesting to change. If there was a more community minded track that let people submit, let not just handpicked, although I suppose any kind of Amazon selection committee is going to be involved, but to pick out from the community stories or projects that are interesting that

can be not just have to get filtered through your town, but something you can actually talk to and say, hey, this is something I'd like to talk about. Maybe other people would find it useful. One of the things that I found super weird about Reinforce this year has been that in a normal year, it would have been a lot more notable, I think. I know for a fact that if I had missed Reinvent, for example, I would have had to be living in a cave not to see all of the various things coming out of that conference on social media, in my email, in all of the filters I put out there. But unless you're looking for it, you would not know that they had a conference that costs almost as much. Yeah, the reInvent-driven development cycle is absolutely a real thing.

You can always tell in the lead-up to reInvent when there's releases that get pushed out beforehand, and you think, oh, that's cool. I wonder why this doesn't get a spot at reInvent. There's some kind of announcement or whatever. And I was looking for that this year for reInforce and didn't see any kind of announcement or that kind of pre-release trickle

of things that are like, oh, there's a bunch of really cool stuff. And that's not to say that cool stuff didn't happen. It just, there was a very different marketing feel to it. Hard to say, it's just the vibes around it felt different. Would you recommend that people attend next year? Well, let me back up. I've heard that they had not even announced a date for it next year. Do you think there will be a reinforce next year? Making me guess, predict the future. Do a prediction.

Why not? Let's engage in some idle speculation, right? I think that not announcing it was kind of a clue that there's a decent chance it won't happen. Because in prior years, it had been pre-announced. I think it was either closing or opening ceremonies or at some point. It was always the, here's what you can look forward to next year. And that didn't happen. So I think there's a decent chance this may have been the last reinforced, especially once all the data is crunched and people look at the numbers.

It might just be, I don't know, I'm not a marketing savvy kind of person, but it might just be that a day at reInvent next year is dedicated to security. But then again, security is always job zero at Amazon. So maybe reInvent just becomes reinforce all the time, right? Do security, everybody. It just feels like a different type of conference. When I reInvent, there's something for everyone. At reInforce, there's something for everyone as long as they work in InfoSec. Because other than that, you wind up just having these really unfortunate spiels of them speaking to people that are not actually present.

And it winds up missing the entire forest for the trees, really. I don't know if I'd characterize it as that. I feel like some of the reinforced content was people who were maybe curious about the cloud or are making progress in their companies and moving to the cloud. And in Amazon's case, when they say the cloud, they mean themselves. They don't moving to the cloud. And in Amazon's case, when they say the cloud, they mean themselves.

They don't mean any other cloud. And Reinforced tries to dispel the notion there are any other clouds. But at the same time, it feels like an attempt to try and make people feel better. There's a change underway in the industry, and it still is going to continue for a while. There's still all kinds of non-cloud it still is going to continue for a while. There's still

all kinds of non-cloud environments people are going to operate for probably until the end of time. But at the same time, a lot of these are moving to the cloud and they want the people who are thinking about this or engaged in it to be comforted by that Amazon either has these services or there's a pattern you can follow to do something in a secure manner. I think that was kind of the primary audience of Reinforce, is people who were charged with doing cloud security or were exploring moving their corporate systems to AWS. And they wanted some assurance that they're going to actually be doing things the right way or someone else had made those mistakes first. And if that audience has been sort of saturated, then maybe there

isn't a need for that style of conference anymore. It feels like it's not intended to be the same thing at reInvent, which is probably, I guess, a bigger problem. reInvent for a long time has attempted to be all things to all people, and it has grown to a scale where that is no longer possible. So they've also done a poor job of signaling that. So you wind up attending Adam Solipski's keynote and in many cases find yourself bored absolutely to tears or you go in expecting it to be an Andy Jassy style of here are 200 releases, four of them good. And instead you wind up just having what feels like a relatively paltry number doled out over a period of days. And I don't know that they're wrong to do it.

I just think it doesn't align with pre-existing expectations. I also think that people expecting to go to reinforce to see a whole bunch of feature releases are bound to be disappointed. Both of those are absolutely correct. The number of releases on the slide must always increase. Up and to the right, away we go. We're pushing more code and making more changes to services. I mean, if you look at the history, there's always new instance types. Do they count each instance type as a new release or do they not do that?

Yeah, it honestly feels like that sometimes. And they also love to do price cuts where you wind up digging into them and something like 90% of them are services you've never heard of in regions you couldn't find on a map if your life depended on it. It's not quite the, yay, the bill gets lower all the time

that they love to present it as being. Yeah, and you may even find that there's services that had updates that you didn't know about until you go and check the final bill. The cost and usage report. And you look and go, oh, hey, look at all these services that we were using or engineers started using after they heard announcements at reInvent. And then you find out how much you're actually paying for them or that they were in use in the first place.

There's no better way to find what is actually happening in your environment than look at the bill. It's depressing that that's true. At least they finally stopped doing the slides where they talk about year over year, they have a histogram of number of feature and service releases. No one feels good about that, even the people building the services and features, because they look at that and think, oh, whatever I do is going to get lost in the noise. And they're not wrong. Customers see it and freak out because how am I ever going to keep current with all this stuff? I take a week off want to have a strategy of saying, no, you can't touch any of those until we've vetted and understand them? I mean, you don't even have to talk about security

in that context, just the cost alone. Understanding it's someone going to run an experiment that bankrupts your company by forgetting about it or by growing into some monster in the bill, which I suspect helps you out when those sorts of things happen, right? For companies that don't have that strategy. But at the same time, all these things are getting released. There's not really a good way of understanding which of these do I need to care about? Which of these is going to really impact my operational flow, my security impacts? What does this mean to me as a user of the service

when there's, I don't know, an uncountable number, really, or at least a number that's so big it stops mattering that it got any bigger? One thing that I will say was great about reInvent, I want to say 2021, was how small it felt. It felt like really a hearkening back to the old reInvents and then, you know, 2022 hit and we go there and half of us wound up getting COVID because of course we did, but it was also this,

just this massive rush of we're talking with basically the population of a midsize city, just showing up inside of this entire enormous conference. And you couldn't see the people you wanted to see. It was difficult to pay attention to all there was to pay attention to. And it really feels like we've lost something somewhere. Yeah, but at the same time, is that just because there are more people in this ecosystem now? 2021 may have been a callback to that, but a decade ago. And these things

were smaller when it was still niche but growing in kind of the whole ecosystem. When I say the ecosystem there but growing in kind of the whole ecosystem. When I say the ecosystem there, I'm kind of talking about how general I want to run something in technology. I need a server. I need an object store. I need compute. Whatever it is that you need. There is more attractive services that Amazon offers to all kinds of customers now. So is that just because we've been in this for a while and we've seen the cloud grow up and like,

oh, wow, you're now in your awkward teenage phase of cloud computing? Have we not yet? We're watching the maturity to adulthood as these things go. I really don't know. But it definitely feels a little like we've watched this cloud thing grow up from a half dozen services to now a dozen thousand services all operating different ways. Part of me really thinks that we could have done things differently had we known once upon a time what the future was going to hold. So much of the pain I see in cloud is functionally people trying to shove things into the cloud that weren't designed with cloud principles in mind. Yeah, if I was going to build a lot of this stuff

from scratch myself, then yeah, I would have absolutely made a whole universe of different choices. But I can't predict the future. And yet here we are. Yeah, if I could predict the future, I would have definitely won the lottery a lot more times, avoided doing that one thing. I regretted that once back in my history. Knowing the future would change a lot of things. But at least unless you're not letting on with something, then that's something that no one's got the ability to do, not even at Amazon. So one of the problems I've always had when I come back from a conference, especially reInvent, is it takes me a few, well, I'll be charitable and say days, but it's more like weeks, to get back into the flow of my day-to-day work life.

Was there any of that with you in Reinforce? I mean, what is your day job these days anyway? What are you up to? What is my day job? There's a lot. So Temporals is a small but quickly growing company. A lot of really cool customers that are doing really cool things with our technology. And we need to build a lot of basics, essentially, making sure that when we grow,

that we're going to kind of grow into our security posture, that there's not anything talking about predicting the future. My prediction is that the company I work for is going to do well. You can hold your analysis on that. So while I'm predicting that the company that I'm working at is going to do well, part of it is also what are the things that I'm going to regret not having in two or three years' time. So some baseline cloud monitoring, right? I want that asset inventory across all of our accounts.

I want to know what's going on there. There's other things that are sort of security adjacent. So things like DNS records, domain names, a lot of those things where if we can capture this and centralize it early and build it in a way, especially that users are less unhappy about. That not everyone, for example, is hosting their own, buying their own domains on personal cards and filing for reimbursement. That DNS records aren't scattered across a dozen different software projects and manipulated in different ways. Then that sets us

up. It may not be perfect today, but in a year, year and a half, two years, we have the ability to then say, okay, we know what we're pointing at. What are the dangling subdomains? What are the things that are, you know, our potential avenues of being taken over? What do we have? What are people doing?

And trying to understand how we can better help users with their needs day to day. I'm also, as a side part of my day job, is advising a startup, Common Fate, does just-in-time access management. And that's been a lot of fun to do as well, because fundamentally, this is maybe a hot take that in a lot of cases, you really only need admin access and read-only access when you're doing really intensive work. In temporal day job, we've got infrastructure teams that are building stuff. They need lots of permissions. And it'd be very silly to say, you can't do your job just because you could

potentially use IAM and privilege escalate yourself to administrator. Let's cut that out. Let's pretend that you are a responsible adult. We can monitor you in other ways. We're not going to put restrictions between you and doing your job. Have admin access. Just only have it for a short period of time when you say you're going to need it and not all the time, every account, every service, all the time, all day. I do want to throw a shout in for that startup you advised, Common Fate. I've been a big fan of their Granted offering for a while now, granted.dev

for those who are unfamiliar. I use that to automatically generate console logins, do all kinds of other things when you're moving between a bunch of different AWS accounts, which it kind of feels like the people building these services don't have to do somehow because of their internal Isengard system handling it for them. Well, as a customer,

can I just say that experience absolutely sucks and granted goes a long way toward making it tolerable, if not great. Yeah. I remember years ago, the way that I would have to handle this is I would have probably a half dozen different browsers at the same time. Safari, Chrome, the Safari web developer preview, just so I could have enough browsers to log into to see all the accounts I needed to access. And that was an extremely painful experience. And it still feels so odd that the AWS console today still acts like you have one account, you can switch

roles, you can type in a role in a different account, but it's very clunky to use. And having software up there that makes this easier is definitely definitely fills in a major pain point I have with using these services. Tired of Apache Kafka's complexity making your AWS bill look like a phone number? Enter Red Panda. You get 10x your streaming data performance without having to rob a bank. And migration? Smoother than a fresh jar of peanut butter.

Imagine cutting as much as 50% off your AWS bills. With Red Panda, it's not a dream, it's reality. Visit go.redpanda.com slash duckbill. Red Panda, because Kafka shouldn't cause you nightmares. Do you believe that there's hope? Because we have seen some changes where originally AWS just had the AWS account you log into. It's the root user. Great.

Then they had IAM. Now they're using what used to be known as AWS SSO, which they wound up calling IAM Access Identity Center. I forget the exact words they put in order, but it's confusing and annoying. But it does feel like the trend is overall towards something that's a little bit more coherent. Is the future five years from now better than it looks like today? That's certainly the hope. I mean, we've talked about how we both can't predict the future, but I would like to hope that the future gets better. I really like GCP's project model. There's complaints I have with how Google Cloud works and if it's going to be here next year and if the permission model is exactly how I'd like the mental organization that feels like Google was able to come in and solve a lot of those problems with running projects and having a lot of these different things. And part of that is there's still services in AWS that don't really respect resource-based permissions or tag-based permissions. I think the new one is attribute-based access control.

One of the challenges I see too is that I don't think that there's been a lot of thought put into how a lot of these things are going to work between different AWS accounts. One of my bits of guidance whenever I'm talking to someone who's building anything, be it at AWS or external, is imagine an architecture diagram

and now imagine that between any two resources in that diagram is now an account boundary because someone somewhere is going to have one there. So it sounds ridiculous, but you can imagine a microservices scenario where every component is in its own isolated account. What are you going to do now as a result? Because if you're going to build something that scales, you've got to respect those boundaries. And usually that just means the person starts drinking. tricky to get in a way that sort of... I guess I always kind of feel that these things are going to change and that the quote, right, the only constant is change. That's true. The services we use are going to change. The way that we're going to want to organize them is going to change. A researcher is going to come out with something and say, hey,

I found a really cool way to do something really terrible to the stuff in your cloud environment. And that's going to happen eventually in the fullness of time. So how do we be able to react quickly to those kinds of changes? And how can we make sure that if suddenly we do need to separate out these services to decompose the monolith even more, whatever the cool current catchphrase is. And we have those account boundaries, which are phenomenal boundaries. They make it so much easier to do. If you can do multi-account, then you've solved multi-region along the way. You've solved

failover. You've solved security issues. You have not solved the fact that your life is considerably more challenging at the moment. But I would really hope that in, you know, even next year, but by the time five years comes around, that that's really been taken to heart within Amazon. And it's a lot easier to be working, creating services in different accounts that can talk to each other, especially in the current environment where it's kind of a mess to wire these things all together. ClickOps has its place, but some console applications just don't want to believe that you have a KMS key in another account because, well, why would you put that over there? It's not like if your current account has a problem, you want to lose all your

data that's encrypted. It's one of those weird things too, where the clouds almost seem to be arguing against each other. I would be hard-p pressed to advise someone not to put a rehydrate the entire business level of backups into a different cloud provider entirely. But they're so steeped in the orthodoxy of no other clouds ever that that message is not something that they can effectively communicate.

And I think they're doing their customers a giant disservice by that. Just because it is so much easier to explain to your auditor that you've done it than to explain why it's not necessary. And it's never true. You always have the single point of failure of the payment instrument or the contract with that provider that could put things at risk. Is it a likely issue? No. But if you're running a publicly traded company on top of it,

you'd be negligent not to think about it that way. So why pretend otherwise? Is that a question for me? Because I... Oh, that was... No, absolutely. That was a rant ending in a rhetorical question. So don't feel you need to answer it. But I'm getting the statement out there because hopefully someone at Amazon is listening to this.

Oh, that's... Hopefully, if you find out who's the one that listens to this and can affect it, then yeah, I'd like to send them a couple of emails because absolutely, there's room out there. There will always be room for at least two providers. Yeah, I'd say a third, but I don't know that Google is going to have the attention span to still have a cloud offering by lunchtime today. Yeah, I really wish that I had more faith in the services and that they weren't going, you know, speaking of services changing underneath you, definitely a major disservice if you don't know if you're going to put into work into architecting and really using cloud providers as they're meant to be used. Not in a sort of least common denominator sense, in which case you're not in good shape. You should not be building something with an idea toward what if this gets deprecated.

You shouldn't have to think about that on a consistent basis. Absolutely. You should expect those things to change because they will. The performance impact, I mean, the performance of these services is going to change. The underlying technology that the providers use is going to change. But you should still be able to mostly expect that at least the API calls you make are going to still be there and still be consistent come this time next year. The thing that really broke me was the recent selling off of Google domains to Squarespace. Nothing against Squarespace, but they have a different target market in many respects. And, oh, I'm a Google customer. You're now going to give all of my information to a third party I never asked to deal with. Great. And more to the point,

if I recommend Google to folks, because as has happened in years past, then they cancel the thing that I recommended and I look like a buffoon. So we've gotten to a point now where it has become so steady and so consistent that I fear I cannot in good conscience recommend a Google product without massive caveats. Otherwise, I look like a clown or worse, a paid shill. Yeah, and when you want to start incorporating these things into the core of your business, to take that point about total failover scenarios, you should, you know, if we wanted to have a domain registered in a Google service that was provisioned to Google Cloud Services, that whole ecosystem involved there, that's now gone. If I want to use Google Cloud with a Google Cloud native domain name host or services, I can't.

Now I can't. There's not workarounds available. I've got to go to some other third party. And it just feels odd that an organization would sort of take those core building blocks and outsource them. I know that Google's core offering isn't Google Cloud. It's not their primary focus. And it kind of reflects that, which is a shame. There's things that I'd love to see grow out of Google Cloud and get better,

and competition is good for the whole cloud computing industry. I think that it's a sad thing, but it's real, that there are people who were passionate defenders of Google over the years. I used to be one. We saw a bunch of Stadia fans coming out of the woodwork. And then all those people who have defended Google and said, no, no, you can trust Google on this service because it's different for some reason or other, then wind up looking ridiculous. And some of the staunchest Google defenders that I've seen are starting to come around to my point of view. Eventually, you run out of people who are willing to get burned after you burn them all.

Yeah. eventually you run out of people who are willing to get burned after you burn them all. Yeah, I've always been a little, maybe this is the security privacy part of me. I've always been a little leery of these services that really want to capture and gather your data. But I always respected the Google engineering that went into building these things at massive scale. Something beyond my ability to understand. I haven't worked in something that big before. And Google made it look, maybe not effortless, but they made it look like they knew what they were doing.

They could build something really solid. And I don't know if that's still true because it feels like they may know how to build something and then they'll just dismantle it and turn it over to somebody else or just dismantle it completely. And I think humans, we do a lot of things because we don't want to look foolish. And now recommending Google Cloud starts to make you wonder, am I going to look foolish? Is this going to be a reflection on me in a year, two years when you got to come in to say, hey, I guess

that whole thing we architected around, it's being sold to someone else. It's being closed down. We got to transfer and re-architect our whole whatever we built because of factors out of our control. I want to be re-architecting things because I screwed it up. I want to be re-architecting things because I made an interesting novel mistake, not something that's kind of mundane. Like, oh, I guess the thing we were going to use got shut down. Like that makes it look like not only can I not predict the future, but I can't even pretend to read the tea leaves. And that's what's hard is because on some level, our job when we work in operations and cloud and try and make these decisions is to convince the business we know what we're talking about.

And when we look foolish, we don't make that same mistake again. Billing and security are oftentimes frequently aligned with each other. We're trying to convince the business that we need to build things a certain way to get a certain outcome, right? Either lower costs or more performance for the dollar so that we don't wind up in the front page of newspapers, any kind of those things. Oh, yes. 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? The best place to find me? I have a website about me, brandonsherman.com. That's where I post stuff. There's some links to a Mastodon profile. I'm not much of a social sort of post your information out there kind of person. But if you want to get a hold of me, then that's probably the best way to find me and contact me.

Either that or head out to the desert somewhere, look for a silver truck out in the dunes and without technology around. It's another good spot if you can find me there. And I will include a link to that, of course, in the show notes. Thank you so much for taking the time to speak with me today. As always, I appreciate it. Thank you very much for having me, Corey. Good to chat with you. Brandon Sherman, Cloud Security Engineer at Temporal. 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 hated this podcast, please leave a five-star review on your podcast platform of choice,

along with an angry comment that will somehow devolve into you inviting me to your new uninspiring cloud security conference that your vendor is putting on and is, of course, named after an email subject line. 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.