Screaming in the Cloud - Keeping the Cloud Reasonable with Shlomo Dubrowin

Episode Date: September 12, 2024

After years of trying, Corey has finally convinced a TAM to come on the show! In this lively episode, AWS Senior Technical Account Manager Shlomo Dubrowin takes the mic to share his fascinating experiences dealing with cloud complexities. Listen in as Shlomo recounts building AWS Reasonable Account Defaults from scratch, stresses the importance of writing a solid application, and shares the benefits of leveraging GenAI to help maintain his work. Don't miss this entertaining and insightful conversation that could save you a few bucks!Show Highlights:(0:00) Intro(0:42) Chronosphere sponsor read(1:15) Finally getting a TAM on the show(2:24) Providing quality customer service as a TAM(5:31) AWS Reasonable Account Defaults(11:01) What went into crafting AWS Reasonable Accounts Defaults(12:20) Chronosphere sponsor read(12:54) Writing a program that won't break easily(17:25) Optimizing billing data(19:53) Transparency in costs(21:27) Expanding AWS Reasonable Account Defaults(23:34) Further optimizing AWS Reasonable Account Defaults in the future(26:18) Building with GenAI(29:01) Where you can find more from ShlomoAbout Shlomo DubrowinShlomo Dubrowin has been a TAM for over 6 years supporting AWS customers from startups through to Fortune 100 companies. He has spoken at re:Invent twice and has specialized in Cost Optimization. Shlomo has been in the tech industry since 1994. And he lives with his wife, son and 2 dogs.LinksClouded Torah: https://www.clouded-torah.org/SponsorChronosphere: https://chronosphere.io/?utm_source=duckbill-group&utm_medium=podcast 

I'm trying to protect you kind of in both places. So whether you get a spike or whether you've got this gradual increase, you'll hear about it. It's up to the user to actually do something about those budgets when you get the notification. Welcome to Screaming in the Cloud. I'm Corey Quinn. I've been talking to Shlomo Dubrowin, who is a senior technical account manager, or TAM as the kids say, at AWS for years, and somehow I have never been able to get him onto the show until now. Shlomo, thank you for agreeing to talk with me. I can only imagine the internal machinations that must have led to this. Thanks, Corey. Complicated environments lead the limited insight. This means many businesses are flying blind instead of using their observability data Thanks, Corey. with end-to-end visibility and centralized governance to choose and harness the most

useful data. CY Chronosphere was named a leader in the 2024 Gartner Magic Quadrant for Observability Platforms at chronosphere.io. I want to start off because I've been trying to get a technical account manager on the show for a while. And to my recollection, 600 episodes in, I believe this is the first time I have a current TAM at AWS. So let me begin by first saying thank you for the amazing work that you folks do. And I'm sorry for the things that we as customers

tend to inflict upon you on a nearly constant basis. Thanks for all of the TAMs around the world. We appreciate it. All the TAMs appreciate it, except Stephen. Stephen can't stand you. Yeah, it's great. There's always that one exception there. But no, you folks do hard work. You're sort of the face of every technical question that people have about AWS, particularly when something isn't working correctly.

And there's a common pattern where people get annoyed that you don't instantly know what is going on with a particular service in a particular availability zone or fraction of availability zone specific to their account off the top of your head, given that you folks generally don't make things up from whole cloth. That's true. And we also don't know the status of every case and every question that you haven't asked us yet. It's always felt to me on some level, like the job is that of a traffic router where you are, you're taking questions from customers in the, in the reactive sense that you do a bunch of proactive stuff too, but then the reactive side, something's going on. The response is great. Let me check on that, which is the right answer when you don't know. And I thought, I found that the response time for Let Me Dig Into That

has gotten progressively shorter over the years. So I sense the hand of automation at work. As I've gone through this journey, and I've become, I personally have become more efficient, I definitely answer faster. And I definitely find myself either knowing the answer off the top of my head, not always, but obviously, you asked me a question, I might have encountered that before. And so I can give you either this is what happened last time I had this question, or this is what I think is going on, but let me get the details. And yes, we have more mechanisms internally to route these things or to get the answers quicker. What I have found that has gone surprisingly well, I suppose, has been just the way that you have been able to, you collectively, not you personally, for better or worse, I've not yet encountered you on a client engagement.

But it turns out there's kind of a lot of TAMs and kind of a lot of customers as well. But it's always been interesting just watching how well you field questions that without context come across as wildly unhinged and if there's one thing that i could improve the customer base across the board and i guess the industry across the board it's asking questions in a way that makes it easier for people to help whereas i'm doing a thing i expect it to do x instead i'm seeing why can you help me understand what's going on? That's a form of a good question. Whereas this thing is broken, terrific, and almost totally unactionable. So if this entire global service were down, I get the sense I would know because

everyone would be running around screaming. That's not happening. So can you be more specific, please? Yeah, for sure. So I definitely have spent some time working with my customers where they ask a question that when it gets to the other side, to the human on the other side, who's trying to decipher it and answer it, either they don't have enough details, they don't know what's going on, they don't have any of the background. So if I have that background, because I know the customer and I know the whatever workload is having the issue, then I can give that to the support folks kind of behind the scenes. Having your TAM knowledgeable of what you're doing and what's going on. Oh, they're doing a migration for whatever service this week.

Then having that knowledge ahead of time, then we can help smooth things along and get you answers faster. There are times where I have to go back to the customer and find them. Often my customers are available on some kind of messaging platform, whether it's, you know, I don't need to mention all of the 50 different messaging platforms, but knowing how to get a hold of Bob on messaging platform three, then I can go and ask them, okay, I saw this case. is this what's going on or is it this? And I can get some of those details and provide them to the support folks so they can actually go and do the digging that they need to do to get real answers. One thing that you've done that really brought this to a head,

which is why we're having this conversation now, is you have created something that is so awesome, I can only assume that it was proposed as an internal AWS service and was rejected by the SVP of bad decisions, whoever that may be. It's something called AWS Reasonable Account Defaults, which is a very AWS-ian name that you built as best I can tell in what amounts to spare time. Yeah, basically, I was interested in this. So I spoke twice at reInvent Chalk Talks on ways

to avoid cost surprises. And when I came back from reInvent Chalk Talks on ways to avoid cost surprises. And when I came back from reInvent last year, a friend of mine said, look, my child's going to university and they're going to start learning AWS and they're worried about cost overruns. So what do I have to do in order to protect my credit card? And so I was like, oh, I just gave a talk about this. You need to go over here and do this. You need to go over here and do that and do this and do this.

And I had nothing concrete to give them. Recently, I put this together, like you said, kind of in my spare time. I've actually used this myself. I've had versions of this personally, but I wanted this to be super easy for a free tier new user to use. So I made it into... No, that is, you are getting spot on to exactly where I want to dig in because it's, when you say reasonable defaults, reasonable for whom? One of the failure modes I found about AWS historically and a number of large companies, a number of companies across the board is they try to treat every customer the same, but you functionally can't. And this is a perfect example of how. If I'm spinning up a new

account at a bank, yeah, I don't really care about whatever your cute little free tier might be. Money, ha, we are money. Versus I'm a student in my dorm room. I absolutely want you to turn my website off rather than charging me $50,000 by surprise. And it's not just about money it's about reasonable approaches to spent to to governance i i just want this thing to work everything within my aws account should be able to talk to everything else is reasonable for someone getting started as an independent learner very unreasonable if you're a bank and there's a continuum between those things and where those where any given customer lands it leads to different outcomes and answers. So who is this built for?

I kept in mind the free tier new user that is, I mean, I remember when I started and I was afraid of what was going to happen. That's who it was built for. And that's who the defaults of this CloudFormation template were built for. But it's configurable. So if you are that bank and this is a project account, then you can change those defaults. The first thing it does is it's going to create two budgets for you. It's going to create a fixed budget, forecasted. I learned the minimum that

you can set for a budget is a penny. So at 80% and 90% of a penny, it's going to send you an email saying- And I get that email every month, generally two or three days in, because there's some lag time behind it. And the name of that budget is, and I'm not kidding, shriek like hell if I owe money. Okay. So mine's not called that, but that, that works. It's my credit dump account, which is why I want it to shriek. If I actually owe real money, there's the, for most people, this is not their actual concern. But I start there, to be very honest with you, it's sort of a smoke test of,

is the budget system working this month? Because if not, do I care about a penny? Not more than is reasonable. Do I care about $50,000? Yeah, I do. That does put a bit of a crimp in the Christmas at the Quinns most weeks. But yeah, those things in between there tend to put a bit of a crimp in the Christmas at the Quinn's most weeks.

But yeah, those things in between there tend to be a sort of graduated study. I just want to make sure that it's working and is this thing on. That works for you. So some people really would get upset if they hit that penny limit. So that's the first budget that gets created. The second one is an auto-adjusting budget. Because what ends up happening is as you start using stuff, you might blow past that penny budget. And so, okay, you're going to get into the $3 range or the $4 range or what have you. I created also an auto-adjusting budget. So as you get past that and you get that, you hit the penny, the shriek, as you called it, budget on the first day, there's another one that's auto-adjusting. So over the last six months, whatever your average

usage was, your average cost, that will keep adjusting. It tells you at the beginning of the month. And so that's another budget. It's another way to kind of keep your eye on the ball so that you know, okay, I'm about to get, costs are increasing. I'm about to get somewhere where I don't want to be. So that's the second one. So there's, I'm really worried about free tier. And then there's the, no, I'm spending a little bit, but it's okay. Without having to do anything, those two will get set up. And then I also set up a cost anomaly detection. The cost anomaly detection, again, you can set the threshold.

The default is, again, a penny. So any spikes that the cost anomaly detection will find, it will notify you about. And so I'm trying to protect you kind of in both places. So whether you get a spike or whether you've got this gradual increase, you'll hear about it. It's up to the user to actually do something about those budgets when you get the notifications or the cost anomaly detection. If you get a notification saying, hey, there's something fishy going on, you should go look at it and you should go determine what's going on so that you can look into it and understand. So those are the first.

That's kind of where I started. And I built these using the infrastructure as code generator, which is part of CloudFormation, because I'm a ClickOps person. I'm actually a Bash programmer. Oh, excellent. I was wondering about that because looking at it at, it's just under 1,800 lines. When my brother visits from Israel, he would always speak to my dogs in Hebrew, and I would say, Yossi, why are you doing that? They don't speak Hebrew. And his response is, oh, they understand it. It's God's language. Now, I don't know exactly what God's language is or is not, but I know the exact opposite is YAML, and that's what it's written

in, 1,800 lines here. I was going to ask, did you sit here and painstakingly write this entire thing by hand? Because I would be clawing my eyes out by line 800 or so. I took piece by piece. I took this budget, this lambda, this, which we'll get into in a minute. I took each piece. I kind of got it working in one account, ran the infrastructure as code generator, got all of the IAM permissions and everything I needed for that. But then I needed to modify it because if you run the same YAML, you run the same CloudFormation, again, it won't work because you've already got something named A, B, C, or whatever you've named them. That's where you'll see there's all kinds of funky stuff that I do in there in order to grab part of the stack ID, the invocation ID. So I've got some randomness in the name. So I can actually run this over and over again, and it will create more and more and more resources. And so you know which one is which. They're all separate. Complicated environments lead to limited insight. This means many businesses are flying blind instead of using their observability data to make decisions, and engineering teams struggle to remediate quickly as they sift through piles of unnecessary data.

That's why Chronosphere is on a mission to help you take back control with end-to-end visibility and centralized governance to choose and harness the most useful data. See why Chronosphere was named a leader in the 2024 Gartner Magic Quadrant for Observability platforms at chronosphere.io. What I like about this approach, and let's be clear, there have been a number of tools, scripts, half-ass bash script, etc., that have been thrown up onto the internet over the years. And they all tend to make more or less different versions of the same error that, as best I can tell, you have very neatly sidestepped. In that you're envisioning the use case of someone starting out on AWS for the first time with an account. Great. Go ahead and implement these things. But as soon as you start implementing it into an account that's been around for any period

of time, it will either conflict and fail, or it will stop on something that really should have been there already or was there, which deleted a bunch of logs because we've decided you don't need those anymore. What you've built takes into consideration that, oh, if there's an existing CloudWatch log group that has an existing retention policy, don't touch it. It is presumed that that is there for a reason. So I haven't done the full analysis on this, but I suspect there aren't any accounts I can think of in which if I were to deploy this, it would cause data loss or break someone's application. Right. So those are two other pieces that you're kind of referring to. And yes, I tried

very much. So I deployed this in my account that I've been using for quite a while, and I've deployed it in new accounts as tests. So there's two Lambdas. And I did this, like I said, I'm a Bash programmer, right? So when I first started doing Lambdas, I used a custom runtime of bash and someone nicely created a layer. I have the exact same boat. I have I have done crappy lambda layers that are hooking bash scripts through Python executes, then wind up running proxy servers on a socks proxy locally to wind up doing weird things with tail scales and lambda layer. But all my stuff is crappy bash. And then I somewhere along the way managed to graduate to crappy Python. Speaking of crappy approaches, I appreciate you're taking the approach of running it in your various test accounts and not that crappy Tam Steven that we talked about mythically

as I'm going to run it in just my customer's account to see how that works. That's OK. I think they're a hospital. But what does that matter? Yeah. You test things where the blast radius is constrained and the failure mode doesn't make the headlines. For sure. So I definitely tested in my own accounts. I created new accounts. I even created a new account with a credit card, which I hadn't done in many, many years because I wanted to make sure that like cost explorer was enabled by default and what things were enabled or not enabled by default. And yes, I write in Bash recently, I guess about a year or so ago, I started writing Bash containers.

I've got a little script that does the compiling for me, the Docker compiling and pushing it to ECR and then telling the Lambda to use the latest one. That's on my GitHub as well. Anyway, so I have two instances that I do this on. I've got one Intel-based and one Graviton-based, so I can do ARM or Intel-based Lambdas for whatever, if I need it to be one or the other.

So that's how I would write this for myself, but I'm not writing it for myself. I'm writing it for the audience. I used Bedrock and a front end that we have here internally for Bedrock. So I basically asked it, I need a Lambda Python that does this. And it helped me put together a framework

and I had to iterate over it. And I can read Python, but it's hard for me to write. And it helped me generate it. So instead of taking me, say, a week to write a Lambda, it took me about an afternoon. There's two important Lambdas that I'm running there. And one you mentioned where it's going to, it's trapping CloudWatch log group creation. That's using EventBridge to do that. It'll set a default retention policy

and that you can choose the retention policy. It's one of the options that you choose when you first start up. Mine is like 30 days. And the other Lambda is S3 multi-part upload lifecycle policy. And I set that for a week and I didn't make it configurable. I could if we needed to. Those two lambdas are mostly there. Those are kind of very low hanging fruit and they're there to protect the user because when you create new lambdas, then it's often that you end up with these log groups and they just kind of keep growing and growing and growing. And the multi-part upload fragments, which are kind of invisible unless you turn on S3 storage lens.

But for a new user, they're not going to know about that. I set it for a week. If you're going to continue your upload, your big upload within a week, you're good to go. If not, it'll quietly go away. Now, there were some other things that I had to do in order to get those to work, which might be interesting to some folks on a technical level. Yeah, that was going to be one of my next questions. For example, I don't believe that you can have CloudFormation enable IAM access to billing data. I think that has to be done in the account via mouse click, but I confess it's been a few years since I've looked into that. You're talking about for the budgets?

Budgets may be separate from this. I remember that there's a, by default, IAM users cannot look at spend data in accounts until the root user clicks a checkbox historically. It is entirely possible, I'm misremembering this, again, it is in years. I don't know, but I didn't touch that. Wonderful. And in a brand new account, you spun up and it just worked. Okay. It is entirely possible that events have once again outpaced me, which is kind of a good thing. If I can't keep up with the pace of innovation, that's positive. So Cost Explorer was enabled by default, and I was able to get to it inside the account. I didn't have to enable it there. I did have to enable CloudTrail. And I know that CloudTrail can be dangerous because it logs stuff and it can get expensive, and especially if you have more than one, right? The first one is free. And in a lot of cases, it can get even more dangerous by not enabling it. But yes, you're right. Right. So what I've done there is I have a Lambda that the CloudFormation pushes. And by the way, you talked about YAML being dangerous because of the spacing.

So I did Python in CloudFormation. So it's Python, which is whitespace specific, and YAML, which is whitespace specific. Wow, you must really hate yourself. It took me a few iterations to get that working. Things were like not aligned and not working. So that was quite entertaining. How did Preston took only a few? That's wild.

Yeah, that was a little frustrating. So I have a Lambda that gets deployed by the CloudFormation. And what it does is it looks in all of your enabled regions for CloudTrail. And if there is a CloudTrail enabled, it stops. It doesn't do anything. If there is not a CloudTrail enabled, then it's going to go and create a bucket for you. It is going to enable a CloudTrail and log to that bucket. So I'm creating the resources for you.

Now, this is the only place in my account where I've seen expense. And that's from the CloudTrail requests of the pushing the logs into the S3 bucket. And in my account, where I'm using it, you know, periodically here and there for building my website, it was like one or two cents per day. 30, 60 cents a month, I thought was reasonable for this. And I put a note in the GitHub that I want people to know that there is this possibility. But I needed that in order to be able to trigger the lambdas on the creation of the bucket and the creation of the group. People often think that my perspective is, oh, AWS should never charge money at the end. That is far from true. I think it needs to be

transparent upfront. If you say, I'm going to cost you 36 cents a month, and then you cost them 36 cents a month, no one is angry or upset unless they're a lunatic. The problem I have is, oh, I assume this is going to cost me nothing. Why did it just cost me $200? That is concerning what gives, what didn't I understand. It's the predictability and transparency aspect more so than it is the never spend money for these services, which I am receiving. That's not a sustainable model. So I try to be very upfront. And I talked about where I tested this and where I saw the costs. And the other thing that I also do is there's another Lambda that gets deployed, because you mentioned I'm in Israel, and we launched a region like a year or so ago. And so it could be that someone's going to launch a new region. If you're sitting out in Taiwan, and Taiwan launches next week or next year, and you turn it on, you're going to want those benefits of these Lambdas that you deployed somewhere.

There is another Lambda that gets run. It gets run by CloudFormation when you first set up the system, and it gets run again periodically. You choose how often you want it to run. Once a day, once a week, once an hour, you choose. And it goes out, it goes to all of your enabled regions, and it makes sure that you have those event bridge rules to forward the CloudWatch group creation and the S3 bucket creation to those lambdas. And that's it. That's a good approach. It's solid.

Are you looking at expanding this down the road to encompass things beyond cost of the basic things to do when you first set up an account? Setting up, for example, OICD relationships between this and GitHub, hypothetically, or more importantly, a prerequisite for that, IAM Access Identity Center. So instead of using IAM users themselves,

in fact, it used to be called AWS SSO, now with a crappier, harder to remember name. So I'm definitely open to ideas. I wanted to keep this simple and I didn't want to force people to do this or do that. Especially so like if you're a free tier user and you're getting started, I didn't want to make it too complicated. You grab a YAML, you go over here, you answer five questions. Right now,

it can only take one email address. There is a method to get it to take more. There is a method to get CloudFormation to iterate over multiple things in a list. I haven't gotten it to work yet. I think that this is, I think you're in the right direction on this. I could see a scenario in which it becomes one of a number of nested stacks where you can effectively turn this into almost a mini application of sorts where check the boxes on the things you want, like cost surprises. Yes. I definitely want to be, I want to have that set up in my new account. Security. Yeah, that's job zero. And I give zero craps about it. Great. People are

going to people. That's what they do. And being able to pick and choose between those things that they want starts to be handy. On the other side of that coin, though, it turns into analysis paralysis. It's great. Sometimes I want two or three choices. When I have two or 300 choices, I sort of freeze and give up. and it's too much decision fatigue. Right, for sure. So again, I wanted this to be, you know, to be super simple for a new user, the defaults are there for the new user. If I was a corporate user, or you know, someone that has a TAM, I can imagine that this same CloudFormation could get used during account vending. And you would use different defaults, you would have a distribution list for the notifications, and you could use, instead of a penny here and a penny there, it could be, I don't know, $100 or $50 or $500, whatever is important to you.

One thing that I find odd is that most of the documentation on this is how to go ahead and install it via ClickOps, which, sure, I get it. That's my approach, too. But there's no quick and easy way for several fascinating and valid reasons to be able to just take, here's a CloudFormation template, go ahead and apply it as the root user in your account, go. You have to talk people through the various clicks

and where to do these things. I can't shake the feeling that there is a better way to vend something like this to a Cloud account, but I'm unaware of anything that resembles that these days other than maybe some of the quick start click buttons and it opens up in the cloud formation window almost ready to go. But even that, as I recall, seemed issue or feature request for the AWS console of make it easier for me to take something external and apply it to my account. Yeah, no, it's an interesting idea.

Like, you know, when AWS launches cloud formation-based things, right, there's that launch button. So you just click on that and it takes you automatically to probably Virginia, to the Virginia region, and it launches it in CloudFormation. Part of the reason too, is I'm trying to save you work down the future because I, one of the reasons I don't tend to do videos, especially, and also mostly blog posts where I have screenshots of what's going on in the console as an instructional is that every once, every, every every once in a while someone on the console

team apparently decides to try and get promoted by doing a redesign of something or altering the way something works and on the one hand yes this is usually an improvement and better for customers on the other that's a whole lot of material i have to go ahead and adjust i'm sure someone who is very bloody minded is going to file an issue next week or so on yours because at the moment on one of the screenshots is shows the search bar and there are 16,724 results for cloud formation the documentation and when there are now 16,725 next week someone's going to want to update the screenshot at which point you close the issue and block them but when they completely redo the cloud formation console at some point who knows when that happens great you. You're back to, oh, no. Oh, no, now I have to redo the screenshots or it looks dated.

And that's one of the biggest problems I think AWS has with updating things and making improvements is that there's such a corpus of community work on how to go ahead and do a thing. But if you follow a how to set up a static website on AWS tutorial from 2012, you're gonna have a bad time 12 years later. Yeah, for sure. I can see that. Not sure what the answer is. But it's one of those areas that I think would, would benefit further down the road. I suppose we're going to find out one of the topic I want to talk to you about as well that you started to get into and I cut you off is you built this partially with the assistance of generative AI. Normally, I flinch when people start talking about Gen AI and their email address ends in amazon.com. But what you're talking about is exactly the way that

I think Gen AI should be used. I've used a number of tools myself to make up for the fact that I'm a terrible programmer, but I'm enthusiastic about it. And iterate on this piece of it and help me build the thing out. It really is a force multiplier. That's a great use. Yeah, it was really great. Looking at a blank page and saying, okay, I need to write this in Python, which is not my first language of choice, was a little intimidating. And I really thought, okay, how can I do this? And so I went to the Gen AI and I said, give me a Lambda that does this, you know, that does the CloudWatch log group retention policy. And it gave it to me. And there were a few other pieces.

There was another interesting nuance in the Lambdas that get run by the CloudFormation. Those are running as a custom resource, if you're familiar with that. And CloudFormation is expecting an answer. And if it doesn't get the answer it expects, it kind of just sits there and waits. Now, some of those lambdas need to also run as a regular lambda. And so the response needs to be different for CloudFormation than it needs to be for when you're running it as a regular lambda. I wanted to kind of trap that in the event data. So I needed to set a variable to trap that.

But if you have a variable that's not set in Python, it complains. The Gen AI is the one that came up with the one-liner that basically said, if this gunk is in the event data, then set it this way. And if it's not, set it that way. And it was a beautiful one-liner in Python. And I could understand it as soon as it came up with it. But me writing it would have taken a long time. Oh, that one-liner would have been 15 lines if I had done it at best, and I would have gone the tossing a Frisbee to yourself across the street and running across to catch it pattern that I tend to fall into when I start attempting badly to do distributed systems.

Yeah, it really is elegant at distilling things like that down. Now, the challenge I run into on the one hand is that when you have it write applications and pitch in, it starts coming up with different approaches for every question you ask it. So it looks like a bunch of spaghetti code. But honestly, am I any better when I'm searching in Stack Overflow? No. In fact, I'm arguably worse. So it's just an evolution of the same old problem. This way, it's just a lot more efficient slash faster. Yeah, and not only that is you can actually give it the errors, right?

So it gave me something, I tried it, I got an error and I said, I got this error and it gave me a fix. I think you win the gold star of first conversation I've had with an AWS employee who suggested a use for Gen AI that was awesome. Good work. Go Tams. Exactly.

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? Hi. So the best place to find me is probably the website that I mentioned that I just launched. It's clouded-tora.org. So it's C-L-O-U-D-E-D-T-O-R-A-H.org. And you have to use the www because it's CloudFront.

There are sneaky ways around it, but those are fun and exciting. And hashtag dot all up, some restrictions reply, void where prohibited. Yeah, I will, of course, put a link to that in the show notes, which is probably easier for people to just do the clicky clicky with the draggity pokey finger stick. But thank you very much once again for taking the time. I really do appreciate it. Thanks, Corey. It's been great. Shlomo DeBrowen, Senior Technical Account Manager, or TAM, at AWS. 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, insulting comment that I'm not going to have time to read because I didn't apply this and I have a big AWS bill to go deal with.