We manage several AWS EC2 environments that were previously protected with Acronis through an integrated provider setup, but that option is no longer viable for us. For on-premises systems we commonly use platforms such as Datto and Replibit, though those tools do not always fit cloud-native workloads well. I'm trying to understand what MSPs are using in production for EC2 backups today. Are most teams relying on EBS snapshots and AWS Backup, or are third-party platforms still preferred? A few of our instances run Microsoft SQL Server, so application-aware protection and database-consistent restores are important. I'd prefer an approach that avoids a large amount of custom scripting or ongoing command-line automation. What real-world setups have worked reliably for you, and how have you handled restore testing, retention, and SQL consistency?
4 Answers
Try not to treat the EC2 instance itself as the primary unit of protection. Build instances from an image or infrastructure definition, keep durable data in services such as EFS, S3, or a database, and back up those data stores separately. That makes rebuilding a failed server easier and gives you better retention and recovery options. Just remember that this does not automatically solve granular file restores or point-in-time database recovery—you still need a suitable data-level backup.
For Microsoft SQL Server, native SQL backups to S3 can work well for smaller databases, especially when you need transaction-log recovery and more granular restore points. AWS Backup with Windows VSS is another good option for instance-level protection. For larger, hybrid, or security-sensitive environments, commercial platforms such as Rubrik, Commvault, Cohesity, or Veeam can add centralized management, ransomware controls, and cross-cloud recovery, but the extra cost and complexity may not be justified for a purely AWS deployment.
We use Veeam when a client has AWS, other cloud platforms, and on-premises systems. Having one console and one operational process is valuable when the team already knows Veeam. For AWS-only environments, though, the native services are usually less complicated and avoid adding another platform. Be careful with the target design and API costs if sending everything directly to object storage; some providers use a compatible low-cost storage target instead.
For AWS-only clients, AWS Backup is usually the simplest choice. Use backup plans and resource tags to standardize schedules, retention, and vault selection, and enforce the tagging with organization policies if needed. For Windows SQL Server instances, configure the Windows VSS option so the backup is application-consistent rather than just a crash-consistent EBS snapshot. The important part is to regularly test restoring the SQL workload, not just verify that backup jobs completed.
The main limitation is scheduling frequency. AWS Backup generally won’t meet a 30-minute recovery point objective by itself, so you may need database point-in-time recovery or native SQL backups as a separate layer. Continuous recovery also has retention and resource-deletion caveats, so deletion protection and pre-deletion snapshots are worth considering.
Also watch out for database consistency on Linux. A plain EBS snapshot is only crash-consistent, so self-managed SQLite, PostgreSQL, or MySQL could be captured during a write. Quiesce or checkpoint the application before taking the snapshot, or create an application-consistent export and protect that instead.