Redundancy of application and data

Question

Redundancy of application and data

Bent Rossen 20

Redundancy of application and data in a other region if there is a fault in the first rigion.

Bent Rossen 20 Reputation points

2026-04-21T08:07:48.0233333+00:00

what is the cost for this solution.
Suchitra Suregaunkar 13,785 Reputation points Microsoft External Staff Moderator

2026-04-21T09:47:15.68+00:00
Hello @Bent Rossen

Thank you for posting your query on Microsoft Q&A platform.

1. Data Redundancy Across Regions:

Azure Storage natively supports geo-redundant replication, which automatically copies your data to a secondary region hundreds of miles away. You have the following options:

GRS (Geo-Redundant Storage) : Replicates your data synchronously within the primary region (using LRS), and then asynchronously to a paired secondary region, where it is again stored with LRS. This provides at least 16 nines of durability.

GZRS (Geo-Zone-Redundant Storage) : Replicates data synchronously across three availability zones in the primary region (ZRS), and then asynchronously to the secondary region (LRS). This is recommended for maximum durability, consistency, and availability.

RA-GRS / RA-GZRS : These are the read-access variants of GRS and GZRS. They allow your application to read data from the secondary region even before a failover is triggered, which is ideal for high-availability scenarios.

Note: Geo-replication is asynchronous, so there is a Recovery Point Objective (RPO) meaning recent writes may not yet be replicated if the primary region becomes unrecoverable.

Reference:

Azure Storage redundancy

Design highly available applications using geo-redundancy

2. Application Redundancy Across Regions (Azure Site Recovery):

For your virtual machines and application workloads, Azure Site Recovery (ASR) provides native disaster recovery by continuously replicating your Azure VMs to a secondary region. If the primary region experiences an outage, you can failover to the secondary region with minimal downtime.

Below are the steps:

Create a Recovery Services vault in your target (secondary) region.

Enable replication for your Azure VMs : The Site Recovery Mobility service extension installs on each VM and begins replicating disk writes to the target region.

Run periodic test failovers (disaster recovery drills) to validate your DR plan without impacting production.

When a regional outage occurs, initiate a failover : VMs are created in the target region using the latest recovery point.

After the primary region recovers, you can failback (reprotect and replicate back to the original region).

ASR now also supports global disaster recovery, meaning you can replicate across continents but not just within the same continent.

Reference:

Tutorial: Set up disaster recovery for Azure VMs

Tutorial: Fail over Azure VMs to a secondary region

Enable global disaster recovery using Azure Site Recovery

3. Database Geo-Replication:

If you're using Azure SQL Database, you can set up active geo-replication to continuously replicate your database to a secondary region. For automated failover with a stable connection endpoint, use failover groups they provide read-write and read-only listener endpoints that remain unchanged during geo-failovers, so you don't need to update your application's connection string.

Reference:

Active geo-replication for Azure SQL Database

Failover groups overview & best practices

4. Traffic Routing for Regional Failover: To automatically route users to the healthy region during an outage, use a global load balancer:

Azure Front Door : Provides Layer-7 load balancing, SSL offload, caching, WAF, and automatic failover across regions. Recommended for HTTP/S workloads.

Azure Traffic Manager : DNS-based global load balancer that routes traffic based on priority, performance, or weighted methods. Suitable for non-HTTP workloads or simpler routing needs.

Reference:

Global routing redundancy for mission-critical web applications

Load-balancing options in Azure

Thanks,

Suchitra.
Suchitra Suregaunkar 13,785 Reputation points Microsoft External Staff Moderator

2026-04-21T10:17:51.3133333+00:00

Hello @Bent Rossen,

Could you please look the above share cost analysis and let me know if it is helpfull.

Answer accepted by question author

1 additional answer

Your answer

Bent Rossen 20 Reputation points

2026-04-21T08:07:48.0233333+00:00

what is the cost for this solution.
Suchitra Suregaunkar 13,785 Reputation points Microsoft External Staff Moderator

2026-04-21T10:17:51.3133333+00:00

Hello @Bent Rossen,

Could you please look the above share cost analysis and let me know if it is helpfull.

Answer 1

For redundancy of both application and data in another Azure region, use geo-redundant platform services and design the app to fail over between regions.

Key elements:

Data redundancy across regions
- Use Azure Storage with geo-redundant options:
  - GRS (Geo-redundant storage): Data is synchronously replicated within the primary region using LRS, then asynchronously to a paired secondary region, where it is again stored with LRS. Provides at least 16 9s durability.
  - GZRS (Geo-zone-redundant storage): Data is synchronously replicated across three or more availability zones in the primary region (ZRS) and asynchronously to a secondary region, stored with LRS there. Recommended for maximum consistency, durability, and availability.
- For read access in the secondary region before failover, use RA-GRS or RA-GZRS so the application can read from the secondary region during primary-region issues.
- Be aware replication is asynchronous, so there is a Recovery Point Objective (RPO): recent writes may be lost if the primary region is unrecoverable. Azure Storage Geo Priority Replication can keep RPO for Block Blobs ≤ 15 minutes.
File shares across regions
- For Azure Files (HDD SMB shares), use:
  - GRS: Synchronous triple replication with LRS in the primary region, then asynchronous replication to a single location in the secondary region, again triple-replicated with LRS.
  - GZRS: Synchronous replication across three availability zones in the primary region (ZRS), plus asynchronous replication to a single location in the secondary region, triple-replicated with LRS.
- GRS/GZRS for Azure Files provide at least 16 9s durability and protect against regional outages; failover uses system snapshots taken every 15 minutes, so the share state after failover is based on the latest replicated snapshot.
Application design for multi-region
- Deploy the application in at least two regions (active/active or active/passive).
- Use geo-redundant data stores (as above) or database technologies that support geo-replication (for example, Azure SQL Database or Azure Cosmos DB with geo-replication) so the app in the secondary region can access up-to-date data.
- Use a global routing/failover mechanism (for example, Azure Traffic Manager or Azure Front Door) to direct user traffic to the healthy region during a regional fault.
- Design the app to handle eventual consistency when reading from secondary storage regions (for RA-GRS/RA-GZRS), including retry logic and user messaging if slightly stale data is acceptable.
Failover behavior
- For Azure Storage accounts using GRS/GZRS:
  - Under normal conditions, reads and writes go to the primary region.
  - If the primary region becomes unavailable and cannot be recovered, initiate a storage account failover. DNS is updated so the secondary region becomes the new primary, and read/write access is restored there.
- For Azure Files with GRS/GZRS, after failover the file share state is based on the latest replicated system snapshot in the secondary region, which may be up to (or slightly older than) 15 minutes behind.

By combining multi-region application deployment with geo-redundant storage (GRS/GZRS/RA-GRS/RA-GZRS) and appropriate failover routing, both application and data remain available from another region if the first region experiences a fault.

References:

Answer 2

Hello @Bent Rossen,

The cost of a cross-region redundancy solution depends on which services you use and how much data/resources you're protecting. There isn't a single flat price, each component has its own pricing model.

1. Azure Site Recovery (VM Replication)"

Azure Site Recovery is billed per protected instance (i.e., per VM or physical server):

User's image

In addition to the license fee, you'll incur costs for:

Replica managed disks in the target region (mirrors your source disk type and size)
Cache storage account used during replication
Storage transactions (read/write operations during replication)
Network egress (outbound data transfer when replication traffic leaves a region)

Reference:

Azure Site Recovery pricing

Understanding ASR charges for managed disks

2. Geo-Redundant Storage (GRS / GZRS / RA-GRS / RA-GZRS):

Storage costs vary by redundancy option, region, and access tier. Geo-redundant options cost more than locally redundant storage because your data is replicated to a second region. As a reference point (Table Storage, East US):

User's image

Note: Actual pricing varies based on storage type (Blob, Files, Tables, etc.), access tier (Hot, Cool, Archive), and region. Always use the Azure Pricing Calculator for accurate estimates.

Reference: Azure Blob Storage pricing

3. Azure SQL Database Geo-Replication / Failover Groups

The geo-secondary database is priced at 100% of the primary database price. The cost of geo-replication traffic between the primary and the secondary is included in the secondary's cost.

In simple terms if your primary Azure SQL Database costs $500/month, the geo-replicated secondary will cost an additional ~$500/month.

If the secondary replica is used only for disaster recovery (no read workloads), you can save on licensing costs by designating it as a standby replica (license-free DR replica).

Reference: Azure SQL Database pricing

4. Azure Traffic Manager: Traffic Manager is billed based on DNS queries and health checks.

User's image

Reference: Azure Traffic Manager pricing

5. Azure Front Door (Alternative to Traffic Manager):

Azure Front Door pricing is based on base fees, requests processed, and data transfer. It comes in two tiers like Standard and Premium (Premium includes WAF, Bot Protection, and Private Link).

Reference: Azure Front Door pricing

6. Data Transfer / Network Egress Costs: Replicating data across regions incurs outbound data transfer (egress) charges. Inbound data transfer (ingress) into Azure is free. Inter-region transfer within the same continent is approximately $0.02 per GB (North America/Europe).

Reference: Azure Bandwidth pricing

How to Estimate Your Specific Cost:

Since the total cost depends on your specific workload (number of VMs, storage size, database tier, traffic volume, etc.), the best approach is to use the Azure Pricing Calculator. It lets you add each service, configure the parameters to match your environment, and get a detailed monthly cost estimate.

Link: Azure Pricing Calculator

User's image

You can also use the Azure Site Recovery Deployment Planner to generate a detailed cost estimation report specifically for your DR scenario it breaks down compute, storage, network, and license costs per VM.

Link: https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-vmware-deployment-planner-cost-estimation

Hope this helps clarify the cost structure. Feel free to follow up if you need help estimating costs for a specific scenario.

If you found the comment helpful, please consider clicking "Upvote it".

Thanks,

Suchitra.

Share via

Redundancy of application and data

1 additional answer

Your answer