DR Strategies for Connected Mobility Workloads, Part 1: Backup and Restore

Introduction

Connected Mobility integrates vehicles, infrastructure, and data analytics to enhance user experience, safety, and reduce emissions. System resilience is critical as disruptions can cause: 1/direct customer impact on vehicle remote functions 2/brand reputation damage through negative publicity 3/manufacturing disruptions 4/revenue loss and legal consequences. Disaster Recovery (DR) is essential to prepare for natural disasters, technical failures, and human errors. This blog is the first in a series examining connected mobility architecture and “backup and restore DR strategies” for CM workloads.

Connected Mobility Reference Architecture

AWS Connected Mobility Lens implements six key scenarios: 1/vehicle and user provisioning, 2/vehicle connectivity management, 3/vehicle data management and insights, 4/connected mobility core services, 5/connected mobility supported downstream system, and 6/customer experience management. Given below is the AWS Connected Mobility Reference Architecture; modules from this architecture will be used throughout the blog series to explain the DR strategies. Part 1 focuses on backup and restore DR strategies for vehicle connectivity, data ingestion, and visualization components (highlighted in grey).

Figure 1: AWS Connected Vehicle Reference Architecture

Connected Mobility DR Options

Connected Mobility is a mixed-criticality workload with different Recovery Point Objective (RPO) / Recovery Time Objective (RTO) requirements like emergency or safety impacting systems requiring RPO/RTO in seconds and use cases involving sending diagnostic emails having RPO/RTO of hours. The RTO and RPO requirements help in selecting the right DR strategy for the workload. A list of potential DR options are backup & restore, pilot light, warm standby, and multi-site active/active.

Backup and Restore DR Option

Backup and restore is the simplest and most affordable strategy, suitable for less critical components of CM applications with recovery time measured in hours. It protects against regional disasters by copying data to another AWS Region and works for on-premises systems as well using AWS as a backup site. Some CM workloads may require this approach for compliance reasons.

Key considerations for a DR implementation include:

1. To create a DR plan, first review the CM architecture, and outline DR objectives and requirements. The DR objectives include minimizing data loss (RPO) and minimizing downtime (RTO). Develop a comprehensive inventory of critical assets requiring protection within your disaster recovery strategy. As a best practice, the entire application should be backed up in another region at regular intervals. In addition to the application code, you also need to backup application configuration and Infrastructure as Code (IaC) templates to the recovery region.
2. Ensure AWS Service Quotas are in sync between regions. Since quotas are region-specific, any increases made in your primary region must also be applied to your disaster recovery region to prevent capacity issues during failover.
3. Define the frequency of backup. The frequency of the backup is defined by the RPO of the application. So, if your RPO is one hour, which means you can afford to lose an hour worth of data, your frequency of backup should be less than an hour
4. Implement strategic backup and recovery solutions tailored to your architecture. Leverage AWS Backup for centralized policy management across applications, while utilizing native multi-region replication for services like Amazon Elastic Container Registry (Amazon ECR). Enhance CI/CD pipelines to automatically deploy changes to both primary and secondary regions, ensuring configuration consistency. For specialized services such as AWS IoT Core, evaluate whether Just-in-Time Provisioning or event-driven synchronization workflows better meet your recovery requirements. Each approach offers distinct advantages depending on your specific workload characteristics.
5. Implement automated systems to detect regional failures and trigger recovery processes. Configure health checks that initiate failover workflows—either automatically or with approval steps. Include automated communications that keep stakeholders informed about incident status and expected recovery times.
6. For quick and reliable infrastructure deployment in the failover region, use Infrastructure as Code (IaC) with services like AWS CloudFormation, AWS Cloud Development Kit (CDK), or Terraform.
7. Establish a comprehensive failback strategy for returning operations to the primary region. Following primary region recovery, execute a structured data synchronization protocol and implement a controlled transition process to restore normal operations while minimizing disruption to business services.
8. Define the data retention policy for the backups as it is an important criterion for cost optimization. Define the policy for primary and secondary regions.
9. Implement security controls, such as data encryption, data integrity checks, access controls, and incident response plans, to protect data and systems while implementing a DR solution. The solution should also comply with regulations like GDPR and SOC2.
10. Establish a regular DR testing schedule to validate recovery capabilities. Conduct periodic drills to identify configuration drift and ensure recovery procedures remain effective as systems evolve, confirming readiness for actual disaster events.

Solution Overview

In this section, we will dive deep into the backup and restore DR architecture for the vehicle connectivity, data ingestion, and visualization modules of the Connected Mobility reference architecture. Figure 2 provides a high-level architecture, backup and restore flows in the secondary region for those modules.

Figure 2. Backup and Restore DR Strategy for CM workload

Backup Solution

To build a successful and cost-effective backup and restore DR solution, we start identifying components that should be included in the backup plan. As shown in Figure 2, the following components require backup:

1. Application: Codebase, CICD Pipeline, build specifications, deployment scripts, Infrastructure as Code (IaC) templates and service quotas
2. Data: Amazon Simple Storage Service (S3) buckets, Amazon DynamoDB (DynamoDB) tables, Amazon Timestream (Timestream) database, and Amazon Elastic Block Store (EBS) volumes
3. Compute: Amazon Machine Image (AMI), Container images in Amazon ECR
4. IoT: AWS IoT device registry, device certificates and policies, IoT Core configurations, rules, destinations, role aliases, custom authorizers

The next step is to choose the right strategy for backup

1. For Timestream, S3, and EBS volumes in the data tier, use AWS Backup—a managed service that compresses data for cost efficiency. While S3 offers cross-region replication, AWS Backup is typically more economical due to compression of data at rest. This solution uses DynamoDB Global Tables to replicate IoT Core events to the secondary region in real-time.

2. For the compute tier Elastic Container Service (ECS) component it is recommended to use AWS Backup for EC2 backup and restore for easy setup and central control. Using AWS Backup, you can copy backups to secondary Regions automatically as part of a scheduled backup plan. The Amazon Elastic Compute Cloud (EC2) AMI are also replicated in the secondary region and available for restore. For Container images the solution leverages Amazon ECR’s native cross region replication setup.

3. AWS IoT Core and related IoT services do not have native backup/restore capability. Given below are the backup solutions for the IoT core services:

a. Device related resources such as the device registry, device policies or device certificates are replicated to the secondary region in real-time. In the solution IoT Core rules stores device related operations in the Global DynamoDB table. AWS Lambda (Lambda) and AWS Step Functions (Step Functions) replicates the operations in IoT Core of the secondary region. After the replication, the record in the DynamoDB Global table will be marked for deletion. Customer can also use just-in-time provisioning/registration for IoT device certificates instead of real-time replication, but this approach will increase response time when vehicles connect to the IoT Core for the first time. In this approach you prepare both regions for the just-in-time setup and when your vehicle connects for the first time they are automatically registered by AWS IoT Core. The blog JIT Registration IoT Device Certificates provides additional details on how to accomplish this to avoid the need to maintain a backup for IoT Device certificates.

b. AWS IoT Core resources like IoT rules, destinations, role aliases or custom authorizers. These should be created in the secondary region using IaC at the same time they are deployed in the primary region. This reduces the chances of configuration drift. The Lambda functions in both regions should have loopback protection so that changes made on the DR system are not replicated back to the source system, and vice versa.

Restore Solution

In this solution, we have chosen Amazon Application Recovery Controller (ARC) to detect regional failures and direct traffic to the secondary region. ARC can check if resources are ready for recovery and perform failovers without any dependency on the control plane. Using readiness checks, ARC monitors resource quotas, capacity, and configuration for your multi-region applications and reviews changes that might affect your ability to fail over to the secondary region. ARC also helps you manage and automate recovery for your applications across AZs. These capabilities simplify application recovery and make it more reliable by reducing the manual steps that traditional tools and processes require.

When a regional failure is detected, the system initiates an AWS Systems Manager (SSM) runbook to restore the CM application in the secondary region. The following steps should be added to the runbook:

1. Data Recovery Restore Amazon Timestream and Amazon S3 data in the secondary region using AWS Backup’s point-in-time recovery.
2. Compute Recovery Restore Amazon Elastic Block Store (EBS) volumes to launch new Amazon Elastic Compute Cloud (EC2) instances using AMI already replicated to the secondary region. Elastic Container Registry (ECR) images maintain continuous replication to the secondary region and are available.
3. The IoT Core Registry in the secondary region receives real-time updates of connected vehicle metadata. Amazon Route 53 Application Recovery Controller (ARC) monitors multi-region recovery health and manages routing control. Route 53 performs health checks every 30 seconds, targeting an Amazon API Gateway GET endpoint that triggers an AWS Lambda function. This function establishes an MQTT connection to IoT Core to verify publish/subscribe functionality.
4. Application Deployment Deploy applications and AWS services in the secondary region using automated CI/CD pipeline

Once ARC confirms that data is restored and application components are up and running, it can perform traffic routing to update CNAME records to resolve the IoT endpoint in the healthy region. At this stage, we can restore connectivity to vehicle companion mobile applications and notify users about service availability through preferred communication channels. This approach ensures minimal disruption during failover while maintaining data consistency and service availability.

AWS Cost Estimate for Backup and Restore DR Option

In this section, we provide a sample cost estimate for 1 million connected vehicles to add backup and restore DR to the vehicle connectivity, data ingestion, and visualization modules of the Connected Mobility reference architecture. We are assuming US East (N. Virginia) as primary, and US East (Ohio) is the secondary region. The connected vehicle data volume assumptions are also listed under ‘Dimensions’ for this estimate.

The cost estimation above was done in June 2025 for this example scenario. Pricing for AWS services change over time and varies slightly between AWS regions. You may get a different value when doing this estimate for your account.

Conclusion

Backup and restore is a cost-effective approach to implement Disaster Recovery (DR) as compared to other DR strategies like pilot light and active/active. When you set up automated processes, this solution delivers Recovery Time Objectives and Recovery Point Objectives (RTO/RPO) within 2-4 hours, meeting the DR requirements for most Connected Mobility (CM) workloads.

For CM systems requiring faster recovery (sub-hour RTO/RPO), consider implementing either warm standby or multi-site active/active architectures using general guidance available at DR options. We will provide DR guidance, specific to Connected Mobility, on these approaches in the upcoming blog posts.