LogiCast AWS News: AWS Getting Started Overhaul, DevOps Agent Slack Integration, EC2 Auto Scaling Updates, and the Bahrain Region
Season 5, Episode 32 of the LogiCast AWS News Podcast brought together hosts Karl Robinson and Jon Goodall of Logicata and guest Kate Gawron, a data and AI specialist at DoiT and co-founder of the Northern PostgreSQL Community Group, to discuss four AWS news stories covering the revamped getting started experience, a new Slack integration for DevOps Agent, multimodal auto scaling for EC2, and the fallout from the attacks on AWS infrastructure in the Middle East.
AWS Reimagines the Getting Started Experience
AWS has been reworking how new users get up and running on the platform, going beyond the recently updated login screen to introduce federated authentication, cost controls, free credits, and a simplified account setup flow. Jon had covered the login screen changes in a previous episode with some scepticism, noting that existing users with IAM setups were largely unaffected. This update goes further, and he acknowledged it addresses something he has complained about for a long time: “Getting going is just a pain, and getting going the right way is even harder.”
Among the specific changes, users can now sign in with a Google, Apple, or Amazon account, receive an initial $100 in free credits with the ability to earn more, and invite team members into a project-style setup that handles some of the underlying account structure automatically. Jon noted the project setup appears to create IAM Identity Center users and workload accounts in the background - effectively doing things properly without the user having to understand what that means. He was cautious about the transition point, though: “I do wonder if there’s gonna be some sort of big learning curve to go from quite hand-held to no hand holding at all.
Kate framed it as AWS making a move toward the developer audience that has traditionally gravitated toward GCP. “It’s much quicker, in my opinion, to get up and running on GCP than it was AWS,” she said, adding that now everyone effectively has access to development tools through AI, there is a larger pool of potential users AWS needs to cater for. She also read the changes as part of a broader attempt by AWS to become more of a product company - something it has not always succeeded at, with Amazon Chime cited as a notable example. Karl pointed out that for customers who do outgrow the simplified setup, that is precisely where partners like Logicata come in.
AWS DevOps Agent Adds Bidirectional Slack Communication
AWS DevOps Agent has gained the ability to communicate bidirectionally through Slack, moving beyond simply posting notifications into a channel to allowing engineers to respond, query, and dig deeper without leaving the application. Jon, a self-described fan of ChatOps, was enthusiastic: the ability to ask follow-up questions - such as requesting a closer look at a specific P99 metric during an incident - without switching to another tool or interface is genuinely useful. He also made the practical point that most high severity incidents happen outside business hours, and being able to investigate from a phone via Slack, without logging into a console, changes the experience significantly.
Kate’s initial reaction was more cautious. She acknowledged the value of having everything in one place but raised concerns about giving an AI agent the ability to take actions against a production AWS account, particularly at 3am when someone might be half-asleep. Jon clarified that DevOps Agent is, to his knowledge, still read-only - it investigates and surfaces findings rather than making changes - and that he would be uncomfortable with autonomous remediation regardless of the interface used to interact with it.
Both Kate and Jon questioned why Slack was the chosen integration target rather than Amazon Q, which AWS has been positioning as a unified workspace. “It seems ironic that given you have Amazon Q Desktop, that should now be this unified pane of all things, the first thing they did was create a Slack integration and not an Amazon Q integration,” Kate said, returning to her earlier point about AWS and its own product ecosystem. Karl noted that Q is still in preview and improving, though he added he has unresolved costs appearing on his bill that he cannot trace back to any visible usage data - a minor illustration of the visibility challenges that come with newer services.
Multimodal Auto Scaling with Amazon EC2 Auto Scaling
Amazon has added support for multiple signal types in EC2 Auto Scaling, allowing scaling decisions to be driven by more than CPU alone. Kate welcomed the change as overdue, explaining that CPU is often a lagging indicator - by the time it spikes, the problem has already arrived. Being able to incorporate application-level metrics means you can see demand building earlier and scale out before the impact hits users, rather than reacting after the fact. She also noted the inverse benefit: avoiding unnecessary scale-out when high CPU is caused by an application fault rather than legitimate user traffic.
Jon connected this directly to a current customer situation involving an e-commerce platform with unpredictable spiky traffic. CPU-based scaling has left him choosing between scaling too early and wasting spend, or scaling too late and risking transaction loss. He has been using predictive and scheduled scaling but has not been able to dial it in precisely enough. “Maybe this is the third thing and we can finally get it dialled in properly,” he said. The flapping problem - where target tracking repeatedly scales out and back in because the threshold is constantly crossed in both directions - was also raised as something better multi-signal inputs could help address.
AWS Bahrain Region and Middle East Infrastructure
Press reports confirmed last week that AWS will not be restoring access to infrastructure at data centers in Bahrain and the UAE that were damaged in Iranian attacks. Karl noted the story had first surfaced around six months ago and that the region had been subject to continued disruption since. Jon was precise about what was actually being said: the damaged facilities are not coming back, but that is different from saying the region itself will never exist again. Physical infrastructure can be rebuilt. The more immediate problem is data that was stored exclusively within the affected region - that data is likely gone.
Kate was measured in her defence of AWS, pointing out that when multiple data centers are hit by missile strikes in close succession, and connectivity is severed, there is little a cloud provider can do to recover or extract data. She drew a contrast with how many organisations managed critical data a decade ago - often on hardware sitting under a desk - and argued that the cloud’s resilience tools are routinely underused. “I think we forget that there’s the good old shared responsibility model,” she said, noting that multi-AZ and cross-region backups exist precisely for scenarios like this. Her practical advice was straightforward: if your company cannot survive losing its data, at minimum your DR backups should be in a different region, and ideally a different country.
The conversation touched on cross-vendor DR, with Kate sceptical of its value for pure resilience purposes. If AWS experienced a failure large enough to lose data across multiple regions simultaneously, she argued, no other cloud provider would be in a position to help either. The discussion closed on the broader topic of data center vulnerability - including the AI-driven construction boom in the US and growing local opposition to new facilities - with Karl noting it raises real questions about how these assets are protected going forward.
The full episode is available on all major podcast platforms and on the Logicata YouTube channel. If you enjoyed it, please leave a rating or review.
*This is an AI generated piece of content, based on the LogiCast Podcast Season 5, Episode 32.