Resources

Over the last year, I’ve had dozens of conversations with companies that are “doing AI.” They’ve launched pilots, experimented with models, and invested heavily in tools – an average of $400k this year. And yet, many of these organizations struggle to demonstrate real impact or articulate a clear ROI. In fact, by the end of 2025 at least 50% of generative AI projects were abandoned after proof of concept, in part due to poor data quality. 

I’ve seen this pattern before. 

When cloud adoption took off a decade ago, moving workloads wasn’t the hardest part. The real challenge was everything that followed: reliability, disaster recovery, cost control, operational efficiencies and organizational realities. That delta between early excitement and lasting value is where most technology initiatives struggle and it is what determines their success and impact. 

AI is no different.

In 2026, business leaders are occupied with everything from trying to predict the next outage to which AI model will win the compute wars, but those are less important than the durable moat you already own: your data. 

Companies struggle to implement AI effectively because systems are built on top of data foundations that were never designed to support them. The issue isn’t a lack of ambition or investment, it’s the underlying infrastructure. 

If cloud migration is like performing a heart transplant surgery on a patient while they are running a race, AI enablement is rewiring that runner’s nervous system into a supercomputer, mid-race. Making that leap requires companies to be able to access, trust, and actually use their data. AI can’t deliver value without clean, well-governed data flowing.

The Same Problem, Showing Up Again

When I founded CloudEndure in 2012, cloud migration was the urgent problem teams were trying to solve. I spent years working directly with customers and sitting down with infrastructure teams during migrations, outages, and recovery events. Data was technically protected, and that was enough at the time. 

Existing backup systems did their promised job in storing copies and aiding audits, but they locked data away and made it difficult and costly to access, reuse, or analyze. Every new initiative from analytics to disaster recovery started by rebuilding the same pipelines from scratch. Data was fragmented across accounts, regions, and providers, and every team paid a premium just to get access to information they already owned. 

Today, AI has exposed that problem again. Most AI efforts don’t fall short for a single reason, but again and again, data emerges as a key constraint. Even strong models can’t deliver value when the underlying data is scattered, incomplete, or locked in systems never designed for analytics or reuse. When data can’t move easily, AI stalls. The runner needs nutritious food.

Why We are at a Turning Point

In 2026, the need for accessible AI-ready data stops being a background infrastructure problem and becomes a center-stage, strategic one.

Data volumes are growing faster than teams can realistically manage with legacy approaches, and expectations for AI-driven insights are skyrocketing. At the same time, failures and outages – whether caused by cloud disruptions, security incidents, or operational errors – are more frequent and more expensive. With operational downtime costing an estimated $2M per hour, companies saw massive annual losses from IT outages 2025.

The way an organization stores and accesses its data determines what it can and can’t do. Teams that modernize their data foundations gain flexibility and can experiment with AI using data that’s already governed, compliant, and available.

On the flipside, teams that don’t modernize will stay stuck. They’ll run pilots that never reach production and duplicate efforts across departments. Critically, they open themselves up to costly disruptions and discover the data they need isn’t accessible when it matters most.

Looking Ahead: Data is Your Moat

I’m seeing a clear pattern: teams that get real results make a few key shifts. They treat data infrastructure as part of their operating system, align storage with business needs like speed and resilience rather than just archival safety, and confront the gaps in legacy systems where data exists but is effectively unusable.

I left AWS and co-founded Eon because this problem never really went away, it just evolved. I’ve learned that backup data becomes something companies store for emergencies instead of something they can use every day. 

Solving this inefficiency is now unavoidable. Not because AI is new, but because it finally forces a hard look at the foundations underneath it. Executives are recognizing that buried backups aren’t just lost opportunities – they’re wasted investments, until companies adopt systems that make them truly accessible.

What does “enterprise-grade” cloud backup mean?

Enterprise-grade backup is not “we can store copies.” It’s about recovering quickly and cleanly at scale, without turning cost, compliance, and operations into a constant fire drill.

An enterprise-grade cloud backup solution should be able to:

1. Centrally manage and automate backup across multiple clouds, accounts/projects/subscriptions, and regions.
2. Restore reliably under pressure, not just in a demo.
3. Provide immutability, isolation, and auditability as table stakes.
4. Keep storage growth and operational overhead predictable over time.
5. Integrate with existing tools (identity, ticketing, SIEM, reporting) so backup ops fit your workflows.

If it can’t do this in your real environment, it’s not enterprise-grade.

What types of enterprise cloud backup solutions exist?

Most vendors say they’re “cloud-ready.” What matters is what you get by default, and what turns into extra tools, extra work, or extra cost later.

In practice, those options fall into four categories:

1. Cloud-native backup platforms (cloud infrastructure + data)
2. Hyperscaler-native tools
3. Orchestration layers for native backups
4. Legacy and hybrid platforms

Why do modern teams prefer cloud-native backup platforms for cloud infrastructure + data?

Cloud-native backup platforms emerged because they fit how cloud teams actually work: API-driven estates, distributed ownership, fast change, and lots of environments.

• They reduce operational drag: fewer (or no) appliances, proxies, or backup servers to size, patch, upgrade, and secure.
• They make governance possible at scale: one place to see coverage, enforce policy, and catch drift across orgs, regions, and services.

Within this category, the real differences tend to show up in three places:

• Automated posture management: Cloud Backup Posture Management (CBPM) how well the platform discovers new resources, enforces policy, and flags drift without relying on manual tagging.
• Granular recovery in real life: whether file/object/database recovery is practical day-to-day, not just “supported” in edge cases, so incidents aren’t all-or-nothing.
• Data usability without restores: whether teams can search and query protected data for audits, investigations, analytics, and AI without spinning up full restores first.

What are hyperscaler-native tools best for?

Hyperscaler-native tools are built into a single cloud (AWS, Azure, or Google Cloud) and are typically snapshot-first for backup and restore.

Where enterprises outgrow them:

• Governance gets messy across many accounts/projects/subscriptions and regions.
• Most rely on snapshots, which can be durable, but often aren’t optimized for long-term retention economics or everyday incident recovery.
• Recovery and security workflows are split across services, vault types, and settings.
• It’s easy to turn on, but at enterprise scale, you often discover extra work: additional components, the “right” vault or storage setup to unlock key restore options, and extra policy setup to roll backups out consistently across accounts/subscriptions/projects.

What are orchestration layers for native backups best for?

These platforms standardize policies, scheduling, and reporting on top of hyperscaler snapshots.

Examples include N2WS; the key point is you’re still running snapshot-based backups, just with centralized scheduling and reporting.

Where they tend to break down at scale:

• Still snapshot-based: to get specific data, teams often end up restoring whole snapshots/volumes first.
• Limitations show up service-by-service (coverage, recovery granularity, restore paths).
• Cost visibility can stay fragmented because you’re still paying through underlying cloud mechanics.
• “Centralized control” can still mean stitching together multiple backup behaviors under one UI.

When do legacy and hybrid platforms still fit?

Legacy and hybrid suites can be a good fit when you have a meaningful on-prem footprint and legacy workloads that need broad coverage.

Where cloud complexity exposes its limits:

• Customer-managed infrastructure (nodes, proxies, appliances) that must be sized, patched, upgraded, and secured.
• Recovery requires restoring to find data and is infrastructure-heavy, which is a mismatch for cloud incidents where teams need targeted fixes fast.
• Cloud scale turns the backup platform itself into another distributed system that you have to operate.
• Layered licensing and add-ons can balloon spend as coverage, retention, and security needs expand.

High-level comparison (by approach)

What should you test when evaluating enterprise cloud backup solutions?

Use these as hands-on evaluation tests. The goal is not “does it exist,” it’s “does it hold up under real conditions.”

1) Can it meet your RTO/RPO targets on realistic workloads?

Validate recovery steps, time-to-first-data, and failure modes on representative workloads.

2) Can you get a cost model you can actually sanity-check?

Get a clear breakdown of what drives cost (storage growth, copies, indexing/search, scanning, cross-region/cross-account requirements, and required infrastructure). Costs will still be estimates, so make sure the vendor explains what inputs they used and how sensitive the model is to retention, change rate, and restore/testing patterns.

3) Does it support multi-cloud operations without adding more moving parts?

This is especially important if you require multi-cloud backups and a single operating model for policy, recovery, and reporting.

4) Can it keep you continuously compliance-ready?

Test retention enforcement, isolation boundaries, auditability, and whether you can prove coverage without a quarterly scramble.

5) Can it restore meaningful workloads under pressure?

In a PoC or lab test, run restores that reflect your real world (encryption, size class, service type, cross-account/region patterns). Validate how many steps it takes, what needs to be pre-provisioned, and whether recovery stays predictable as the environment grows.

6) Does it support granular recovery for real incidents?

Granular recovery is what saves you during partial data loss, accidental deletes, and corruption. File-, object-, and database-level recovery should be practical, not a special project.

7) Is ransomware resilience built in, or assembled?

As part of its ransomware package, backup solutions should have immutability and isolation as the baseline, plus detection signals and the ability to recover from known-clean points without resorting to heroics.

Which operating models do today’s vendors use?

Instead of a checkbox grid that goes stale, use a shortlist lens based on what the platform is designed to protect first:

• Cloud-native backup (cloud infrastructure + data): Eon
• Hyperscaler-native: AWS Backup, Azure Backup, Google Cloud native mechanisms
• Orchestration layers: Snapshot policy/scheduling/reporting tools (examples: N2WS and similar products)
• Legacy/hybrid suites: Veeam, Commvault, Rubrik, Cohesity

Cloud-native backup for cloud infrastructure + data

Eon

Best for: Cloud-first enterprises protecting production infrastructure across AWS, Azure, and Google Cloud that want fast, precise recovery, strong ransomware resilience, predictable cost behavior at scale, and direct access to backup data without making full restores the default.

Eon is a cloud-native backup platform for cloud infrastructure + data built to remove customer-run backup infrastructure while improving day-to-day recovery, governance, and cost control.

It’s built for protecting cloud infrastructure and designed to make protected data useful after it’s backed up, not just stored.

Unlike restore-first tools, Eon is built so teams can find, inspect, and reuse protected data for audits, investigations, analytics, and AI workflows, without spinning up full restores first.

What to validate in a real-world test:

• Recovery under pressure: targeted recovery for real incidents (file/object/database-level), not just full restores
• Cost behavior: how storage grows over time and whether the platform reduces long-term overhead
• Governance: continuous discovery and policy enforcement without relying on manual tagging
• Ransomware resilience: immutability and logical isolation as baseline, plus clean recovery workflows
• Data usability: ability to search and query protected data directly for audits, investigations, analytics, and AI (turn backups into a live data lake)

Table stakes, baseline, and built in: compliance-grade retention beyond 35 days, immutability, logical air-gapped backups, cross-region/account recovery patterns, RBAC, and audit logs.

Legacy/hybrid backup platforms

These can be a fit for hybrid estates with significant on-prem and legacy workloads. For cloud-first teams, the key question is what you’re signing up to operate.

What to validate (Veeam, Commvault, Rubrik, Cohesity):

• What customer-managed infrastructure is required, and how it scales.
• Whether granular recovery is consistent across cloud-native workloads.
• How costs accumulate across licenses, infrastructure, and cloud consumption.
• Whether policy and reporting keep up with constant cloud change.

Hyperscaler-native cloud backup

These tools are often the default starting point in a single cloud. At enterprise scale, friction usually shows up in governance, operating model complexity, and cost transparency.

Azure native backup: what should you check?

Validate:

• Which vault type you’re using, and which resources it actually governs.
• How policies roll out across many subscriptions and regions, and how you keep them consistent.
• How cross-region recovery behaves in practice, and what configuration choices enable or restrict it.
• Whether any workloads require agents/extensions, and what that means operationally.

Google Cloud native mechanisms: what should you check?

Validate:

• Whether centralized backup requires additional operational components (appliances/connectors).
• Which services share the same backup operating model vs. require separate approaches.
• How you handle analytics and object storage protection, where “versioning/replication” patterns may not behave like true backup workflows in incidents.

AWS Backup: what should you check?

Validate:

• Whether you’re relying on multiple backup mechanisms across services, and how you prove coverage.
• How isolation and recovery behave across accounts and regions (including copy requirements for restore).
• How optional capabilities like indexing, scanning, or specialized vault workflows affect cost and operations.
• Whether your database model is snapshot-first, PITR-first, or layered (many teams use native PITR for short windows, then another platform for longer retention and cyber recovery).

Case studies: what “right fit” looks like

NETGEAR

NETGEAR moved from an appliance-heavy legacy platform to Eon’s SaaS-managed approach, cutting operational overhead and improving recovery speed while lowering backup storage costs by 35% and improving restore speed by 88%.

SoFi

SoFi standardized backup operations across regions and improved visibility into posture and spend, reporting 100%+ ROI and improved resilience.

What’s next?

If you’re actively evaluating platforms, the fastest next step is a hands-on evaluation of real recovery, real governance, and real cost drivers. See how Eon performs.

FAQs

What are the main types of cloud backup solutions today?

Most enterprise options fall into four categories:

1. Cloud-native backup platforms: cloud infrastructure + data first, designed for cloud operating models, with varying levels of automated posture management, granular recovery, and data usability
2. Hyperscaler-native tools: built into AWS, Azure, or Google Cloud, usually snapshot-centric
3. Orchestration layers: standardize policy/scheduling/reporting on top of hyperscaler snapshots
4. Legacy/hybrid suites: built for on-prem first, extended into cloud later

The practical difference is what you have to operate, how recovery works at scale, and how costs behave over time.

What should I prioritize when choosing an enterprise cloud backup solution?

Prioritize what fails first at scale: recovery under pressure, governance across accounts and regions, ransomware resilience, and long-term cost behavior.

Do I need multi-cloud backup if I’m “only” on one cloud today?

Maybe not today. But many enterprises still need a consistent operating model across accounts, regions, and teams. If your company expects cloud expansion, M&A, or portability requirements, validate early.

Are snapshots enough for enterprise backup?

Snapshots are a useful building block, and many tools rely on them. The question is what comes next: how you manage governance, retention economics, ransomware resilience, and granular recovery at enterprise scale.

When is a legacy platform still the right choice?

When you have a significant on-prem footprint and legacy workloads that need broad coverage. If you’re cloud-first, validate how much infrastructure you’ll be running and how restore workflows hold up in real incidents.

When is Eon not the right fit?

Eon is designed for cloud infrastructure backups. If your primary need is endpoint/laptop backup or traditional on-prem backup, you may want tools built specifically for those environments.

S3 Versioning is a feature that lets you roll back deletes and overwrites. It’s not designed to carry your disaster recovery or cyber recovery plan.

Versioning is great for “oops” moments. But if the scenario involves ransomware, compromised credentials, region-level availability issues, or large-scale recovery, versioning alone won’t give you the isolation and recovery motion you actually need.

Backup isn’t “can I retrieve a thing.” Backup is “can I recover what matters, fast, safely, and predictably, when the situation is ugly.”

What S3 Versioning is (and what people mean when they say “backup”)

S3 Versioning keeps multiple versions of the same object in a bucket. If someone overwrites a file, uploads a bad artifact, or deletes something, you can restore a previous version.

Also: if your goal is actual backup for S3 (not just more versions inside the same bucket), it’s worth understanding the difference between “versioning” and an S3 backup strategy.

When teams say “backup,” they usually mean:

• Isolation from compromised identities and misconfigurations
• Immutability you can rely on during an incident
• Recoverability at scale, with workflows that aren’t a pile of scripts
• Auditability and retention controls that stand up in real environments

Versioning can help you roll back a mistake. It is not built to carry your incident or cyber recovery plan.

The first gap: versioning doesn’t change the blast radius

Versioning doesn’t move data into a safer failure domain. All versions typically share the same:

• AWS account boundary
• IAM access plane
• Bucket policy posture
• Region (unless you add replication)

So if something goes wrong in that same blast radius, versioning doesn’t magically become a backup.

Where this shows up in practice:

• Compromised credentials: an attacker with permissions can delete versions, change policies, or trigger conditions that remove recovery options.
• Misconfiguration and drift: a single bad change can impact the bucket, the versions, and your ability to access them.
• Regional incidents: if versions only exist in one region, you’re still betting your recovery on that region being available.

Yes, you can reduce this risk with tight IAM, MFA Delete (where applicable), Object Lock, replication, and/or cross-account patterns. But now you’re assembling a backup system out of multiple S3 features, and you still don’t get orchestrated recovery.

The failure mode isn’t “S3 didn’t keep versions.” It’s “we couldn’t confidently recover the right data fast enough without making the incident worse.”

The second gap: it’s not about “instant discovery,” it’s about retention and findability

A common question is whether versioning only helps if you notice right away. The real answer: it’s not about recency, it’s about whether the right versions still exist and whether you can find them.

Here’s what determines whether versioning will save you in a rollback scenario:

• You can only roll back to versions that still exist. If versioning has been enabled for months (or years), and you haven’t expired noncurrent versions, you can restore older versions long after an overwrite or deletion.
• It gets harder to find the right version as time passes. S3 will keep versions, but you may be sifting through lots of versions across prefixes and buckets. Without strong naming discipline, inventory, or tooling, older recovery becomes “possible, but painful.”
• If versioning wasn’t enabled at the time of the incident, it won’t help retroactively. You only get versions from the point you enabled it onward.
• If lifecycle rules expire noncurrent versions (common for cost control), older versions may be gone. That’s the tradeoff: cost control vs. deep rollback history.

So versioning can work weeks later. It’s just not a clean, predictable recovery mechanism once scope gets big.

“We also use CRR.” Replication still doesn’t equal backup

Cross-Region Replication (CRR) is a valuable availability feature. It copies objects to another region.

But CRR doesn’t turn versioning into backup for two reasons:

1. CRR can replicate bad outcomes, too.
   Overwrites, delete markers, and encrypted/corrupted objects can replicate, depending on how you’ve configured replication.
2. You still don’t get recovery orchestration.
   You’re still stitching together recovery by bucket, prefix, object, and version. During an incident, that becomes slow, error-prone, and hard to validate.

Replication helps with resilience, but it doesn’t replace an actual backup strategy.

Availability features help you stay up. Backups help you get back even when trust is broken (credentials, configuration, data integrity).

“What about Object Lock?” Helpful, but still not the whole story

Object Lock can provide immutability if configured correctly. That’s a strong control.

But it doesn’t solve:

• Setup drift across many buckets/accounts
• Org-wide coverage guarantees (who’s protected vs who isn’t)
• Recovery workflows at scale
• Ongoing posture management and reporting

Immutability is necessary, but it’s not enough on its own.

The cost trap: noncurrent versions grow quietly

Versioning can become an unplanned storage multiplier.

Overwrites typically create a full new object version. For large objects updated frequently, noncurrent versions add up fast. Many teams only notice after costs compound, because version growth is gradual and spread across many buckets.

That’s why versioning almost always needs lifecycle rules. And lifecycle rules almost always reduce your rollback window.

The tradeoff is unavoidable: either you pay for long history, or you prune history and shrink your recovery options.

What to do instead: treat versioning as a revert then add real backup controls

If you want something that holds up during ransomware, access compromise, or large-scale recovery, you need controls versioning doesn’t provide on its own:

1) Isolation

Backups should live in a separate blast radius. Account-level separation (separate backup accounts/vault accounts) is a common approach. If the primary environment is compromised, recovery assets shouldn’t be in the same line of fire.

2) Immutability that’s baseline

Immutability should be built in and consistently enforced, not something that varies bucket-to-bucket or team-to-team.

3) Recovery you can execute

You want recovery workflows that are repeatable under pressure:

• Testoring specific objects/prefixes safely
• Proving what’s recoverable (and what isn’t)
• Restoring at scale without scripting your way through a crisis

At minimum, an enterprise cloud backup platform should give you the boring-but-nonnegotiable stuff by default: compliance-grade retention beyond 35 days, immutability, logical air-gapped backups, cross-region/account recovery, RBAC, and audit logs.

The goal isn’t “more controls.” It’s fewer bets. You shouldn’t have to discover during an incident that recovery depends on one bucket policy change from six months ago.

How Eon compares to S3 Versioning

When versioning is the right tool (and when it’s not)

Use versioning for:

• Accidental deletes and overwrites
• Quick rollbacks after a bad deployment
• Basic protection against day-to-day mistakes

Don’t rely on versioning as your backup strategy if you need:

• Cyber recovery confidence
• Isolation from compromised access
• Large-scale restore readiness
• Consistent posture across many accounts/teams

S3 Versioning is useful. It’s just not backup.

Treat it like a revert option, then build a real backup strategy around isolation, immutability, and recovery workflows you can prove in practice.

For a while, cloud backup was a set-it-and-forget-it safety net. The mindset feels efficient, and for a long time, it kind of worked.

But since today’s multi-cloud and hybrid environments don’t stand still, a backup plan that depends on static rules and manual tagging breaks quietly, then fails loudly when a restore matters most.

Even when nothing breaks, passive backups can turn into a liability. For example:

• Costs grow without a clear explanation of why. 
• Retention drifts out of compliance. 
• Audit requests turn into fire drills. 
• Data that could support analytics and AI stays sealed away in cold storage, expensive and unused.

A cloud backup strategy has to perform every day, not only during disaster recovery.

So, how can you improve your cloud backup strategy?

Cloud-first teams tend to see the biggest gains from five changes. Each targets a failure that occurs repeatedly in real-world environments.

1. Control backup costs, not just recovery outcomes

Control costs by reducing redundant copies and making retention intentional.

Snapshot-based backups for small changes, duplicate protection across tools, overly long retention, and “just in case” full-environment backups can multiply spend faster than the value you get back. Teams also struggle because many backup artifacts feel opaque, so cleanup turns into guesswork.

A cost-aware backup strategy usually includes:

• Incremental backups: capture only workload changes, so you stop paying for repeated full copies of mostly identical data.
• Discovery, classification, and inventory: automatically identify what’s protected, what’s missing, and how each workload maps to retention policies, so teams can right-size coverage without guessing.
• Searchable backups: quickly find the backup set you need (by workload/account/region/time/policy) without starting a full restore just to figure out what’s inside.
• Compressed, deduplicated backups: cut storage footprint across versions and retention windows, helping control storage growth and retrieval overhead.

Many cloud snapshot systems already implement incremental behavior under the hood for certain services. However, costs still rise when teams keep too many restore points, copy backups across regions and accounts without guardrails, and run overlapping tools against the same workloads. Inventory and retention discipline usually matter as much as the copy mechanism.

Example: NETGEAR reported 35% lower backup storage costs and 88% faster recovery for a mission-critical 10TB SQL Server database after switching to Eon.

2. Recover what you need without restoring everything

Pick granular recovery over full restores, and prove it works with restore testing.

Many snapshot-based approaches treat backups like sealed boxes: backups are stored as opaque artifacts that typically require a restore workflow to access specific files, objects, or records. When an incident hits, teams end up rehydrating far more than they need, stretching downtime and adding storage and compute overhead. When an incident hits, teams end up restoring entire environments even when they only need a small dataset, which stretches downtime and adds storage and compute overhead.

Granular recovery flips the workflow. Teams pull back only what they need, such as a file, an object, or a specific table, instead of rehydrating an entire environment. Database nuances matter here: for many engines, “granular” often means restoring to a scratch environment and then exporting the table or rows you need, rather than injecting a single table directly into prod.

Restore testing makes the whole plan real. Schedule test restores and treat failures as production issues, because IAM drift, KMS permissions, network rules, and schema changes often break restores long before anyone notices.

3. Stay audit-ready without living in spreadsheets

Automate policy enforcement so coverage and retention follow rules rather than memory.

Manual backup plus static retention policies fail in dynamic cloud environments. When a backup plan relies on humans to tag resources correctly, it also depends on them to remember every new service, account, and workload that appears. You know how that ends: some data gets over-retained, inflating costs, while other data gets missed entirely, creating compliance and operational risk.

Automated policy enforcement fixes the failure mode. Retention and placement rules apply dynamically based on resource context, metadata (including tags where available), and policy requirements. New workloads inherit compliant policies automatically, and aging backups get pruned according to business and regulatory requirements.

Cloud Backup Posture Management (CBPM) usually sits on top of that approach. CBPM turns “backup management” into continuous posture checks across clouds, including:

• Coverage reporting across environments and teams
• Drift detection when backups fall out of policy
• Audit-ready records for backup success, failures, and access events
• A single place to answer “what is protected and for how long”

Eon uses CBPM to surface coverage gaps and policy drift across accounts and clouds, without relying on perfect manual tagging.

4. Keep backups resilient during a ransomware incident

Assume attackers will target backups, then design for immutability and isolation.

Resilient teams assume that production access paths will fail eventually, whether due to credential compromise, misconfigurations, or human error. Attackers know backups represent the fastest route to recovery without paying, so they go after recovery data early.

Two controls make the biggest difference:

• Immutable backups that attackers cannot alter, encrypt, or delete during the retention window.
• Logically air-gapped backups that isolate recovery assets from operational environments, production credentials, and the access paths attackers use to reach production.

Isolation needs real operational guardrails: separate roles, tight admin paths, and strong controls around who can change retention or delete protected data. Key governance matters too. If attackers gain broad admin rights or key management control, they can still break recovery workflows even when backup copies exist.

5. Turn backups into data your teams can actually use

Index and structure backup data as you capture it, then keep it readable and queryable in place.

If backups are only usable after a full recovery job, they do the minimum and still cost a premium. Teams pay for storage, then pay again when they duplicate data into a separate lake for analytics, investigations, or AI training.

A more helpful approach keeps backup data searchable and queryable without spinning up production systems or moving data through ETL pipelines. Platforms that store backup data in open, query-friendly formats, such as Parquet, and maintain table metadata, let teams query backup copies using their analytics engine of choice, without spinning up production systems or moving data through ETL pipelines.

Eon follows this pattern by exposing backup data in open formats like Parquet and publishing Iceberg/Delta-style table metadata, so analytics tools can query historical copies without ETL pipelines.

That zero‑ETL approach turns backups into a practical source of historical data for investigations, reporting, and model development, long before disaster recovery becomes relevant. Teams also reduce duplication between “backup storage” and “analytics storage,” which often accounts for a large share of data spend.

Why should you improve your cloud backup strategy?

The five practices above deliver real wins in a few common enterprise scenarios.

Reduce backup sprawl and runaway costs in elastic environments

Backups often become one of the largest and least controlled data footprints in the enterprise. Opaque snapshots encourage a “back up everything, keep it forever” mindset, and spend grows in ways nobody can explain.

Incremental capture plus searchable inventory changes the day-to-day workflow. Teams can right-size backups to what actually needs protection, remove redundant copies, and keep retention tied to policy rather than habit.

Accelerate analytics and AI using backup data

Legacy backups behave like black boxes, which means analytics teams can access only a thin slice of historical data. Pulling more usually requires expensive restores and ETL-heavy pipelines that slow experimentation.

Indexed, queryable backup copies stored in immutable object storage, often in open formats like Parquet, let teams run queries and AI workflows directly on historical backup data. Teams reduce ETL effort, expand analytical depth, and avoid adding another storage system for every new use case.

Improve governance with Cloud Backup Posture Management

Regulated teams face strict retention and data protection requirements. Traditional tools often rely on manual classification and policy enforcement, leaving teams unsure which resources are protected, which have drifted out of policy, and how to demonstrate controls during audits.

CBPM addresses the day-to-day pain. Teams get continuous coverage checks, drift detection, and audit-ready reporting that reflects how environments actually change across AWS, Azure, and Google Cloud.

Recover cleanly after ransomware or a major failure

A ransomware event compresses every decision into minutes. Teams can’t waste time debating whether backups are clean, accessible, and recoverable.

Immutable and logically isolated backups provide teams with recovery points that attackers can’t destroy. Granular recovery lets teams restore only the affected resources first, reducing downtime and limiting the scope of rebuild work.

Build backups that perform every day and under fire

Backups still support RTOs and RPOs. Cloud teams also rely on backups to keep spend predictable, keep audits calm, and give security teams a recovery path they can trust.

A stronger cloud backup strategy delivers:

• Faster restores without full-environment rebuilds
• Backup costs tied to real requirements, not sprawl
• Continuous compliance through policy enforcement and posture checks
• Recovery data that stays safe during ransomware incidents
• Backup data teams can query for investigations, analytics, and AI work

Resource-Level Tracking in Cost Explorer

We’ve upgraded Cost Explorer to give you a more granular view of your spend. In addition to grouping by resource type (like S3 or EC2), you can now drill down into individual resources. This allows for precise cost tracking per resource and per vault, even if a single resource is backed up to multiple vaults.

Snapshot Holds for Enhanced Data Protection

To protect a snapshot past its expiration for critical maintenance or compliance windows, you can now place and remove holds on snapshots. When a hold is active, the snapshot is retained indefinitely from deletion, or until the hold is explicitly removed.

Expanded database support: Aurora Global and Cloud SQL for PostgreSQL

We’ve expanded our multi-cloud resource discovery to include Amazon Aurora Global Database and Google Cloud SQL for PostgreSQL. These resources will now be automatically discovered and available for backup configuration.

Note: Existing RDS or CloudSQL backup policies will apply to these new resources automatically. If you do not wish to back them up, please refine your policy conditions to exclude them.

Granular recovery and S3 import restores for DynamoDB

Our restore capabilities for DynamoDB have become more flexible. Using the restore API, you can now restore DynamoDB table snapshots directly to existing tables. This eliminates the need to create new tables during a recovery process, streamlining your restoration workflows and maintaining configuration consistency.

Additionally, we’ve introduced an S3 import restore method that bypasses account-level Write Capacity Unit (WCU) limits. By staging data in a dedicated S3 bucket, we eliminate WCU consumption and significantly reduce recovery times. You can select your preferred method and customize index configurations within the revised restore interface.

High-frequency backups for EC2

For mission-critical workloads requiring low recovery point objectives (RPO), we’ve introduced 15-minute backup intervals for EC2 instances. You can now configure high-frequency backup policies to ensure your EC2 instances are protected with minimal time between backup windows.

Note: While these Eon snapshots are logically air-gapped, they do not get scanned or indexed. As a result, data-aware features like filesystem exploration and granular recovery are unavailable for high-frequency EC2 backups. To use these features, we recommend maintaining a separate daily backup policy.

Learn more

Want to learn more about Eon? Request a demo or follow us on LinkedIn to stay up to date on the latest developments. We will be publishing these product updates monthly moving forward.

Eon integrates with Amazon Redshift, allowing you to query database backup data in place.

Why use backup data for analytics?

Because backups already hold any critical data across the organization.

They include long-range context and consistent point-in-time versions that production systems rarely preserve. When that data becomes usable:

• You answer historical questions without rebuilding environments.
• You cut out redundant analytics copies and pipelines.
• You work from a single governed source of truth.
• You reuse the same datasets for investigations, validation, compliance, and BI.

What does it mean to query backups in Amazon Redshift?

It means backups are no longer expensive and useless. Instead, they form a rich data lake that already holds critical data, instantly ready for analytics or AI/ML workflows.

Eon stores database backups as deduplicated tables in Amazon S3. With the Redshift integration, those tables appear directly in Redshift as point-in-time datasets you can query immediately.

If you want to see how a table looked last week, validate a change, or compare before-and-after states, you query the backup itself rather than a rehydrated environment.

Key benefits of querying backups in Redshift

• Instant point-in-time analytics without waiting for restores
• No ETL pipelines or duplicate analytics clusters
• Trusted baselines for audits, investigations, and debugging
• Lower cost by eliminating redundant environments and copies
• Cross-cloud context via Eon’s unified catalog when needed

How the Redshift integration works

A simple, AWS-native flow:

1. Eon continuously stores backups as deduplicated Hive-partitioned tables.
   Eon introduces a modern backup format that consists of Hive-partitioned tables stored in Amazon S3.
2. You choose which backups to share with Redshift.
   Eon grants read-only access while preserving immutability and governance controls.
3. Redshift queries in place.
   Amazon Redshift discovers and queries the tables directly in S3.

The result: Redshift treats your backups as point-in-time datasets ready for immediate analysis.

What teams do with Redshift-queryable backups

Analytics and BI without rebuilds
Run Redshift queries on historical snapshots to validate changes, investigate incidents, or analyze trends without restoring anything first.

Faster audits and compliance checks
Search and query long-retained point-in-time data directly, instead of waiting on exports or restore jobs.

Operational insight and investigations
Backups provide a clean historical truth for debugging, root-cause analysis, and validating system behavior over time.

How Eon keeps backups usable and secure

Making backups queryable does not mean making them risky.

Baseline protections stay on by default:

• Immutable backups
• Logical air gaps
• Read-only analytics access
• RBAC and audit logs
• Autonomous Cloud Backup Posture Management (CBPM)

Analysts get governed access to historical truth. Security teams stay in control.

Want to see this live?
Get a demo, and we’ll walk you through Redshift-queryable backups end to end.

Switching to Eon gave us the cloud visibility and recovery speed we’d been missing for years.
‍
—Satish Nair, Sr. Manager IT, NETGEAR

About NETGEAR

NETGEAR is a global provider of networking and connectivity solutions with a growing AWS footprint across EC2 workloads and large SQL Server databases. As cloud adoption accelerated and new acquisitions expanded their environments, NETGEAR needed a unified, cloud-native approach to control costs, improve visibility, and shorten recovery times across the business.

The Challenge

After nearly eight years of using a legacy provider in a traditional data center environment, the shift to AWS exposed several limitations:

• Limited visibility into backup spend: Previous tools provided little transparency into actual backup costs or usage.
• Slow recovery: Instances larger than 10TB could take up to 24 hours to recover, significantly impacting recovery objectives.
• Operational overhead: Multiple components and moving parts increased both cost and management burden.
• Delayed improvements: Requests for critical features often went unanswered, slowing modernization efforts.
• Corporate cost pressure: Leadership mandated meaningful infrastructure savings and greater control over cloud spend.

Their previous solution wasn’t built for cloud scale, and visibility gaps made cost control and DR planning increasingly difficult.

Why Eon

Cloud-native from day one

NETGEAR chose Eon because it was purpose-built for cloud workloads rather than retrofitted from on-premise architecture, with the added goal of leveraging backup data as a backend data lake to generate insights using AI technologies.

Eon enables backups that reflect the way our cloud truly works—faster, more transparent, and easier to operate.

Real-time cost clarity

Eon’s Cost Explorer gave NETGEAR instant insight into spend by resource and application, eliminating the delays and inaccuracies of manual reporting.

Eon heard our requirements and mobilized the right team to deploy the solution, adding NETGEAR-requested features in days—flawlessly and without errors.

A simple, fast deployment

Eon integrated cleanly into their AWS environment. The same team that managed their previous tool deployed Eon in under a week with virtually no retraining.

The Solution

NETGEAR deployed Eon across its AWS workloads as part of a broader shift to a cloud-first backup strategy. With Eon, NETGEAR now benefits from:

• A cloud-native, agentless architecture aligned with AWS best practices
• Optimized recovery for large, business-critical databases
• Real-time spend visibility through Cost Explorer
• Automated coverage and posture monitoring aligned to Cloud Backup Posture Management (CBPM) principles
• Monthly cadence reviews covering usage, cost, and roadmap updates

The Results

35% reduction in backup storage costs

Eon’s storage model and automated policy management immediately reduced NETGEAR’s backup spend, helping them meet a company-wide cost mandate.

88% faster recovery for a 10TB SQL Server database

Recovery dropped from 24 hours to under three, strengthening their disaster recovery posture and reducing operational risk.

Cutting 10TB recovery from almost a full day to a few hours strengthened our confidence in our disaster recovery strategy.

Accurate, real-time cost visibility

Cost Explorer eliminated manual reporting and enabled chargeback by instance, application, and team.

Operational simplicity from day one

Deployment was quick, onboarding was minimal, and the team immediately gained clearer visibility and easier day-to-day management.

A partnership that accelerates innovation

The speed, transparency, and collaboration continued beyond deployment, giving NETGEAR confidence in both the platform and the team behind it.