Amazon Keyspaces (for Apache Cassandra) is a scalable, serverless, and Cassandra-compatible database service for highly available applications. For data protection, Amazon Keyspaces provides point-in-time recovery (PITR), which lets you restore a table to any second within the last 35 days into a new table. PITR also works for multi-Region tables when PITR is enabled on all replicas, and the source and destination use the same replicated Regions. PITR is optimized for recent operational rollback. Some teams need protection that reaches further: retention past the 35-day window, recovery outside the original operational footprint, and the ability to inspect historical data without first provisioning a full restore.
Some teams need a protection model that goes further still. They need to inspect or query historical table data without first restoring a full environment, classify what a table contains so that retention follows the data rather than the resource, and run those workflows across more than one data store. Eon, an AWS Partner, addresses these needs by combining agentless protection, policy-driven backup posture management, incremental backups, global deduplication, granular recovery, and direct access to backup data in open formats such as Apache Iceberg and Parquet.
In this post, you will learn where native Amazon Keyspaces protection fits, where Eon complements it, how the Eon backup and restore architecture works on AWS, and how to evaluate Eon for retention, investigation, and cross-source analysis use cases on Amazon Keyspaces.
Where Amazon Keyspaces protection fits, and where Eon complements it
Native Amazon Keyspaces protection is the right starting point for most workloads. PITR covers operational rollback within the last 35 days, restoring a table to any second in that window into a new table. Many teams meet their recovery requirements with PITR alone, and you should evaluate it first.
The following table summarizes when Amazon Keyspaces PITR is the right fit and when to consider Eon.
Eon is designed for the use cases that sit outside that model. Three needs come up most often as Amazon Keyspaces deployments grow:
- Direct access to backup data without a full restore. When a team needs to validate a recovery point, answer an audit question, or inspect table contents as of a past date, restoring a full table into a new environment is more work than the question requires. Eon exposes backup data as queryable datasets so teams can read historical data in place.
- Data-aware governance at scale. As new tables appear across environments, manual tagging and one-off policy assignment can drift, producing over-retention on low-value data and under-retention on regulated data. Eon discovers and classifies tables automatically and assigns retention based on what the table contains.
- Cross-source analysis. The records behind a customer journey or transaction often span multiple stores, which in many environments means Amazon Keyspaces, Amazon DynamoDB, and SQL databases running on Amazon EC2. Eon stores protected data from these sources in open formats and supports querying across them.
The rest of this post describes how Eon delivers these capabilities and when each one applies.
Solution overview
Eon performs agentless, cross-account backups of Amazon Keyspaces tables into a secure, customer-owned vault. There is no client agent to install on the source workload: you deploy a least-privilege IAM role in your source account using CloudFormation or Terraform, and Eon assumes that role to read from the source, so the source account never pushes data out and protected data stays within your AWS environment. The cross-account trust is scoped with an external ID to prevent confused-deputy access. Protected data is written to a vault in a dedicated, single-tenant AWS account that is logically air-gapped from your production and other environments.
Backup and Recovery architecture
Eon initiates an initial full data export from the source Amazon Keyspaces table as a parallel, token-range scan, then captures ongoing changes by reading directly from Amazon Keyspaces change streams (Keyspaces Streams). Both paths are transformed to Apache Parquet and stored as snapshots in an encrypted Amazon S3 vault. By default, the vault is encrypted with an Eon-managed AWS KMS key that lives in the vault account and is rotated automatically, using server-side encryption (SSE-KMS); if your requirements mandate control over encryption keys, you can instead supply your own customer-managed key (CMK) and grant the vault account access to it. Backups are compressed and incremental, and they are created according to the backup policies you define, which control storage growth and give you flexible recovery points over time.
Eon supports two restore paths from the vault, and you choose based on what the situation requires:
- Full table restore. Eon reconstructs the complete dataset from the incremental snapshots and populates a new Amazon Keyspaces table in the target restore account. Use this path for recovery, alternate-environment restores, and disaster recovery drills.
- Granular, query-driven restore. Eon makes the backup data directly queryable through Amazon Athena, so you can recover specific records or a subset of data without restoring the entire table. Use this path to validate a recovery point, inspect specific rows, or answer an audit question before taking any restore action.
Prerequisites
To follow this solution, you need:
- An Amazon Keyspaces table with the data you want to protect, and CDC available on that table.
- An Eon account and the Eon connection configured for your AWS environment.
- A Keyspaces table with CDC available, plus the Eon source-account connection (CloudFormation or Terraform). Source access uses the AWS managed read-only policy for Amazon Keyspaces. The restore account grants cassandra:Create/Modify/Alter/Drop/Select/TagResource, scoped to Eon-tagged resources.
Walkthrough
- Enroll — Source accounts → AWS accounts → New connection, deploy the CloudFormation/Terraform template; Eon then discovers your Keyspaces tables.
- Backup policy — create a policy whose condition matches Keyspaces tables (resource type, tag, or data class), set frequency (as fine as 15-minute intervals) and retention, and target a vault; show as a config snippet.
- Recover/inspect — run a query-driven restore (SELECT … against the snapshot) to pull a subset without a full restore.
Use cases where Eon can complement Amazon Keyspaces
Each optional use case below pairs a need that sits outside native PITR with the Eon capability that addresses it, so you can see the capability in the context where it matters.
- Retain protected data beyond the 35-day PITR window. When business requirements call for retention past the 35-day window, Eon provides long-lived protection. A forever-incremental model with global deduplication keeps storage growth in check as retention extends, so you align backup frequency and retention to the workload rather than to a fixed rollback limit. Keyspaces’ backup is forever-incremental — an initial Parquet full plus item-level CDC, coalesced into retention points — so the physical footprint tracks change volume, not retention length, and a global deduplication pass removes redundancy across the vault. On the same pipeline Eon uses for DynamoDB, a full year of retention typically lands at under 2× the live table size, with global deduplication driving up to ~90% physical reduction versus the cloud-native snapshot path.
- Investigate before you restore. Instead of restoring a full historical copy, query the backup data directly through Amazon Athena to validate the right recovery point, inspect table contents, or answer an audit question before taking any restore action. This is the capability that turns protected data into a queryable dataset rather than an opaque copy.
- Apply compliance-aware protection to regulated data. When tables contain sensitive customer or business data, Eon automatically discovers and classifies that data (including PII, PHI, financial data, and custom data classes and entities) and maps it to a corresponding backup, retention, and governance policy. Protection follows what the table contains, not just where it lives, which reduces reliance on manual tagging and the policy drift that creates protection gaps as new tables appear. Eon auto-discovers and classifies new tables as they appear and maps each to a backup/retention/governance policy based on contents (PII, PHI, FI, + custom).
- Run cross-Region recovery and disaster recovery drills. Eon's agentless protection operates across accounts and Regions, so you can rehearse restoration into alternate accounts or Regions and build confidence before a real incident.
- Ask questions across protected data sources. Eon stores protected data in open formats (Apache Iceberg and Parquet) and supports querying them, so security, operations, and analytics teams can trace customer activity, validate historical state, or understand how a production issue propagated across systems. Eon stores protected data from Keyspaces, DynamoDB, and SQL databases on EC2 as Parquet on S3 and supports SQL across them via Athena
Conclusion and next steps
Amazon Keyspaces PITR provides native, well-established protection for recent operational rollback within a 35-day window. For workloads that need longer retention, direct query on backup data, data-aware classification, or analysis across distributed data sources, Eon complements that foundation while keeping protected data in the customer's own AWS environment.
To get started, see Eon’s AWS Marketplace listing. For native Amazon Keyspaces protection, see Point-in-time recovery for Amazon Keyspaces.
