On-prem backup tools fail in the cloud because they assume things the cloud doesn't provide: fixed capacity, fast mutable block storage, long-lived hosts, and free I/O. The cloud is elastic and ephemeral, its object storage is slow and immutable, and every read and write is billable. So the agent-and-appliance model fights the environment instead of running on it, driving up cost, widening the attack surface, and leaving multi-cloud coverage gaps that only surface during a restore.
Why do agents add risk and complexity in the cloud?
Agents add risk because they depend on long-lived credentials and constant patching, and they break because cloud hosts don't live long enough to run them. On-prem vendors traditionally relied on per-host software agents, small applications installed in the I/O path to copy data to a media server.
The same model breaks in the cloud. It contradicts the nature of autoscaling groups, throwaway nodes, and immutable images. New virtual machine (VM) instances spin up instantly, and containers live for only a few seconds, never staying long enough to transfer data for backup.
Cloud teams also have to manage AMIs, marketplace images, VM templates, and container layers to keep agents up to date. Any pitfall, a forgotten patch, a kernel that's out of step, or a customized image that's drifted from the approved baseline, creates a vulnerability that only surfaces during a recovery drill.
Agents also depend on credentials. That means long-lived credentials, open ports and daemons with elevated privileges, and third-party components, all of which widen the attack surface and, when exploited, hand attackers a high-value foothold.
Agent: A piece of backup software installed on each host or VM, running in the data path to copy data out. In the cloud, agents have to be patched across every image and depend on standing credentials, which adds operational load and attack surface.
What does a cloud-first alternative look like?
A cloud-first backup runs on the cloud provider's APIs rather than on software installed on every host. One service talks directly to the snapshot and replication endpoints in AWS, Azure, and Google Cloud.
Going agentless removes the ports, the fleet-wide patch cycles, and the sprawling credential stores. When new resources come online, the system adds them automatically through API-based auto-discovery, so coverage keeps pace with change instead of waiting on a runbook.
Agentless backup: A backup approach that uses the cloud provider's native APIs rather than per-host software. No agents to install or patch, no inbound ports, and continuous discovery of new resources.
Can backup appliances scale in the cloud?
Not well. A backup appliance is a specialized, all-in-one device, and its throughput and metadata capacity are fixed. Scaling demands adding and reconfiguring boxes, with no elastic fan-out, so it lags dynamic cloud workloads.
Both physical and virtual appliances are limited in throughput and metadata handling. Whenever you hit an appliance's ceiling, a mini-project pops up: buy a new unit, reshuffle schedules, re-wire storage targets. Meanwhile, the rest of your cloud environment auto-scaled hours ago.
A cloud-native backup and recovery service treats storage as an elastic service that stretches on demand. When demand spikes, workers fan out horizontally; when load eases, they shrink back to baseline. Storage scales on its own, so you're never bottlenecked by CPU or rack size. That elasticity holds RPO/RTO steady as backups scale.
Why do virtual backup appliances inflate cloud costs, and what can you do about it?
Virtual appliances inflate cloud costs because they are billed as always-on VMs, and the cloud charges for storage operations that the old model treated as free. Cloud storage doesn't behave like the disk these tools were built for.
On-prem storage is fast and mutable: you write at the block level, and I/O is effectively free once you've provisioned capacity. In the cloud, object storage is slow, runs over HTTP, and is immutable, so every change means a whole-object write, and every read and write is a billable operation. Managed services hide their underlying storage entirely, so a tool built to mount a volume and copy blocks has nothing to grab onto. Appliance-based backup ports bring the wrong assumptions into an environment that charges for all of them.
When legacy backup providers adapt to the cloud, they ship their appliances as virtual appliances that run as always-on VMs, consuming compute and storage even when no jobs are running. Meeting peak demand means adding more always-on VMs and licenses, so costs rise during the spike and persist afterward, unlike elastic, API-driven services that scale back toward zero when idle.
Virtual appliances increase cloud costs primarily due to:
- Idle runtime: Virtual appliances consume vCPU, memory, and storage 24/7, even when no backup jobs are running.
- Extra components: Network proxies, catalog databases, and load balancers all add fixed costs to your total bill.
- Licensing vs. cloud scalability: Per-appliance or per-feature licensing increases spend as you add instances.
- Traffic charges: Egress and cross-region transfers create unpredictable cost items.
The bill compounds quietly. One Eon customer finding made this concrete: writes into S3 Glacier IR alone made up roughly 75% of their annual storage cost, which was spend that stayed invisible until someone went looking.
To get cloud spend under control, alongside the broader cloud backup best practices that apply across your estate:
- Use cloud-first backups with global deduplication, compression, and off-peak scheduling.
- Use real-time scalability to add workers for spikes and park them when idle to avoid unnecessary fees.
- Use a cloud backup cost explorer (by tenant, account, region, and policy) to find waste and tune cost while holding RPO/RTO.
NETGEAR did exactly this. Moving from a legacy provider to a cloud-first model cut their backup storage costs by 35% and reduced a 10TB SQL Server recovery from roughly 24 hours to under three hours.
How do security gaps multiply in the cloud, and how do you prevent them?
Security gaps multiply because a single backup misconfiguration can cascade across accounts, subscriptions, and regions, widening the blast radius of an attack. These are a few common on-prem vulnerabilities and how to close them.
Agents and appliances widen the attack surface. Long-lived credentials, open ports, and third-party components create new vulnerabilities. CVE-2023-27532, a 2023 Veeam Backup & Replication flaw, exposed stored backup credentials via an unauthenticated API, a clear example of how legacy backup software can become a weak point in a cloud environment.
Flat trust and over-permissive IAM. Broad service permissions and an all-powerful admin role violate least-privilege principles and make auditing harder.
Catalogs and metadata as targets. Ransomware groups now actively turn off snapshots, delete catalogs, and modify retention policies in legacy backup systems. NotPetya's 2017 sweep through Maersk showed how quickly a self-propagating attack can take out an entire estate, including recovery infrastructure. If lost or tampered with, identity stores and backup catalogs are single points of failure in legacy designs.
Change and drift. New accounts and regions come online faster than manual runbooks can keep up with, leaving blind spots that no one sees until a restore fails.
Best practices to close these gaps:
- Implement identity-first controls: least-privilege roles, just-in-time (JIT) access, short-lived credentials, and dual control for destructive operations (deletes, retention edits, key rotations).
- Create logical air gaps: store backup data and catalogs in separate accounts and projects with separate encryption keys.
- Minimize exposure: use backup services that aren't exposed to the internet, turn off private endpoints, remove inbound ports, and use agentless or API-first paths.
- Centralize evidence: generate role mappings, drift reports, access logs, and recovery attestations to verify posture.
Do these, and your backup serves as a ransomware-resilient layer that still recovers cleanly even when a breach occurs.
Why does multi-cloud complexity break legacy models?
Multi-cloud breaks legacy models because each platform has its own API structures, identity models, service limits, and failure zones, and per-cloud tooling can't reconcile them. Run legacy tools across all of them, and you get duplicated policies, separate runbooks per cloud, and limited visibility. Basic global questions about coverage, RPO, and retention turn into manual administrative work.
Legacy backup models aren't built for multi-cloud backup management because of:
- Inconsistent APIs and features: small differences between providers make backup and restore unpredictable and drive policy drift.
- Identity model mismatches: enforcing least privilege uniformly across clouds is hard, so teams fall back on overly broad roles.
- Manual scripts and runbooks: per-cloud scripting adds operational load and human error.
- Uneven scale and limits: provider-specific quotas and failure domains hide weaknesses until a surge or failure exposes them.
Closing these gaps requires a unified multi-cloud backup solution that connects to native provider APIs through a single console for posture, coverage, and recovery management.
Cloud backup posture management (CBPM): Continuous monitoring and enforcement of backup coverage, policy, and recovery readiness across cloud accounts and providers, the backup equivalent of posture management for security. Replaces per-cloud dashboards and manual runbooks with one authoritative view.
What should a cloud-first backup look like?
A cloud-first backup is agentless, elastic, secure by design, and managed across clouds from one place. The capabilities that matter:
These add up to shorter backup windows, faster and more reliable restores, simpler operations, and a risk posture that holds up against current threats.
Where Eon fits
Eon is a cloud-first backup built the way the cloud actually works: agentless, API-first, and elastic, with no appliances to run and no agents to patch. It connects via a read-only IAM role, auto-discovers and classifies resources across accounts and clouds, and automatically applies policy through CBPM, so coverage keeps pace with change rather than waiting on tagging or runbooks. Recovery is granular, down to the row and file, so you restore what you need without a full-snapshot rollback.
SoFi replaced a snapshot-heavy setup across five AWS regions and cut recovery from a full day to minutes, with over 100% ROI in the first year. The point isn't that Eon is a cheaper appliance. It's a different model.
There's a second payoff most backup tools can't offer. The data Eon ingests lands in open formats like Apache Parquet and Iceberg, which means your protected estate becomes queryable for analytics and AI with no separate ETL project. The same platform that protects your data turns it into something you can use.
See how cloud-first backup affects your costs, recovery time, and coverage. Request a demo of Eon.
FAQ
Can I just run my existing backup software on cloud VMs?
You can, but you inherit every on-prem assumption it was built on: agents to patch, appliances billing 24/7, and per-host licensing, all running in an environment that charges for idle compute and every storage operation. It works, expensively, and it still leaves the ephemeral and managed-service workloads uncovered.
What's the difference between agent-based and agentless backup?
Agent-based backup installs software on each host to copy data out, which means patching and standing credentials on every machine. Agentless backup uses the cloud provider's APIs instead, so there's nothing to install, no inbound ports to open, and new resources are discovered automatically.
Do managed cloud databases like RDS need a different backup approach?
Yes. Managed services don't expose the underlying storage or filesystem, so there are no backup files for a traditional agent or scanner to reach. Protecting them requires an API-based approach that works with the service's native snapshot and change-capture mechanisms.
Are immutable backups enough to stop ransomware?
No. Immutability prevents a backup from being altered, but it doesn't indicate whether the data inside was already corrupted or encrypted before the copy was made. You also need detection that can verify a recovery point is clean, and recovery granular enough to restore only the unaffected data.
What is CBPM?
Cloud backup posture management continuously monitors and enforces backup coverage, policy, and recovery readiness across accounts and clouds. It answers the questions that per-cloud dashboards can't: what's protected, how long it takes, and how fast you can get it back.
How is cloud backup cost different from on-prem?
On-prem, you pay once for provisioned capacity, and I/O is effectively free. In the cloud, storage is billed continuously, and every read and write is a separate charge, so a tool that moves and rewrites data inefficiently runs up a bill that's hard to see until you attribute spend by account, region, and policy.
