Nobody on your team read the full list of what changed in your AWS account yesterday. They couldn't. And the AI era is making it worse by the day.
This week we are bringing you another post torn from the pages of real life, inspired by our Infrastructure Change Tracking feature that has proven its worth since the first day in production. Every AI app you ship adds another layer of constant motion. GPUs spin up and down, ephemeral compute appears and vanishes, autoscaling fires all night, and increasingly the agents themselves provision resources on the fly. Your account no longer changes when you deploy; it changes by the minute.
We've written before about “weather coconuts”: tools that tell you what you already know but never what to focus on or how to fix it. There are plenty of infrastructure-change coconuts. A human still has to sift the list, decide which changes matter, and act. Detection was never the bottleneck. You are. In Firefly's State of IaC 2025, 67% of production incidents traced back to configuration drift, 86% of organizations called it a significant challenge, fewer than a third monitor it continuously, and teams burn roughly 40% of their infrastructure time chasing it by hand. Those numbers are not a tooling gap. They are the ceiling of what people can do manually.
This is a teardown of a real AWS environment. In the window below, AlertD logged 951 infrastructure changes. Go ahead, try to read 951 diffs and find the one that quietly widened an IAM policy. This is what it looks like when an agent does it for you instead.
How can infrastructure changes be dangerous?
Because the one change that matters is buried in thousands that don't, and it looks exactly like all the rest. In a dynamic environment, change is normal: Kubernetes creates and destroys nodes all day, routines grant and revoke access, and that's fine. What isn't fine is the needle in the haystack that shouldn't be there: a rogue CLI command, a manual fix in the console, another team's action. None of it is malicious, and none of it is AWS's fault; it is just the natural entropy of a live cloud. But each unrecorded change is a potential cost leak or a security hole, and teams report spending roughly 40% of their infrastructure time on manual remediation.
So… what exactly is changing?
Everything, continuously, and detecting it was never the hard part. AlertD ingests your resources and metrics non-stop. Because Flappy schematizes and understands your environment, it can diff every change and analyze every diff: which resources were created, modified, or deleted across EBS volumes, S3 buckets, network interfaces, IAM, and the rest, with counts and filters by service and change type, no tagging or setup. That part is solved. But this is where most tools stop, and handing a person a longer list was never the answer. The receipts are useless if no one can read all of them in time.
Seeing what changed is the easy part. Finding the needle is the point.
An agent reads all 951 changes, rates each one, and groups what matters into themes, so you read the five that count instead of the thousands that don't. Monitoring every change by hand to check whether it's fine isn't fine; it's costly and pulls engineers off real work. Would you be brave enough to whitelist a whole pile of activity and trust nothing slips through? This is the exact point where people stop scaling and agents take over. AlertD uses an LLM to rate each change and group the important ones into themes — security, cost, compliance, performance — as curated highlights. That is not a fast changelog; it is a different job, done by something that does not get tired at change number 200. And it does all of this with zero configuration: you never define a category or tag a single resource. AlertD reads the raw change data and builds the themes itself, the same way it auto-classifies and cohorts your entire fleet, so it works even when your tagging is a mess (and whose isn't).
Can it tell me what a change actually means, and how to fix it?
Yes, that is the whole point. Open a highlight and you get a plain-language explanation, the evidence behind it, and a ready-to-apply fix. Take a real one from this environment: a new IAM access key was created that could grant a user access to certain resources. AlertD lays it out in three parts — what it detected, why it flagged it, and how to solve it (review the permissions, verify which roles attach to it, enforce least privilege) — with the actual access key diff as evidence right beside it. Then it offers to fix it with an agent, generating the change as Terraform, CloudFormation, or console steps. You are not invited to read fifty diffs and guess. You are handed the meaning and the remedy.
Why are agents the only way to keep up now?
Because AI has pushed the rate of change past the point where adding people helps at all. A few years ago you could staff your way through it. Not anymore. Every AI workload multiplies the motion, and each dimension — security, cost, compliance, performance — is a full-time watch of its own that never stops. That is why teams lose 40% of their infrastructure time to manual remediation and why fewer than a third monitor drift continuously; the manual approach is already underwater, and the tide is still coming in. Hiring more engineers to read more diffs is a losing race. Work that would take a person hours has to run continuously, in seconds, which is exactly what an agent does. At AI-era fleet scale, agents are not the convenient option, they are the only one, and Gartner expects a third of enterprise software to be agentic by 2028 for precisely this reason.
What happened when we rolled this out?
Flappy caught a real breach in Slack, an external user given privileged access, and the team reverted it in minutes. Here's a real example: Flappy alerted an SRE team that an external user had been given direct access to systems he should never have touched. A Terraform change had pulled in external users and granted them access to privileged information. The team immediately recognized it as an important potential breach, deleted the offending file, and reverted it — before it became an incident.
Is this only about change?
No. The same agents and data layer that catch a risky IAM change also find wasted spend and right-size your workloads. AlertD gives you change and impact insight across security, compliance, cost, and performance for your whole AWS footprint. Change detection is one pillar of an agentic cloud operations platform. The point was never another changelog to scroll. It is to catch what changed, tell you what it means, and bring you the fix, at machine speed.
Your infrastructure is not going to slow down. AI is only going to make it move faster. The teams that keep up won't be the ones who hired more people to read changelogs. They'll be the ones who put agents on it.
See what changed in your own account. Install AlertD from AWS Marketplace →
Frequently asked questions
What is infrastructure drift?
Infrastructure drift is the gap between the state your infrastructure-as-code declares and the state actually running in your cloud. It builds up whenever something changes out of band: a console edit, a CLI command, an auto-scaling event, or a resource left behind after a migration.
Drift vs. changes?
Manual console or CLI changes, emergency hot fixes that never make it back into Terraform or CloudFormation, automated scaling and lifecycle events, and orphaned resources are all changes that cause drift — they make the deployed infrastructure differ from the IaC definition. That said, proper IaC updates can also be harmful, so AlertD agents go over every change.
How does AlertD detect changes?
AlertD ingests your AWS environment and records every change by service and resource type, then uses an LLM to rate each change and group the important ones into themes — security, cost, compliance, and performance — so you see the few that matter instead of a raw changelog.
How does AlertD help fix changes?
For a flagged change, AlertD explains what it detected, why it matters, and how to solve it, with the actual diff as evidence, then generates a ready-to-apply fix as Terraform, CloudFormation, or console steps that you review and apply through your own pipeline.
Do I need to tag my resources or configure AlertD first?
No. AlertD is zero configuration. It auto-classifies and categorizes your environment and fleet on its own, building the change themes and resource cohorts from the raw data, so it works even when your tags are incomplete or inconsistent.
Does AlertD change my infrastructure automatically?
No. AlertD analyzes, explains, and drafts the fix. It works from read-only access and never changes your environment on its own; you stay in control of every action.
Sources: Firefly, State of IaC 2025 (67% of production incidents traced to configuration drift, 86% call drift a significant challenge, fewer than one-third monitor continuously, ~40% of infrastructure time on manual remediation); Gartner, agentic AI forecast (a third of enterprise software agentic by 2028); AWS Config, CloudTrail, and drift-detection documentation.
