# 368: Push, Pull, and Pray: GitHub Outage Strikes
Duration: 75 minutes
Speakers: Justin, Ryan, Matt
Date: 2026-08-28

## Transcript

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

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

[00:14] Justin: We are your hosts, Justin, Jonathan, Ryan, and Matt.

[00:18] Ryan: Episode 368, recorded for August 18th, 2026. Push, pull, and pray, the GitHub Actions strikes. Good evening, Matt and Ryan. How you guys doing?

[00:28] Matt: Good. How are you?

[00:29] Ryan: Better than my GitHub Actions from yesterday that never ran.

[00:34] Matt: Yeah, they might. I had some random alerts today of like, I think just things that we're still cleaning up.

[00:40] Ryan: Yeah, I just got a bunch of weird pull request notices. I'm like, I'm pretty sure I submitted that code yesterday. Still catching up. Uh, well, I am in beautiful Atlanta on East Coast time with Matt. So, uh, I now know what it's like to record the podcast at 8:30 at night. And I don't like it, so sorry about that.

[00:59] Matt: And we started early, slash on time today compared to normal where we, it's like 9, 9:15 by time we all get together.

[01:07] Ryan: Or we, yeah, we get to all the topics and we argue with the show title and all the things, yeah, so. Well, today's top story is why I was flying to Atlanta yesterday. GitHub decided to take a nap all day. They confirmed a widespread outage starting at 9:40 AM Eastern time on August 17th affecting web API Actions, pull requests, issues, webhooks, and authentication services. I mean, like, what's really left at that point? Just call it all, it's all down. As of 11:42 AM EDT yesterday, GitHub had moved into mitigation mode, but error rates remained unchanged, roughly 20% for web and API traffic, and approximately 50% for archive and raw repository content downloads. Pretty critical issues to GitHub. Copilot was added to the list of affected services at 10:31. Git Operations, Packages, Pages, and Codespaces remain listed as operational, indicating that outage was concentrated. But I never wanted to verify any of that because I was just manoid and mad. They did post on their post action that complicating factors impeded recovery, including a number of scraping attacks on code load endpoints. And to prevent recurrence, their follow-up actions include correcting auto scaling policies to account for service mesh sidecar concurrency and capacity, auditing Istio request concurrency and scaling limits, reviewing retry limits and backoff behavior, addressing the VS Code retry behavior that amplified Copilot token traffic, and improving Load Balancer capacity monitoring. So, uh, are you basically saying you were DDoSed and failed?

[02:30] Matt: DDoSed and particularly attacked on different, a bunch of different fronts and failed.

[02:35] Ryan: Yeah. I mean, that's just a bad outage. Like, and their communication was pretty shitty through the whole thing. I mean, I was reminiscing about the 2019 CrowdStrike outage and I just go back to their communication and how much better they were at these things. And it's like, you know, they're just hurting nothing but themselves at this point. The, the reputational damage that they're taking, I think, is pretty high. Like, I would seriously question someone's logic of saying, hey, you know what, we're going to adopt GitHub in 2026. Like, until they can prove themselves that they can fix these issues, I'm not sure that that's a, a solid place.

[03:12] Matt: No. And their core thing of just Git itself needs to essentially be 100% uptime, in my opinion. Sure, GitHub Actions, and you know, is more add-ons, but the, the core of it, just Git itself, like, I was getting weird errors across the board. Yeah, forget the website and everything else, but I mean, you gotta get the core working.

[03:34] Ryan: And like, they can blame AI and they can blame, you know, expect, you know, all this extra load, but like, how, like, they need to be public about it, be like, hey, we've You know, they've been vocal about the fact that they're saying like 10x or 20x the low that they were expecting before, but then like, what's your actual timeline? What's your actual plan to get out of this problem? Like, I, like, you owe the community at this point more than just, you know, lip service that it's gonna get better.

[04:01] Justin: Yeah. They're becoming a joke, right? Like, it's big. I know several engineers where it's just, you know, there's, they're making fun of it, like rather than you know, touting it. So it's just not good.

[04:12] Ryan: Well, and I mean, if you start losing open source communities off of it, as they're going to go to GitLab or to other places that can host them more reliably. I mean, we talked about GhostTTY, I think last time. They haven't yet moved, but they, you know, say they're still going to move. I just, it's just a tough, tough road to hoe. And I was in a conversation just the other day about somebody and it was like, hey, we should move from, you know, Bitbucket to GitHub. And I was just sort of like, eh, I'm not so sure that's a great idea.

[04:39] Matt: You have not been on Bitbucket recently then.

[04:42] Ryan: I mean, I've, it's true. Bitbucket may be just as messed up as GitHub is. I don't know. But, uh, and then like I've tried GitLab, you know, Ryan and I did a project together on GitLab and it was okay. I don't know that I'd be super there.

[04:54] Justin: It's fine. Yeah. I kind of like their CI/CD pattern better than I like GitHub Actions, but I mean, it's not that different.

[05:01] Ryan: We use CodeCommit.

[05:03] Matt: Like, It's not being deprecated.

[05:06] Ryan: It's undeprecated. I mean, it'll work just as well as GitHub is at the moment.

[05:10] Justin: I mean, there's other, there's other people playing in the market that are coming for GitHub's Actions. Cursor just launched a code hosting platform.

[05:16] Ryan: I mean, Actions isn't, I mean, yes, Actions is cool. I love Actions, but you know, there's been players before them. CircleCI was out there forever. There's always Jenkins.

[05:27] Justin: No, I mean, Cursor's hosting Git, like they're, They're going full.

[05:31] Ryan: Yeah. They said they're going to do their own Git thing, which again, do I trust a vibe-coded Git solution from Cursor? I don't, I don't know.

[05:39] Justin: What isn't vibe-coded these days? I don't know.

[05:42] Ryan: I mean, everything is vibe-coded at some level. I don't know. I, but yeah, again, I think this is, this transparency problem. Again, if they were public about the issues, like, like this, they've put, you know, at least the post-action items on the incident, but like, I want to see a real postmortem. I'm like, I think they deserve, the community deserves a CrowdStrike-level mea culpa.

[06:03] Matt: Yeah, they definitely need a full, I almost think of it like, like when Amazon writes up their postmortems or, you know, and Azure has started getting much better at it, like, you know, minute by minute kind of what happened, what they were doing. And I know it takes time to gather those and this is 24 hours after it happened. So like, but you get a week is kind of my, line in the sand.

[06:25] Ryan: My next recording, they have a full postmortem, I will be happy. If they have said nothing, then I'm just gonna be complaining. So I'm gonna follow up on this next week and talk about it.

[06:36] Matt: But it's not even that, it's like, talk about how they're trying— like, before now, they should have been talking like, yes, we are adding capacity here, we are doing these things. And they've sort of touched on it if you look at a bunch of different things, but there's not like here's the timeline to the community. And GitHub isn't cheap too for organizations.

[06:54] Ryan: So like, it's expensive, especially if you're using pretty expensive tool, really expensive, right?

[06:59] Matt: So they really need to open up a lot more. And I'm trying to figure out if it's, you know, GitHub's mostly been running, you know, on their own. I, we've talked about on the show where it's folding more into the Microsoft world. So is it that Microsoft is now kind of controlling more of it and controlling the narrative from, you know, from what they do slash legal slash compliance perspectives, or what is it? Because I felt like they used to be better about communicating stuff.

[07:26] Ryan: I mean, they were, but you know, and they're blaming that AI has caused the problem for them.

[07:31] Matt: And so use AI to fix the problem.

[07:34] Ryan: Yeah, exactly. I mean, but again, maybe it's hardware capacity related then, but again, like it's, it's about being transparent with the community and I feel like they just have to be They have to do more. And yeah, if Cursor comes up with something, maybe that's interesting. You know, maybe Cloudflare can, you know, puff out a GitHub alternative. They seem to do like, they do those kinds of things. Anybody at this point, uh, you know, it's starting to become fair game. Or GitLab, you know, GitLab should offer 30 days free for companies, you know, coming from GitHub. You know, there's lots of ways to try to be marketing against this, which I would frown on most of the time, but it's just too, like, at this point, they're just been so lack, of any honesty about what's happening. I just, I don't even care. The dirty marketing happens now.

[08:17] Matt: I saw today, I think on Reddit, it was like Microsoft was down yesterday, Claude's down today, development's down 80% this week because of the two outages.

[08:27] Ryan: I'm like, yeah, sounds about right for a real active directory. I mean, at least in the case of Claude, like, okay, Claude's down, I'll switch to Codex or I'll switch to, uh, OpenAI LLM or whatever. So like there's, there's plenty of alternatives that are all really good. GitHub is, you know, the monopoly in that space. And why are we talking about GitLab? You know, we just talk about it's not their best. You know, there's other alternatives, but they're not as good. And so unless those other brands start really investing heavily, like they're— it's not like Claude being down, in my opinion.

[08:57] Matt: But it's also like, you can't— it's your single source of truth too. It's your code repo. It's not like you can—

[09:05] Ryan: which makes all of the AI work because AI is so, uh, writing so much code that you don't know what it is that you need to have proper ability to roll back at any time.

[09:14] Matt: I was even going with, you can't even like multi-vendor your Git repo. Like, what are you gonna do, synchronize on every commit and push up to two locations?

[09:25] Ryan: And I mean, it's not, I mean, it's not hard to do.

[09:27] Matt: You just set up multiple remotes, but you tell every developer to do that and make sure they push to both locations and do pull requests.

[09:34] Ryan: Here, I will have Claude start right now to write a simple utility alias that will just do the auto-push to two different repos. And when they do git push, Oh, we'll alias it. It'll be fine. No, no, no.

[09:46] Justin: Definitely had, I've definitely done that from like, you know, Bitbucket to GitHub migrations. Replace like all the capabilities. Yeah.

[09:56] Ryan: Yep.

[09:57] Matt: Then you run into Bitbucket API limits and yeah, then you get really mad. I don't know if you've ran across that doing those migrations, but that was painful.

[10:04] Justin: Yeah.

[10:04] Matt: Then you have to do idempotency with all the repos because you realize that you can't consistently do a git pull. On Bitbucket, it was a load of fun. I've done a few migrations, in case you can't tell, from Bitbucket.

[10:15] Ryan: Yeah, the multi-remote is a problem for the pulls. That is a bit of a hand chicken shirt. You know, there is a plugin for Dropbox that makes Dropbox actual Git. I can just go back to that for my personal stuff, I guess.

[10:27] Matt: Yeah, interesting.

[10:28] Ryan: Not to worry about it.

[10:29] Matt: That feels like Matt and Ryan level bastardization.

[10:33] Ryan: Oh yeah, I don't know if the plugin still exists, but there was literally a Dropbox Git plugin that you could install and it would basically, 'cause the, you can't just use a folder with Dropbox. It wouldn't work the right way. But the, the commit, the plugin fixed it so it would work properly. It was awesome. Uh, but then I was like, well, once GitHub Personal came out, I was like, I don't need this. I can just use GitHub 'cause I don't mind paying $0 for my personal projects. And so I stopped using it, but maybe I need to go back.

[10:58] Justin: I don't know.

[10:59] Matt: I have a solution. Route53. Figure it out.

[11:02] Justin: Good luck.

[11:02] Ryan: Yeah, I can just use that as my database. Perfect.

[11:04] Matt: Exactly.

[11:04] Justin: Yeah. Yeah.

[11:05] Ryan: Yeah.

[11:06] Matt: All right.

[11:07] Ryan: Well, let's stop bashing GitHub for now. It'll come up again, I'm sure. For now. AI is how machine learning makes money this week. Anthropic is adding two new capabilities to Claude managed agents. First, a self-hosted sandbox in public beta and MCP tunnels in research preview, both aimed at keeping agent tool execution and data within enterprise security boundaries. Music to Ryan's heart.

[11:28] Matt: Yes.

[11:29] Ryan: Self-hosted sandbox splits the architectures where Anthropic's infrastructure handles agent orchestration and context management on actual tool execution, code files, and data stay on the customer's own infrastructure or managed cloud providers like Cloudflare, Daytona, Modal, or Vercel. MCP tunnels let managed agents connect to internal databases, private APIs, and ticketing systems without exposing them publicly. A lightweight gateway makes a single outbound connection requiring no inbound firewall rules or public endpoints with end-to-end encryption. Is that a VPN? Like, why, why are we complicating things?

[11:57] Justin: Because you don't really want to have Anthropic VPN to every company. That uses their enterprise product, but—

[12:03] Ryan: Ah, yeah, that's maybe true.

[12:05] Justin: Yeah. I mean, this is definitely something that if you're going to have, you know, someone else own, you know, your execution, so many things come up immediately like that you can't access and everything internal stuff that, you know, you don't really want to expose publicly. And then you basically are saying expose this publicly. Uh, it always, you know, it's come up a lot for different migrations for Jira Cloud and, and certain things like that where you have integrations that are internal. So I, you know, this doesn't surprise me. It's a good feature. I think not everyone wants to manage the, the whole execution and context management and have it all run locally and on the resources on that. So it makes sense.

[12:48] Matt: I mean, I also see this as like a cosplay later on too. If you have your own data center and your own equipment, why pay for them to host it? Let it spin up and down, start everything, GitHub Actions. GitLab Workers.

[13:00] Justin: Yeah. And then you get up Actions, just like GitHub Actions. So they'll increase their prices exorbitantly for the API costs.

[13:07] Matt: Did they ever, did they ever come back to that? I know they drew, they stopped doing it. They rolled that back. They never came out with a future one, did they?

[13:16] Ryan: Uh, I haven't looked in a bit. I was annoyed because I want to try it for the Cloud Pod, uh, GitHub repos. And they were still not accepting new signups last I looked. So, and then I found PR Agent and I said, well, I guess I don't need that anymore.

[13:29] Justin: Mm-hmm.

[13:31] Ryan: Moved on with my life. You know, there were a couple companies here I didn't, I hadn't recognized before. Daytona? Have you guys heard of Daytona? I know, I've heard of Vercel, I know Cloudflare, I've heard of Modal, although I haven't tried it, but Daytona, that's a new one to me.

[13:41] Justin: Yeah, that one I don't know.

[13:43] Ryan: Another neoscaler out there just trying to make a buck?

[13:47] Justin: That would be my guess.

[13:49] Matt: Daytona.io?

[13:51] Ryan: That would be obvious. Or Daytona.ai.

[13:55] Matt: .io, secure and elastic infrastructure for running your AI-generated code.

[13:59] Justin: Yeah, that's it.

[14:01] Ryan: Interesting. Then I get to the examples for process execution. I'm just like, eh, that sounds like fun. Let me learn that. Let me point AI at this problem because that looks ugly. Nothing built in for Python projects, it appears. At least that one was. And then npm. Oh, Ruby.

[14:23] Justin: Hey-o. They've got Ruby. Yeah, you'd be good. They've got Go and Java.

[14:27] Ryan: Yeah, yeah.

[14:28] Justin: Yeah.

[14:28] Ryan: All right. Well, now I'm more interested. I was just looking at the programmatic control file. It was all Python. I was like, okay. I don't know. All right. Never heard of it.

[14:38] Justin: I'm gonna check that out. That's new for me too.

[14:41] Ryan: Yeah. OpenAI is previewing Ultrafast, a new API service tier for GPT-5.6 Sol that runs up to 14 times faster than standard processing, generating up to 750 output tokens per second, powered by the Cerebris hardware. Unlike prior speed trade-offs that required smaller or more specialized models, UltraFast delivers the full GPT-5.6 LLM model at high throughput, meaning developers no longer have to sacrifice intelligence for latency. Early customers include Jane Street are testing UltraFast across incident response, financial research, and fraud detection, customer support, commerce, and iterative research workflows, with OpenAI citing internal use for log analysis and rapid experimentation loops that previously ran overnight. Service is currently in limited preview to a select group of customers, which means not me, and OpenAI is accepting signups for notifications as access and capacity expands, so pricing and generative details are not yet public, but I assume it's going to be way more expensive. Oh yeah.

[15:31] Justin: I imagine there's some beefy infrastructure behind this.

[15:34] Ryan: Has to be, right?

[15:35] Justin: Yeah.

[15:36] Matt: I'm just slowly watching AI get more and more and more expensive.

[15:40] Justin: Mm-hmm.

[15:40] Matt: It's just getting less and less subsidized by companies.

[15:42] Ryan: It will continue to get more expensive. Uh, that's how it works. They have it there. So CS4 system and CS3 system are the Theranos computers that do this. And yeah, they're like full-size racks. Yeah. So they're gonna be expensive. But then also they have, uh, their own cloud. So now I'm intrigued by the cloud though. Hmm.

[16:03] Justin: Can I remember? So it's, it's more than just hardware, huh?

[16:05] Ryan: It's— But the cloud, and so when they don't sell the hardware, they turn it into their own cloud. And when they can sell the hardware for more margin, they'll do that to OpenAI. That's how I see it.

[16:13] Justin: That makes sense.

[16:15] Ryan: Moving on to cloud tools. Docker is replacing its third-party virtualization layer with a first-party VMM built in-house, giving them full control over the stack that sits between host hardware and containers on Mac and Windows Docker desktop installs. The switch targets concrete pain points, including faster container startup, quicker file I/O for edit-compile-test loops, and memory that gets returned to the host when containers are idle instead of being held indefinitely. Windows developers are getting a notable change here, moving to a VM built and maintained directly by Docker, aiming for Hyper-V level isolation combined with WSL2-like speed. The same engine also powers Docker Sandboxes, so improvements in future enterprise admin controls for governance features lands in both products simultaneously, part of a stated longer-term goal of unified runtime across laptop, cloud, and on-premise environments. It's included in the Docker Desktop version 4.86. I've been using the VMM on the Mac for quite a while now, so I 'Cause the Mac virtualization with the old version was a lot of emulation. And so I switched to the VMM quite a while ago and I've been very happy with it. So I assume on the Windows side it's gotta be good too.

[17:19] Matt: I stopped using Docker when they changed all their licensing and I just use Podman for most of my personal stuff without any real problems.

[17:25] Ryan: I do the same thing, uh, but I do have Docker installed for the occasional times where I need something Docker-ish. Um, but, uh, it even, I think on Podman, I think they've also adopted the VMM as well. It's open source.

[17:39] Matt: I thought it still, I mean, maybe I haven't looked under the hood. It was spinning up its own like, um, KVM container, uh, virtual machine for a while on the M1s to get the x86 hardware and everything else. So I'll have to try this. Yeah.

[17:56] Justin: I mean, if this is like, you know, truly built by Docker and, and it's totally customized and gives them the performance that might be an advantage over the open source options, which they have not had for a while since they went to that weird business model. Yeah.

[18:12] Ryan: And they still have not made people, you know, happy. Okay. So they both call it a VMM. So that's my confusion. So the, for Podman, they're using a QEMU or Apple HV hypervisor framework with Fedora Core as a guest Linux. And then for Docker Desktop VMM, they also are using the hypervisor framework from Apple. But they're using LinuxKit as their guest Linux OS. So it's slightly, slightly different, but basically the same idea. They're both using the Apple hypervisor framework, which is what I was alluding to that I moved to that I was very happy with.

[18:42] Justin: Yeah. Cool.

[18:43] Ryan: We have a Packer upgrade this week. First of all, there's two things here about this. Uh, first of all, HashiCorp finally stopped blocking the podcast show note editor or screen. It's been nice. Last few HashiCorp articles, I haven't had to paste the entire story into the article. So that's been nice. Is occasionally it still hits. But, uh, but anyways, so Packer also got an update, which I love Packer, so that always makes me happy. And this time, Packer 1.16 is adding Salsa provenance association to machine image builds, giving teams a verifiable record of how images were built, including the source build steps and environments used in the process, which should be super easy to just copy-paste the Packer script. But whatever, uh, this addresses supply chain security concerns by allowing organizations to cryptographically verify the machine image was built as expected without unauthorized modifications before deploying it to production. The provenance data includes metadata about the build environment, plugin versions, and configuration, which can be tracked against Salsa Framework standards for build integrity. Integration works with existing Packer workflows, so teams adopting this feature do not need to significantly restructure their existing image build pipelines. And for engineers managing compliance requirements or working in regulated industries, this provides an audit trail for machine images similar to software bill of material practices.

[19:52] Justin: You know, more and more I like these types of features for, for building in provenance. We're seeing so many different attacks sort of come at different places in supply chain. You know, it's, it's great to see sort of that cryptographic signing where you can verify that what is, what something says it is, it actually is, which I, I really like. And then being able to trace it down, like even from less security issue, just from an operational point of view is really handy. So I like this.

[20:23] Ryan: Yeah. I mean, software supply chain continues to be a big deal for anybody who cares about compliance.

[20:31] Matt: It's always amazing the additional features they slowly keep adding to these tools. Like Packer's been around for 10+ years and they rewrote it also from Ruby to Go again. Like.

[20:44] Ryan: Well, I mean, it's a crypto 'cause there really hasn't, no one else has come on the market to say, hey, we're gonna give you a really simple way to build AMIs.

[20:51] Justin: Yeah, except for the cloud, the clouds themselves, right? Like that's—

[20:54] Ryan: But even their tools aren't simple.

[20:56] Matt: No. And Microsoft Azure is Packer. You can like, it's literally packer-logs, .log file. Like they don't even hide the fact that they stole it.

[21:05] Ryan: I mean, I, I know Amazon has their own image factory now, but what is, what's Google's answer on this? Are they using Packer? Are they using something? Else? Because they only have AMIs in GCP, so.

[21:16] Justin: I don't know if they have their own solution for building images, VM images.

[21:20] Ryan: I don't know if they do either.

[21:21] Justin: Yeah. I'm not aware of one actually, now I think about it.

[21:24] Matt: Quick Google search says Cloud Deployment Manager. That's not it.

[21:30] Justin: Mm-mm.

[21:31] Matt: Azure. A lot of stuff.

[21:33] Justin: Yeah. Deployment Manager is, is them ripping off Terraform. That is just straight Terraform.

[21:38] Ryan: Yeah, it runs Terraform.

[21:40] Justin: It just runs Terraform for you. Yeah.

[21:44] Matt: Yeah. Azure's just Azure Image Builder and ECS, ECS Image Builder.

[21:49] Ryan: Yeah. But, and at least the Azure side's very good that it's built on Packer. I think Amazon's might be built on Packer too.

[21:55] Matt: I would assume somewhere under the hood it is.

[21:57] Justin: Yeah.

[21:59] Ryan: Yeah.

[22:00] Justin: Unless, unless they change the licensing model to make that cost prohibitive, but we'll just use the word on their off though. Kubernetes, what up? Yeah, I know every version of it that I've built is built on Packer.

[22:11] Matt: Yes, yes, it's always Packer somewhere under the hood.

[22:14] Ryan: Uh, all right, AWS, uh, IAM Role Manager is a rethink, uh, for the starting point of your IAM roles. It automates role creation and attachment for supported services like Lambda and EventBridge, eliminating the manual step of writing trust policies and attaching permissions before building Enable it via the IAM console account settings or control access at the org level with SCPs. For services with unpredictable permission needs such as Lambda functions running custom code, Role Manager attaches the PowerUserAccessManaged policy, which excludes IAM, Organizations, and Account Settings management, giving broad service access without full admin rights. The roles created by Role Manager are standard IAM roles that customers fully own and can view, edit, or delete. Each role retains a referenceable to its source template, visible by get-role and list-roles, and creation events are logged in CloudTrail. AWS recommends disabling Role Manager before production deployment and using IAM Access Analyzer to scope roles down to these privileges, disabling grants 90 days of unused access analysis at no additional cost. Positioned as a tool for development in sandbox environments to accelerate prototyping, with the trade-off that broader permissions like power user access need tightening before production use, shifting the security review to a later stage in the workflow rather than eliminating it altogether.

[23:22] Justin: Hmm. I mean, that's, you know, it's a definitely an enhancement over what, you know, you typically see in development, which is people just granting like super admin or, you know, very permissive roles. So I kind of like the idea of, you know, something that's dynamically building these and attaching it. You know, I wish that the managed roles that it was attaching and building were a little bit more granular and then utilizing that sort of the role manager smarts itself to apply those and, and figure out the delta. So it wasn't so, overly permissive and not production recommended.

[23:55] Ryan: Well, I, I wish that they would create this as like a learn mode, like, right? Like, hey, I'm gonna create this IAM role manager. I don't know what I'm gonna need. And so I would like you to monitor my service for the next 3 weeks. And as you, as I do things, I want you to add to my role and document it in a change ticket or in some type of document, SBOM file, whatever, I don't care. And then after 3 weeks you lock it down. And that becomes the role. That's what I would like you to do. Like, this is like half of it. Like, hey, we gave you this thing, but it's a little bit too broad. And then you have to use your tool to analyze it, to then scope it down. Like, why don't you just give me a role that I know is going to be flexible and dynamic, and then just heavily document what you add to it and notify me via Slack or something else that you're adding a new permission to it based on something. And if I don't think that's accurate, then I can fix it right then.

[24:41] Justin: I don't know.

[24:41] Ryan: That just seems too logical, I guess.

[24:43] Matt: I think they'll get there. This is them piecing it together. Like they're building all the different pieces and then they'll add that. That'll be a re:Invent announcement.

[24:52] Justin: Maybe.

[24:53] Ryan: Yeah.

[24:53] Justin: That'd be nice. I mean, I think a lot of people are having to rethink IAM permissions like this and how they build them for, 'cause it's, we've been able to do this for applications 'cause you have, you know, you have releases and you tie that release, you know, the permissions needed there. As we adopt more and more agentic, you know, workflows within our applications, you don't really know which permissions necessarily that you need access to. And, and I think people are, sort of struggling with the ability to define it as this is what my production application should do, and I should be able to communicate that in some way to my Agentic workflow in my app. But people are more trying to panic and make sure that it works for the user experience. And it's, I think there's a little bit of a struggle right now, you know, where it's just like figuring out how we're going to manage permissions in a way that works for a very dynamic exp— you know, environment. So we'll see. I think there'll be a lot of changes in the space that are similar. Stupid AI agents.

[25:51] Matt: It's AI's fault.

[25:52] Justin: It is.

[25:54] Ryan: It's always AI's fault.

[25:55] Matt: That's what GitHub Actions says.

[25:58] Justin: Except for when it's DNS.

[25:59] Matt: Or DNS.

[25:59] Ryan: Yeah. They're introducing advanced Kubernetes control plane configurations in EKS. EKS will now expose direct configuration of API server, scheduler, and controller manager settings, letting admins tune pod placement event retention, and node port ranges without maintaining a custom scheduler or workaround infrastructure. This targets teams migrating from self-managed Kubernetes who need to preserve tuned settings. The most allocated scoring strategy is a notable addition, allowing customers to pack pods onto already utilized nodes rather than the default spreading behavior, which can reduce the number of active nodes and lower compute costs for batch CI/CD and AI/ML workloads. Event retention is now configurable, letting customers shorten the default 1-hour window down to reduce etcd storage pressure on high-turn clusters, or lengthen it for extending debugging. The tradeoff being a narrow window for kubectl get events and describe pod history. The horizontal pod autoscaler sync period parameter requires ECS provision control plane and pairs the separate improvement increased HPA sync concurrency up to 40x the default Kubernetes value. I mean, I appreciate this, but also like, if this is your problem, maybe think about separating your blast radius.

[27:02] Justin: Yeah, I mean, this is exactly what I hate about Kubernetes and, and take, you know, the advantage of using something like EKS is taking a very Kubernetes-like experience, but also having it be sort of managed and maintained by someone else. And then you're gonna, the more they open up this like highly granular tuning, it's just gonna make things complicated and unpredictable when you get it wrong. So like, I don't know, like I get why they're doing this. I get that they're solving, you know, customer needs that are not able to migrate to Kubernetes. To EKS when they would want to, but this is everything I don't like about Kubernetes. It's precisely why I don't want to adopt it.

[27:41] Ryan: I mean, especially on Amazon, just use ECS.

[27:45] Matt: I feel like also if you're getting, if you want this level of granularity, you probably shouldn't be using the managed service at that point. Like, to me, I want to use a managed service because I don't want to think about this level of detail. I want the default Amazon recommendations for things. Yeah.

[28:05] Justin: I mean, from an Amazon point of view that they want as many people using their products as possible.

[28:09] Matt: Yeah.

[28:09] Ryan: They're gonna charge you more if you're using—

[28:10] Justin: So the defaults for EKS aren't gonna be insane. So it makes sense. This is just sort of advanced options.

[28:17] Ryan: I mean, they, they're not eliminating everything. I mean, they're giving you, they're just giving you some more knobs. So, right. You know, do some—

[28:23] Matt: I just don't want those knobs. I think that that's—

[28:25] Ryan: Then I, I would recommend you have a look at ECS.

[28:28] Matt: I love ECS. I run it at home. I run it where I can.

[28:33] Ryan: I run it everywhere. It's simpler. Uh, it's much better. But I mean, the people who—

[28:36] Matt: But do you run ECS?

[28:37] Ryan: Who run EKS are gonna want Kubernetes and they're gonna want all the knobs. 'Cause that's what people seem to like about Kubernetes, which is the part that I hate about it.

[28:45] Justin: And I imagine if you have, like, we don't have any use cases, we don't have any use cases like where we need to spin up like 1,000 containers at once or, or, you know, so other things like that, which might, require some of that. So it's, it's easy for us to say, cuz we're, you know, generally standing up like an internal API service or the Cloud Pod website or, you know, like different things like that. But yeah, I would say that that's what the majority of people are using too, as well.

[29:08] Ryan: This, this new Ryan who's like, I don't know, be devil's advocate. Screw that, Ryan. Oh, I still would.

[29:14] Justin: I still wouldn't do this.

[29:15] Matt: Don't worry.

[29:17] Justin: I would find some other, I'd find some other solution.

[29:20] Matt: At my prior day job, if we were building from scratch, net new Kubernetes would've probably been a good way, way to build it out. You get the isolation by namespace, you really can get the granularity there. Like it would make sense, but that's not where the company was at the time.

[29:40] Justin: Yeah. Yeah.

[29:43] Ryan: Uh, AWS is extending Bedrock agent core observability beyond native AWS runtime, enabling monitoring of AI agents running on-premise or on other clouds like GCP and Azure using AWS Distro for OpenTelemetry auto-instrumentation, so teams no longer need separate monitoring stacks for agents deployed outside AWS. The solution requires 3 components: a) auto-instrumentation for agent framework, IAM credentials for Sigv4 authentication, and specific OpenTelemetry environment variables to route telemetry to the CloudWatch OTLP endpoint, giving a unified observability dashboard regardless of where the agents run. AWS validated the approach on both on-premise setups and Google Cloud Shell, confirming identical telemetry output, including sessions, traces, span metrics, token usage, and latency, where the agent runs on Agent Core runtime or a competitor's cloud. This matters for multi-cloud and hybrid AI deployments where visibility into agent reasoning chains, tool invocations, and model outputs is needed to detect hallucinations, monitor for harmful outputs, and track token usage for cost governance across distributed environments.

[30:41] Justin: Yeah, I mean, I get it. I think this is, you know, the tricky part is still in that local configuration on all those distri— like workloads. And so like you I do like that there's an answer, but you're gonna have to configure each one of those agentic workloads with all three of these, you know, configurations to point it at the right place. And anything that I can't sort of put in place on for other people to adopt and it requires them to take an action, I sort of bristle at.

[31:08] Ryan: Well, I mean, other than the auto-instrumentation for Agent Framework, I mean, everything else is, isn't it at the agent runtime that you configure those like OTEL endpoints and Mm-hmm.

[31:20] Justin: But I mean, those are the, those aren't necessarily always centrally managed.

[31:25] Ryan: True.

[31:25] Justin: Especially if you're talking about the, the use case that they're talking about where it's running, running, you know, those agentic workloads in multiple clouds and stuff. I don't know if it's, you can't really put all that in one place necessarily.

[31:36] Matt: True.

[31:37] Justin: And so like, it's, I mean, this is great. We need more of this, but it's also sort of like, that's the big struggle right now with a lot of these things. Getting the visibility into it is, is it's requiring a lot of end user configuration and coordination across businesses. Which can be problematic and leave, you know, big gaps. So it's, I mean, I like it though, but I need the pattern.

[31:58] Ryan: Sounds different than anything else that we ever do in ops.

[32:01] Justin: Nothing. It's exactly the same thing.

[32:04] Matt: Thank you.

[32:05] Ryan: I was like, ah, sounds like what I do every day.

[32:08] Justin: Yeah.

[32:09] Matt: Yeah.

[32:10] Justin: I just want more solutions. I want something that's like centrally configurable. Like this is why I keep running back to like you know, enterprise offerings for agentic workloads so that you have that sort of central configuration. You can offer the service to the rest of the business rather than sort of letting them all develop their own agent frameworks wherever they're running.

[32:29] Ryan: Oh yeah, it'd be nice if they just gave you like a managed agent runtime that you can deploy in any cloud that has, you know, talks back to the mothership and I don't have to do anything other than set the SCP for it and then it could work.

[32:41] Matt: Yeah.

[32:42] Justin: I mean, and they do have that, right? That's built, that's built into, to Bedrock. And so like, it's interesting to me that they have this like agent core, which is more of like the framework of running, running these agents on Bedrock. It's sort of an interesting way of doing it where it's like you don't have to run it on Bedrock. It's just sort of the, you know, agent SDK sort of configuration of the app layer. But, so it's interesting.

[33:06] Ryan: Yeah. AWS is bringing Amazon's Qwik agentic AI directly into Word, Excel, PowerPoint, and Outlook, letting users interact with connected enterprise data, uh, without leaving Microsoft 365 apps. Extensions are agentic rather than simple chatbots, meaning the AI can directly edit documents, insert sections, generate charts from live data, and draft emails with full thread context when tracking all changes by an audit trail with visual comparisons. Deployments require no client-side installation since everything runs in the cloud. IT admins can push extensions through the Microsoft 365 Admin Center, and no additional licensing is needed for Quick customers on Plus, Professional, or Enterprise plans. I mean, that's nice that Uh, it's not something like Claude you can just install and then when you go to authenticate, it breaks. So at least this apparently doesn't install until you, uh, enable it in the marketplace first, which is slightly better, but still.

[33:52] Justin: Oh, I bet you they can still install it.

[33:53] Ryan: I'm, yeah, it's probably not a full—

[33:55] Justin: this is, you can probably, uh, deploy those Claude plugins with, uh, the admin center too. It's just that we're again, require multiple parts of the business to coordinate with each other. That goes so well.

[34:05] Matt: That's it.

[34:06] Ryan: IT would have to be willing to do it. And then, you know, they're already mad that I bought Claude and then, you know, all those things. And so, yeah, I'm just never going to get what I actually would like out of this.

[34:17] Justin: They need to review all the, you know, integration points. And so like, it just says, you know, it's not secure.

[34:23] Ryan: And now, now more people in security woke up and were like, wait, you're doing what on my laptop? Like, it's just, it's a, it's a lot.

[34:29] Justin: Yeah, absolutely.

[34:33] Ryan: Well, unfortunately, uh, Jonathan's not here for us to play taps for him. The AWS Certificate Management will finally discontinue email validation to prove domain validation for certificates. Finally killing a piece of code that Jonathan wrote almost 12 years ago that would automatically click in the email, accept. ACM, it will discontinue email validation for published certificates by September 30th next year. 2027, requiring migration to DNS validation ahead of the CA/B Forum's industry-wide March 15th, 2028 deadline. The key milestone: NOMA email validation in Rio region starting January 1st, 2027, with no new email-validated certificate requests after March 31st, 2027, and no renewals of email-validated certs after September 30th, 2027. Wah wah.

[35:21] Justin: This is the longest-coming, like, decommissioning. I feel like we talked about this like a year ago and it felt And now it still feels a year out.

[35:29] Matt: Well, it's all the SSL stuff that's happened over the last couple years of, you know, shortening. And you know, there's gonna be a crisis at one point.

[35:37] Ryan: We knew the CAB forum thing was coming. So like that, that's step one, right? It was coming. All the cloud providers negotiated with CAB to push it out a little longer to give them more time. And then Amazon's gotta look at it.

[35:49] Justin: Oh, did they? I didn't know that. I thought it was still coming in like a couple months. Okay.

[35:53] Ryan: I mean, it's still coming for new certs, but at least for renewals and things, because like there was some talk of invalidate certs, uh, prematurely, which would have been really bad for people. So, you know, I imagine it's just a matter of they had to work through it. And there was something else they released recently for DNS ACM validation to simplify something. And I think maybe that was one of the prereqs that Amazon had to kind of kill this. But, uh, yeah. Sad to see this one go just because I know how long that code has run that Jonathan wrote.

[36:24] Matt: Yeah.

[36:24] Ryan: Even though it was a terrible model and we hated it.

[36:26] Justin: Yeah, no, it was, it was, uh, completely in self-defense, right? Like it was just how to scale with a business that was pointed at a single inbox of a single engineer. Like that's not going to work out.

[36:38] Ryan: But hey, it was better than a ticket to request a cert. So I'll take it.

[36:41] Justin: Oh no. The security guy hates this, but the, the engineer who was on the other end of that service, like I love this.

[36:47] Ryan: Like, I still love it.

[36:48] Justin: Like, I would take the compromise any day. It did some sanity checking. It wasn't like it would approve anything, but it was, you know, the, the fact that it was just kind of arbitrarily, like, from a domain clicking, clicking accept was, is pretty funny. And we laughed at the time when we knew it was a bad idea. Oh yeah. But what else are you gonna do?

[37:07] Ryan: I mean, that was probably one of the heavily adopted cloud platform services we had.

[37:11] Matt: Yep.

[37:12] Ryan: Yep.

[37:13] Matt: I mean, I feel like ACM had to be one of the quickest adopted services.

[37:18] Justin: Oh, for sure.

[37:18] Ryan: Well, I mean, it had the advantage of not costing $400 like a DigiCert did, so it was definitely a cost savings for anybody who adopted it quickly.

[37:27] Justin: Yeah. And then it was $400 and a guaranteed outage when you have to remember to rotate it manually, right?

[37:32] Matt: So you have to deal with it. It was everywhere. It was simple. It was easy. Granted, the email at first was the pain in the butt, but it wasn't that long. Maybe it was like 6 months to a year after. They added the DNS and I don't know anyone, there's very few people I know that still manage certificates on AWS right now.

[37:51] Justin: There's like specific use cases, but yeah, like when you have to, like you need the private side of the cert for something like some sort of other application.

[37:58] Matt: You can export it now. You can do that. Can you export it? Export ECS. Yeah. Like a year ago.

[38:01] Justin: It just doesn't, it just doesn't auto-rotate once you do that, presumably.

[38:05] Matt: It does. It puts it in Secret Manager and you can link it up to EventBridge to then Rotate it on your EC2 instance if you want to. Definitely haven't ever done that before.

[38:16] Justin: Oh, but that's fine. Right? Redis secret. It's a runtime secret. I get it. That doesn't even sound bad.

[38:22] Ryan: Yeah, no, it's good.

[38:23] Justin: I mean, it's not great to write it to disk, but I get it.

[38:26] Ryan: Well, I mean, you shouldn't write it to disk. You should pull it at runtime from Secrets Manager.

[38:30] Justin: Mm-hmm.

[38:31] Matt: Yeah. But you load it into nginx and nginx has to have it somewhere. Well, this is nginx's dumb, but yeah, there was an SSM, um, document somewhere in the middle and it ran it that way. But yeah, I mean, it's, you know, the Java, Java KeyStore, like there's always something, there's always something. Yeah. But like you can export it.

[38:51] Ryan: At least the funding is there to do it well if you wish to do it well. But you can also do it badly if you decide to do so, which is why security exists. Uh, to make sure they don't boot that way.

[39:03] Justin: Yeah, only I may implement the bad insecure solutions.

[39:08] Ryan: AWS is adding 5 preconfigured read-only dashboards to Billing and Cost Management covering Cost Overview and Trends, Compute, Database, Reservations, and Savings Plans with data automatically populated for existing accounts. Cost Overview and Trends dashboard provides 12 months of historical spending data broken down by service, account, and region, plus forecasting for future costs. I mean, thank you, but how about you make it so I can just share those dashboards between accounts and then I can, right?

[39:33] Justin: I would just, you might be able to now because they, they did make this multi-account quite a while ago. So I don't know if these managed dashboards are, can take that input, but.

[39:43] Ryan: Hey, but like, I, I just know that I've created custom dashboards in the past in AWS for these things. And then I'm like, oh, I have to put that in the, in the other account. And it's like, oh, nope, sorry, recreate the dashboard.

[39:54] Justin: Yeah, they're like, yeah, can you do that in QuickSight? You're like, no, no, I cannot.

[39:57] Ryan: Well, I will, and I refuse to.

[40:00] Matt: Yeah. And then dashboards were always complicated. Like you couldn't do them easily in Terraform because it was a JSON blob.

[40:06] Ryan: Yeah, I was gonna say, you can't write them in Terraform either, which would be the other way to solve that problem. Yeah, and you can, it's just not pretty.

[40:12] Justin: Yeah.

[40:12] Ryan: I mean, I made Claude do it 'cause I was so hard, so I was like, I'm not doing this myself.

[40:17] Matt: I did it before Claude existed.

[40:19] Justin: I would go do it in my dev account and then export it.

[40:22] Ryan: Plus the thing is, it's not easy to export and import them. Or if you have like little minor changes, you have to like reimport the whole thing. Like it was a pain.

[40:29] Justin: Yeah.

[40:29] Matt: Yeah.

[40:30] Justin: Wasn't exactly. The thing that I hope this gives, uh, is I remember the first time my account team at Amazon gave me like the full analysis of my account and the cost savings and all the RIs, and it was a very rich, detailed bunch of dashboards and spreadsheets. And I was, I always, always. Like, why don't you guys just put this directly into the product? Right?

[40:50] Ryan: Like, why do I, why is it this, like, why is this, why is this kind of specific support that I have to pay extra for? And it's part of the QBR when you could have just given this to me in the dashboard. Yeah. No, I know that was annoying.

[41:00] Justin: So I'm hoping that some of that functionality that you would get from that is built into these two.

[41:05] Ryan: So, because it's annoying enough. EC2 Auto Scaling now allows batch termination up to 100 instances in a single Terminate Instance in Auto Scaling Group API call. Cutting down the number of calls needed to scale down groups, or increasing the frequency of outages. Targeting workloads with rapid scale down needs, including AIML training jobs, container orchestrators, and event-driven architectures to spin up temporary fleets. All instances in a batch are validated atomically before termination starts, and existing behaviors like lifecycle hooks and Load Balancer active draining still apply, for instance. Okay, that's nice. Available in all AWS regions at no additional cost.

[41:38] Justin: See, I like this just because I've had to terminate large fleets, and then when you have to wait for it to sort of like like roll through, you know, before you have to like loop the command line for it. Or redeploy the auto scaling group so that you can change like the, you know, the number of instances that can be down, you know, higher. Like that's always such a pain. So this makes that a lot easier.

[42:01] Matt: I like it. I was gonna say, I've just seen it had to people loop through the EC2 instances in the auto scaling group for like their app does something funky as part of a deployment, thus They know they can't do blue-green 'cause it's too complicated with the app for some reason, but they essentially spin it up and then go in and terminate all the instances, you know, and force it to essentially do a terrible blue-green type deployment with an outage in the middle.

[42:26] Ryan: I mean, you just described it as like, the app is too complicated to do blue-green, but you're gonna do this terrible Rube Goldberg machine instead? Like, this is horrible. Oh my gosh.

[42:34] Matt: And that's what people did.

[42:36] Justin: Yeah. You see it for like applications that need to read like a fixed data schema and then you do an update and they're like, well, can't really do blue-green because it's all going to touch this database, which isn't part of this deployment. So let's just do this horrible thing. We'll just make the cloud team figure it out.

[42:50] Matt: Yeah, yeah, that's where I've been.

[42:52] Ryan: Yeah, I mean, I've seen it. I don't like it.

[42:54] Justin: Yeah, I know, it's awful.

[42:56] Matt: Yeah, I will say the database blue-green service I've played around with a couple months ago, it's actually pretty impressive. I don't know if you guys have actually used that one.

[43:04] Justin: No, I mean, I want other teams to use it. I try to not use databases wherever possible.

[43:11] Ryan: I mean, I've been, I've had to recently use DMS and that's come a long way too. So like, that's a lot of DMS has come a long way, really improved themselves.

[43:19] Matt: Yeah. But the blue-green, like gives you zero downtime schema updates and stuff like that. It's pretty impressive.

[43:24] Justin: That's really awesome. More, more of that, please.

[43:27] Matt: I mean, it spins up a whole new instance and stuff like that behind the scenes. And then it's a choreographed dance that's happening. But it's pretty impressive how it works, and it's good for like database version upgrades and things like that.

[43:41] Justin: Yeah, that sounds awesome.

[43:43] Ryan: Amazon is expanding its Builder Loft program, which is mostly shocking to me because I thought the Builder Loft program was dead, but apparently it's not. New permanent locations will open in Berlin, Hyderabad, and São Paulo, following the first location in San Francisco, which opened in July of 2025 and has apparently hosted over 22,500 developers. I am not one of them because I Didn't realize they reopened this after the pandemic. I thought it— These are free permanent community spaces offering workshops, hackathons, pitch nights, and coworking areas for developers, students, and tech professionals distinct from AWS's early temporary pop-up lofts and GenAI lofts. City selection ties to regional strategy, but the Berlin will focus on digital sovereignty content following the AWS European Sovereign Cloud launch. Hyderabad targets AI and cloud-native upscaling, and São Paulo addresses Brazil's cloud market, which AWS cites is growing 30% annually. This is a programming event that was community-driven, which local user groups and meetup organizations able to book space at no cost while AWS provides the physical infrastructure and supports that. And Ryan, I'll see you at the loft in 2 weeks. We'll head back.

[44:42] Justin: Traveling. Nice. Yeah, no, that's cool. I'm trying to figure out now, now I, I thought it was these developer lofts that I went to, but now I'm not sure if it was one of those pop-up lofts.

[44:52] Matt: So like, yeah, I mean, I did the pop-up loft way back in the day.

[44:56] Justin: Yeah.

[44:57] Ryan: Right. But I mean, they were, they were not very temporary. They were, they were in those—

[45:00] Matt: Yeah, they were like, um, like a couple years at a time.

[45:03] Ryan: I mean, I went to, I, I mean, this, the address on this one is Market Street, which might be where the original pop-up loft was. I might have been to that one 'cause I was on Market Street as well. I went to a couple meetups there and there was like a hackathon night I went to there. But yeah, it's been a while and, uh, I definitely have not been since well before pandemic. Yeah. So I'm sort of intrigued to go check it out. And so yeah, I could do a day working from that off that loft. I'm down. Totally.

[45:25] Justin: Yeah, I'm down.

[45:26] Ryan: There was one in New Jersey, uh, or New York. I've sent Matt there, but I don't know if there is one cuz that would require research and I didn't do research.

[45:34] Justin: Yeah. I don't know if I wanna fly to New Jersey to go work out of a pod.

[45:37] Ryan: Oh no, I'm not gonna go with him.

[45:38] Justin: I'm just, oh, you're just gonna make him go.

[45:40] Ryan: He's just sending me there.

[45:41] Matt: Yeah.

[45:41] Ryan: Did you, did you figure that out for the way he worded that? Sorry, it didn't sink in that, uh, he would just, he would just go by himself and then he'd, he'd FaceTime us from the loft, right?

[45:51] Justin: It's like the, the Cloud Pod. Return to office policy, you have to go work in an office by yourself. Nice. Great.

[45:57] Ryan: I mean, the last thing I see is it was the one in Broadway was closed in earlier this year, so I don't think there's one in New York. So sorry, sorry Matt, we can't, we can't do that.

[46:07] Matt: Damn, I don't have to go work from, do a podcast from a loft. What could possibly go wrong with that?

[46:12] Ryan: We just go hang out there and other people and, you know, do, do cool Amazon-y things, I guess. I don't know. Don't have a beer dispenser. That's all that matters. All right. AWS is rolling out a redesigned sign-in page with a unified email entry point, replacing the current root user versus IAM user selection step. The system automatically detects the correct sign-in flow based on the email entered, which they also provide screenshots of this new experience in the thing. And we're making Ryan go for the first time to go look at it. So for his live reaction, but, uh, Ryan, let us know how, what you think. All right.

[46:44] Justin: Yeah. We started going through this in the pre-read and they're like, wait, wait, wait, you haven't seen it yet. Go through this. And so it's, yeah. Okay. So IAM username redesigned shows the current one. Yeah. I don't know what's in there. Oh, look, it just looks like trash. It just looks like everyone else's, like every other company. It looks like good. There's no graphics. It's just like almost. It's almost just black and white text on nothing. Like, wow.

[47:16] Matt: What's the rainbow gradient in the background too? Like, it's not like Amazon things that I would've expected.

[47:23] Justin: It's not their colors or anything. It's just some random blue and lime green.

[47:28] Ryan: How did, okay, so, you know, the account ID and alias method and an IAM username, like that is how I've logged into forever. And this new login form, Does like, it has email address as the default. So now I don't have an email address for my IAM user. So now I had to go hit this IAM user button down on the right, the bottom right, if you see it there, to get to the normal login page. Now, instead of it being one page, I now have to go two clicks, which is annoying to me.

[47:54] Matt: Which also means you're going to get more and more people to not use IAM users and use the root account for things. Like, I feel like we're going in the wrong direction.

[48:03] Ryan: That's actually a good point. I hadn't thought of that. Yes, it'll, it'll force people to use email, their root emails more often. You are 100% correct.

[48:11] Justin: I wonder if there's like some sort of session management at the browser level where that, you know, like maybe the first time you have to do 2 clicks, but then, 'cause I'm looking at the other screens where they show the, the current active sessions. And so being able to see all of your different Amazon accounts that you have a session for in a screen, which is, which is nice. I mean, it's ugly, but it's nice.

[48:31] Ryan: I mean, that, that would be nice for, you know, it tell you if they expire or log out, which I mean, it has a Pluses and minuses. The other thing that they also are encouraging here, which I also hate, is that the— use your amazon.com login, which if you've ever, uh, had a startup or you created, you know, you used your Amazon personal Amazon account to create the corporate AWS, that's a bad day.

[48:52] Justin: What does Corey Quinn call it? The underwear account. Like, that's my— that was always my favorite, my favorite thing. You need your underwear account to sign into your corporate account.

[49:00] Matt: Yeah, I thought they depre— like They finally made me change my password for it because it's no longer my default, like my personal account.

[49:07] Ryan: Well, they originally used to have the same cookie domain. So if you were auto logged into your underwear account, you would automatically log into your Amazon console account. And that was super annoying. I complained publicly to Barb about that and they actually fixed that shortly after that. So my one claim to fame. But yeah, it's, it's kind of like, again, I don't understand that. Then also, I don't know if I want to use my Apple ID to sign into, out to AWS either. That's a weird choice.

[49:29] Justin: So, I mean, it's strange, but it's just a federated identity.

[49:32] Ryan: Yeah, it's just a federated identity.

[49:33] Justin: I don't care.

[49:34] Ryan: Same thing with the Amazon one. It is a federated identity at that point, but yeah. Yeah, I don't, I, I'm sure there's going to be some growing pains on this new login page. So be prepared.

[49:42] Matt: So one, I went to go test it right now. It's a different color schema background, like, than the screenshot. Then two, I just tried and I put my email and it goes, you have a root account. And as a builder ID, 'cause I have a builder account. And it asks you which one, but it's still like IAM root user. It's still like sending you the root account. Like, it should be like, I feel like you should be sending people away from the root account. It should be like, hey, in order to get in with the root account, you have to press these 16 buttons in just the right order to open the trapdoor to get your root account.

[50:16] Ryan: Yeah, it's sort of weird 'cause I, I put my email address in for one, you know, one of my accounts that I know is a single sign-on account. And yeah, 'cause the continuous AWS builder ID or continue with IAM root user, but it didn't even give me the option like, oh, this is recognized to a Google SSO account.

[50:31] Justin: Yeah.

[50:32] Matt: And if you press IAM, it's just back to the old way. Like, they feel like they need to like do this and maybe they're still building out, but it should be all in one. Like, I shouldn't be on the new one just to press IAM, then go to the old IAM Lambda.

[50:45] Ryan: Well, that's 'cause they, they don't actually know how to do a user interface for that. So they're like, we really want everyone to start using email addresses, but we fully screwed this up and we've already got a bajillion people doing the other thing.

[50:56] Justin: I don't know.

[50:57] Ryan: Yeah, it's a weird—

[50:57] Matt: that's why I always told people to use their, you know, back before, you know, SSO was really a thing into AWS, I always told people to use their email addresses as usernames inside of AWS, because at least you were able to tie it.

[51:11] Ryan: So actually, this doesn't work for me at all.

[51:15] Matt: It breaks more things.

[51:17] Ryan: So it told me, so I was logged into my personal Amazon account. And so when I chose Google, it just defaulted to my default Google account, which happened to match the Amazon account. So then it was like, well, you don't have this. I'm like, okay, fine, log out. And then I put my, my work email address in and I said, use my Google authenticator, you know, Google account. And it's like, oh no, I can't find that. Cause I actually, technically that's an SSO login, which comes through a different portal, which isn't tied into this. Like, this is, this is a disaster. Train wreck in real time.

[51:45] Matt: We at The Cloud Pod really like this too. Thank you.

[51:49] Ryan: This is a quality implementation if I've ever seen one of a new UI form. So well done, Amazon.

[51:56] Justin: Yeah. I mean, at The Cloud Pod, we have a long history of being super positive for any of the AI improve or UI improvements that Amazon's made over the years. This is yet another that has thrilled us to exactly what we'd expect, which is it's awful.

[52:11] Ryan: Well, that's, uh, that's I look forward to seeing that go worse.

[52:15] Justin: Mm-hmm.

[52:17] Ryan: Cloud Shell now includes a built-in visual editor for all those new people who don't know how to use Vim. It's launched by a simple edit command, removing the need for Vim, Emacs, or local file downloads to make quick changes. I mean, I prefer forcing people to use Vim and Emacs all the time, but whatever. The editor supports standard GUI features like syntax highlighting, find and replace, multi-line selection, and undo redo, addressing a longstanding friction point for users editing scripts, Lambda functions, or CloudFormation templates directly. In the browser. And I say this makes, makes you a man out of you. So just learn those Vim commands.

[52:47] Justin: I agree.

[52:49] Matt: My problem is it's some of the, some of the older like random OSs you would do like vi sudo and pulls up nano by default. It was like Ubuntu did that for a little while. I think it was Ubuntu. One, one distro used to, used to drive me crazy. Like it was vi sudo and it would pull up nano. You would have to like change your sudoer to make sure. That it was your vi sudo that used nano or there was, or used vim. It was, it always drove me crazy. Or maybe it was for vi.

[53:14] Ryan: I guess I don't ever run vi sudo. I always just sudo vi. Maybe I'm, maybe I'm the problem.

[53:20] Matt: Well, no, that's if you're editing your sudoers file.

[53:23] Ryan: Oh yes. The sudoers file.

[53:25] Justin: Yes.

[53:25] Matt: Sorry.

[53:25] Ryan: That's, yeah. Yeah. Uh, that's, that is weird. Maybe I don't, I don't do that very often though, so I guess I'd never noticed it or I just annoyed about it and moved on with my life. I don't know.

[53:35] Matt: My problem is I just, my muscle memory just goes colon wq. Yeah. And then you just see colon wq in your editor. You're like, wait, no.

[53:44] Ryan: I had an outage once a long time ago at a company and like the service wouldn't start and they're like, what is, what's happening? And I, you know, finally go look at the file and I'm like, oh yeah, someone edited this in Nano and put wq bang at the end of it.

[53:57] Matt: Not even mad about it.

[53:59] Ryan: I know, I wasn't mad at all. I was like, well, I would have, I, I could have made this mistake.

[54:06] Justin: So I definitely still do that.

[54:11] Ryan: All right. We all do it, Ryan. Amazon Bedrock Agent Core Payments is now generally available, letting your AI agent autonomously pay for APIs, MCPs, and web content using stablecoin wallets for Coinbase and Stripe Privy with credentials secured by Agent Core Identity Secrets Manager rather than exposed to the agent itself. And what could possibly go wrong?

[54:32] Justin: Yeah, I still, yeah, I wanna run it in the sandbox and I'm apprehensively getting over my approving every single action thing. I'm definitely not letting it anywhere near my money.

[54:46] Ryan: Right. Well, I love that the fact that like, it's not real money, it's just stablecoin money.

[54:51] Justin: Right, right, right. Yeah.

[54:52] Ryan: Let's not get crazy talk. Like if you lose your fake money, you can't be that mad. That's what they, this is sort of like if it was your real money in your bank account, like a whole different set of regulations are involved because it's, it's this unregulated wild, wild west of Bitcoin stablecoins. We can do terrible things that no one should care about when we lose your money for you.

[55:11] Justin: Right.

[55:12] Ryan: That's, that's the route it feels like. If, if you were really serious about this, you would let me use my bank account in dollars, but you don't.

[55:18] Justin: So, but the banks won't let you if they're, they're like, nope.

[55:20] Ryan: The banks are dumb. Uh, and then finally, IAM Policy Autopilot now accepts Terraform plan files as input, extending its scope beyond application source code to infrastructure deployment permissions, generating CRUD-scoped policies for the resources defined in a plan. This is reportedly the most requested feature since the tool launch at re:Invent 2025, addressing a gap where teams could scope application-level IAM permissions but had no equivalent tooling for deploy-time permissions Terraform itself needs. Generated policies reference specific resource ARNs rather than wildcards where possible. Which helps teams move away from overly permissive deployment rules that grant broad access across certain resource types. The tool complements existing Terraform-aware analysis that cross-references resource structures like SDK calls and application code, so teams can generate both runtime and deployment IAM policies from the same tool. IAM Policy Operator is open source, free to use, and runs locally rather than as a managed service, available at Natavis Labs GitHub repo for teams to integrate into their CI/CD or local workflows, assuming GitHub is up when you go to look for it.

[56:21] Justin: And now not only is it a CLI, but it's an MCP server.

[56:25] Ryan: Oh, good. Oh, good.

[56:27] Matt: What could possibly go wrong?

[56:28] Ryan: Wait, why would I was curious, like, wouldn't, why does it have to be a Terraform plan file? Why not just my Terraform file? What's, what's the secret sauce that I'm missing there, guys?

[56:38] Justin: Oh, module lookup. Data lookups of, of your actual, of your actual state in real life. Yeah.

[56:44] Ryan: Yeah, that's right.

[56:45] Justin: Okay.

[56:45] Ryan: I would, but I would think if you're doing a brand new infrastructure, you You maybe wouldn't have those lookups anyways. I mean, maybe you would.

[56:53] Justin: I mean, well, so think about the, where you want to define your IAM policy, where you want to say, oh, access to only the specific resource name or resource name asterisk, like that kind of thing. So like this way you couldn't do that for anything that the, the AWS provider was going to dynamically generate as it runs. This way you could, based off of the plan, it would, all the data lookups and stuff would happen. Be before they apply, so not everything, but you'd at least have that ability.

[57:20] Matt: I mean, I think that it would be nice if they eventually can look at your thing and give you a more permissive policy.

[57:27] Justin: Right.

[57:28] Matt: Like if it is doing a data lookup, like, you know, data star on, you know, list secrets to start with, you know, /prod/secret name, whatever garbage it is, you know, but I get, I like that this is a good starting great point. And because I've definitely dealt with, uh, Ryan, who was paying my butt back in the day, that made me have exact permissions for stuff. And I was the dummy that actually followed the rules versus everyone else that, yeah, a lot more wild cards than I did.

[57:56] Ryan: Ryan believes in nothing but least privilege.

[57:58] Justin: That's true. So yeah, yeah, if you're working on a project for Ryan, just know you're, you're gonna have to take a couple passes at it for sure, the IAM policy, because it's It's not like I'm not like a no asterisk guy, but it's like, it's also like, I can, if you're just gonna do like admin policies for all the services, like that's not cool, man.

[58:15] Ryan: Like, yeah.

[58:17] Justin: And do you really, do you really need your service account to have full deployment permissions of your resources?

[58:21] Matt: Yes.

[58:21] Justin: No, it's the service account that's running the app. Deploy it to something else.

[58:25] Ryan: I mean, if you wanna have a lot of fun with Ryan though, just try to have him explain to you why pass role star is bad. Oh, CI/CD pipeline. It's so bad. But like, so he'll, you know, let him rant about it and then say like, okay, so how do I do all of these scenarios without having a pass role star? And then watch his head implode as he tries to like work through the connotations of how you have to build the IAM permissions for it. 'Cause it is terrible.

[58:48] Matt: Yeah. Yeah.

[58:48] Justin: Well, yeah. I mean, it's just, it sucks. Like having a deployment user, it's almost impossible not to have IAM pass role configured for that deployment user. And so whatever your runtime is, make that the least privileged thing. 'Cause that's the thing that's most likely going to, bite you later if there's any kind of issues in your production app. Do you really need your production app to be running as a service account that gives a role to another service account? I hope not, but sometimes maybe, I don't know. I can't think of a valid use case.

[59:18] Matt: Just a secure query.

[59:18] Justin: Yeah, no, someone will do it just to piss me off. It's true.

[59:21] Ryan: This is why we don't let Ryan involve in the source code editing for the Terraform for The Cloud Pod, because Azure will start as it Just 'cause I'm too lazy for the Helm project and—

[59:33] Matt: Wait till he looks at Vault.

[59:34] Ryan: He hasn't rewrote it. So, you know, tell Ryan, rewrites it and gives me a pull request. I'm not fixing it.

[59:38] Justin: Well, now there's this Autopilot and MCP server, so I'll just—

[59:41] Ryan: Yeah, no, no, no, no.

[59:42] Justin: I'll just tell AI to do it.

[59:43] Ryan: Yeah, sure. Okay. Good luck. 2029. AI won't even know that that feature exists for at least 6 months. So you're gonna have to like tell it it exists first and give it all the documentation.

[59:56] Matt: Who knows?

[59:56] Justin: Oh, I've been threatening to make these changes for what, like 6 years? We can wait.

[60:00] Ryan: Yeah, yeah. All right, let's move on to, you know, at work, highly secure.

[60:06] Justin: No, yeah, at home, not so much. Not so much.

[60:09] Matt: Don't look at my home stuff.

[60:10] Ryan: Yeah, yeah, no question.

[60:11] Justin: For sure.

[60:13] Ryan: GCP, uh, Google has released Gemini 3.7 Flash just 3 weeks after 3.6 Flash, showing measurable gains in coding tasks with Frontier Code scores improving. From 34.4 to 43.6 and Deep-SWE from 49.0 to 65.3. If I knew either of those were, I would be impressed. The model outperforms 3.6 Flash on WebDev Arena and shows notable improvement in document processing accuracy on GPT-PDF benchmark. Pricing is set at the introductory rate through year end of $0.75 per 1 million input tokens and $3.75 per 1 million output tokens, roughly half the cost of 3.6 Flash, which they just announced 3 weeks ago. So go figure. Making it more accessible for production agent deployments. The model powers Gemini Spark, Google's personal AI agent, available to AI Pro and Ultra subscribers in over 160 countries.

[60:58] Justin: Well, the only good thing is if it's only going to be out there for 3 weeks, you don't really have to worry too much about migrating off of 3.6, so that's good.

[61:05] Ryan: Yeah, I mean, you didn't have time to test it, validate it, and get it through your CI/CD pipeline most likely. Uh, yeah, that's good.

[61:12] Justin: Just, yeah, it'll be a quick Punt over to 3.7. How different can it be? Hopefully it's faster.

[61:17] Ryan: I mean, if 3.8 comes out in 2 more weeks from now, then people are gonna start rioting. So I hope this isn't their new, like, hey, this is our continuous deployment model for Google models. Like, fuck you.

[61:27] Justin: Start doing like fuzzy version, you know?

[61:29] Ryan: Yeah.

[61:30] Justin: Matching. So it's like, eh, anything under 4 is fine.

[61:34] Matt: That's what I do with the Terraform provider for AWS.

[61:37] Justin: Yeah.

[61:38] Ryan: Yeah. Moving on to Azure. Azure Front Door now supports mutual TLS in public preview, letting the service authenticate clients using X.509 certificates at the edge before requests reach the origin application, useful for B2B, IoT, financial services, and enterprise scenarios requiring client-level verification. Four validation modes give customers flexibility: require and validate, require without validation, validate when presented, and pass-through to origin. So teams can decide whether Front Door or the origin server handles certificate tracking. My recommendation is pass to origin and don't make Azure Front Door do this because as Matt will tell you, it takes, you know, potentially up to 4 to 7 days to update your Azure Front Door depending on the current outage situation of the process.

[62:18] Justin: Wow. Uh, yikes.

[62:22] Matt: I wonder if it's faster if you're on premium because they could charge you more to get it to update faster than if you're on standard.

[62:29] Justin: Hmm.

[62:29] Ryan: Maybe.

[62:31] Matt: Maybe that's going to be their new way. It's not that it's more secure, 'cause really premium's just more secure 'cause you can lock it down to like a, you know, blob storage account directly versus, you know, having to have the storage account be public. But I wonder if they'll make it so it updates faster and, you know, is less likely to break it out.

[62:49] Justin: It's one of those features that makes no sense. There better be some sort of technical reason on the backend and not just some terrible like product team's way to try to boost revenue for that, 'cause it drives me nuts.

[63:02] Matt: It's charging for basic security features, something like that really upsets me.

[63:08] Justin: Mm-hmm.

[63:09] Ryan: Yeah, don't get me started on HashiCorp and SSO. And then, and then, so, Tex, general availability of batch rule updates for Azure Front Door for standard and premium users. You can now batch rule updates as a general available feature, letting customers add, update, delete, or reorder multiple rules in a rule set as a single atomic operation, which based on the prior comment about how long it takes to update these Azure Front Doors, that's a blessing.

[63:32] Matt: I mean, I just still wonder, you know, what was it, about a year ago now they had their massive outage. I feel like over the last, like, couple months they've just started dropping more and more features. So it's almost like they had this massive delay on getting things out because they were stabilizing, updating, fixing, and now they're just churning through the backlog of all these features that they're just trying to roll out more and more and more now.

[63:56] Justin: Yeah, maybe they're practicing, you know, site reliability, but the engineering where they, you know, they didn't have the, you know, the capital, you know, so they had to pay down their tech debt and get their SLOs up before they could release new features. Now they have.

[64:12] Matt: No, I think they just broke it so badly that they had to fix it to be stable to actually be able to release to it.

[64:18] Justin: Yeah, I mean, that's way more likely.

[64:22] Ryan: Uh, Microsoft is merging its consumer and commercial Copilot apps into a single Microsoft Copilot app, a precursor to a broader super app expected by end of September that will combine chat, coding, co-work, and Autopilot agents. Uh, Windows Insiders will get it this week, a broader mobile and web work worldwide in mid-August, and Windows and Mac apps in mid-September. The commercial changes are largely cosmetic, including the name change and new URL. Good. Can't wait for that. Several consumer features are being retired on August 18th, including Code Violet Podcast, which first I've heard of it.

[64:53] Justin: Didn't know that. Yeah, no wonder they're killing that.

[64:56] Matt: Yeah.

[64:56] Ryan: Group Chat and Deep Research. Deep Research replacement Researcher will only be available to Microsoft 365 Premium subscribers, not Personal or Family tiers. Microsoft states work and personal accounts remain logically separated within the unified app with no data crossover and unchanged enterprise security and compliance. Yeah, I trust you on that one, Microsoft. Sure.

[65:13] Matt: They have such a good security background. What are you talking about?

[65:17] Ryan: Yeah.

[65:18] Justin: I mean, I've always hated how Microsoft has handled this Copilot naming and everything, and I was trying to help out my wife who was trying to figure out how to get Copilot working for her work app, and I was using our personal M365 tenant and thinking I was talking the same thing, 'cause they're all named the same thing and you don't know. And I just, you know, ended up like working with telling her to give bad instructions and that she was giving to her IT team and the whole thing is awful. And so I'm hoping that they fix some of that and just make it sort of make sense. 'Cause right now it doesn't.

[65:51] Ryan: I mean, I, it does not, Microsoft doesn't make anything make sense. So like, it'll, we'll see how this goes. But like, I know like at the day job, if you go to copilot.microsoft.com, it's blocked 'cause that's a per, it's considered the personal. So and they don't want data to get leaked, but now it's the same URL for personal and for corporate, then like now there's a problem because how do I prevent a personal Microsoft login from logging into the copilot.microsoft login versus the enterprise account, which is allowed to do it on the corporate laptop? Like there's some, like there's some things they're about to mess up that I can already foresee.

[66:24] Justin: Yeah, they better have that control on in the enterprise app where you can sort of lock that down, right? And they probably do. I know it's something that you can do in Outlook. Which is you can disable the ability for people to add their personal email addresses. So it's probably something they'll do.

[66:38] Ryan: Uh, well, if you, if you also, if you use the Copilot recall feature to spy on all your users, uh, apparently you will have to reapply that manually because that won't get, that won't get migrated over. So just be aware of that.

[66:50] Matt: Does like the Chrome Enterprise or Internet Explorer, whatever it's called, Enterprise, do, does that, can that control like what log, like what user account you log in with?

[67:02] Justin: Uh, I don't think so.

[67:04] Ryan: I think it, you know, you can do browser extensions that get some of that link, but so I mean, you could, you can force, you could force your login to the site through Edge, but again, the problem is using the same URL, you can't just URL filter on it. And so the problem is if I can get to that login and I can log in with any Microsoft account, my personal or my work, it violates the security control. Well, that's what I was trying to figure out if they were trying to push people to use the enterprise browsers, because I don't see how that fixes it because enterprise browser doesn't prevent you from using your, any email address to log into a Microsoft product.

[67:40] Justin: Not the browser by itself, but other technology stacks would allow that.

[67:45] Ryan: I mean, like, uh, yeah, that, so again, I wouldn't be surprised if some of that doesn't change, like, because it's going to cause some problems for people. But we'll see, maybe, maybe I'm wrong on that one. And finally, Azure Container Apps Sandboxes in preview provides hardware-isolated microVMs for running untrusted AI agent code, addressing the trade-off between giving agents useful permissions and limiting security exposure. Sandboxes will start in seconds, scale to thousands, and incur no compute charges while stopped. Key controls include egress allow listing to restricted network access, managed identities for secretless Azure authentication, and snapshots that capture a configured environment for reuse. Reducing repeated setup time for long-running or recurring agent tasks. Yay.

[68:25] Justin: No, I mean, this is more and more of this isolation and control from a platform level, like I said, is the way to go. And so you provide your company with the execution environment of which run, and then you get to tightly control and offer hopefully a secure experience and functional, uh, experience for the rest of your business. And this is a great way to do that. I like it.

[68:47] Ryan: All right, well, I have two Oracle stories for us this week. It's been a bit.

[68:50] Justin: Yeah.

[68:50] Matt: Woo!

[68:50] Ryan: The first one's really kind of an Amazon story and an Oracle story combined, so it's like a twofer. Apparently Oracle and AWS are deepening their strategic collaboration as enterprise adoption of Oracle AI Database at AWS is accelerating. The Oracle Exadata Database Service on Exascale and Trisher is now generally available for Oracle AI Database at AWS, offering pay-per-use pricing and pooled storage that removes the need to provision dedicated database and storage servers. Worth noting, this brings Exadata economics to smaller workloads, not just large enterprise deployments, because if you ever price out Exadata, you know that it costs bajillions of dollars. The expanded strategic agreement between Oracle and AWS focuses on accelerating migration, with the service now live in 22 AWS regions just one year after general availability. And listeners should weigh whether this reflects genuine enterprise demand or aggressive partner incentives from AWS. Sub-200 millisecond latency uses AWS ECS placement groups is a notable technical claim for OLTP and ERP workloads. The host may want to scrutinize what conditions and configurations are required to actually hit the number in production. There's zero ETL integration with Amazon Redshift and direct access to Amazon Bedrock, SageMaker, and Qwik service lets customers apply AWS AI tools to Oracle data without moving it, which is a pretty good selling point.

[69:59] Justin: I mean, I like this, I guess, in the sense that they don't have to move data around, but I honestly don't understand why either business would do this because it just feels like the ability to sort of do compute on storage using different resources. But I guess that goes both ways, so maybe it works out. I don't know.

[70:14] Ryan: And basically this is a way for Amazon to pass money to AWS, uh, to Oracle to make them not, you know, be mad at them. But I, I do kind of miss the Andy Jassy days when Oracle and AWS hated each other. But apparently those days are over and this friendship partnership is here now.

[70:29] Justin: Yeah, I guess. I mean, Jassy's still around. Like, he's still charging.

[70:34] Ryan: Yeah, he's still around.

[70:35] Justin: But bang, right? Like, yeah.

[70:36] Ryan: You got bigger fish to fry than be mad at Oracle about dumb stuff, so.

[70:39] Justin: I guess that's right.

[70:42] Ryan: And then our final story, Oracle is redesigning the OCI service limit increase request workflow using its Redwood design standards and consolidating limit quotas and usage into a single console page under governance administration. Which again, if you go to the article, you can see screenshots of the amazing quota increase service Let's look at them.

[71:01] Justin: Does it look as good as the Amazon one? This kind of does, actually. It does look very much the same.

[71:07] Ryan: I mean, if you've ever used Oracle applications like Oracle ERP, you know, Oracle ERP 8, you know, which is over 20 years old, it looks just like it. So yeah, they've really improved things with the new Redwood UI standard. So I thought I saw this and I just had to laugh at it. A little bit.

[71:24] Justin: Yeah, it's pretty funny.

[71:24] Ryan: Hey, the fact that you wrote a whole blog post on your improved user experience for quota increases, and then number two, it looks that bad, uh, just makes me laugh, uh, in a way that I don't— yeah, this isn't healthy.

[71:36] Matt: But it just looks like 1995 called with their UI design.

[71:41] Ryan: That is true. That is exactly what it looks like.

[71:44] Justin: Did I miss a memo about everyone naming things after trees?

[71:47] Ryan: Oh, Oracle's been doing things after trees for way longer than you and I have been in a place where we're naming countries.

[71:54] Justin: I feel like there's been several announcements where people are doing announcement naming things like either, you know, we were talking about Cedar and Dogwood and now there's Redwood and like, I'm like, there's a lot of tree stuff going on right now. And it's not just Oracle, it's across everyone. But yeah, I don't know.

[72:11] Matt: They're just good names.

[72:12] Justin: I guess so.

[72:13] Ryan: And trees are hardy. You know, it's just, they are hardy. Yeah, the new— all the new Oracle UIs are called Redwood, uh, and they've been using that for since 2025, but I think even before then they were based in Redwood Shores. That was— so Redwood was a code name many a time for different things they were working on, uh, over the years. Well, gentlemen, we've reached the end of the show.

[72:36] Justin: Yay!

[72:36] Matt: How do you like recording at 10 PM?

[72:40] Ryan: Yeah, it's not great.

[72:42] Matt: It's a little bit harder.

[72:44] Ryan: Mostly cuz I'm already jet lagged and I had to wake up at 4:00 AM yesterday because the pro— the fun thing about living an hour away from SFO and taking an 8:30 AM flight is that you either leave at 4:00 AM and you get there at 7:00 and make your flight barely, or you get there at 5:00 AM and have 3 hours to kill at the airport. There is no in between. And so you have to, uh, you know, so luckily on Monday I got up at up at 4:30 AM and went to the airport and was there by 5:30. No big deal. Uh, but you know, one little, one little fender bender on the Bay Bridge and that would've been, I would've barely made that flight. That's just the sad reality of Bay Area traffic.

[73:20] Justin: Yeah. There's a giant body of water between here and there no matter where you go.

[73:24] Matt: Yeah.

[73:24] Ryan: So, you know, even though I, uh, you know, I'm not, not only am I recording late, but I'm also tired and jet lagged and not fully recovered from the loss of sleep yesterday, so. There we go.

[73:34] Matt: It's by the end. I can always tell somewhere I start to fade off and I come back.

[73:40] Ryan: Oh, I almost deleted the entire end of the Azure and Oracle section. I was just like, we don't have to talk about these. I can just delete it.

[73:47] Matt: Wait, I'm allowed to do that during weeks that I just have zoned out?

[73:50] Justin: Got it.

[73:51] Ryan: Nice. I mean, I mean, if I don't see it, I don't know where—

[73:54] Justin: That's true.

[73:56] Ryan: Yeah. I thought there was a story there.

[73:57] Matt: Should I just start editing what you're saying while you're saying it? Like you used to do to Peter.

[74:01] Ryan: That was always fun with Peter. He would start editing it mid-ti— as I'm talking, I'm like, no, no. And that was when I used to write all the show notes by hand, so I had a lot of typos and he used to always like to fix the typos as we were going. Uh, that was fun too.

[74:14] Justin: It's fun.

[74:14] Ryan: Good times. Good old Peter. Yeah, we should, we just need to do, uh, all right gentlemen, we'll see you next week. Uh, I'll be, I'll be in another lovely location. I'll share next week.

[74:24] Justin: Wow. Justin travels the world. Traveling forward to another week of cloud news wrapped up. Vault will collect the news. 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.