LogiCast AWS News: AWS Sign-In Updates, CloudWatch Observability, DevOps Agent Pipelines, and London Region Expansion

Logicata 25 August 2026

Season 5, Episode 28 of LogiCast, the AWS news podcast from Logicata, sees hosts Karl Robinson and Jon Goodall of Logicata joined by guest Jessica Coelho, AWS community builder, AWS user group leader in Belo Horizonte, Brazil, and platform database engineer. The episode covers updates to the AWS sign-in experience, a roundup of CloudWatch observability announcements, the AWS DevOps agent for CI/CD pipelines, a new availability zone in the London region, and Amazon’s internal Region Flex programme.

AWS has updated its sign-in flow, introducing federated login options - including Google, Apple, and GitHub accounts - alongside a cleaner multi-session experience. The change is opt-in for now, and Karl noted that having tested it, accepting the new experience appeared to be a one-way door without clearing browser cookies.

Jon’s take was broadly positive on the federated login additions, framing them as reducing the number of things to actively manage, but he was clear that the update shouldn’t matter much to most teams doing things correctly. “You should be using IAM Identity Center to sign into your organisations, even if you only have one account,” he said, pointing back to a previous episode discussion about a user who got locked out of everything by skipping the foundational setup steps. He acknowledged there are still edge cases where IAM users are unavoidable - the team’s own use of Amazon Q Desktop being one example, given it requires IAM Identity Center configured in us-east-1, which conflicts with their existing setup.

Jessica agreed the optionality was welcome, and said she tends to stay on familiar workflows until a change becomes mandatory. Karl observed that muscle memory plays a big role in resistance to console changes generally - something that applies well beyond just the login screen. Jon mentioned the team uses granted.dev as a preferred tool for switching between accounts via the CLI, and said he didn’t expect any of the sign-in changes to affect that workflow.

CloudWatch Observability Announcements - July Roundup

AWS published a summary of observability updates from July, and the panel focused on two in particular: CloudWatch Logs intelligent tiering, and the ability to create alarms directly from log query results.

On intelligent tiering, Jon was measured. The bulk of CloudWatch Logs cost sits in ingestion, not storage, so reducing the price of long-term storage is unlikely to move the needle for most users. “If you have very high log storage costs in CloudWatch Logs, I guarantee you’ve already looked at using something else,” he said. He did soften slightly on learning the setting can be applied at account level rather than per log group, pointing out that services like Lambda create log groups automatically and retain them indefinitely by default - so enabling intelligent tiering account-wide is low-risk and may recover a small amount of cost with no downside. Jessica added that many organisations simply don’t manage their logs well, and for those teams the automatic tiering and eventual deletion at 90 days could provide meaningful savings without requiring any active effort.

The alarms-from-log-queries feature drew more enthusiasm. Previously, getting an alert based on something appearing in a log required setting up a metric filter, creating a metric, writing an alarm against it, and configuring thresholds - several layers of configuration to achieve something conceptually straightforward. That pipeline can now be handled directly. Jon described the old process as “writing Nordic runes in the console,” and said this change removes a significant amount of boilerplate. Jessica confirmed it was something she had been wanting, particularly for database and EC2 log monitoring in complex environments. The feature was announced as generally available on 1 July. Jon also noted that ALB logs can now flow directly into CloudWatch without routing through S3 and Athena first, and that AWS Managed Prometheus collection is now available natively in CloudWatch, removing the need to maintain separate collectors.

AWS DevOps Agent and GitHub Integration via CodePipeline

AWS published a solutions post on integrating the DevOps agent with CodePipeline and GitHub, with the aim of automating diagnosis and response when pipelines fail. Jon drew on his background as a DevOps and platform engineer to frame why this matters. A recurring frustration in that role, he said, was spending time proving to development teams that a failed build was caused by their code rather than the pipeline itself. Anything that removes that back-and-forth is useful. The pattern here - where a developer raises a pull request, the pipeline runs, something fails, and the agent identifies and potentially resolves the issue without a platform engineer getting involved - represents a step forward in how agentic tooling is being applied. “I pre-told it what it’s allowed to go and do and it handles it for me,” he said, distinguishing this from conversational AI interactions.

Jessica noted that while this particular workflow is less directly relevant to her database-focused role, the troubleshooting angle is broadly applicable. She observed that the feature appears to place particular emphasis on log interpretation and surfacing actionable information to the people supporting the pipelines. On the broader question of agents in her own work, she described using agents to analyse logs and flag query-level issues in relational and non-relational databases - identifying problem queries, suggesting indexes, and proposing optimisations. She is not yet letting agents make changes autonomously, citing the sensitivity of database environments. “The database is really critical and sensitive,” she said. “They are my babies.”

New Availability Zone in AWS Europe - London Region

AWS announced a fourth availability zone in the London region. Jon welcomed the announcement in principle but was openly sceptical about what it means in practice. London has had three availability zones for as long as he has been working with AWS - around a decade - while regions like us-east-1 have six. The announcement arrived without significant coverage beyond Amazon’s own blog, which he noted gave him pause. “I’m not seeing it on any kind of major news publication, I’m only seeing it on Amazon’s own one,” he said.

His bigger concern was whether the new AZ actually addresses the capacity constraints the team has seen emerge in London over recent years. He described observing T-series instance availability issues in London - something he characterised as unusual and unexpected. Jessica pointed out that based on her reading, the infrastructure appears heavily oriented toward AI workloads - GPU and training instance types - which may mean limited relief for general-purpose compute. Jon acknowledged that even if it is full of AI-specific hardware, it could reduce overall load on the rest of the region’s infrastructure. Jessica added that Brazil’s local region is significantly more expensive than US options for her clients, meaning most of them run workloads in the US regardless of location, so the London expansion is less directly relevant to her day-to-day.

Amazon’s Region Flex Programme and Power Constraints

The final article covered Amazon’s internal Region Flex programme, described as an effort to reduce reliance on a small number of large AWS regions and redistribute workloads across more locations in response to tightening power constraints. The panel agreed the article was ambiguous on whether this applies to Amazon.com’s e-commerce workloads, AWS’s own internal services, or both - though all three felt option three, customer workloads, was unlikely.

Jon described the engineering scale involved as “utterly monumental,” noting that moving workloads between regions is a significant undertaking even at modest scale. The power angle was the more interesting thread for him. A figure cited in the article put Irish data centre electricity consumption at 7,663 gigawatt hours in 2025, representing 23% of metered electricity use in Ireland, up from 5% a decade earlier. Ireland has introduced tighter conditions for new data centre grid connections, including a requirement to demonstrate the ability to disconnect from the grid entirely for a defined period - a condition that some operators have met by purchasing diesel generators, which Jon noted sits awkwardly alongside the sustainability commitments AWS has made publicly. The broader point was that as power generation shifts toward more variable renewable sources, the ability to move workloads based on where power is available becomes a genuine operational requirement rather than an optimisation exercise. Jessica said she had not encountered capacity constraints directly with her clients, but was interested in whether Region Flex might eventually be offered as a capability for customers - something she framed as speculative but worth watching.

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 28.*