---
title: Paxos, Raft, and Byzantine Fault Tolerance: What Cloud Architects Need
description: You rarely implement Raft on EC2, because you buy it in Aurora, DynamoDB, and EKS etcd. This guide explains quorum math so you can trust managed services and avoid rolling your own coordinator.
url: https://www.joinhorizon.co/blog/consensus-paxos-raft-byzantine-fault-tolerance-cloud/
datePublished: 2026-06-12T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: palaniappan-p
category: Cloud Architecture
tags: engineering-guide, distributed-systems, aws
---

# Paxos, Raft, and Byzantine Fault Tolerance: What Cloud Architects Need

> You rarely implement Raft on EC2, because you buy it in Aurora, DynamoDB, and EKS etcd. This guide explains quorum math so you can trust managed services and avoid rolling your own coordinator.

**June 2026**: **Raft** (etcd backing EKS) elects a leader with majority quorum; **Paxos** family underpins many storage systems. **Byzantine fault tolerance** (BFT) handles malicious nodes, which is overkill for AWS VPC trust boundaries unless you have blockchain or multi-party trust.

## Symptom → mechanism → AWS control

| Production symptom               | Mechanism                                          | AWS control                                              |
| -------------------------------- | -------------------------------------------------- | -------------------------------------------------------- |
| Leader election storm            | Raft quorum loss during rolling upgrade            | MSK rolling broker updates with min.insync.replicas=2    |
| Split-brain on network partition | Majority quorum not enforced                       | Aurora multi-AZ with single writer endpoint              |
| Byzantine node behavior          | BFT requires 3f+1 nodes; cloud assumes crash-fault | AWS managed services delegate consensus to control plane |

**Opinionated take:** You rarely implement Paxos. You configure quorum on MSK and Aurora and trust AWS control planes for everything else.

> **Benchmark pattern (hypothetical workload):** 5-node MSK cluster (RF=3) simulating broker loss, leader election completes in 4.2s, 0 message loss with min.insync.replicas=2, vs 23s recovery on RF=2 misconfiguration at 50K msgs/sec ingest.

## What AWS already consensus-manages

| Component         | Consensus inside          |
| ----------------- | ------------------------- |
| Aurora storage    | Quorum replicas           |
| DynamoDB          | Partition replication     |
| EKS control plane | etcd (Raft)               |
| MSK               | Kafka controller election |

**Do not** run homegrown Raft on EC2 for app locks. Use DynamoDB or Step Functions with idempotency.

## Self-hosted ZooKeeper

When someone proposes “self-hosted ZooKeeper,” ask what **managed** equivalent buys: operational quorum, fencing, upgrades.

## AWS services map

| Need                     | Service                          | Skip when                                 |
| ------------------------ | -------------------------------- | ----------------------------------------- |
| Managed consensus        | MSK (KRaft), Aurora (4-of-6 storage quorum), DynamoDB (Multi-Paxos) | Self-hosted etcd on EC2                   |
| Quorum-aware failover    | Aurora Global Database           | Read replicas only, no failover SLO       |
| Understand not implement | AWS docs on MSK ISR              | Building custom Paxos in application code |

## What to do this week

1. Map each critical state store to its failure quorum (N/2+1).
2. Run EKS etcd backup/restore drill documentation review.
3. Skip BFT designs unless threat model includes malicious peers.

## More in This Track

Part of the **Engineering Guides** library (June 2026).

- Previous: [Part 3](https://www.joinhorizon.co/blog/distributed-coordination-redlock-consistent-hashing-elasticache/)
- Next: [Part 5](https://www.joinhorizon.co/blog/exactly-once-cqrs-event-sourcing-replay-aws/)
- Browse tracks: [Engineering Guides hub](https://www.joinhorizon.co/resources/engineering-guides/)

## What this guide doesn't cover

Exactly-once and CQRS are covered in part 5 of the track.

## FAQ

### Should we run our own Raft on EC2 for application locks?
No. Use DynamoDB conditional writes or Step Functions with idempotency. Homegrown Raft on EC2 for app locks buys operational quorum, fencing, and upgrade risk that Aurora, DynamoDB, MSK, and EKS etcd already own.

### When is Byzantine fault tolerance the wrong design on AWS?
Skip BFT unless the threat model includes malicious peers (multi-party or blockchain). Inside a VPC trust boundary, crash-fault quorum is what Aurora, DynamoDB, and etcd assume. BFT needs 3f+1 nodes you will not operate well.

### What could go wrong if min.insync.replicas is too low on MSK?
A broker loss can elect slowly and drop messages. The hypothetical five-node RF=3 pattern in this guide recovers in seconds with min.insync.replicas=2; RF=2 misconfiguration stretched recovery at 50K msgs/sec ingest. Set ISR to match the durability SLO.

### Does Aurora Global Database replace understanding quorum?
It hides the Paxos family but does not remove the N/2+1 math. Map each critical state store to its failure quorum, including the single-writer endpoint on Aurora multi-AZ, before you promise split-brain immunity.

---

*Source: https://www.joinhorizon.co/blog/consensus-paxos-raft-byzantine-fault-tolerance-cloud/*