About
A major European airline runs its AWS estate through a traditional managed service. Patching had climbed from roughly half its machines to around 90%, then stalled and never reached full coverage. Lifecycle and runtime upgrades dragged on for months, sometimes years. And a steady stream of low-value, reactive work, the Priority 3 and 4 jobs, piled up with no one to own it.
Rather than pitch a cheaper managed service, Firemind ran a single live session on the airline’s own AWS estate, across multiple accounts. Its IT Operating Engine took on the everyday run work that cloud infrastructure management is made of, the patching, lifecycle, cost and fixes, under the airline’s own documented procedures. The question was whether the work that never gets done could run through reviewable code, safely, on a live estate.
Scope: a single live session on the airline’s own multi-account AWS estate, running its real operational scenarios. The results below are what the engine demonstrated in that session.
Challenge
The managed-service model kept the estate running, but left the airline’s team carrying the work that never paid off. Three problems had set in:
- Patching hit a ceiling. Compliance had risen from 40 to 50% of machines up to 80 to 90%, then stopped there, never reaching full coverage.
- Lifecycle work never finished. Runtime and end-of-life upgrades took months or years, and there was no spare capacity to modernise the legacy systems behind them.
- The backlog had no owner. A steady stream of low-value, reactive Priority 3 and 4 jobs, with little visibility into patch status, end-of-life exposure or compliance.
The airline needed that tedious, reactive work handled at volume, with full visibility and under its own governance. Not a cheaper version of the same managed service.
Solution
In a single live session, Firemind ran its IT Operating Engine against the airline’s real scenarios, executing strictly to the airline’s documented procedures, with every change delivered as reviewable code its engineers could approve.
Works across the airline’s multiple AWS accounts, under its own operational procedures.
Consolidates patch status, end-of-life exposure and vulnerabilities into a single view.
Patches, decommissions and provisions as reviewable, governed code, not console clicks.
Finds unmanaged resources and configuration drift, and raises fixes to keep the estate in line.
The session proved three things:
-
It saw the whole estate at once. Consolidated lifecycle and end-of-life reporting across multiple AWS accounts: machine support end-dates, missing patches and security vulnerabilities, including flagged exposure on Red Hat systems. The visibility the team had been missing arrived in one view.
-
It did the work the team kept putting off. The engine handled patching from simple Linux kernels up to a 3-node Elasticsearch cluster. It patched that cluster in 21 minutes, with zero data loss and all 175 documents preserved, to the airline’s own procedures. It decommissioned an EC2 instance and its EBS volume while preserving a shared network interface and security group still in use elsewhere. It also created backups and copied them across regions, from EU North to EU Central.
-
It ran through reviewable code, and corrected itself. New machines arrived as pull requests with auto-generated Terraform. Drift detection scanned an account, found 15 unmanaged resources and raised a pull request to bring them under management, recovering on its own when one import first failed.
Nothing ran outside the airline’s control. Every action followed its documented procedures and landed as reviewable code its engineers could approve. Alongside the operational work, multi-account cost reporting surfaced 20 to 70% in potential savings from underused resources and reservations.
Results
Running live on the airline’s own estate in a single session, the engine cleared real backlog work and proved the model. Beyond the headline figures:
- The work that had no owner, done at machine speed. The Priority 3 and 4 jobs the team never had time for were executed in the session, to the airline’s own procedures.
- Visibility the team had been missing. Patch status, end-of-life exposure and compliance, consolidated across accounts into one picture.
- Operations as reviewable code. Changes came as reviewable, governed code the airline’s engineers could read and approve, rather than opaque console actions.
- A path that is moving forward. The engagement is progressing, with follow-up sessions on validation and governance and a security-findings integration.
It captures the little things we don’t want to do.
This was never about a cheaper managed service. It was about clearing the reactive backlog for good, paying down years of stuck technical debt, and running operations as reviewable code the airline’s own engineers control.
