We recently worked with an enterprise software provider that builds and hosts core administrative software for higher education. Hundreds of colleges and universities run on its Google Cloud environment. The footprint spans roughly 180 projects today and is on track to reach about 400. Nearly all of it runs Microsoft SQL Server on Compute Engine Windows VMs.
Their director of cloud strategy summed up the outcome better than we could:
It's an easy sell for me to say, ‘hey, we're going to reduce our costs by between 20-30 percent. And we're also going to gain functionality that is much needed.’
Why Do EdTech Vendors Carry the Compliance and Resilience Burden?
Hosting changes what backup has to prove. Every institution's contract sets data protection terms. FERPA and state student-privacy laws stand behind them, and auditors ask for evidence. The requirement travels with the contract, not the cloud: the same immutable-retention language applies whether a vendor hosts institutions on AWS, Azure, or Google Cloud. If the company can't prove coverage for every institution, it doesn't have coverage.
The pattern holds for any company hosting customer workloads, and native tooling leaves each cloud, account, and project to fend for itself. Now multiply that across 180 projects. Each institution runs in its own project, so "are we compliant" has to hold for every one of them, every time someone asks. A spreadsheet can't answer that question.
The Challenge: A Backup Policy from the Veeam Days That Cloud Tooling Couldn't Satisfy
The higher ed tech company was mid-migration, moving all hosted customer workloads to Google Cloud. The move surfaced a problem. They had written their backup policy years earlier for Veeam and physical storage: two copies of every backup, one local and one off-site, immutable throughout. Google Cloud Backup and DR couldn't satisfy it.
The director framed it simply: the policy gap meant changes were coming no matter what. Eon just reduced the hit.
Three more gaps followed:
- Native restores deposited files into a Cloud Storage bucket. Then, an engineer copied them back to the machine by hand over the CLI. Their engineers called the process time-consuming and difficult.
- Nothing scanned the backups for ransomware, so a poisoned copy would look identical to a clean one.
- PCI and SOC 2 required recovery copies in a second region, which native tooling handled on a per-project basis.
And in this business, a hit on one hosted institution becomes a breach story for all of them. By the time the team started evaluating, the estate held more than 600 TB, with the full environment projected to exceed 1 PB once migration was complete. Every gap scaled with it.
The Evaluation: Ten Success Criteria and a Four-Day Proof of Concept
The team wrote ten success criteria in advance and scored Eon against them over a four-day proof of concept (POC). The list included:
- Autonomous policy assignment across projects with drift protection
- Immutable retention that satisfied the written policy
- Cross-region vaults, which the team stood up and verified during the POC
- File, folder, and full-VM restores their engineers could run themselves
- Ransomware scanning on recovery copies
- Fit with the team's existing Terraform code
- Cost modeling against their current native backup spend
Mid-POC, the team asked for a capability the product didn't have yet: restoring a VM to a specified internal IP address. Eon shipped it during the POC, and the team's systems engineer ran a live restore with it on the next call. It landed without issue.
The cost model settled it. On a three-year view, the numbers came in well below the company's native backup spend. All ten criteria came back met, and the deal went from first conversation to signed contract in about two and a half months.
The Solution: One Policy Engine and a Vault Production Can't Touch
Deployment asked little of the team: one read-only IAM role, no agents, no appliances, no per-project setup. From there, Eon discovers every resource, classifies the data inside, and applies protection policy on its own- the practice we call Cloud Backup Posture Management, or CBPM. New institution projects inherit the policy as they appear, and Eon corrects drift rather than leaving it for the audit to find. The platform runs the same way on AWS and Azure, so a multi-cloud estate sits under one policy engine.
Every recovery copy lands in an immutable, logically air-gapped vault, captured forever-incrementally (a full copy once, changes thereafter) and deduplicated globally. Cross-region protection is a policy setting: pick the region, and copies land in a vault there.
The Results: Governance, Compliance, and Cyber Resilience the Team Can Prove
Governance runs on its own
Eon finds new resources as institutions onboard, classifies the data within them (including student PII), and assigns policy without anyone tagging anything. When coverage drifts, Eon flags and fixes it before an audit would have found it.
Compliance stopped being a scramble
"Are we compliant?" used to mean checking on a project-by-project basis. One policy engine now holds the answer for every institution at once: what's protected, how long it's protected, and how fast it comes back.
Restores run in minutes
Every copy is immutable and logically air-gapped. A counterpart lands in a second region, and Eon scans them all for ransomware. When something breaks, engineers restore files, folders, or full VMs themselves within minutes, without buckets or CLIs. For contrast: the average ransomware recovery industry-wide now takes about three weeks and costs $1.7 million (Sophos State of Ransomware 2026).
Backup spend modeled 20 to 30% lower
The company ran the model on its own retention and change rates, alongside its native Google Cloud bill. Eon came in 20 to 30% lower for three years of backup, and functionality went up.
If your contracts promise more than your backup tooling can prove, do what this team did: write your success criteria and give Eon four days. Request a demo.
Frequently Asked Questions
Is Google Cloud Backup and DR enough for immutable, indelible retention?
It depends on your policy language. For the team in this story, native controls fell short of a written policy requiring encrypted, immutable, indelible copies with an off-site counterpart, and restores stayed manual. Audit your tooling against your contract terms before an institution's auditor does.
Does Eon only work on Google Cloud?
No. Eon protects AWS, Azure, and Google Cloud from a single control plane, with the same read-only access model across all. SaaS data is covered too: Microsoft 365 and Google Workspace get automatic point-in-time backups that land as an independent, off-tenant copy in a vault the customer controls. And vaults can pair across regions or clouds, placing recovery copies in a separate trust domain from production and with credentials independent of the environment an attacker would compromise.
Can Eon protect SQL Server running on Compute Engine Windows VMs?
Yes. Eon takes agentless snapshots of Compute Engine VMs as often as every six hours, with no software on the machine. Engineers browse and restore individual files, folders, or the full VM.
What happens if the primary region goes down?
Recovery runs from the second region. A vaulted copy differs from cross-region replication, which copies an attack as faithfully as it copies your data. Copies in the vault remain immutable and logically air-gapped, ready to restore even when the primary region is having a bad day.
What drives the cost difference against native backup?
Capture and storage. Eon backs up forever-incrementally and deduplicates across the whole estate, so each backup adds only what changed since the last one. The company in this story modeled 20 to 30% savings against its native Google Cloud backup spend over three years.
