LogiCast AWS News: Secrets Manager EventBridge Integration, GuardDuty AI Investigations, Billing Glitch, and More

LogiCast AWS News: Secrets Manager EventBridge Integration, GuardDuty AI Investigations, Billing Glitch, and More

Logicata

Season 5, Episode 27 of the LogiCast AWS News Podcast features hosts Karl Robinson, CEO and co-founder of Logicata, and Jon Goodall, principal cloud engineer at Logicata, alongside guest Alam Ahmad, AWS Community Builder and content creator focused on AWS, AI, and DevOps topics. The episode covers four news stories: a new Secrets Manager integration with EventBridge, an AI-powered investigation feature for GuardDuty, a widely-reported AWS billing display glitch, a domain expiry incident that locked a web developer out of his own account, and an update on the AWS data center in Bahrain.

AWS Secrets Manager Now Sends Update Notifications to EventBridge

AWS Secrets Manager can now publish secret update notifications directly to Amazon EventBridge. Previously, if you wanted to know when a secret had been changed, your only option was CloudTrail - the log of every API call - which Jon described as requiring considerable effort to parse and act on. “If you wanted to be able to take action off the back of your secret being updated,” he noted, “you had to stitch together a vast array of different things in order to be able to do that.” Now the notification lands on the default EventBridge bus, and a filter is all that is needed to trigger a downstream action.

Alam welcomed the change but flagged that common sense had not exactly been applied early here. “Visibility around credentials are extremely important because it is like a low hanging fruit when you want to attack an infrastructure,” he said, adding that for large teams or organisations with high staff turnover, this kind of visibility is something you need. Jon agreed the feature is useful, but used the opportunity to raise a longer-standing complaint about Secrets Manager’s pricing - roughly 40 to 50 cents per secret - compared to SSM Parameter Store’s secure string parameters, which he argued offer near-identical functionality, encrypted with the same KMS keys. Automatic rotation is the main differentiator, but Jon pointed out that many teams already built that themselves in the days when Secrets Manager required it, and writing that boilerplate today is straightforward. Whether the pricing calculus changes how teams approach secrets management remains a valid question, even with the new EventBridge integration in place.

GuardDuty Investigation Agent

AWS has introduced an investigation agent for GuardDuty, currently in preview, that automates the initial stages of threat investigation. GuardDuty already ingests signals from several sources - VPC flow logs, CloudTrail, RDS login attempts, and others - and surfaces findings when it detects unusual activity. What the investigation agent adds is the ability to take a specific finding, a specific account, or up to 100 accounts across an organisation, and automatically correlate related activity into a single report with actionable recommendations.

Jon explained why this matters in practice. GuardDuty findings are useful if you already understand the environment well enough to interpret them quickly, but for anything less obvious than a brute force attack or crypto mining activity, working out what is actually going on takes significant time and often requires input from multiple people. The investigation agent aims to bridge that gap - moving from “I have seen this server calling out to a strange endpoint, you might want to look at it” to “I have looked at it and here is what I think is happening.” He noted that the feature is free during preview, but expressed concern about what the eventual pricing model might look like, given that the GuardDuty DevOps agent ties its pricing to a support plan, which he described as unfriendly.

Alam observed that a lot of what AWS’s agents are doing is handling lower-complexity work - integrating with ticketing tools, mapping findings to the MITRE ATT&CK framework, producing structured reports - and that the broader pattern is AWS looking at what security teams are already doing manually and automating it. “It’s primarily focused on SOC level one or just junior roles, but it’s helping junior guys and girls with their jobs, providing them with more information,” he said. Karl noted that the investigation agent, unlike the DevOps guru agent or the security agent, appears in lowercase in both the Helpnet Security article and AWS’s own blog post, suggesting it may be a sub-feature of GuardDuty rather than a standalone named service.

AWS Billing Console Glitch

A bug in the AWS billing console temporarily displayed wildly incorrect charges for some customers, with figures reported as high as 55 trillion dollars and forecast end-of-month totals reaching 103 trillion. Jon noted that a member of the Logicata team was personally affected, seeing a bill showing roughly 10.4 billion dollars against a budgeted amount of ten dollars. AWS acknowledged the issue and fixed it, but the response from the company - described publicly as a “slight billing issue” - drew strong criticism.

Jon was direct about why that framing was a problem. Seeing a bill of that magnitude, even an obviously incorrect one, is not a minor inconvenience for everyone who encounters it, and a dismissive response fails to acknowledge that. He argued the correct approach would have been a clear explanation of what happened, an apology, and signposting to support resources. Alam echoed that point, noting that even a bill of a few hundred pounds early in someone’s AWS journey can be alarming, and that the “slight miscalculation” framing sat badly. Both agreed that the community has every right to make jokes at AWS’s expense here, but that AWS joining in with a casual tone was misjudged. Karl added that since AWS billing is eventually consistent rather than real-time, there was never any risk of anyone actually being charged these amounts - and that any card provider would almost certainly block a transaction of that scale as fraudulent regardless.

AWS Route 53 Account Suspension and Domain Lapse

An article in The Register documented what Jon described as a comedy of errors involving a web developer who manages domains and hosting for multiple clients through Route 53. Payment card expiry notices went unread in his spam folder, his AWS account was suspended, and all his clients’ websites and email accounts went offline. Attempting to log back in to resolve the situation, he found that the MFA for his root account was tied to a software authenticator on a broken laptop. His email-based MFA backup sent codes to an address that was hosted on one of the suspended domains, making it inaccessible. It took several days to verify his identity and restore access.

Jon’s main takeaway was less about the payment lapse itself and more about the structural mistake: “Do not put the thing that manages your stuff in the same place as the stuff.” In this case, the recovery path for the AWS account depended entirely on infrastructure that sat inside the suspended AWS account. He described his own approach of routing domain and account recovery to a personal Gmail address specifically because it is disconnected from everything else he manages in AWS. Alam noted that from his work in incident response, small misconfigurations and overlooked hygiene issues - lapsed credentials, unreturned hardware from departed staff, missing backup MFA - consistently have outsized consequences. He also pointed out that once the account was suspended, the developer found himself bounced between departments trying to resolve it, which added to the difficulty of an already stressful situation.

AWS Data Center in Bahrain

Iranian state media claimed that an Amazon data center in Bahrain had been struck and destroyed by cruise missiles, framing the attack as a response to alleged US strikes on a nuclear facility. Jon was sceptical of the “destroyed” claim, pointing out the scale of these facilities and noting that state media from any country carries an inherent agenda. AWS stated that no customers were impacted and that workloads had been proactively moved to other sites. Karl found during the episode that the status page for the Bahrain facility had not been updated since 30 April, when Amazon was already advising customers to migrate workloads elsewhere.

The practical advice from the group was straightforward: if you are still running workloads in that region, move them. Jon noted that this has effectively been the guidance since the first strikes on the facility. Alam raised the broader question of whether geopolitical risk now needs to factor into decisions about where to host infrastructure, and observed that AWS had at least managed the customer impact by moving workloads proactively before further damage occurred.

---

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

Need help with your AWS?

Our free healthcheck takes 2 minutes and gives you a clear picture of where your AWS stands.