LogiCast AWS News: AWS Well-Architected Agent, Observability with Kiro, DevOps Agent Security Triage, and a New UK Data Centre

Season 5, Episode 34 of the LogiCast AWS News Podcast features hosts Karl Robinson, CEO and co-founder of Logicata, and Jon Goodall, principal cloud engineer at Logicata, joined by guest Chris Belfield, a principal architect with 14 years of AWS experience.

Please note: we were unable to record this episode, so no recording is available. We hope you enjoy the written recap.

AWS Well-Architected Agent Preview

AWS has launched a preview of the Well-Architected Agent, an AI-powered tool designed to help customers optimise their cloud environments against the Well-Architected Framework. For Logicata, a Well-Architected partner, the natural first question was whether this signals the end of partner-led reviews.

Jon traced the evolution of the review process from heavily manual assessments, where reviews could take days, through to tools like Service Screener and the IaC Analyzer, and now into the agentic space.

“I think you’d be naive to think that this wasn’t coming eventually.”

He noted that specialised agents for security and DevOps already exist. The Well-Architected Agent is a logical extension of that trend. His key point was about cadence: reviews are supposed to be continuous and repeated, not one-off audits, so anything that makes them faster and easier to run regularly is a net positive.

Chris brought a practical lens, noting that the value of any review depends on the feedback loop rather than the report alone. He also highlighted an important consideration for agentic tools more broadly: giving an agent enough access to assess an environment means scoping permissions carefully, and any proposed infrastructure-as-code changes should go through human review before being acted on.

Jon agreed on the access point, drawing a distinction between read-only and view-only permissions - the agent cares about configuration, not content, so it doesn’t need to read what’s in an S3 bucket, just how it’s configured.

Karl pointed to a real-world use case Logicata has seen: customers using the resulting report to demonstrate due diligence to auditors and investors.

“If you do it yourself, you’re effectively marking your own homework.”

A third-party-reviewed report carries more weight in those conversations.

The consensus was practical - this is a tool that accelerates the process, not one that replaces the judgement of the people doing the work.

AWS Observability Power for Kiro

This article, from the AWS Cloud Operations blog, walks through a set of MCP servers packaged as a Kiro “power” - a one-click installable collection of pre-configured tooling for AWS observability. It connects Kiro to CloudWatch Logs, X-Ray traces via the AWS Signals MCP server, and CloudTrail, allowing developers to investigate issues through a conversational interface in their IDE.

Jon, who uses Kiro regularly and has several powers installed, was positive about the concept. His main recommendation was to go through the setup in a sandbox:

“These things are always worth going through because you learn more doing the setup than you do using the tool on the other end.”

He cited an experience at AWS Partner Equip where working through manual SLI and SLO configuration in CloudWatch taught him more than the workshop itself was designed to cover.

One practical consideration he raised was around authentication. To use it, your IDE needs to be pre-authenticated against the target account, which means tokens or profiles have to be set up in advance. For an MSP managing 30-plus accounts, getting that working reliably enough to be useful at 2 a.m. requires some upfront investment.

He also noted, with a nod to a previous guest, that whatever access you give the agent should be tightly scoped:

“Give it read only, cos that’s giga chad security.”

Agents left with broader permissions have a habit of trying to deploy things when they can’t find another way forward, burning tokens in the process.

Chris added a data handling perspective: if an agent is pulling CloudWatch logs through to a local machine, and those logs contain PII, that creates a potential exposure. Jon noted that PII shouldn’t be in logs in the first place, but acknowledged it’s worth being aware of.

All three agreed that the root cause analysis capability is strong when the underlying data is clean and well-structured, with the shared observation that good tooling works best on top of solid observability foundations.

Security Triage with AWS DevOps Agent

The third article covers a scenario familiar to anyone who has done on-call work: a security alert fires at 2 a.m., and someone has to work out what’s happening before they can do anything about it. This post applies DevOps Agent - already used for operational incident correlation - to security alarms, using GuardDuty alerts as the trigger.

Jon explained why this lands with DevOps Agent rather than the security-focused agent: the security agent handles penetration testing and vulnerability scanning, while DevOps Agent handles response and investigation. The article makes this clear early on - “it doesn’t just do operational stuff” - and then walks through how to set it up with a deliberately broken sandbox environment.

His framing of the value was the most concrete of the three topics. On-call work involves roughly 10 minutes to become functional after being woken, another 10 to get to a laptop, then 20 more minutes working out what the alerts are actually saying before any diagnosis begins. DevOps Agent handles that investigation phase, so by the time a human is functional enough to engage, the triage work is largely done.

Jon sees it as equivalent to a first-line support function - it investigates, surfaces where it thinks the problem is, and can execute a limited set of pre-approved non-destructive actions.

“That’s all this is.”

The discussion touched on practical deployment questions, including how the agent works across multi-account setups and what the cost looks like at scale. Jon clarified that DevOps Agent is now generally available, costs $0.00083 per agent minute, and agent spaces themselves carry no standing cost - you pay only when the agent is running. The routing to the agent is intentional and human-configured, not automatic.

The group agreed that the root cause analysis use case has genuine value, particularly as the quality of the underlying alerting and metrics improves. Karl noted that getting tools like this into the market is how AWS learns what improvements are needed - a dynamic that applies to most of what the three discussed this episode.

AWS Data Centre Planning Permission in Iver, UK

AWS has been granted planning permission for a new data centre in Iver, east of Slough - an area Karl described as already being something of a data centre cluster. The project will include 27 backup generators and replace 17 existing industrial and warehouse units rather than using greenfield land.

Jon noted that building on existing commercial land rather than green belt is the right call, and that locations like this tend to have good road access - important for the staff who still need to work there. He flagged that the UK region is named London despite being in the Bristol area, and that a new availability zone has recently been added, though whether this site feeds into that or serves another purpose isn’t clear yet.

The article mentions the generators will run on hydrotreated vegetable oil - Jon’s observation was that if you visit and it smells like fish and chips, that’s why.

The wider discussion touched on AWS’s sustainability commitments and the reality that the focus has increasingly shifted to bringing AI capacity online quickly. Water positivity and net zero targets were topics on the podcast not long ago; now the conversation is about how to meet growing demand. Chris noted it would be useful to see more transparency about how new capacity maps to customer demand, and Karl offered a straightforward take:

“I just don’t think you can get away from the fact that data centres are not particularly environmentally friendly.”

All three acknowledged the tension between the infrastructure AI requires and the environmental cost of providing it - an ongoing conversation across the industry with no simple answer.

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