LogiCast AWS News: Amazon Inspector for AMIs, ECS Auto Scaling Improvements, DevOps Agent Extensions, and AI Cost Pressures

Season 5, Episode 38 of the LogiCast AWS News podcast brings together hosts Karl Robinson, CEO and co-founder of Logicata, and Jon Goodall, principal cloud engineer at Logicata, alongside guest Renato Losio, AWS Data Hero and editor at InfoQ. The episode covers four topics: vulnerability scanning for Amazon Machine Images, auto scaling improvements in Amazon ECS, extending AWS DevOps Agent with MCP and custom skills, and Amazon’s internal AI usage memo alongside rising AI service costs.

Amazon Inspector Vulnerability Scanning for EC2 AMIs

Amazon Inspector can now scan EC2 AMIs directly for vulnerabilities, without requiring a running instance. Jon explained why that matters in practice: previously, scanning a backup or archived AMI meant either converting it to a volume and attaching it elsewhere, or spinning up a server inside a quarantine subnet with locked-down security groups. Neither approach is straightforward. The new capability removes that overhead entirely.

Jon pointed to a real-world example - the PHP vulnerability that circulated recently, which he referred to as the “PHP apocalypse.” The issue wasn’t just patching live systems; it was the question of what to do about existing backups that remained unpatched. “We’ve patched it, but we’ve got backups that will be still unpatched, and we need to make sure that there’s nothing that happened on them.” Scanning the AMI directly, without standing up infrastructure, keeps the threat surface lower because there is no running server for anything malicious to spread from.

Renato added a complementary perspective - the value isn’t only in incident response, but in the build pipeline. If you’re generating your own AMIs for auto scaling groups and deploying them regularly, being able to verify them before deployment adds a meaningful layer of assurance. “It’s very different to have it after the service has been spun up and it’s running, part of the cluster, versus - oh, I can do it upfront.” He also noted that the implementation looks straightforward, without requiring complex setup to get findings.

The broader concern both raised was what happens after the scan. Alert fatigue is well-established in ops and security teams, and Karl coined what he called “CVE fatigue” - the tendency to become desensitised to a steady stream of vulnerability findings, particularly as AI tooling surfaces them faster and in greater volume. Finding vulnerabilities is the easier half of the problem; acting on them is the harder one.

Auto Scaling Response Times on Amazon ECS

AWS published a detailed technical post on the AWS Containers blog examining improvements to auto scaling response times in Amazon ECS. Jon described it as a heavy read, but one worth the effort for anyone running container workloads.

The core of the improvement is a reduction in the monitoring interval from 60 seconds to 20 seconds, giving three times the data points for scaling decisions. Jon walked through why latency in auto scaling compounds: monitors need time to detect a change, thresholds need to be breached, compute needs to come online, and then containers need to start on top of that. The gap between a container starting in under five seconds on a warm host and the full cold-start scaling path taking around five minutes is significant. “30 years ago, if you’d said I can have a new server serving live traffic to production in under five minutes, I think they’d have called you a crazy person. But these days that’s just not quick enough.”

The improvements AWS describes reduce that end-to-end time considerably - the post cited figures moving from around 363 seconds down to around 86 seconds in tested scenarios. Renato welcomed the numbers but raised a reasonable question about the choice of 20 seconds specifically. “Why 20 seconds? I mean, it was 60 and now you go to 20 - why not 10, why not 1 second?” He drew a parallel to Aurora Serverless v2, where similar questions arise about why minimum units land at the values they do rather than rounder alternatives. Jon speculated the answer probably involves avoiding overreaction in scaling decisions, and that “20” likely represents a rounded figure from empirical testing rather than a precise engineering target.

Renato also noted that the article itself stands out for its transparency - showing real numbers, explaining the methodology, and not simply asserting that things are better. “I love that they didn’t simply send out a message saying we reduced from 60 seconds to 20 or whatever. This time the article is a very credible deep dive.”

Extending AWS DevOps Agent with MCP Servers, Custom Skills, and Connectors

An article on the AWS Cloud Operations blog details how AWS DevOps Agent can be extended using Model Context Protocol servers, custom skills, and connectors. Jon had recently encountered the practical limits of the agent’s default context in a conversation with a vendor demonstrating a CMDB integration, which prompted the question of why you would bother connecting an external resource graph when DevOps Agent builds its own. The answer, he said, is that the agent’s built-in graph only covers what it can see within the connected account. It has no visibility into external scanning tools, no access to runbooks or wikis, and no knowledge of institutional context that lives in engineers’ heads or internal documentation systems.

“If it’s written down at all, it’s not written down somewhere DevOps Agent can get to it - certainly not natively.” With MCP servers and custom skills, it becomes possible to feed the agent relevant SOPs, previous root cause analyses, and platform-specific documentation at investigation time. Jon described this as narrowing the starting point for an investigation rather than leaving the agent to work from a wide set of metrics and gradually converge.

Renato made a point worth noting for anyone who might dismiss the article because they are not currently using DevOps Agent: the open source skills and the patterns described have value independent of the specific service. “I had many ideas of how to do things simply by looking at what is in those positions. You don’t necessarily need to use DevOps Agent to really benefit from those.” He suggested the skills, connector patterns, and MCP interaction models are worth examining even if you are working with different tooling or still using more conventional prompt-based approaches.

All three acknowledged that agentic tooling in production remains relatively rare in practice. Jon noted that internal use exists but that most of it is still single-shot prompting rather than true agentic workflows. Karl mentioned hearing at recent conferences about large enterprises rolling out AI agents at scale and then pulling them back - either because the expected benefits did not materialise or because token costs were not returning sufficient value.

Amazon Bedrock, AI Costs, and the Q3 Earnings Memo

The final two topics blended into a broader discussion about AI economics. A CRN article reported on Amazon’s Q3 earnings announcement, with AWS CEO Andy Jassy quoted suggesting Bedrock could eventually become as large a service as EC2. Karl described the claim as bold, given EC2’s scale and the fact that many AWS services run on EC2 infrastructure beneath the surface.

Jon’s assessment was that as a top-line service revenue figure, it is plausible over a longer horizon - perhaps two to five years at the outside - but only if you count the numbers in a specific way. “Bedrock or certainly parts of it run on top of EC2. If you count the numbers in the way that I would call honest accounting, no.” Renato was more measured, categorising the headline as marketing-adjacent, and raising a practical concern about adoption friction. Default limits on Bedrock model access - requiring tickets, approvals, and account-level exceptions - create a very different experience from EC2’s early days, when most users could simply start using the service. “That was not how the adoption of EC2 started.” He added that the rate of growth Bedrock has shown is impressive, but that sustaining it depends on resolving the limits experience.

A second article, written by Corey Quinn for The Register, covered an internal Amazon memo urging employees to use AI more deliberately rather than maximising token consumption. AWS had reportedly run an internal token usage leaderboard, which Jon described as being at odds with the company’s frugality principle. He also noted that the price of Kiro had effectively doubled for new enterprise billing through AWS accounts - the same dollar amounts now purchasing half the token allocation, framed as a pooling model for flexibility. “It’s what they call shrinkflation. You get less for your money, dressed up as a way of giving you more flexibility.” Renato agreed the pooling model makes operational sense for larger teams, but called the halving of token value “quite aggressive.”

The wider theme all three touched on was that the period of subsidised AI access driven by venture capital appears to be closing. Foundation model costs are rising, subscriptions are becoming more expensive, and the expectation of perpetually falling cloud prices - something AWS established over two decades - may not carry into the AI layer. Renato raised the possibility that cloud pricing norms themselves could eventually shift. “With inflation going up, cost of chips, no hardware - you wonder, there will be a point of no return when that rule will be broken.”

---

The full episode is available on all major podcast platforms and on the Logicata YouTube channel.

*This is an AI generated piece of content, based on the LogiCast Podcast Season 5, Episode 38.*