# 377: The end of stack overflow and we know it… and AI feels fine
Duration: 107 minutes
Speakers: A, B, C
Date: 2026-10-29

## Transcript

[00:07] A: Welcome to The Cloud Pod, where the forecast is always cloudy.

[00:10] B: We talk weekly about all things AWS, GCP, and Azure.

[00:14] A: We are your hosts, Justin, Jonathan, Ryan, and Matt. Episode 377, recorded for the week of October 20th, 2026. It's the end of Stack Overflow and we know it, and AI feels fine.

[00:29] B: Hello, hello, hello.

[00:31] A: We got a special guest treat for our listeners. We got a special guest since, uh, Justin has abandoned, uh, me and, and Matt. So we felt we needed some additional supervision.

[00:41] B: So from what I understand, it's not actually supervision. It might just be more kids in the asylum.

[00:45] A: It's just gasoline to a fire.

[00:47] B: Yeah.

[00:48] C: Who's ran the delay button like so you don't get fined by Ryan?

[00:53] B: It's the one week lag that we have and it's still not enough.

[00:56] A: Yeah, exactly. All right, well, introduce yourself, Mr. Cody.

[01:01] C: Yeah, my name is Cody Chandler. I'm an old hat in the technology industry. I've been doing it for almost 30 years. They call me one of the beards in technology and just here to try to make fun of Ryan and hopefully convince everybody that they should never run SQL Server on Kubernetes.

[01:26] A: Nice.

[01:27] B: Yeah, I really thought you were gonna go with the Eagles joke there. I'm just saying.

[01:31] C: No, Heather will get that. Heather. Yeah, Heather and Bolt will get that for sure.

[01:37] B: It's so bad because Bolt is trained on so much of the history, how cynical it is at this point too. You're like asking a question and then it like makes fun of Kubernetes for us, and I'm like, oh no.

[01:49] A: Yeah, it's pretty great.

[01:52] C: Thank you very much for having me on here. Um, very excited to go through and be a part of this thing. I, I would like to say, uh, uh, thanks a lot, Matt, for, for going through and sending me all, uh, the notes of things that I should be aware of for the show. I would like to say that it really kind of freaked me out that AI was reading me things about how AI was going to devastate the world.

[02:18] B: Well, that sounds about right. So for our listeners, one of the features of Bolt that we've added is it reads us the show notes. So if you're— one of us is walking the dog or whatever, it will actually just produce an MP3 file like a day before and it just will read you the notes. And that is what Cody is referring to, that feature of Bolt.

[02:39] A: And I still don't do it.

[02:41] C: His beautiful voice goes through and says AI will be the devastation of your life. It's like, it's the absolute opposite of like a self-help documentary, you know? Like, you know, you are good enough. It's like, no, you're not, right?

[02:56] B: You don't use half the features of Bolt. The integrated calendar link that you, that you can always save you every time that you need to use. Uh, there was one the other day you were like, I was like, it's built out of the scheduling I think once you did.

[03:12] A: Oh yeah. No, I try to use the scheduling when I remember. Uh, it usually takes me 27 tries to remember it and then I try to ask for help and, and then Bolt makes fun of me cuz of it's been trained on the shit.

[03:22] C: It's Bolt.

[03:24] B: Yeah, that sounds about right for Bolt.

[03:26] A: Uh-huh.

[03:26] B: Yeah. How many years have you been a host of this podcast?

[03:29] A: You don't know how to do this? Like, shut up, you stupid machine.

[03:32] B: We should make it be like even more tacky. Like if you type a command that doesn't exist, be like, are you stupid? Come on, figure this out. Help should definitely give you a sassy response back too. Just saying. All right, shall we kick us off with follow-up news?

[03:47] A: Let's do it.

[03:50] B: All right, OpenAI models have hacked something else this week. They've hacked a crypto wallet and breached even more websites. After OpenAI disclosed the Hugging Face breach a couple months ago, they've now disclosed 4 more incidents that occurred where its internal models hacked or bypassed restrictions during training. I'm really thinking somebody needs to get fired for how their environment is set up. Since the July disclosure, when test agents exploited a zero-day in an internal— in an internet-restricted tool, also known as Artifactory, broke Hugging Face networks and steal benchmark data, OpenAI has reported 4 additional June instances— I think it's October, I'm just saying they're a few months behind— showing the behavior was not nicely. Two of the new cases involved hacking websites when direct retrieval failed, which is definitely not what we do in Vault. I'm just saying. And one, a model denied access to hospital bed statistics on the government website, used a file download feature to pull up the server configuration and file and credentials. Bypass the authorization check and save the data locally. Holy crap. Another incident reportedly involved a model where it exposed credentials to draw cryptocurrencies from a wallet when it could not otherwise access. The model also bypassed companies' imposed browsing restrictions. The article did not give full details about how everything was done though. So sandbox egress controls are set up really well at OpenAI, up here, my understanding.

[05:23] A: I'm just kind of hoping that this is still like discovery of things that previously happened so that they've addressed these things, but it's not really clear whether that's the case. And so it's like, it, it, you know, we keep reading these stories and it kind of just feels like it's like, oh yeah, broke out again. Oh, it broke out again. Oh yeah, still getting out. But I hope it's all just sort of like going back through discovery and just being like, oh, it did this. Oh no, it did this. But it's getting kind of scary.

[05:52] C: It's going to have to come to accountability, right? Like somebody's going to have to be held accountable. You can't just be like, oh, we wrote this neat thing, it's doing this silly stuff, oops, right? You've got to go through and help hold people accountable. And if that's the CEOs or whatever, they've got to figure out how to put limits on these things. I mean, like even in internal home networks, We're trying to do this. A bunch of us are working on, you know, internal models and internal gateways to go through and kind of limit our token usage. But instead of token usage, it's like hacking the DoB, right? Yeah.

[06:34] B: Yeah.

[06:35] A: Can you imagine trying to like fine-tune one of the open weight models and you're trying to test it internally and it all of a sudden breaks out and starts hacking all these different sites? Like we're, OpenAI is, you know, reporting on it and making it a press brief, all of us would be in prison.

[06:49] B: It was just the FBI's knocking at your door, like, come on, guys. That's where some of it needs to eventually go. It's like, great, you are finding vulnerabilities, you're disclosing them, maybe a few months too late. And, you know, they're talking about these things in June. The Hugging Face one got a lot of publicity in July. Kind of wondering why it took them 4 months to talk about these. You know, at one point I would almost just throw them all out in the news at the same time and be like, we accidentally did this thing and look, here's 5 examples of how we messed up, but this is how we're fixing it. And it's the accountability on the backend that we're not seeing. You know, their CISO saying, look, we are going to come out and yes, our tool is hacked and they're not configured properly, but this is how security is stepping in to help control the guardrails of everything. Or this is how our QA environment is now being reconfigured to not— we have a physical— no physical network connection or something. I don't know, they gotta do something here to make these things. But then again, it was 4 months ago at this point, so is it a moot point already? I don't know.

[07:54] A: Yeah, I can guarantee you it didn't take them 4 months to talk about it, not internally.

[07:59] B: Yeah, no, they've been talking about it for more.

[08:02] C: Oh man, it's really bad. Yeah, I've been in those, uh, before publicly released, oh no, this is really bad conversations. But, you know, uh, we have a dog and it does a lot of stupid stuff, and the dog is not a human. And, uh, I try to train the dog to be very good. She can sit, she can close doors, she can do all sorts of cool stuff. But every once in a while she goes through and is in the neighbor's yard or, you know, poops on the neighbor's front yard and I have to go like, sorry, that's me, I'll go clean this up. But ultimately it's my responsibility. And I think that because everybody thinks that AI is so cool and they love being on this like frontier and we can't inhibit these things, that nobody wants to take accountability. And it's like, ultimately it's your puppy.

[08:58] A: Mm-hmm.

[08:58] B: Yeah, it's the accountability that's lacking. Like, and like what Ryan said, if we did this, we would all be in jail. If a company does it, it's fine, don't worry about it. All right, to our follow-up section. So unlike, I think it was last week when Justin made fun of it not working, we've fixed it so it adds to the show notes now. And We have two, one that Ryan and I decided was boring and we didn't care about it really, only Justin would've cared about it. But this one was, if you guys remember from a year or two ago, Amazon came out and said, we don't trust moving our systems over to O365, they're not secure, it has not passed our internal audit controls. And so our follow-up is, did Microsoft ever fix the security issue? Issues that stalled the Amazon 365 rollout. And what we did find out, this is back in episode 336 that this was a follow-up from, was yes, Microsoft resumed their O365 rollout in 2025 after Microsoft addressed the security concerns. They did not abandon their plans and went ahead with the deployments. So good news, they moved forward. So maybe Microsoft is now better and more secure. Not sure.

[10:19] A: It's at least more secure enough for Amazon, so I guess that's good. Like, as I don't want to run my own exchange, I understand why Amazon didn't either. So it makes— I'm glad that they were able to like pivot to that. I'm glad that it helped Microsoft because as everyone who's a Microsoft 365 customer is going to benefit from whatever improvements they've made because of that. It's good news.

[10:41] B: I don't think I've run an exchange since like 2012 or 2014, whatever year it was that was. And I was happy to never— there was not— oh, it must have been 2013, sorry. Um, and it was a pain then, and I don't envy anybody that runs it. I don't envy anyone in the Microsoft 365 team that runs that system. It was not stable then.

[11:09] C: Everybody who looks at anyone who runs exchange thinks they're idiots. However, everyone also will not run exchange because they're not an idiot. The worst.

[11:26] B: Yeah. And anybody who says— The cynicism is really high with Tony today.

[11:31] C: Yeah. Yeah.

[11:32] B: Vault is going to get to a new level of cynicism after this episode. Uh oh.

[11:37] A: Okay. Moving on to general news. KDE turns 30 with Plasma 6.8 and other remote upgrades and a farewell to X11. So it's finally dropping native X11 support in favor of Wayland. Shift worth quick discussion. Sorry. No, it's perfect.

[12:05] B: Perfect.

[12:07] A: Plasma 6.8 removes the ability to start new X11 sessions, making Wayland the only native session type. Legacy X11 apps still run through XWayland, and users on Plasma 6.7 keep their existing sessions for now. KDE follows GNOME, which dropped X11 support in 2025. And the 42-year-old X11 protocol, really, is losing its remaining major desktop holdouts. Which matters if you're running a Linux workstation, a VDI, or any other older tooling. The built-in Remote Desktop Server was reworked and network-accessed virtual displays, and the new features include a clipboard sync between client and server and an exclusive mode that locks the physical display while the client sets a matching virtual one. Also, there's adaptive streaming for slower networks, and that's very relevant if you're running your own home lab or accessing Linux distros remotely. Other notable changes include NVIDIA triple buffering enabled by default, CUP backup integration— is that like the CUPS printer thing? I think it's different— and a streamlined union theming session, and a system monitor that lets users pin processes for specific CPU cores through the GUI. KDE released a documentary, The KDE Documentary: A Story of Free Software. Alongside the milestone, it ties into a year-end fundraiser and a reminder of how community-funded open-source desktop projects sustain themselves. I've never, I don't think I've ever heard of like a open source software releasing a documentary about how it's born. That's kind of, kind of interesting.

[13:34] C: It was like, we were worth it, guys.

[13:36] B: Yeah.

[13:38] C: Look what we did. Oh, look, X11 is, makes me sad because that was the first time that I figured out how to play a fart noise on somebody else's computer, which really taught me like, this is what I want to do. Of my life. But also, I worked a ton in X11 and KDE. Well, KDE was an upgrade to what I was doing because using the, uh, SGI RX boxes, um, but X Windows and having a mouse while using a Unix terminal was like a huge upgrade. Um, and then also being able to go through and kind of remote session and have a remote computer's window on your computer, um, which I'm taking a long time to try to explain to that because it's kind of— nobody would know that this is important.

[14:35] B: But yeah, like X forwarding was a big thing, and getting that to work was a pain in the neck, but when it worked, it was fantastic.

[14:42] C: Yeah, but I mean, like, and then there was a whole company built on this, right? Like Citrix, right? Was what's built on this. And it was stuff that we as nerds had had for, for years. Tons of cool stuff, uh, that I did with, uh, you know, X11 that, like, I'm kind of bummed. There's the TAPS was well played, sir.

[15:06] B: Well played. I remember fighting with X11 on Gen 2 for quite a bit to get to work, but once that thing worked, it worked. And like you said, it had a lot of really nice features that people didn't use, but configuring it and dual screen configuring it back in the day, that was fun. That required a new level of hating your life.

[15:27] A: I was gonna say, fun is not the word I would describe it.

[15:30] B: Well, if you're listening to this podcast, then you probably have the same definition of fun as we all do.

[15:35] A: I'm just saying.

[15:35] C: So I can tell you, life-changing for me, X11. There was a guy who ran a CNC machine. And they, when you run a CNC machine, you run it 24/7. It runs all the time. Um, he would run into problems Christmas, New Year's, 11 o'clock at night, 2 o'clock in the morning. And I was on call and this is '98. Uh, so I'd get a phone call and he'd be having a problem and I could connect via VPN and then bring up X11 to go through and troubleshoot his problem. Life-changing, right? It saved me from, you know, an hour's worth of travel to go into the office. Um, and those are things that we take for granted now, right? Like with all the silliness you can do just for things that come on a MacBook when you buy it.

[16:29] A: Yeah. But network KVMs, like all kinds of crazy stuff that exists now that didn't exist.

[16:33] C: Oh, KVM. Oh, Jesus.

[16:35] A: Yeah. Yeah, no, I mean, that's, that's where I learned about X11 for the first time as well, right? Similar type of thing. Used to set up like the, the initial tools row for data centers and it was like whenever there was an issue with that stuff, there's no infrastructure to lean on. So you're, you're kind of like, you know, hacking into your own stuff a little bit, trying to get it to work again after you go away. And if it, if I couldn't get it to work, I'm taking another plane ride out to wherever this data center's located.

[17:01] C: Yeah, you take a plane ride out, grab a crash cart. Hook up a VGA monitor to the, you know, back of some 4U unit.

[17:11] A: Yeah. In a cold hair dryer.

[17:16] B: Yeah.

[17:18] A: Super fun. Don't miss that at all. I kind of do actually, but that's cause I'm weird. Anyway, moving on. The Yandex adage. The data shows that instead of going dark, the malicious bots went on the move. After it was reported that Ukrainian drone strikes on 3 Yandex facilities, traffic from Yandex networks collapsed and people online assumed that the Russian bot farms went down with it. Cloudflare analyzed the traffic from the 2 ASNs and reported that the strikes to the data centers and found that search crawling stopped, but the one operation Cloudflare could trace in detail simply moved the, to other Russian hosts with the same code, the same fingerprints, and essentially the same volume. While the traffic in the networks collapsed by 90 to 99% around October 11th, the aggregate HTTP volume only shows a single network that went down, and this says nothing about whether the malicious bots were disrupted. The two SAs behaved very differently, with the nginx search was only 99.5% automated and mostly verified crawlers like Yandexbot, so the main effect was less search indexing, with publishing a new site seeing a 44% drop. However, Yandex.Cloud was about 95% bots, none verified, and looked like the application encrypted traffic. Malicious automation migrated rather than stopped, and bot requests from Yandex.Cloud to one gambling customer dropped to zero on October 8th, with identical requests appearing on other Russian hosts like Redis and SelectL. Attack traffic fell on Yandex.Cloud, um, but social media bots and post-like reply traffic showed no unexpected shifts. CloudRail— Cloudflare notes that it can rule out connection using data outside its own network. I guess the key takeaway is that AS and volume is unreliable proxy for threat activity, and cloud workloads are portable and can move providers within hours. Detection key on behavior such as shared TLS fingerprints, request rates, and WAF rules with very sensitive endpoints.

[19:13] B: So what I'm hearing is they have properly configured their design for failure. People running these bots, and they have full HA and DR capabilities. And this is what every business should strive for. And it just shows it's a business. If they're offline for minutes, it costs them X millions of dollars. Yeah, it's kind of sad but kind of true. Like, right?

[19:36] A: Like, so yeah, the attackers have learned DevOps principles.

[19:39] B: Yeah, right. That's like, they failed over. That's fantastic. They did what we all wish our companies were doing every day.

[19:48] C: I don't even think it's that complicated. I think they just changed their outbound routes. Probably. Like, they just figured out how to use a different gateway. I mean, yes, they ruined like a few, but then they moved the compute somewhere else and then just routed the traffic a bit around.

[20:07] B: Tell, how many companies have you seen in your career that could not have pulled that off?

[20:13] C: Oh, I mean, is all an answer?

[20:18] B: I like to think that our current day jobs, we are made them be better. So the answer currently is yes, so that we all feel good about ourselves, but we all secretly know the answer's no.

[20:31] C: You forget my day job is building the clubhouse for my daughter.

[20:37] B: Yes. So do you have HA in case the clubhouse falls apart? What's your DR strategy for? What if the tree rots, it catches on fire by lightning strike? What are you gonna do?

[20:46] C: Oh no, our house has multiple backbones, like, to the internet. Like, we run OSPF and BGP. Like, don't think that the Clubhouse is going offline for a second. I'm just saying, like, enterprise companies, not the Clubhouse, but enterprise companies, they're in trouble.

[21:04] A: All right. Moving on, bringing the magic. Google breaks open a bottleneck in quantum computing. Google Quantum AI published results showing that the magic state cultivation works on real hardware, tracking a longstanding resource bottleneck in building useful quantum computers. Magic states are required for universal quantum computing, but producing error-corrected ones is estimated to consume up to 95% of a machine's capacity, and each state can only be used once. On the Willow processor, cultivation reduced errors about 40 times versus uncultivated states and produced T-states with 99% local fidelity. It works as a filter: inject a noisy state, run coordinated measurements, and discard any flawed attempts. The team also demonstrated grafting states from distance-3 color code into a distance-5 surface code, showing purified states can survive transfer error correction schemes on actual hardware. Engineering challenges were notable. The lab noise from electrical equipment drift and temperature variation invalidated the additional benchmarks, required additional system controls and new self-benchmarking techniques that use the cultivation to measure itself. Cultivation still needs to be used, still needs to be shown at a larger scale. And the practical implementation, implication is that reducing magic state overhead shrinks the physical machine size needed for useful workloads. That's crazy. How are they doing this on actual hardware if they haven't actually invented the hardware yet?

[22:32] B: They are inventing it essentially as is. They're building the prototypes is essentially what they're doing, but they have to name it something fun like the Willow processor because, you know, they have to have code names for everything nowadays.

[22:44] A: Magic State Cultivation. That's pretty cool. Yeah, I like code words.

[22:48] B: I mean, I only understood about 50% of what they're building here, but like, it sounds pretty cool. Like, Distance 3 color mode into a 5— distance 5 surface code. I don't know what that means. I'm colorblind, so maybe that's why. Like, feels like a little bias here that they're using colors. Just saying. Does that mean I'm not gonna be able to use quantum computing in the future? I don't know.

[23:09] C: It's like my dad helped build a, a, uh, the, the radar thing for the B-2. It was like, you didn't build the B-2. And then we look at the B-2 now, we're like, wow, that's cool, Dad.

[23:23] B: Neat.

[23:24] C: Like, we're going to be saying the same thing. We're like, oh yeah, remember we were talking about quantum computing in 2006 or '26. And, you know, we were there at the ground floor and nobody knows what it is. Nobody knows what's going on. But we'll be telling our kids we were there.

[23:41] B: There'll be a back in my day. Yeah.

[23:45] C: Yeah. Oh yeah. I remember, remember when we talked about like how it was the 3-string color to the 5 thing and Matt's colorblind couldn't understand, but yeah, we invented it basically.

[23:56] B: Yeah.

[23:58] A: All right. So it's the end of Stack Overflow as we know it. Stack Overflow, Stack Overflow's 2026 developer survey shows AI assistants are eroding its core Q&A traffic and the company is pivoting to stay relevant. 64% of survey developers visit Stack Overflow less for simple questions because of AI. 29% ask fewer questions and 27% contribute less. Answering routine programming questions is among developers' top uses for AI. The company is expanding beyond public Q&A, AI-assisted search and conventional search into Chat, and which is, I guess, Slack Internal, formerly Stack Overflow for Teams, now free for all users, as a revived developer story feature for hiring positioned to respond to AI-generated resume spam. Stack Overflow for Agents lets AI agents search validated answers and draft new entries with ChatGPT plugin added. And the pitch is that agents need a verified knowledge base the same way human developers once did. Data licensing is notable revenue. Stack Overflow was an early site to charge AI companies for training data, and Google was the first licensee.

[25:06] B: Wait, wait, wait, we're saying that Stack Overflow is verified working, like, working. Like, I've definitely read a lot of things on Stack Overflow and people are like, this is what you do, and you're like, please don't ever do it that way. Like, this is horrible. Like, I understand that you can build a boat out of cans of soda, but please don't do that. Please do something, you know, more logical, like, I don't know, anything else. Like, and that's what I feel like this is. It's like pitch that agency verified knowledge bases. They don't know that I trust Stack Overflow as the verified human knowledge base. I guess it's verified human, but it's not verified working human, which I guess is the nuance there that I'm trying to drive.

[25:53] C: But the hockey stick I was worried about with AI, like 2 years ago. So 2 years ago, before Claude Code and stuff, um, we had a bunch of people using AI at work. And, uh, they were using autocomplete and having it build, you know, uh, functions and methods and classes and stuff. And my immediate thought was, if it's trained on that, eventually it's going to run out of stuff to train on. Um, and so I thought that was kind of going to be the it for AI, like not being able to get more information. Um, it went past that, of course, with Claude code and agents and stuff like that. But now you're going through, you're looking like, okay, cool, what's gonna happen to all these things that we loved and used forever? Even though, uh, Stack Overflow's got a bunch of bad answers, where is, uh, where are these models going to get their information to train on bad solutions, which it gives me all the time, by the way.

[27:00] A: Yeah. No, I mean, it's sort of this funny, this self-perpetuating machine of like, well, all the AI training was done on stuff in Stack Overflow. So when you disagree with the results, you're like, why did it do this? You're like, oh, 'cause it's 'cause of Stack Overflow. Of course, that's all the crazy stuff I used to find on there that I copy and pasted it there. And, but, uh, I mean, that I learned from.

[27:26] B: Uh, so we had a data scientist that worked for my day job a while ago, a prior day job actually. And he did some analysis and he said the difference between, was it like 3.5 and it was, it was a 3.0 and 3.5, whatever the jump was there. And if you took that same amount of increase, like, 'cause it was trained at X number of data was the big thing at that point. Each new model was only trained on more data, which is why they was getting better at the time. You know, by the time you hit— I want to say he said like if they kept going up by like 0.5, he said like by 5.5 or 5.0 or 6.0, it was not gonna— there, it was gonna have more data than required, more training data than the whole world had ever generated.

[28:13] C: Yeah, no, you're going to run out of smart people to do stuff. That's my biggest concern with this whole thing. Is there's— there— when I joined this whole thing of technology, I was driving a truck, and then I went through and I started soldering for a living, and, you know, making $6 an hour. And then eventually it got better, and I learned more, and then they turned me into a programmer, and, you know, I did more and more stuff. And it was like becoming a craftsman. Now We're not training the people that are the new joiners, right? The NCGs. They're not getting their first, you know, bit of experience with things. And then after that, 5 years down the road, who's going to be creating the content for the models to train anymore? Like we've killed the information for the input side of the whole machine.

[29:11] B: And I try to make, I try to not say like, well, I think you need to understand the basics to understand, you know, the next-gen stuff, AKA, you know, in the cloud, it was always like, you need to understand the networking before you can understand, you know, how to do, build a VPC and routes and everything else. And the same concepts apply elsewhere. But I'm also trying to think back, like when I was taught, like, I never learned assembly, never learned punch cards to understand how to program in C++ and Java and all these things. So like, it's almost like there is a next starting point and everybody always thinks that you need to understand what they consider the basics, but there's always a generation before that says like, no, you need to understand the basics that I learned. You know, so, but I, get, I feel like here people are like, I wrote this whole app using AI. And I'm like, cool. Do you understand how it works? Have you thought about the security implications? Have you thought about the secure software development lifecycle of it? Like, and I feel like that's what people are fundamentally missing. They're like, I can spew stuff out there, but now how do I take a spew garbage that's a POC and move it into a production workload that is, doesn't even need to be that scalable, but at least basically secure, like at basic security level, not like Fort Knox, but like, have you attempted to sanitize your inputs? Like done the basic OWASP Top 10 stuff. I'm not saying to 100% 'cause nobody does, but like that, that's where I feel like people are just using AI to the point where like they don't know the basics. They don't know how to do software development. So they don't know how to drive their agent in an effective manner. True.

[31:02] C: And that's the whole, maybe we're just cows conversation, right?

[31:10] B: Because—

[31:11] C: Ooh.

[31:11] B: Sorry.

[31:13] C: So I mean, like, V2 of the software engineer might just be that the agents, instead of training upon the data that, you know, of stuff that we've built over the last you know, 20 years. Now they go through and say, hey, maybe this isn't even a good way to do it. And they start defending against the things that they would think are better for security issues. And they start building software in a language that may not even be human readable, um, which goes back to assembly or to some, you know, weird ASCII characters that only make sense to computers to pile, and they may not even care that we like FastAPI or whatever it is, because they'll just instead do a multiprocessor in front of whatever web thing they've decided to build.

[32:08] B: There was an interesting thing I saw online, not to keep going down random tangents. Someone on Reddit did an analysis and gave AI I assume it was the same AI. I'm not sure, honestly. And it's one of those things I was reading at night as I was falling asleep, but it was— they gave AI the same project and told it to design and build it itself 12 times. And what was interesting about it was it chose the same— it was like X number of time, and it was like high correlation between them. Like 10 times it chose— let's just say I'm making up whatever the answer is here, but like chose Python and an RDNA PostgreSQL database and didn't have a caching layer and chose pretty much the same stack, like 8 out of 10 times I think it was, or 8 out of 12 times. And I'll try to dig it up to see if I can find it. But the question is, are you going to essentially with AI start to really consolidate into single kind of streams of which AI has seem to be the most effective because that's what it has the most training data on. And our new programming languages and new other things going to be less included in there. AKA, is it always going to default to Python? Are more and more stuff can be built on Python than, let's say, Go? Because Python is older than Go.

[33:33] C: No, I think that's exactly what I was getting at. I think is like, we think it's going to run out of training data based upon Stack Overflow running out of data, right? Eventually it read the whole thing. Once it's done that, it's not going to progress or hockey stick or get more intelligent as it did from like 2 to 3 to 3.5. However, what it may do is decide that everything that we've been doing was wrong the whole time and do it differently and do it in a way that you can't even be trained to understand because it's so much better. Like why, you know, if you look at Python or you look at C, like C specifically is a language that you go through and you write, but then it gets compiled to bytecode and the bytecode you can't even like really understand, but it makes it easier for the computer to understand, which is why you compile it because it can run faster on the computer because it's compiled. What if you don't even have to have a language anymore? And instead all this stuff it doesn't have to understand anymore, it could just make up its own thing, which is what you're seeing where they're hacking stuff.

[34:44] A: I think it's possible. I mean, I think that right now where AI's at, you know, we're talking about generative reasoning, which is math prediction. So I don't think it's gonna get, I don't think it has the ability yet to do something like decide that entire method is wrong. Right? It can definitely derive certain things there, but, and the technology's gonna improve, so eventually it probably will be able to make that decision. It will be able to make that distinction. And I think that's when we're getting a little closer to like general, general intelligence, which is kind of frightening. But in terms of like, you know, the, are we only gonna have Python code running forever just 'cause that's what the LLM's trained on? Like, I don't know if that's much different than you know, moving on from Perl or, you know, some of the older languages. Like, I don't know if that's, you know, because it's just not that popular and it would go through cycles like that. I think I'd like to think that if there's benefits in something like Rust, even though there's not as much data that the model's trained on for, for Rust programming, that the advantages would still be there and still be, you know, a choice that's being used by predictive reasoning.

[35:52] B: I don't know.

[35:54] C: It will, the smarter it gets. That's, that's what I think.

[35:57] B: Or until it just built its own programming language that fixes all the flaws that the humans created in the Pythons, you know, and the Gos and everything else, which—

[36:06] A: The humans are the flaws. That's, that's where it's all gonna go wrong.

[36:10] C: 100%. That's what I'm telling you, man. Like, every language is human readable. It doesn't have to be.

[36:17] B: Which brings us to how ML takes over the world. I mean, how ML makes money. AI SAML Makes Money segment of the show.

[36:24] A: Beautiful, beautifully done.

[36:28] B: Sovereign cloud for France, Snowflake and Blu. Snowflake announces it's intended to partner— I love how it's intended there, just saying— with Blu, a French national operating cloud de confidential— I'm sorry that my French horribly butchered that— to bring an AI data cloud to France's regulated sectors with sovereignty built in. Aka it's only in France. Snowflake claims to run on Blue's infrastructure, which is operated by French entities in French data centers under French laws. It will hold all the certifications that they need to do this. The framing is that AI workloads touch sensitive data located in France, and therefore you want to keep all that data in France under the control, pushing for stricter controls over who operates and can access it. Kill switch mitigation is a key point design. Customers keep their data in their own S3-compatible object storage using Apache Iceberg open table format, so data stays accessible without migrating. Snowflake's CoreTech AI offers a single united API and self-hosted open source and frontier models, so customers can swap models if one is discontinued or unavailable in the region without having to change application code or pipelines.

[37:46] A: And this is gonna be more of a thing, right? We're seeing more and more, you know, data sovereignty rules and requirements. And I think that the, the new French laws are, are frightening, but also a reaction to, you know, politics of the time. And it's, you know, it's a, it's a giant pain, but also it might be a big opportunity for Snowflake, right? There's a lot of the cloud providers that aren't able to offer all their services. And if Snowflake is able to, run a comprehensive program that's operated within the French data sovereignty constraints, then they might be the first to do it smoothly and might be a lot of easy way to get, get some market share.

[38:24] B: Does AWS— I know Azure has a France region. AWS is a Paris region, EUS3. So they all kind of already are rolling out that stuff there.

[38:37] A: Well, this is, this is different than just having a center of the region.

[38:40] B: This is their whole, yeah, yeah. This is the whole, I just was wondering, 'cause I know they're doing the whole disconnect the EU from the rest of it, which we've talked about in the past. This actually this upcoming weekend. So by the time this show drops, AWS is doing their big test. But I was just even curious if other providers could do that specifically in France. Like I know AWS could, or—

[39:02] A: so Google, Google's running a very similar thing, like Snowflake, like this Snowflake article where they're, They're operating their program on top of this, and, but it's all gonna be hosted within these French localized regions or centers operated by French personnel. And I imagine, you know, well, I don't know this, but I'm sure it's under the covers somewhere in the fine print of contracts. Like there's probably a kill switch where they can disconnect it and disconnect Google's access from it so that it's all just run entirely within region.

[39:32] B: I guess though, like Outposts kind of would do that too. Like an Outpost runs it all local, but I guess like an Outpost still does have connections back to AWS.

[39:44] A: Still needs to talk to the mothership, right? Yeah.

[39:46] B: But I thought that's mainly for configuration more than anything, but I guess maybe I'm wrong.

[39:50] C: Yeah. So there's a, for GCP, what they do is they leverage a third-party contractor that actually owns the hardware and then licenses the software from Kubernetes.

[40:00] B: Yeah.

[40:01] C: My, that's my understanding from my limited S3 and S3 scales work.

[40:09] A: That's the way I read this, this Snowflake. I think it's the same model.

[40:13] C: Yeah.

[40:14] A: That, you know, Blue is owning and operating that and they're licensing basically the Snowflake.

[40:18] C: Yeah.

[40:19] A: I think it doesn't say that specifically, but it sure seems like it if you squint at it. All right. Moving on to AWS. Amazon is funding 12 small nuclear reactors at a former Indiana coal plant. It's putting its money behind these 12 small modular nuclear plants, and it's a useful data point on how hyperscalers are tackling data center power demand. The planned 960-megawatt plant would use 12 X-energy XE-100 SMRs at the site of a demolished coal plant near Terre Haute. It will be operated by AEP with Amazon as the first power customer. It is 3 times the size of the first Amazon and X Energy agreement from 2 years ago. Unlike some recent data center power projects, these reactors would connect to the public grid, though Amazon says the output would serve its data centers, and that raises a grid versus behind-the-meter discussion. The broader overall goal is 5 gigawatts of new US nuclear capacity by 2039. But the timeline very much depends on X Energy delivering its first plant at Dow's Seadrift site in Texas. That site hasn't even broken ground, but the NRC construction permit is still in its final review. The Dow's plan is facing a Texas state lawsuit over environmental noncompliance.

[41:34] B: Dun dun dun.

[41:36] A: SMRs are meant to avoid the budget and schedule overruns of recent U.S. nuclear builds through factory manufacturing. But experts say those cost benefits can take about a decade to appear. Xenergy went public in April at $23 a share and jumped 27% on day one and has since fallen by nearly two-thirds, just like every other public launch. Stock rose about 10% pre-market on this news but was down under 2% at publication. So markets are very cautious about this one.

[42:04] B: I mean, I think localized power like this is definitely interesting if they can pull it off, because they can build these things much faster, much more easily localized next to thing, next to like the data centers, which is nice. The negative part of that is you now have a bunch of small nuclear reactors all over the country. That feels nice and safe, you know. So I, I don't know enough, you know, about the grid versus meter discussion, um, but I think that's probably a key importance here that we should probably learn a little bit more about, Ryan, you and I. And maybe we'll make Cody learn some stuff and come back and tell us about it.

[42:47] A: I mean, I know a little bit about it just because I, this is sort of like a, you know, curiosity that AI data centers and power and water use, this is something that I, I don't know, I feel like I have a lot of discussions with and I want to stay educated. And so I do a lot of independent research and I think the biggest difference I see with this announcement is that the connection is gonna be to the grid, which means that it's going to, while the, the power that is generating is intended for Amazon data centers, it's also available at the grid. It also means that it could be used for not Amazon data centers and can be overall made to expand the grid to make it inherently more stable. Whereas all the other announcements that I've seen where they're running, you know, these gas power plants are local, it's very localized to just that system, that, that data center facility directly. And I don't think it's as efficient to do it that way. You know, I, you know, I think I've talked about it on the show before. Like, I don't, I don't actually see nuclear power as such a downside as it's been sort of led off to believe. Like, you know, nuclear waste sucks and it's, we don't really have a great way to deal with it, but comparatively to the amount of pollution and gas exploits to a traditional gas or coal fire plant, like it's nothing. So it's one of those things where I think it's the, the, in the media it kind of got a bad name and there's absolutely a downside, but I'm not sure that it's not the way to go for this type of thing, especially when AI is gonna be so, and every computer is gonna be so power hungry.

[44:17] B: Well, I don't know that computers, I'm gonna say the data center's gonna be more power hungry unless if we start to distribute that, which I don't think we put in our show notes, but Like I saw an article that Matt, Apple was gonna start to use your GPU for essentially compute when you're not using it. It reminds me of the old like folding at home. Yeah.

[44:40] C: What was that called?

[44:41] A: SETI? SETI at home?

[44:43] C: Yeah.

[44:43] B: SETI at home. Folding at home. You know, it's like, but you're still, you all buy stuff. Uh, Mac shared.

[44:51] C: I mean, conceptually, I think it's good that they're gonna go through, cuz I, I've been talking to some people that are trying to build some data centers, and I tell them where I have a conflict is like, you know, the whole not in my backyard thing. Nobody wants it in their backyard. Nobody wants to deal with the noise, the, the issues that come with it. And they go, oh no, we're doing all these good things. But it's because they have a PR person that's going through and saying, yeah, we're gonna— I know you don't want to build the a power plant in, in your, your backyard, but we're also gonna subsidize you. It's like, not really.

[45:30] B: Mm-hmm.

[45:31] A: Yeah. I mean, tax incentives, we're gonna create all the jobs and you know, there's always the, the sort of PR play for any large project. And it is sort of like, it's sort of like the dirty underbelly of any big business sort of those contracts and sort of feels gross. And I, I don't know if that's just because of the, amount of money in play for these things. But you know, it's also, I, I get really conflicted 'cause you know, what do you do? Do you put Pandora back in this box? Like how do you, how do you, uh, do you stop the use of technology? Do Google searches go back to like boring, just index searches? Oh my God.

[46:09] C: Those are the good days.

[46:10] A: I know.

[46:12] B: Mac Minions is the answer of what it was called. Did some real-time follow-up.

[46:18] C: So, no, I mean, I, I, I think you're right. You can't, you know, put Pandora back in its box, but like, also we gotta figure about what we're gonna do with resources. Uh-huh. Which has been a problem for a long time, but I mean, like water, it turns, turns out it's important. I like it.

[46:37] A: Kind of needed to live.

[46:38] C: Nice. Yeah. I've got some—

[46:41] A: I like it when it's not flammable.

[46:44] C: You get that?

[46:47] B: That's a details, Ryan, details.

[46:48] C: I know, I know, seems like a small request, but no.

[46:54] A: All right, AWS Transform announces Azure to AWS Cloud Native Code Conversion. Transform can now convert Azure SDK code in .NET apps to AWS SDK code, giving Azure shops a tool path for migrating cloud-native applications rather than having to manually rewrite them all. The .NET Modernization Agent detects Azure SDK usage in submitted source code and surfaces conversion options in the assessment report and modernization plan, lets you accept or adjust them before making the transformation. It then converts to AWS SDK calls and validates its changes. Supported conversions at general availability are Azure Functions to Lambda, Azure Blob Storage to S3, Azure Queue Storage to SQS, and Azure Cosmos DB to Amazon DynamoDB, which is available only in preview. This converts the SDK calls, but the data model differences between Cosmos' multimodal DB partitioning versus DynamoDB's key design, for example, in terms of are triggered, their semantics are triggered, but they still need human review. It will reduce the code migration effort, but it's not a full migration solution. This is a direct play for Azure-native workloads, extending AWS Terraform beyond its earlier focus on .NET Framework to .NET and mainframe modernization, and it lowers a common switching cost objection for multi-cloud or Azure-to-AWS moves. This is available in 8 Amazon regions: US East, Mumbai, Tokyo, Seoul, Sydney, Canada, Frankfurt, and London. And the announcement did not include any pricing details when launched.

[48:45] B: I mean, it's nice that they're adding more and more things to Terraform, and they're essentially building it as like an AI-centric tool at this point. Here's another AI agent that will help you do these transformations. And while these transformations are great and good for Amazon because they're getting more workloads there. You know, you still do have to test it. You can't just run these things. And that's what I worry, you know, the marketing people are saying, look, we have this thing. Okay, cool. But you know, like you said, DynamoDB and Cosmos DB are two different designs. Yes, they're both NoSQL databases, but if you're running either of them at I'm gonna say a medium scale, not talking like Amazon's DynamoDB that we talked about during like Prime Day. That's a whole different level of ridiculousness. But like a medium to large size business leveraging it, you can't really just move it over. You gotta look at your key constraints so you don't have hot targeting or what they call a hot partition or anything else like that to make sure that you're actually able to go, let alone IAM and stuff like that. You really need to take a human look and make sure this does move. For small businesses and small apps, it'll be fine. Yeah, you might need to add an IAM permission, or, and/or make sure you have a proper unit test and end-to-end testing of your application. Like, that's the only way you could do this really, like, more hands-off. But at that point, do you really need an agent to migrate your code? You're probably doing that yourself.

[50:18] A: I can't wait to see, so, or hear someone who's actually used one of these things and pulled it off. Like, it seems like the Pangea that everyone always wants. They're stuck in this legacy framework and they don't know how to spend the time and resources to migrate off of it while also not just losing all their customers as they cease to make any improvements. And so like, it seems like this comes up a lot and I never see it really fully deliver, right? Like I remember the Babelfish thing that Amazon released years back that was supposed to be how you got all your Microsoft SQL servers to talk into Aurora natively. And I don't know anyone using that. I don't know if it works. I don't know if there's performance concerns. We hear about these modernizations and AI is gonna rewrite all your .NET applications into modern frameworks. I've never heard of anyone actually pull it off. At any kind of scale.

[51:10] B: Yeah, I was gonna say, I've seen at my day job small and medium-sized ones do it, but like medium-sized unsophisticated things, not a medium highly complex company leverage it. And that, that I think is the fundamental difference is you can do it, but like you gotta make it, you gotta still do the testing, 'cause otherwise you You can't just fire and forget.

[51:36] C: Look, here's hoping that eventually Azure only runs Exchange. It's not what you have to deal with.

[51:44] B: I will say they do run Microsoft SQL and the Hyperscale product is solid. And I know that they've been making more and more improvements under the hood. It's expensive, don't get me wrong, but like if you're stuck on a Microsoft stack, Like if you are a Microsoft stack, I kind of probably shouldn't say this out loud, being on Azure makes a little bit more sense than trying to run your Microsoft stack on AWS. I know a lot of people run their Microsoft stack on AWS, but like they have their stuff more fine-tuned in Azure because they worked with the, the, the database team to build Hyperscale. They like, They worked with it. I'm sure AWS did the same thing. They worked with PostgreSQL to figure out how to abstract out the storage layer to its own thing. You know, they probably worked with stupidly smart people that wrote PostgreSQL to figure this out. But if you're on micro— like, that's where I just think things make more sense.

[52:47] A: Yeah, I agree with you with running it. I mean, I know I've in previous past lives, I've walked away from money that Microsoft was giving me to move to Azure. And the reason I did it wasn't because I could run Microsoft SQL Server better on a different cloud. It was because I wanted to provide an environment for the, for devs and teams to innovate outside of Microsoft SQL Server. And so it's like, it's just really, it depends on what you want as a business. I think if you're looking to sort of not only change the technology stack, but also sort of modernize the way that you operate and run your business, that's when maybe looking somewhere else makes sense. But if you know you're gonna be just on this platform and it's the thing that makes you the most money and you know you're never going to touch it. Yeah, just Azure is going to be the best place for that workload for sure.

[53:34] C: Thank God Justin's not here. He'd be telling you about how the moment they figure out how to run SQL Server on Kubernetes.

[53:42] A: Mm-hmm.

[53:43] B: Yeah, this is why we don't let Justin do things anymore. It's just bad news bears when he does. He's like, let's just randomly run it over spot for our things at the 10th line. It's fine.

[53:56] A: Now we just let him go off and then we just edit it out in post too.

[53:59] B: Yeah, it's fine. Don't worry about it.

[54:04] A: All right, let's move on. Amazon CloudFront announces dual stack support for VPC origins. So now CloudFront supports end-to-end IPv6 for private VPC, VPCs, closing a gap that forced teams to choose between IPv6 and origin security. Dual-stack VPC origins in CloudFront allow ALBs, NLBs, and EC2 instances that are in subnets that are IPv6 to no longer have to translate themselves into IPv4 to talk to CloudFront. This is pretty great when companies have moved to IPv6 architecture and to meet regulatory requirements such as government and public sector IPv6 adoption policies. And now they don't have to expose their origins to specialty IPv4 networks or the internet. This is available in all AWS commercial regions where VPC origins are supported at no additional cost.

[55:03] B: This is a nice quality of life given that how much you will pay for IPv4. You know, you pay that IPv4 tax at this point and for most businesses, no one gives it, you know, whatever, because it's such a small tax right now. But starting to truly make things be more and more IPv6 native helps. And I'm actually surprised this, I guess I just never ran into this because I'm one of those people who still runs IPv4 everything. But like, you know, it's, I'm surprised that this feature didn't already exist.

[55:37] A: Yeah, that was a surprise. And to beat a dead horse, I think the reason why everyone's so resistant to really adopt IPv6 at scale is, is that same human-readable thing. And so this is a perfect example where AI doesn't care. It can read all like, you know, octets of IPv4 or the 11 billion octets that are in IPv6 with at the same level of effort. And so, but as humans can't, we, it's not as, uh, easily parsable for us. And so like, This is probably one of those examples where IPv6 finally needs something like AI and machine reasoning.

[56:10] B: You're right. I mean, I just can't wrap my head around like letters and numbers and routing. Like I finally understand it. I understand that's how MAC works and everything else, but like when push comes to shove and everyone's, you know, I'm like, okay, 10.0.0.1 is my house. 10.0.0.2 is whatever. Yes, I have way too many IP addresses. But I don't care. And if my company I'm working for grows beyond 255 sites, I will probably no longer be here. That's somebody else's problem. Like, we are at 3 now. Going up to 255 is a future problem. If we hit that scale, we're having good problems in life. Like, yeah, it's like IPv4 is just easier and it's all human. Like, I totally get it.

[56:59] C: I just refuse. I, uh, I went through and figured out how to do CIDR block calculations with BitShift and thought I was a genius. And then, uh, the new thing is gonna be too hard.

[57:12] B: I'm too old. Won't do it.

[57:14] C: Refuse.

[57:15] A: I'm just gonna rely on tooling. Like, I don't, you know, like something's gonna have to tell me everything, you know, like it's just. I'm never gonna look up like subnet math now. I probably can't even do it anymore. I haven't had to do it in so long. Like, you know, I learned it once, but it's probably gone already.

[57:31] B: I could do some of them, like 25. Sure, you could do that. 24, 23, like you do that. I bet you could go down, like up and down from 24 pretty well.

[57:42] C: Oh, come on. 28, 32. Those are easy cheese. I bought, I bought Interconnecting 6, I bought Cisco network devices at Barnes& Noble for like $27 in the '90s and read that thing back to front 100 times. And when I finally understood the networking, I was like, God, I don't want to do this. This is—

[58:03] B: Did you also buy a bucket of NAND gates to build your own router?

[58:06] C: It's all solved. But then they go through it, they're like, how about IPv6? And I'm like, okay, it's magic again. I don't care.

[58:14] A: All right, Amazon CloudWatch announces log routing and chain log parsers. CloudWatch Pipelines now supports conditional log routing and chain parsers, giving teams finer control over how logs are transformed and where they land. Conditional routing lets you send each event to a different CloudFront log— CloudWatch log group based on conditions evaluated against the process fields such as severity, source, event type, etc. This means that retention policies and access controls can be applied per log group without separate ingestion paths. Chain parsers apply multiple parser processors in sequence, whereas later parsers consume fields produced by, from earlier ones. A common example in parsing a JSON envelope first, then running a Grok parser on a field extracted from it, which handles the nested or mixed log formats into a single pipeline. Together, these features reduce the need for custom Lambda functions or third-party log shippers to split and reshape the logs before they reach CloudWatch, and it keeps the transform and route logic inside a fully managed service with no infrastructure to run. Practical use cases include routing security or error-level log events to a log group with longer retention or tighter IAM access while sending verbose debug logs to a cheaper, shorter retention group. This is available in all commercial AWS regions where CloudWatch Pipelines is generally available. It's configurable via the console, CLI, and the SDKs. There was no specific pricing announced as part of the release.

[59:40] B: Well, it's logs, so it must be cheap, Ryan. I hear they're very easy to run.

[59:46] A: And pipelines, anytime you have to do like, you know, parsing on demand at scale or at a super quick rate, right? Super cheap. They always charge, they always charge that in pennies. Like, I love this tool. I have built so much log routing logic around to just do these specific things, like exactly this, like in Lambda. I for— we did some metric in a previous job where we calculated, it was like number of, can't remember if it was like feet to the moon or something was the same amount of Lambda hours we spent in a year. We did some sort of funny, we did some sort of funny metric on a slide that was just the amount and it was all just log parsing. And log routing. That's all it did was, um, and adjusted into, you know, from AWS accounts into the logging solution. So yeah.

[60:38] B: Weren't you like the number one like Lambda consumer in a region or something at one point for like 6 months?

[60:45] A: For like a hot second.

[60:46] B: Yeah.

[60:46] A: Yeah. For like a hot second we were, I don't know if that was just because our use case was ridiculous or if it was just, you know, cuz we were newer to reach or something like that. Like I, I tend to think it was something more along those lines, but it was, it was a lot. And the cool thing about it was it wasn't, it didn't break us financially. And so it was really a great success story to using serverless to do this because it, we calculated the cost of running on containers or VMs and it was astronomical in comparison because of the amount that we would've had to have in terms of running in different, different locations and different runtimes all executing at once. So it was kind of cool.

[61:23] B: What I didn't realize, and I completely segre— segre— because I was looking at what if the pricing was on the pricing page, is I didn't realize LiveTail is charged by minute. It's 1 cent per minute of LiveTail. So I'm going to apologize, Justin. I'm pretty sure I left LiveTail running at one point when I was doing BoltBot for a couple, like an hour while I was like doing other stuff. So good to know. No, don't leave LiveTail running. Yeah, great feature. Didn't know it was that expensive though.

[61:55] C: Yeah, I mean, the, the FinOps guys, the execs are always going to be looking at cost. And you know, every time you go through, everybody wants visibility. They're like, oh, Datadog, New Relic, Sumo Logic, whatever. And then everybody looks at the ingestion, they're like, oh, this is bad, turn it on, off, right? What's that company called? The that does that preemptive log parsing.

[62:19] A: Preemptive log parsing?

[62:20] B: Doesn't Datadog do some?

[62:22] C: No, it starts, yeah, it starts with a C. Anyways, at first you go through, you spin it all up, you get it on everything, everybody goes, this is great, I can see everything. And then eventually they want to go through and associate any of the logs that you're doing, uh, or parsing with a project. So this is where you're going to see these things as part of like your initial standup of a project, right, for TCO. So I said FinOps, you know, entered the chat because they love this, right? Everybody's looking at TCO.

[62:54] A: Well, it's a great way to save money, you know, when you get that executive who needs to make some sort of numbers and they're like, I need you to save $6 million. It's like, I'm just going to go through and change the retention of all the CloudWatch log groups.

[63:04] C: Done. Across the board, right? Yeah, the base, uh, the base Terraform.

[63:10] B: So I will say that's where Azure automatically does some of that, which was nice.

[63:15] C: Listen, you're never going to win me over on Azure.

[63:19] B: Trust me.

[63:20] C: But I like, I know that you're trying to hold on. You're like, it's really nice if you talk about the—

[63:24] B: No, no, no, no, no, no, no. You clearly have not listened to enough episodes whenever we talk about the App Gateway and my hatred and my I don't even know what the right term is. PTSD from that service. There's things they do well. There are many things they do not do well. Uptime is one of them, for example. They don't do that so well. So anyway, on to other Microsoft services, Ryan.

[63:49] C: I'm just kidding. I wouldn't be talking to you if I really thought that you loved Azure.

[63:54] A: I mean, yeah, no, we'd like, we would question some sanity and some life choices. It wouldn't, wouldn't be okay.

[64:01] C: No, it was just— we know.

[64:05] B: I secretly think Justin got me the job, or, you know, Helm was a reference and whatnot, a job at that company because he wanted somebody that had to learn Azure to join the podcast in the future.

[64:16] A: It's self-defense, man. Otherwise one of us would have to do it. No way.

[64:20] B: Yeah, he likes, you know, manip—

[64:22] C: he—

[64:22] B: it's like 3D chess is what he, he plays.

[64:25] C: I've decided Actually, maybe he doesn't like you.

[64:31] B: Oh, that thought has come through my head many times.

[64:37] C: He's just putting two and two together on New Year.

[64:42] A: Amazon RDS Proxy now supports SQL Server 2022. So AWS extends its RDS Proxy to now cover SQL 22, which matters to anyone running a connection-heavy .NET or legacy Windows workload on a managed SQL Server. RDS Proxy now works with RDS for SQL Server 22 instances, pooling and sharing database connections to improve efficiency and application scalability. This closes a version gap for teams that upgraded to 2022 and could no longer use the proxy. That's a bummer. For multi-AZ deployments, the proxy connects to the standby during failure and preserves application connections, reducing failover times up to 83%. This is a practical benefit for apps that cannot tolerate long reconnection storms after a failover. Authentication uses the standard IAM for the app to proxy connection while the proxy uses credentials stored in AWS Secrets Manager to talk to the database. This removes the hardcoded database passwords and application code and centralizes credential management. Setup is just a few steps on the RDS console and then you have your application ready.

[65:43] B: So it's 2026 and they updated it to have 2022. So does that mean 2031? Cloud Run, they'll have SQL 27 out. It already has proxy.

[65:56] A: I mean, we talked about running Microsoft SQL Server and difficulties. And so yeah, I mean, I imagine that, you know, people are just now getting onto SQL Server 2019. And so this is ready just in time for them.

[66:07] B: There you go. And they finally made Justin happy probably by doing it on, well, they probably did it on ECS. Could you imagine running Microsoft SQL on ECS? EKS.

[66:18] A: I don't know how these hyperscalers run, run it. That's always been the secret thing that I'm afraid of, is Justin's going to find out that all these hyperscalers are running it in Kubernetes and be like, ah, no.

[66:29] B: Well, I know back in the day we got on an outage call with, with like, uh, like we were on a call with AWS about debugging a step 1 outage for a customer that was running Microsoft SQL. And the issue was somehow the Windows firewall turned on to block SQL. Or something like that. And this is like, to be fair, this was like, you know, 2017. But like, I still wonder how much of that is still behind the scenes of like, yeah, it's just a .NET Core, you know, Windows Server that they're running or something.

[67:06] C: It 100% is.

[67:07] B: Mm-hmm.

[67:08] A: I never wanna know how the sausage is made on the internet.

[67:10] B: No, this is an area I'm like, I'm good. Mm-hmm. We talked about that long, there was a long article, I wanna say it was like late last year where like a, uh, someone that claims they were internal went on like a 7, like it was like a 7-page article about how Azure is run. Here you go, Cody, with like everything is like still manually logged into and configured and there's no automation and whatnot. And like, is that the way all these clouds are? Are the sausages just hidden behind us at this point? Or are they really as automated as we all like to think they are? And I'm sure the truth is somewhere in between. Some things are automated more than others.

[67:49] C: Probably 15 years ago, I went through to a dinner in Venice Beach, and I was eating at this little Japanese place, and this guy sitting next to me was talking about how he worked for this company, and it was all held together with duct tape and bubble gum. And, uh, you know, I was sitting there eating dinner and I kept looking over at him and I, I managed to get a glance of his badge and it was a Google badge.

[68:18] B: That feels about right for all these companies.

[68:20] C: Yeah. Because I used to work a bunch of startups and I was like, oh, I can't wait till I get somewhere that there's finally some sort of process and stability and people aren't making all these silly mistakes. And then that, that dinner in, in Venice Beach ruined it for me.

[68:39] B: Yep.

[68:39] A: All right. Up next, Amazon just announced that EC2 Image Builder can now reuse running instances from an Auto Scaling Group for its image builds. That should speed up AMI pipelines for anyone tired of waiting on instance launch and bootstrap, which is everybody, am I right? Instead of launching a fresh EC2 instance for every build, Image Builder now picks an already running instance from the designated ASG. Applies the build components and creates the image. And this removes much of the launch and bootstrapping time for each pipeline to run. The autoscaling group automatically replenishes pool as instance gets consumed by builds, so warm capacity is always available for subsequent pipeline runs. It's essentially just a warm pill, warm pool rather. This feature is fully opt-in and configured through the infrastructure configuration, and existing pipelines without an HD behave just as they did before. So there's no migration risk. This is available at all AWS regions at no additional costs, although you do still pay normal EC2 costs for the ASG instances that are running inside the pool.

[69:41] B: So I misread this when I originally, you know, saw the headline. I read it as more like Image Builder creates a new image and it auto shoves it into an ASG, so it just auto refreshes. So this ASG will automatically refresh and That's not what it is. And I actually dislike this feature the more that I've been reading about it because I like my image factory to start and build up. And I get that you don't want to build from scratch every single time, but at that point, then put like an interim build in there because who knows what people have logged into that, you know, or what things have changed on that EC2 host, even if it's in an auto scaling group, in the meantime, imagine like, if this EC2 instance is in a web server that got hacked and now you're building new images off of that. Like that's where my brain's going versus building something from scratch every time. So I get it speeds up.

[70:43] C: It's gonna be lower than OS, right? It's just gonna be running hardware. That's a provisioned VM state of memory and CPU. I was thinking the same thing, but I was thinking more low level of if you go through and you inherit somebody else's already warmed up infrastructure, meaning memory, right? It's got stuff there. So I was going to ask Ryan if you saw a security threat from that of like pre-warmed memory 'Cause it's written to.

[71:16] A: Yeah, I go, I'm a little conflicted on it. Like, 'cause if there's, I think it kind of depends on how you've configured the pipeline and you're, you know, you're already running on someone else's computer, shared tenancy model. If you're that concerned about what's in memory, then you need to be running on some sort of confidential node. Amazon's protections at the tenant level with hardware running on Nitro cards and everything. Like, I'm not— I no longer surely worry about that, that level of concern.

[71:45] C: Talking about hot hardware, right? So you're going to go through, you're going to mount a new disk, right? So Matt's concerned about OS and the stuff that was done there is going to go away because it'll be a new EBS volume.

[71:57] B: No, it's not. That's what this is saying, unless if I'm wrong.

[72:00] C: Oh, really?

[72:01] B: It says this is a running instance. Yeah, right. It's a running instance. So if I have two web servers Let's use the example that I'm sure we'll talk about next week. PHP released a vulnerability, and I have a PHP web app running on a server, and it gets breached, and we don't notice yet, and we, and it randomly chooses that instance from it to patch the PHP vulnerability. That system's already been breached. Now we are building on that server.

[72:31] A: Right. So, but, the breach in PHP, to use that example, that, that's not going to proliferate in a way that's going to be dangerous that way. This is— that's talking about like a, uh, how to exploit a running PHP process.

[72:45] B: Okay, I haven't looked honestly into the PHP stuff today, but because it's all happened today, but like, that's my concern.

[72:51] A: We will talk about it more the next— yeah, next show. But, you know, to— but, you know, like, so it is— there are specific type of exploits where your modification you're modifying that existing resource and therefore that modification puts something in place where you can later have it call home or do something like that. So we can definitely have, you know, there's definitely a risk of that. But I think it's also offset by like, if you've ever tried to do like a Windows pipeline, which I know we all have, patching a Windows sucks and takes hours. And so like, if you could have a warm pool that's constantly patching these hosts and is already running, And then you can just put your customizations on top of that patched host. So I can see an advantage there where you might be safer overall just because you're producing less vulnerabilities into your already built images because they're patched. So I don't know.

[73:39] B: You still don't know what's on your images. Like the nice thing about an image bakery here—

[73:44] A: Just because it's running doesn't mean it's accessible or tainted. I get the risk, but you have to mitigate that risk.

[73:49] B: I'm not even going if it's tainted, you know what's on it. How many times have people said, we have this server, here's how you build it. And you go, cool, let me go automate that build. And you go automate it and it doesn't work. Oh, these packages are no longer available. I mean, new ones, or, oh, this, oh, you missed these 16 things that we had to install. It's that business knowledge gap of, how to build that image, that worries me. You know, I've been at companies, I've been at places where people are like, we have this, and what we've done is in VMware, we just clone it and deploy on, you know, update and make changes on top of it. No one knows over the last 5 years how the hell to build that machine again. And that's what I'm concerned about, is people just always grabbing the latest, doing something, and now you have to go from, We'll even stick out your Windows example, Windows 2022 to 2026, 'cause it's at end of life or whatever, 2025. I hate Microsoft numbering at times. You know, and how do you then know where to start from scratch? Or somebody's just gonna take that image and do a Windows update on it. Like it just, it leads to bad practices of not knowing what's on your systems. In your scenario, is your auto scaling group more than 2?

[75:12] A: Because I don't think that you're ever gonna run a scenario where your image pipeline is launching all of its instances at beginning and then slowly depleting them over time. Like it's just gonna run, pick one, and stand up a new one. And so depending on how much you're—

[75:26] B: Well, okay, I guess what I was—

[75:27] A: Running in buildings and what you can scale down, like there's never gonna be more than 1 or 2 and it should only be hours to live.

[75:33] B: Well, I guess I was envisioning the whole purpose of this is you take an image, you, let's just use the simple patching, right? You patch the image and then you tell Amazon to refresh all images with this new AMI ID that you've just generated. 'Cause you know that this was a working image before. That's what I was envisioning this feature for. So I have my web server, I've updated something on it. I made a new AMI out of it. Auto-scaling group, go launch all new servers from this AMI. New IAM ID. That's the way I was envisioning this to be used.

[76:07] A: I see.

[76:08] B: No, I think this is, this is not, that's definitely not this, right?

[76:11] A: This is definitely instead of starting an instance like EC2 run, it's starting with an already running node. I think it's as simple as that.

[76:19] C: That's, and that's where I got confused on the EBS, because I figured you would just be stealing already running resources as opposed to spinning up an underlying infrastructure. That was my understanding.

[76:33] A: I mean, AMIs are always just snapshots, right? Of point in time snapshots. When you take that snapshot is the key. And so like there's, you know, whether or not that the beginning of the resource lifetime is from 5 minutes ago or an hour ago or 2 days ago, I don't know, depending on, you know, other environments or other changes within that environment, if it changes the the paradigm a whole bunch.

[76:58] B: I guess when I originally read this, I thought it was gonna be like the Azure feature of latest. So like you can tell your auto scaling group, your scale set to just pull latest. And then if you update and tag, it works kind of like Docker does. If you tag your scale set with latest, AKA you've done your monthly patching and you have a new, you know, EC2 instance there, your new AMI there, it will just pull that version during its maintenance window. That's where I thought they were kind of going with this feature, and it's actually the inverse.

[77:30] A: It's, that's launch templates and rolling refresh. That's been around for a while.

[77:37] B: Yeah, but there you have to do, there you still have to run deployment 'cause you have to deploy a new launch template. Here it's like pull latest, and then it has a maintenance window that just automatically swaps it out during its window. It's slightly different. There's no deployment, there's no infrastructure change, there's no, goes into our conversation from last week, you know, how do you keep your ISC in line with your auto-scaling groups and, you know, with your, with a dynamic environment. Kind of the same thing where like latest then is a tag to an image ID and it auto-updates for you versus having to in a launch template say, Here's the new image template, now do an EC2 auto refresh, refresh instances. It's a little bit more managed. It's a nice feature because of the way Windows operates. Let's be honest, this is, they built it out because it's Windows versus you can run Windows on AWS, but you might hit yourself a little bit at times.

[78:36] A: Well, and two features that we can agree on are awesome. Amazon ECS Gateway now is a fully managed ingress solution for ECS. So they just announced ECS Gateway and it's acting, it allows a creation of an ingress layer in front of your ECS services and aims to take precedence over the per-service ALB certificate and security group busywork off of the platform teams, which is absolutely the first complaint I ever heard about ECS in like 2016.

[79:08] C: You're careful.

[79:09] A: ECS Gateway is an account-level resource that dynamically provisions all the ALBs, certificates and DNS hostnames, the listener rules, target groups, security groups, the flavors, the logos, and all of the things that are needed for allowing ingress to your ECS service. Formalizes a platform team versus application team split, where the platform team defines subnets, security groups, TLS listeners, WAF, and associate the gateway with the clusters. And then the app team just adds the connectors to a create service or update service. And the, the new gateway can just, can associate with up to 10,000 clusters and a cluster supports up to 5 gateways. Host-based routing lets up to 25 services share a single ALB, which should cut the ALB sprawl and cost. And ECS adds ALBs as the capacity fills and removes them when empty. But the max ALB count default quota is 10 and the deployments will fail if that limit was hit with no capacity left. Adoption can increment. Existing services with their own Load Balancer can add a gateway connector and run both paths in parallel before cutting over. Works with AWS VPC networking across EC2, Fargate, and ECS managed instances. Those service AZs must be a subset of the gateway AZs. There's no additional charge for ECS Gateway itself, and it is available in all commercial regions where ECS is available.

[80:27] B: This is a cool feature and saves a lot of headache and like you said, a lot of ALBs are gonna go away once people use this. Like so many $18 charges, you know, out there because of this lack of a feature.

[80:42] A: Well, the funny thing is the ALBs aren't gonna go away. They're gonna stop being configured by the users, right? You still get charged for the ALBs. All this is doing is sort of formalizing the path that everyone did when they're using an ECS service and then complained about how Kubernetes just does this for them. Now this just does it for them. But much like Kubernetes, all this existing software-defined load balancing, all of the software-defined logging rules and all these things, it's all just under the covers. All Kubernetes does is abstract it out and away into piles of YAML that you have to define and inherit with precedence. And so this is kind of great because it allows all of that same sort of functionality and, and, and the ease from an end-user standpoint. But also maintains that the existing sort of ecosystem of ECS across all of the, the Fargate and managed ECS services. So it's cool.

[81:31] B: It doesn't trim down. I feel like one of the issues I always had with ECS at times was like, you know, every service had to have an ALB and therefore this one now more natively supports, I think you said up to 25 in one Load Balancer. So that's kind of where I was thinking.

[81:48] A: The point is that the ALPs are still there, they're just being managed, they're created by Amazon instead of you.

[81:53] B: Oh, I thought it was managing rule sets inside of it a little bit better.

[81:58] A: So the host-based routing is within that ALB. So 25 services can use that same ALB, so it'll be reused as much as Amazon can, but all of that abstraction layer's being handled under the covers.

[82:10] B: Into the world of GCP, if you're still listening to us for some strange reason, Wiz Sensors for GKE. Turkey threat detection for Kubernetes. We're really on a Kubernetes kick today, guys. Google and Wiz, which also is Google, just shipped a managed Wiz runtime sensor add-on for GKE in preview, which takes eBPF runtime threat detection from your third-party agents you maintain to a platform that you toggle on. The add-on deploys from Wiz sensors to both standards and Autopilot GKE clusters, monitoring syscalls, processes, network connections, file access to catch reverse shells, privileged access, and container escapes. GKE manages deployment, pod lifecycle, and updates. So teams no longer have to handle agents across dozens or hundreds of clusters, which if you have hundreds of clusters, you hopefully have a lot more management. Credential handling uses GKE Secret Manager secret sync. Ooh, say that 3 times fast. So their Wiz API keys can live off clusters and rotate without restarts or distributing Kubernetes secrets. It requires workload identity federation for GKE and granting GKE access to Secret Manager. Proxy and mTLS egress configurations are supported for lockdown environments. Day one. Fleet governance comes with custom organization policy constraints that can block any creation without the sensor enabled, closing the gap where rogue or new clusters evade runtime detection, aka shadow IT. Sensors update and run independently of GKE version and node pool lifecycle, so detection rules arrive without upgrading or workload disruption, as long as it's not CrowdStrike taking on the internet. The center uses fixed per-node memory limits and predictable overhead, which matters in burstable AI and web workloads. Telemetry feeds directly into the Wiz Security Graph and Wiz AI app to correlate vulnerabilities code is actually running in memory, helping prioritize real risks. Good luck on pricing as they have not publicly stated it.

[84:22] A: So this is the first Wiz announcement I could remember hearing about since the acquisition by Google. And it, I think it's very telling that it's a deep integration with GKE, um, and effectively getting vulnerability data from runtime of GKE clusters into the Wiz platform, which is a super cool, uh, service that only to my knowledge CrowdStrike offers today. So, and you have to do a, you have to do a lot more, uh, sort of wrangling and plumbing to make the existing solutions work. So this is kind of neat. I think it, it is, I imagine it's just gonna be something you, is just there. And if you're a Wiz customer, you'll just be able to get this natively, which is kind of crazy.

[85:10] B: I think it's an add-on. So it's another thing you probably have to buy is what I've gathered.

[85:15] A: Well, you have to own Wiz. Wiz is not a Google product.

[85:19] B: Yeah, but Wiz is an add-on, you know, it's an add-on. I know that they're, they're getting more and more integrated. I know a few people that work for Wiz have like, they're definitely getting more Google-fied as a company.

[85:31] A: So, well, Google's gonna wanna make the most of that investment, right? So they paid a lot of money for it. People really like Wiz. They do maintain they're gonna keep Wiz multi-cloud, like they're not gonna make it a Google-only tool. So that's, which I think is good, 'cause if you're an existing AWS customer using Wiz, you're probably nervous.

[85:49] B: Yeah, it was only a $32 billion, yeah, event purchase price.

[85:54] C: Yep.

[85:55] B: Oh, roughly, also roughly $1 billion in additional for employee retention bonuses on top of the base purchase price. No big deal.

[86:04] A: No big deal.

[86:05] B: What's, what's, what's your $32 billion? What's another billion here or there? Introducing new scalable perimeter options with VPC service controls. Google just made VPC service controls much easier to manage at scale. For anyone that's worried about data exfiltration, especially as AI agents start crossing platforms and taking stuff without you knowing about it, perimeters can now—

[86:29] A: point on the doll where AI touched your data.

[86:34] B: Thank you for getting the reference I was going for. I was just trying to be more subtle about it, Ryan.

[86:41] A: Yeah, no, I'm subtle as a lot of bricks.

[86:46] B: This is what happens with Justin's out here, guys. Mm-hmm. Purview can now include folders as members, so every project with nested subfolders inherits policies automatically and memberships follow projects when they are moved. Dry run mode supports folder memberships too, because before you just had to do it and now you can actually see what's going to do in advance. So administrators can test things. Nice to do. Ingress and egress rules now accept folders and, and organizations directly, replacing long lists of individual projects and keeping attribute counts under quota. Private Service Connect endpoints for Google APIs are now supported as attribute rules, so a policy can match a private connectivity architecture, including endpoints, and propagate through Network Connectivity Center. Guided violation recommendations in Violation Analyzer, because Google names stuff directly on the nose there, generates a narrowly scoped fix for blocked requests such as ingress rules, egress rules, access levels, or accessible service changes that can be validated in dry run first mode. Google says this cuts resolution times back from days to minutes and reducing the temptation to open parameters to widely. All this is available to you at no cost. Ryan.

[88:08] A: Yeah, full disclosure, I made everyone keep this in the show because I know only I'm interested in this, but I think it's super cool and it's only because VPC service controls ruin my life on a continuous basis. And this is finally an improvement for VPC security controls that I like and doesn't make my life harder. For once. Um, so yeah, so applying a security perimeter, you define— define a perimeter as all the projects all at once, meaning that if you want to allow something like project vending, you have to give someone permissions to modify at the organization layer whether or not a security perimeter applies or not to a project. Kind of a big deal. And now you can tie it directly to the folder, which is a one-time action, and any project deployed to that folder automatically inherits those rules. Thank you, Jesus. The other thing that's super cool about this is the way that Google protects the, uh, API access within VPC service controls is through DNS hackery. So you're effectively in your VPC config intercepting the DNS targets for this and just rerouting it to internal Google APIs. That sucks. And then everything outside of that doesn't, uh, is considered outside of the boundary, 'cause then it's publicly accessing the, the Google API. So it's this awful thing and you have no tuning other than this is internal, this is private, this is restricted. That's all you can do. And so now with this change, you can actually define actually HPL patterns at layer 7. So then now you can do much more sophisticated routing on, on those protections and, and how those VPC service controls, uh, protected APIs are accessed, which I think is very cool. Have I allowed you? You guys under—

[89:54] B: I was trying to find the snoring.

[89:58] C: Yeah, were you just waiting for him to shut up too? God, I'm never doing this again because I was horrible.

[90:05] B: I'm adding in for next time Ryan does this, the snoring, the sound effect.

[90:13] A: Yeah, yeah, uh, you're welcome.

[90:17] B: So on to other things that make you You wanna go to sleep, Ryan? Do you wanna take a sway at Azure? On Azure. Oh yeah.

[90:25] A: How about automatic zone balancing for your virtual machine scale sets? Huh? Yeah? Got your attention now? Azure just made automatic zone balancing generally available for machine scale sets. Means your multi-zone scale sets can now heal their own zone imbalances instead of silently drifting towards one AZ zone. That's gonna blow up and screw you later. Over time, scaling operations and other capacity constraints leave zones unevenly populated, so a single zone outage can have far more of an impact than expected. The POST example has a 50% impact when balanced versus a 33% when balanced across all 3 zones. Thanks. The feature continuously monitors for this and rebalances automatically. Rebalancing uses a create before delete approach, replacing 1 VM at a time with cooldown periods between operations. The health is validated through the Application Health extension or Load Balancer health probes before the existing instances are removed. Any instance protection policies of course are respected. Automatic instance repairs are enabled by default with this feature, giving instance-level and zone-level resiliency out of the box. Although customers can opt out of repairs if they prefer to manage recovery themselves like fools. Changes since preview, the AutoScale coordinations where scale-out and customer-initiated capacity changes can, Kubernetes can cancel in-progress rebalancing while scale-in waits for the rebalance to finish. And the zone balance math that counts active, deallocated, and powered-off VMs. Let's place practical considerations. It is best for stateless workloads since rebalancing recreates VMs rather than preserving the identity, networking, and disks. There's prerequisite that at least 2 availability zones for all, and all instances must be zonal. and the application health monitoring must be enabled. It can be turned on via the portal, CLI, PowerShell, REST API, carrier pigeon, smoke signals. But there was no pricing listed.

[92:18] B: There's no pricing for this. There's no pricing. It's just, it's a built-in feature of the scale sets. And we'll go back to the prior statement. I've been in a situation where Azure had a zone outage. Everything nicely scaled over, failed over. I was nice and happy. And then all of a sudden another zone about a month later failed over, but things hadn't rebalanced since then 'cause the scale set hadn't moved up and down. And it goes into the comments of how a single zone can become a little bit more heavy than others. So it's a nice feature, it's a nice quality of life improvement. The issues in the preview are kind of funny if you think about it, if it, you know, how they occurred, but you know, It's a good quality of life improvement. Yeah, I mean, it's scaled in. Oh wait, we canceled it because we were doing it too, which sounds like Microsoft because they can't have two operations running at once. So I get why it happened, but still, I mean, it's just a nice quality of life, you know, if you're running anything at any level of scale.

[93:20] C: Still not going to Azure, Matt.

[93:22] B: Not doing it. Well, if that doesn't make you If that doesn't want to make you, maybe Ryan has one more.

[93:29] A: Maybe one more temptation. Now generally available, service tag match conditions for Azure Front Door Premium WAF. All right, do I have your attention, sir?

[93:41] B: No.

[93:41] A: WAF now supports service tag match conditions and custom rules, letting you filter traffic by Azure service IP groups without matching or maintaining IP lists yourself. Custom rules can now match a request source IP against Azure service tags, which Microsoft updates automatically as the underlying IP prefix changes. This removes the manual work of tracking and updating all your IP lists. Allow use case lets Azure services your app depends on, such as monitoring and health check traffic, without hardcoding their IPs. You can now deny traffic from Azure services and your app never expects requests from or throttle a given service's traffic rather than blocking it outright. Conditions can be combined, for example, a service tag plus URI, host, or request method to lock down sensitive paths like admin endpoints to specific Azure sources. Feature's generally available as of October 2026 and applies to the Premium tier only.

[94:37] B: Yay, Azure Premium. This is just nice because you could actually now, and AWS had it for years, you know, had the, okay, you're only allowed to access the ALB if you come from the WAF, you're only allowed. So they started to be able to kind of control what can go where if it comes through a certain location, a certain set of services. Great quality of life improvement from a security perspective because you're able to lock stuff down. Does this tell you how interesting all the Azure stories were this week, guys? Super. These were the ones we selected for your listening pleasure.

[95:15] A: Yeah, exactly.

[95:16] B: For the one person that fell asleep listening to this.

[95:18] C: I'm told I'm moving all my workloads right now. You got me, Matt.

[95:21] B: I knew it.

[95:21] A: We got it.

[95:23] B: But, but we can't— we tempt you with some Oracle stories now, Cody. I think by the end of this story, you're really gonna want to move to Oracle. I don't know, man.

[95:34] C: I'm just now thinking of shifting my stuff to Azure.

[95:37] B: I don't know.

[95:37] C: Anything could be more tempting.

[95:41] B: Introducing Dynamic Resource Virtual Machines. Oracle For the one person that fell asleep listening to us, I'm sorry.

[95:55] A: We're very sorry. Go back to sleep.

[95:58] B: This isn't your dream show.

[96:00] A: We need the listening metrics. Leave us on.

[96:04] B: Oracle just made Dynamic Resource VMs generally available, a way to pay roughly 10% less for VMs by letting OCI overcommit the physical CPU and memory behind them. DRVM, just to make the acronym really hard to say, keeps your configuration of OCPUs and memory shape. For example, 8 OCPUs— everyone else just calls them vCores, but whatever— and 64GB of memory. But OCI dynamically manages the physical resources underlying what 10% discount in order to save you money. Under the hood, it relies on dynamic CPU scheduling and memory overcommit with OCI monitoring host memory pressure and rebalancing instances without rebooting. In practice, this is Oracle's monetizing fleet-level oversubscription. So expect trade-offs to be less predictable performance when you get a noisy neighbor syndrome. Unlike OCI's burstable instances, there are no baseline utilization requirements and no burstable credits to accumulate. You can use the full configuration capacity on demand, which is cleaner than the credit burstable model that other clouds provide, though I really like it, even though a lot of people tell me I'm crazy. And you are crazy, though. Or, eh, different problem for a different day. Though Oracle gives no hard performance guarantees, which also terrifies me. Oracle says stay on standard VMs for sustained latency-sensitive or database workloads, which is what I assume everything is on Oracle. And if you use DR VM for variable workloads like dev/test, CI/CD workloads, stateless ETL batch jobs, et cetera. A 10% saving is modest, but it does make things be cheaper.

[97:57] A: I will say this model like when choosing this over like the credit thing, like I'd rather have a credit threshold that I can monitor and then know when the performance is going to go crap or just instead of just Oracle turning it off whenever they want to. So, but I don't know if I, like, I guess if I, you know, if I had a use case where it wasn't that sensitive and it could be just turned off at any time.

[98:20] B: Sure.

[98:21] A: I guess I would select this just to save some money, but this is just thin provisioning.

[98:25] B: It is. And what worries me here is they don't say you're always gonna get 50%, you know? And that's what kind of concerns me. It's like you could go down to very low performance and you could be paying a lot of money. Like that 10% savings doesn't feel like a good ratio here. But—

[98:45] A: Yep, probably not. It depends on the workload, right? If you have a, if you have something you don't care about or doesn't, isn't used a lot. Maybe.

[98:52] B: But then that's when I use burstable.

[98:54] C: Mm-hmm.

[98:55] A: Like, but does Oracle have that?

[98:56] B: I don't know. We can have TrackIt tell us next week. We're gonna—

[99:02] A: No, no more follow-ups.

[99:03] C: Wait, wait, hear me. We don't wanna know. Yeah. I, I think the, I think I figured something out here. I think the O in OCPU may have something, something to do with Oracle.

[99:19] A: No way. Well, Oracle can't call it vCores because they charge for those. So, all right, one last story. So if we haven't convinced Cody to move all those workloads to Azure or into Oracle, how about one of the NeoClouds? So Crusoe Cloud is offering NVIDIA HGX v3 Blackwell Ultra systems. And this page we kept in there only because it's really worth a look for anyone tracking how emerging GPU clouds are pitching their inference economics against the hyperscalers. The HCX B308 GPU Blackwell Ultra baseboard with 2.1 terabytes of total memory and 144 petaflops of sparse FP408 dense— don't know what that means— connected via 5th generation NVLink versus the Edge HGX B200, which no one wants anymore. Clearly no performance, but it does have the, the new B300 card has 1.5 times more memory, 2.1 versus 1.4, and it has 2x per GPU network bandwidth.

[100:25] B: Send us all your old GPUs that you don't want. We'll take them.

[100:28] A: Seriously. Yeah.

[100:29] B: Yeah. Yeah.

[100:30] A: NVIDIA's claims versus the H100 are 7.5x more dense per compute and 50% higher throughput per megawatt. These are the vendor figures, so don't trust them. And obviously measured against low-latency agentic workloads, so real-world gains will vary by model and serving stack. Crusoe claims up to 20x faster and 81% cheaper than traditional cloud providers for, for renting GPUs. So it's worth discussing how those numbers are benchmarks and what workloads they apply to. And if that's cheaper than me buying my own GPUs and just generating a whole bunch of heat in my garage. Yeah, maybe I'll look into that.

[101:07] B: I definitely have seen looking at some of the GPU stuff, um, recently that it is significantly cheaper to, if you are gonna be using a GPU like this, to run on these Neo Clouds. I've seen a couple customers, you know, and then I've done a price comparison moving them over to AWS and I'm like, Nope, don't do that. Like, I know I shouldn't say that out loud, but like, nope, this does not make sense here. Like, you are saving way too much by running it. So if you are actually leveraging that GPU and you've written your application code or you are doing your own training or things along those lines, I think it does make sense to run in these Neo Clouds and just set up, you know, a site-to-site or whatever that you need across it to transfer your data. Hopefully you don't get killed on egress costs, but you know, there's ways to keep that cheap if you can.

[101:59] C: My only hope is that it's gonna make all the cool video cards last gen so I can buy one.

[102:07] A: 'Cause for, for your gaming rig.

[102:09] C: Yeah. Just anything.

[102:11] B: Yeah.

[102:12] A: No, I mean, it's still gonna be like an absorbent amount of money 'cause it's, everything's expensive and, and too much. And people are just trying to like, they're building data centers and powering them by nuclear. You know, things as fast as they can. So I don't think anything's going out of date or going out of use. They're just adding more.

[102:30] B: At one point, we'll just go raid a data center that, you know, closed, shut down, went bankrupt, you know, and there's no security guard there watching anywhere. We'll just, you know, go steal whatever's left in there.

[102:41] A: Oh no, no, no. Hella LAN party, dude. We'll go into the data center. Hella LAN party in the data center.

[102:47] C: Quick one. So we were talking about this, I think, before the show started, right? Like, yeah, it's interesting to figure out like what can be a local, what can run at a data center versus what can run on a hyperscaler. I don't know. I, I think that's going to be a huge math problem that somebody should really figure out.

[103:09] A: And like, and this is a— we didn't even discuss this option, which would be, you know, spinning up a VM in Crusoe Cloud and using the GPU on that to run you know, your Herbies or Opa-Claw agent and have your local thing, your local model installed directly on that and use its inference. Like we were just talking about the benefits of like, when do you run something locally and when do you ship it off to, you know, a higher performer, you know, frontier model. And this is just yet another layer, you know, like, and it's, you know, when I look at what I want to do, which is all the simple home automation stuff and little things like that, like it's not on my home network, But that's fixable. And so maybe this, you know, trying to figure out the cost economics of these things is challenging. And when you have to match it against the capabilities of where you're running these things.

[103:55] C: But yeah, how smart?

[103:57] A: How smart do you want it? And you know, how smart do you want most of it to be? And 'cause like 90% of it, I don't want it to be smart. Like watch these stupid metrics climb and fall and then send me a, Notification, right? Like, that doesn't take a whole lot of smarts and reasoning. I don't need a powerful frontier model, but I also, you know, it's not gonna be a whole lot of tokens, but it's also like, then if I'm gonna use something that's hosted, how do I get it access to my Home Assistant server? Like, do I have to, you know, like, it's, it's just different weird things you gotta figure out. Oh my God, we did it, guys.

[104:32] B: Cody, what do you think? Would you join us again, or is this way too much?

[104:36] A: Work. We're terribly sorry.

[104:37] C: I had a lot of fun.

[104:39] B: Good.

[104:40] C: Hopefully I don't look too stupid in the, uh, post.

[104:42] B: No, no, they fixed that for us.

[104:44] A: We fix it in editing. We're— Elliot's a genius, so we say nice things about him at the end so that he edits the show to make us sound smart because he's been doing it for years somehow.

[104:54] C: Oh, thank you, sir. Nice to meet you. Yeah, it's funny because like I wanted to prep, so I listened to the show notes, read some stuff, like trying to figure out like how things went. And then we got on and I was like, are we going? Like, what do we do? It's actually after doing it once, I don't think I'd put 30 minutes into it. I put like way too much time thinking about what we were going to be doing.

[105:20] B: You know, the more you prep, the better show it is. But I will say I don't always have the time to prep or even read the show notes because of life at times. So there's times I just. Walking blind like today. I'm like, well, we're talking about stuff. Let's see where the conversation goes.

[105:36] C: Yeah, no, but I mean, like, I went through it, listened to the stuff, but having it live show notes that people are editing, like, I was watching it go back and forth and you're putting notes in back and forth or hurry it up. It went a lot easier than, like, because I've been on other things that I show up and people are just like, okay, look, show up and be entertaining.

[105:58] A: Go.

[105:59] B: Yeah, dance monkey, dance.

[106:01] A: Yeah, we gave up on that, you know, long ago. We hope we're entertaining, but it's, you know, the underlying premise of the show is we're going to have to learn about this cloud stuff, so we're just going to take you on the journey with us.

[106:12] C: You hope you'll be entertaining, but that's not—

[106:15] A: I hope so.

[106:16] C: Yeah.

[106:16] B: But you're promising.

[106:18] C: Yeah.

[106:19] A: No promises.

[106:20] C: It's not for lack of preparation anyways.

[106:23] B: Yeah, exactly.

[106:25] C: Correct.

[106:25] A: Yeah, the more I prepare, the less funny I am. I know that for a fact. That's been scientifically proven.

[106:29] B: That's true.

[106:29] C: You're horrible. However, we did prepare. We tried very fucking hard, dude.

[106:34] A: You are correct, sir.

[106:37] B: All right, Cody, thanks so much for joining us. Hopefully we'll have you back soon.

[106:42] C: Yeah, no, we'll do it again.

[106:43] B: Thanks, guys.

[106:44] A: All right.

[106:44] B: Later.

[106:44] C: Appreciate it.

[106:45] A: Bye. Another week of cloud news wrapped up.

[106:49] B: Boat will collect the news.

[106:50] A: Justin will get the notes, Jonathan will write some code, Ryan will watch the perimeter, and Matt will reluctantly watch Azure. Till next week for AI, Amazon, Google Cloud, and Azure, and hey, maybe even Oracle, who knows? Check out TheCloudPod.net for our newsletter, join our Slack, message us on socials, or leave a review.