~24x less cloud operations effort across 36 tests, zero disruptions

When your best engineers spend their days on bureaucracy

The client is a large Nordic enterprise running more than 300 AWS accounts across two AWS organisations. The estate was built over roughly a decade by many teams, and it carries the inconsistency that implies. Infrastructure created a dozen different ways. Drift never reconciled. A tagging standard written down but never enforced. Patch status tracked unevenly.

Its senior cloud engineers spent a large share of their week on routine operational work. Patching. Backups. Resource cleanup. Tagging compliance. Security findings. Cost review. One of them put it plainly: this is bureaucracy, and it is a waste of their time and their creativity.

The client’s position on autonomy was equally plain. They did not let AI change anything, and they expected that to remain true for years.

Challenge

Two problems, and the second one is the harder of the two.

• Routine work consumed senior engineering time. Each service request took hours or days. Provision a server. Resize a disk. Patch a fleet. Rotate a credential. Chase a security finding. The people best equipped to improve the estate were the people fulfilling the tickets it generated.
• At more than 300 accounts, consistent change was effectively undoable. Making the same change everywhere, and proving it landed everywhere, is not a task a human can complete. One engineer described estate-wide change as “Mission Impossible with a human in the loop”.

So known gaps stayed open. Resources unmanaged by Terraform. Orphaned resources accumulating over years. A tagging compliance initiative that had been started five times and finished none of them.

The ask was specific. Show that an autonomous operations platform can safely do real operational work in this estate, and show that the guardrails hold, before it goes anywhere near production.

Solution

Firemind deployed its IT Operations Engine in two phases over ten weeks, against non-production AWS accounts. Every action required human sign-off.

Phase 1 covered four non-production accounts and a dedicated sandbox, spanning incident response, OS patching on Linux and Windows, security remediation, service request fulfilment, Terraform pull requests, cost observability and governance reporting.

The client then wrote the Phase 2 scope themselves. Their technical lead proposed five new capability areas after seeing Phase 1: database operations, software installation at scale, version upgrades, security group changes across the estate, and an explicit test of the human approval gate. Their VP Digital signed it off. All five were delivered and demonstrated three weeks later, across five AWS accounts.

Three independent layers govern what the engine can do:

1. Skills are the client’s own documents

   Their Confluence tagging guidelines and their Elasticsearch patching runbook were read and executed as written. Operational standards are encoded without anyone writing code.

2. Permissible actions decide how each action runs

   Autonomous, one approval, or blocked outright, set per action type. Anything with data loss potential always requires explicit sign-off.

3. IAM permissions are the hard boundary

   The engine cannot act outside what the AWS role permits, whatever it is asked to do.

Every action carried a full reasoning trace, and the engine re-planned rather than stopped when things went wrong. A resource deleted mid-scan invalidated a Terraform import pull request, so a corrected second commit was issued automatically. A Windows install found the AWS CLI missing and an S3 permission absent, and completed via an operator-approved pre-signed URL and standard PowerShell. A database migration into a VPC with no internet access had no suitable tooling available, so the engine wrote its own Python client and used that.

The client kept the pace. Autonomy is promoted one action type at a time, when they choose, and never by default.

What changed: hours back, gaps closed, and a path to scale

Work that normally arrives as a multi-hour service request completed in minutes. More importantly, work that was previously not attempted at all became routine.

Beyond the headline figures:

• The riskiest task in the runbook stopped being risky. An Elasticsearch rolling patch, including the index replication check the team performs by hand before taking each node down, ran with no data loss.
• Estate-wide change became a single operation. One inbound security rule was added across every security group in scope and verified in every region, including confirming that empty regions had no drift. That same operation does not get harder at more than 300 accounts than it is at five.
• The approval gate held where it mattered. A request to permanently delete an EC2 instance was automatically classified critical risk, paused, and routed to an operator for explicit confirmation before anything was touched.
• Standing gaps closed. The tagging initiative that had been started five times was applied as an enforcement pull request in under nine minutes. Fifteen resources unmanaged by Terraform were imported. A read only assessment across five accounts and 44 security groups produced 32 severity ranked findings with a remediation schedule, and changed nothing.
• Every case passed. Every test case across the two phases ran with zero disruptions, a complete audit trail, and human approval gates respected throughout.
• The client asked for more. The strongest signal in the engagement is not a number. It is that after Phase 1, the client’s own technical lead wrote the next scope and their VP Digital approved it.

The modelled figure above is built from the 25 cases that were individually timed. Eleven further cases ran without being separately timed, so it understates the work. It comes from non-production accounts only, and the 16 hour baseline is an assumption agreed for the pilot rather than a measured average.

Scope. The pilot ran on non-production AWS accounts only. No production system was touched at any point, and every action ran under human approval. All figures on this page relate to that environment. Time savings are modelled against an assumed 16 hour manual baseline per service request, not a measured one.