Multi-Region Active-Active on AWS: What It Actually Costs You

Surviving a full regional outage with no downtime is the thing every architecture review eventually asks about, and the answer is usually more expensive than the person asking expects. In a multi-region active-active setup, two or more AWS regions serve live production traffic at the same time. If one region fails badly, the others keep serving without a manual failover and without waiting for anything to warm up.

Managed services have made this much more approachable than it was five years ago. What has not changed is that you are now running a distributed system with a data layer spanning thousands of kilometres, and the failure modes are less “region goes dark” and more “two regions disagree about the truth.”

Active-active versus active-passive, and why the distinction costs money

Decide which problem you are solving before you build anything. Multi-region deployments fall into two families, and treating one as the other is how teams end up paying for resilience they never asked for.

Active-passive sends all production traffic to one primary region while a secondary sits ready. That readiness has degrees. A pilot light replicates data and keeps compute switched off. A warm standby runs a scaled-down copy of the application all the time. When something breaks you scale the standby up and move DNS. It works, and it means accepting a recovery time measured in minutes or hours.

Active-active is a different animal. Both regions serve live traffic continuously, both hold a complete application stack, and the data in each is live and writable.

Active-active earns its complexity when you genuinely need near-zero recovery time, or when a globally spread user base needs low latency from a nearby region. If what you actually need is to survive a bad day with an hour of degradation, warm standby costs a fraction as much and has far fewer ways to surprise you.

The honest framing: active-passive is a recovery strategy, active-active is an architecture. Partial failures are the hard part, not total ones. A region that is up but returning errors for 3% of requests is much harder to handle than a region that has plainly vanished.

What the whole thing looks like

Two properties in that diagram matter more than the service choices. First, each region is a complete cell that can serve any request on its own. Second, nothing in the request path crosses a region boundary. The moment Region A makes a synchronous call to something in Region B, you have two regions and one failure domain, which is worse than a single region because you are paying twice for it.

Routing traffic with Route 53

Your ingress layer decides which region a user reaches. Latency-based routing uses AWS telemetry to send each user to the region with the lowest measured network latency to them. Geolocation routing maps the resolver’s location to a region, which is what you want for data residency rather than speed.

Create one record per regional endpoint, distinguished by set_identifier:

1
resource "aws_route53_record" "api_eu" {
2
  zone_id = aws_route53_zone.main.zone_id
3
  name    = "api.example.com"
4
  type    = "A"
5

6
  alias {
7
    name                   = aws_lb.eu_west_1.dns_name
8
    zone_id                = aws_lb.eu_west_1.zone_id
9
    evaluate_target_health = true
10
  }
11

12
  latency_routing_policy {
13
    region = "eu-west-1"
14
  }
15

16
  set_identifier = "eu-west-1-endpoint"
17
}
18

19
resource "aws_route53_record" "api_us" {
20
  zone_id = aws_route53_zone.main.zone_id
21
  name    = "api.example.com"
22
  type    = "A"
23

24
  alias {
25
    name                   = aws_lb.us_east_1.dns_name
26
    zone_id                = aws_lb.us_east_1.zone_id
27
    evaluate_target_health = true
28
  }
29

30
  latency_routing_policy {
31
    region = "us-east-1"
32
  }
33

34
  set_identifier = "us-east-1-endpoint"
35
}

With evaluate_target_health = true, Route 53 stops returning a record whose load balancer is failing, and traffic lands on whatever is left.

This is why Route 53 Application Recovery Controller exists. Routing controls are on/off switches you flip yourself, backed by a cluster of five regional endpoints so you can still operate the switch during an event that is affecting your own tooling. Readiness checks separately audit whether the standby region is actually capable of taking the traffic, which catches the quota and capacity problems that only show up at the worst moment.

The useful mental model: health checks are for failures you did not predict, routing controls are for decisions you make. Draining a region because latency is climbing and you want out is a decision, not a health check.

The data layer is the whole problem

Everything above is comparatively easy. Keeping data correct in two places that are 80 milliseconds apart is where the difficulty lives, and the right answer depends on what your writes actually do.

DynamoDB Global Tables

A global table is a set of replica tables in different regions sharing a primary key schema. Write in eu-west-1, and DynamoDB propagates that write to us-east-1 asynchronously using streams. Replication is typically well under a second within a continent, and it is never guaranteed.

1
resource "aws_dynamodb_table" "users" {
2
  name             = "users"
3
  billing_mode     = "PAY_PER_REQUEST"
4
  hash_key         = "user_id"
5
  stream_enabled   = true
6
  stream_view_type = "NEW_AND_OLD_IMAGES"
7

8
  attribute {
9
    name = "user_id"
10
    type = "S"
11
  }
12

13
  replica {
14
    region_name = "eu-west-1"
15
  }
16

17
  replica {
18
    region_name = "us-east-1"
19
  }
20

21
  lifecycle {
22
    # Replicas drift outside Terraform when you add or remove regions
23
    # through the console during an incident. Ignoring them here stops
24
    # the next plan from proposing to tear one down.
25
    ignore_changes = [replica]
26
  }
27
}

Streams with NEW_AND_OLD_IMAGES are required, because that is the mechanism replication uses.

The behaviour you have to design around is conflict resolution. Global tables use last-writer-wins based on timestamp. Two regions updating the same item within the replication window means one update is silently discarded, with no error and no log entry on your side. For a user’s display name, that is acceptable. For a balance, it is data loss with extra steps.

Aurora Global Database, and its one writer

Aurora Global Database gives you a primary region and up to five secondaries with replication latency typically under a second, plus fast promotion. It has one hard constraint: a single writer. Every write commits in the primary region.

Local write forwarding softens this. Applications connect to a secondary’s reader endpoint, issue writes, and Aurora forwards them over the AWS backbone to the primary. Your code stops caring which region it is in. Your latency budget still cares, because every forwarded write pays the round trip. At 80 milliseconds between regions, a transaction doing four sequential writes has just spent a third of a second on network time.

Call this what it is: active-active for reads, active-passive for writes. That is a legitimate and common design, and it is worth being precise about, because “we run Aurora Global Database” and “we are active-active” are different claims.

Aurora DSQL

Aurora DSQL is the option that changes the answer for relational workloads. It is serverless, PostgreSQL-compatible, and built for active-active from the start, separating compute, storage, and transaction coordination so each scales independently.

The interesting part is the concurrency model. Rather than taking locks as a transaction proceeds, DSQL uses optimistic concurrency control and defers coordination to commit time. Because consensus happens synchronously at commit, a read in one region reflects a committed write from another, which is what people usually mean by “no replication lag.” AWS publishes a 99.999% availability SLA for multi-region configurations.

What you pay for that is a different failure mode in your application code. Transactions that conflict get rejected at commit, and the client is expected to retry:

1
import psycopg
2
from psycopg import errors
3

4
def transfer(conn_factory, from_id, to_id, amount, attempts=5):
5
    """DSQL rejects conflicting transactions at COMMIT rather than blocking.
6
    Retrying is not optional error handling, it is the concurrency model."""
7
    for attempt in range(attempts):
8
        try:
9
            with conn_factory() as conn, conn.transaction():
10
                cur = conn.execute(
11
                    "SELECT balance FROM accounts WHERE id = %s", (from_id,)
12
                )
13
                (balance,) = cur.fetchone()
14
                if balance < amount:
15
                    raise ValueError("insufficient funds")
16

17
                conn.execute(
18
                    "UPDATE accounts SET balance = balance - %s WHERE id = %s",
19
                    (amount, from_id),
20
                )
21
                conn.execute(
22
                    "UPDATE accounts SET balance = balance + %s WHERE id = %s",
23
                    (amount, to_id),
24
                )
25
            return True
26
        except errors.SerializationFailure:
27
            if attempt == attempts - 1:
28
                raise
29
            # Full jitter. Retrying in lockstep just recreates the collision.
30
            time.sleep(random.uniform(0, 0.1 * (2**attempt)))
31
    return False

If your team has never written retry-on-serialization-failure code, that is the real migration cost, not the SQL compatibility.

Conflict resolution, cheapest option first

Once you accept writes in more than one region, the CAP theorem stops being an interview question. During a partition between regions you either keep accepting writes and let the data diverge, or you refuse writes and stay consistent. Most businesses pick availability and then need a plan for divergence.

The cheapest plan is to make conflicts impossible rather than resolving them. Region affinity assigns each user a home region and routes their writes there, while reads can happen anywhere. Since most records in most systems are only ever written by one user, this eliminates the large majority of conflicts for the cost of a routing rule. Reach for it first.

When two regions genuinely must write the same record, the next cheapest option is to make ordering irrelevant. A DynamoDB ADD on a counter is commutative, so increments from either region compose correctly no matter what order they arrive in. Set unions behave the same way. This works beautifully for likes, view counts, and tag sets, and not at all for anything where the new value depends on reading the old one.

Last-writer-wins is what you get by default from Global Tables, and it is a real choice rather than an absence of one. It is correct whenever the most recent write is genuinely the one you want and losing the other causes no harm.

Optimistic concurrency control is the option that refuses to lose a write. The system detects the collision at commit, rejects one transaction, and hands the problem to the client. This is DSQL’s model, and you can approximate it in DynamoDB with a version attribute and a condition expression:

1
// Conditional write: fail rather than clobber a concurrent update.
2
await ddb.send(
3
  new UpdateItemCommand({
4
    TableName: 'orders',
5
    Key: {order_id: {S: orderId}},
6
    UpdateExpression: 'SET #s = :next, version = :newV',
7
    ConditionExpression: 'version = :curV',
8
    ExpressionAttributeNames: {'#s': 'status'},
9
    ExpressionAttributeValues: {
10
      ':next': {S: 'shipped'},
11
      ':curV': {N: String(currentVersion)},
12
      ':newV': {N: String(currentVersion + 1)},
13
    },
14
  }),
15
);
16
// A ConditionalCheckFailedException means someone else won. Re-read and retry.

Cross-region networking

Internal service calls and replication need a path between regions. For two or three regions, cross-region VPC peering is usually right: direct, simple, and cheaper because you avoid per-attachment and per-GB processing fees.

Transit Gateway earns its cost once you have many VPCs or on-premises connectivity to fold in, because maintaining a peering mesh and its route tables stops being tractable. Be clear-eyed about the pricing though. You pay hourly per attachment plus per-GB processing, and that processing charge sits on top of standard inter-region transfer. In a chatty active-active application, that stacking is the line item that shows up in a quarterly review with someone asking what happened.

The cheaper architectural answer is usually to move less data. Region-local caches, region-local queues, and asynchronous replication instead of synchronous calls all reduce the bill and the coupling at the same time.

Testing it, or admitting you have not

An active-active architecture you have never failed over is a hypothesis, not a capability.

Configuration drift between two supposedly identical regions is not a risk, it is a certainty. Emergency patches, manual parameter changes, a security group tweaked at 2am, a quota raised in one region and not the other. Each is individually reasonable and collectively guarantees that your secondary region is not quite what you think it is. The failure you will actually hit is not “the region was down”, it is “the other region could not scale because nobody raised the account limit there.”

I have written up how this played out on a real system, including the numbers, in the multi-region active-active payments API case study.

Frequently Asked Questions

References

• AWS Multi-Region Fundamentals
• Disaster recovery options in the cloud (AWS Well-Architected)
• Route 53 latency-based routing
• Route 53 Application Recovery Controller developer guide
• DynamoDB global tables
• DynamoDB condition expressions
• Amazon Aurora global databases
• Aurora write forwarding for secondary regions
• Amazon Aurora DSQL user guide
• Aurora DSQL concurrency control
• AWS Global Accelerator vs CloudFront
• Transit Gateway pricing
• Building resilient multi-region serverless applications
• aws_route53_record Terraform resource
• aws_dynamodb_table Terraform resource