Healthcare Backup and Disaster Recovery Planning Solution
We implemented centralized backup and automated disaster recovery as part of the AWS migration, so the healthcare platform went live already resilient and compliant.
OUR CUSTOMER
Healthcare SaaS for Therapy Providers
TherapyBOSS is a healthcare SaaS platform for therapy providers and home health agencies. It helps clinical teams manage patient scheduling, electronic visit documentation, referrals, reassessments, and other care delivery workflows.
THE CHALLENGE
Data Protection and Regional Recovery
As part of TherapyBOSS’s migration from on-premises infrastructure to AWS, the DevOps team had to integrate backup and disaster recovery into the new cloud environment before go-live. The SaaS required reliable protection for critical data, long-term retention, and a clear recovery path if the primary AWS Region became unavailable. This brought the following challenges:
Lack of Centralized Backup Governance
TherapyBOSS stored critical data in Amazon RDS for MariaDB, Amazon DocumentDB, Amazon EFS, and Amazon S3. Managing each service separately would make it difficult to apply retention, encryption, and lifecycle policies consistently. The DevOps team needed to establish a centralized backup approach for these different data stores.
Insufficient Long-Term Backup Retention
Short-term recovery points alone could not meet the platform’s healthcare compliance and audit requirements. The backup strategy needed standardized daily and monthly tiers with clearly defined retention periods across environments.
Dependence on a Single AWS Region
The production environment would run in the US East (Ohio) Region. To reduce dependence on a single AWS Region, the DevOps specialists had to prepare a secondary recovery Region and establish a reliable path for restoring platform operations there.
Undefined Recovery Targets and Failover Process
The team needed to define clear recovery time and recovery point objectives and create a repeatable failover process. During an incident, specialists had to be able to promote databases, redeploy services, and validate the platform by following a controlled procedure instead of improvising manual recovery steps.
Recovery Dependencies Across the Tech Stack
The platform relied on databases, file storage, containerized services, streaming, search, and monitoring components. Recovering this interconnected stack required careful sequencing. The DevOps team needed a reproducible approach that would reduce configuration inconsistencies and restore the environment in the correct order.
Risk of S3 Data Inconsistency Across Regions
Application data stored in Amazon S3 had to remain available in both the primary and disaster Recovery regions. The architecture also needed to keep this data consistent after failover and failback, allowing either region to become the active environment.
THE SOLUTION
Backup and Disaster Recovery Implementation on AWS
To address the identified challenges, our DevOps specialists combined centralized backup management, continuous cross-region replication, Infrastructure as Code (IaC), and automated failover and failback procedures to protect critical data and enable regional recovery.
Centralized Backup Across AWS Data Stores
The DevOps specialists configured a dedicated AWS Backup vault and backup plan for each environment. Resource selections connected through Terragrunt dependencies allowed the team to centrally protect:
- Amazon RDS for MariaDB
- Amazon DocumentDB
- Amazon EFS file systems
The production backup schedule included two retention tiers:
- Daily backups retained for 30 days
- Monthly backups retained for 730 days, or two years
Lifecycle policies automatically delete expired recovery points. The team also applied AWS KMS encryption, database deletion protection, and final snapshots.
Amazon RDS and Amazon DocumentDB kept native automated backups for point-in-time recovery within a one-day window.
For regional protection, AWS Backup copies production recovery points from us-east-2 to a separate destination vault in us-west-2. Daily cross-region copies remain available for three days, while monthly copies have a 60-day retention period in the DR Region.
Continuous Cross-Region Data Replication
Long-term backups provided reliable recovery points, but meeting the near-zero RPO target required continuous replication of critical application data.
The DevOps team configured:
- An Amazon RDS cross-region read replica in
us-west-2 - A secondary Amazon DocumentDB Global Cluster member in
us-west-2 - Bidirectional cross-region replication between versioned Amazon S3 buckets in
us-east-2andus-west-2 - Amazon ECR replication from
us-east-2tous-west-2
Bidirectional Amazon S3 replication allows objects to move between both regional buckets. After failover to us-west-2, new application data created there can replicate back to us-east-2 during failback.
Amazon ECR replication kept production Docker images available in us-west-2, so Amazon ECS could pull the same image tags locally during failover instead of rebuilding containers.
Pilot-Light DR Environment
Specialists prepared a pilot-light environment in us-west-2 with the infrastructure needed to recover the platform during an outage in the primary Region.
The DR environment included:
- Amazon VPC
- Application Load Balancer
- Amazon ECS
- AWS Cloud Map
- Amazon MSK
- Amazon OpenSearch Service
- Amazon EFS
- Grafana and Loki
- VPC peering
- Amazon Elastic Container Registry (ECR)
The DevOps engineers defined these components in Terraform and organized their activation through a controlled Terragrunt apply sequence. During recovery, the sequence creates or updates dependencies in the required order before deploying the application services.
As a result, the DevOps team gained a reproducible way to recover the interconnected stack. The controlled sequence keeps the environment setup consistent, prevents dependent services from starting prematurely, and avoids reconstructing the DR environment from scratch each time.
Automated Regional Failover
The DevOps team developed an AWS CodePipeline workflow to coordinate regional failover. A manual approval gate prevents accidental activation while allowing specialists to initiate recovery quickly during a confirmed regional incident.
After approval, the DR pipeline:
- Promotes the Amazon RDS cross-region replica.
- Initiates the Amazon DocumentDB Global Cluster failover.
- Applies the required DR infrastructure through Terragrunt.
- Deploys the Amazon ECS applications using specified container image tags.
AWS CodeBuild and Terragrunt execute these actions in a predefined sequence. The final validation steps confirm that the databases have assumed the correct roles and that the recovered platform can operate in us-west-2.
By automating the main promotion, infrastructure deployment, application recovery, and validation tasks, the team established a repeatable process designed to meet an approximate one-hour RTO and a near-zero RPO while cross-region replication operates normally.
Automated Regional Failover Sequence
Documented Failover and Failback Procedures
We prepared DR and failback runbooks that define responsibilities, required checks, execution steps, and post-recovery validation.
The failback procedure returns database writer roles to us-east-2, re-establishes the required replicas in us-west-2, and verifies Amazon S3 data consistency before production operations return to the primary Region.
Together, the automated pipelines and runbooks provide TherapyBOSS with a controlled recovery path for both failover and failback, removing guesswork from execution during an incident.
Backup and Disaster Recovery Architecture on AWS
AWS Services We Used
THE RESULTS
Resilient AWS Environment with Backup and DR
The solution improved TherapyBOSS’s ability to protect its platform and maintain operations during infrastructure failures. Key outcomes included:
- Recovery readiness from go-live. TherapyBOSS moved to AWS with backup and disaster recovery capabilities already incorporated into its production environment.
- Reduced business disruption. The company gained a defined recovery path for restoring platform operations during a regional outage.
- Predictable recovery outcomes. An approximate one-hour RTO and near-zero RPO under normal replication conditions provide clear expectations for service restoration.
- Lower incident response risk. A repeatable recovery process helps the client’s technical team act consistently under pressure and reduces dependence on improvised decisions.
- Less operational overhead. Centralized management and automation reduce the manual effort required to maintain backup and recovery readiness.
- Improved audit readiness. A structured, long-term data retention framework helps TherapyBOSS address healthcare compliance and audit expectations.
WHY ROMEXSOFT
AWS Backup and Disaster Recovery Partner
Romexsoft is an AWS DevOps company and an AWS Advanced Tier Services Partner. Our DevOps specialists design and implement backup and disaster recovery solutions for SaaS platforms migrating to AWS.
Our approach to this project combined centralized data protection with automated regional recovery:
- Configuring AWS Backup vaults and retention policies across Amazon RDS, DocumentDB, EFS, and S3
- Setting up continuous cross-region replication to support a near-zero RPO
- Building a pilot-light DR environment and Infrastructure as Code deployment sequence through Terraform and Terragrunt
- Automating failover and failback through AWS CodePipeline, backed by documented runbooks for incident response.
Frequently Asked Questions
How often should disaster recovery failover be tested?
Most teams test failover at least twice a year, with more frequent tests for platforms with strict RTO/RPO targets or regulatory requirements. Testing typically includes a full failover simulation, a failback verification, and a review of runbook accuracy after any infrastructure changes. Regular testing confirms that automated pipelines, replication, and promotion steps still work as configured, since AWS services, IAM permissions, and application dependencies change over time.
When do you need AWS Backup versus native database snapshots?
Healthcare platforms typically run both together: native snapshots handle day-to-day operational recovery, while AWS Backup covers the long-term, compliant, cross-region protection that auditors and regulators care about.
Native snapshots are built into the database service and support point-in-time restore within a short window (often around a day) – ideal for reversing an accidental deletion, a bad migration, or bug-induced corruption with minimal setup.
AWS Backup centralizes retention, encryption, and lifecycle policies across multiple AWS services at once, extends retention to meet audit requirements, and copies backups to a separate Region for disaster recovery.
Can a disaster recovery strategy like this apply to non-healthcare SaaS platforms?
Yes. The architecture pattern (centralized backup, cross-region replication, a pilot-light DR environment, and automated failover) – applies to any SaaS platform running on AWS, regardless of industry. Healthcare platforms often adopt this approach due to compliance and uptime requirements, but fintech, e-commerce, and media streaming platforms face similar risks from regional outages and benefit from the same recovery model.
What's the difference between AWS Backup and third-party backup tools?
AWS Backup is a native AWS service that centralizes backup policies across services like RDS, DocumentDB, EFS, and S3, without requiring additional agents or licensing. Third-party tools such as Veeam, Commvault, or Druva often provide broader cross-cloud support, more granular reporting, or features tailored to specific industries, but add cost and operational overhead. For teams operating entirely within AWS, AWS Backup usually offers a simpler setup and tighter integration with existing AWS security and monitoring tools.
