기준일을 100으로 놓고 그린 선입니다. 통화가 서로 달라 지수로 겹쳤습니다.
아마존AWS. 위 표의 영업이익률 35.43%, 아마존 전사 영업이익의 57.03%가 여기서 나옵니다. 이 조각이 읽은 계약서를 쓴 곳입니다.
99.99%는 약속이 아니라
계산 결과다
AWS는 자기 계약서에 두 숫자를 따로 인쇄해 둡니다. 서버 한 대는 99.5%, 서로 다른 구역(AZ)에 두 벌 이상 세우면 99.99%. 두 숫자를 잇는 말은 문서 어디에도 없는데, 곱해 보면 맞습니다. 그 식을 직접 돌려 보고 — 약속을 지켰는데도 내가 손해를 보는 구간을 찾아봅니다.
손잡이
기본 99.5%는 제가 고른 게 아니라 계약서에 인쇄된 값입니다 — “Instance-Level Uptime Percentage of at least 99.5%”.
1에서 2로 넘기면 적용되는 계약 자체가 바뀝니다. 리전 레벨 SLA의 적용 조건이 “two or more AZs”라서입니다.
★표준값이 없습니다 — 가정입니다. AWS가 이 값을 인쇄한 문서를 찾지 못했습니다. 대신 화면이 그 대수에서 99.99%를 지킬 수 있는 상한을 그 자리에서 풀어 같이 띄웁니다. 0으로 내리면 교과서 독립 가정으로 돌아갑니다.
★가정입니다. 이름이 긴 이유가 있습니다 — 모든 AWS SLA가 크레딧을 “멈춘 그 서비스, 그 리전 청구액”의 %로 정의합니다. 전체 클라우드 비용이 아닙니다.
그 달의 길이
눌러서 맞춰 보기
★스노우플레이크 19.1%는 인쇄값 둘에서 계산했습니다 — FY2026 10-K의 “제품 매출원가 중 71%가 3사 클라우드 비용”과 매출원가·매출 금액. 전사 클라우드비라 이 손잡이의 정의보다 넓습니다(상한 쪽 눈금).
두 숫자를 잇는 말은 없는데, 곱하면 맞는다
AWS의 컴퓨트 SLA에는 숫자가 두 개 인쇄돼 있습니다. 하나는 인스턴스 한 대 99.5%, 다른 하나는 리전 레벨 99.99%. 문서는 이 둘이 서로 무슨 관계인지 한 줄도 설명하지 않습니다. 그런데 한 대의 정지 확률을 그냥 제곱해 보면 이렇게 됩니다.
n = 1 → 99.500000% 월 216.00분 — 99.99% 문턱 미달
n = 2 → 99.997500% 월 1.08분 — 통과
n = 3 → 99.999988% 월 0.01분
이 식이 뱉는 99.99%를 넘기는 최소 대수는 정확히 2입니다. 그리고 같은 계약서가 리전 레벨 SLA의 적용 조건을 이렇게 못 박습니다.
“For Amazon EC2 with all running instances deployed concurrently across
two or more AZs in the same region … available for each AWS region with a
Monthly Uptime Percentage of at least 99.99%”
— Amazon Compute Service Level Agreement
제 식의 답과 AWS 계약서의 조건이 같습니다. 즉 저 SLA 표는 법률 문장으로 보이지만, 실제로는 1 − (1−a)n 을 계약서에 옮겨 적은 것입니다. 손잡이의 대수를 1에서 2로 넘겨 보세요 — 계기 ②의 문턱이 통째로 갈립니다.
99.99%를 약속한다는 건, 무엇을 주장하는 것인가
위 계산에는 조용한 가정이 하나 깔려 있습니다 — 고장이 서로 남남이라는 것. 현실에서는 일부 고장이 여러 대를 한꺼번에 죽입니다. DNS, 제어면, 리전 전체. 그 몫을 β로 떼어 내면 곱셈이 이렇게 바뀝니다.
뒷항에는 n 이 없다 — 그래서 대수를 아무리 늘려도 여기는 안 줄어든다.
Amax = 1 − β·q 천장
그럼 거꾸로 물을 수 있습니다. 두 벌로 99.99%를 지키려면 β가 얼마 이하여야 하나? 풀어 보면 1.5150%입니다. 다시 말해 AWS가 두 AZ에 99.99%를 약속한다는 건, 자기 고장의 98.5% 이상이 서로 독립이라고 주장하는 것과 같습니다.
★이 문장은 AWS가 한 적이 없습니다. 그들이 인쇄한 두 숫자에서 제가 역산한 것입니다. 손잡이의 β를 1.6%로 올려 보세요 — 넷째 계기가 뒤집히면서 “대수를 늘려도 못 맞춘다”로 바뀝니다. 위 그림에서 곡선들이 한 점으로 모이는 게 그 지점입니다.
9 하나가 얼마인가
가용성은 9의 개수로 말하는 관습이 있습니다. 9가 하나 늘 때마다 허용되는 정지가 10분의 1이 됩니다. 30일 기준으로 세면 이렇습니다.
| 9의 개수 | 가용성 | 30일 기준 허용 정지 | 31일 기준 | 이 등급을 쓰는 곳 |
|---|---|---|---|---|
| 2 | 99.0% | 432분 (7시간 12분) | 446분 | 크레딧 계단의 두 번째 칸 |
| 2.5 | 99.5% | 216분 (3시간 36분) | 223분 | EC2 인스턴스 한 대 · RDS 단일 DB |
| 3 | 99.9% | 43.2분 | 44.6분 | S3 표준 |
| 3.5 | 99.95% | 21.6분 | 22.3분 | Lambda · RDS 다중 AZ |
| 4 | 99.99% | 4.32분 (259초) | 4.46분 | EC2 두 AZ 이상 · DynamoDB 표준 |
| 5 | 99.999% | 0.43분 (26초) | 0.45분 | DynamoDB Global Tables |
| — | 100% | 0분 | 0분 | Route 53 (호스팅 존) |
맨 아랫줄이 이 조각의 급소입니다. Route 53은 100%를 약속합니다. 어떻게 가능하냐면, 같은 문서가 정지를 이렇게 좁게 정의하기 때문입니다 — “그 호스팅 존에 배정된 가상 네임서버 넷이 모두, 그 1분 내내 모든 DNS 질의에 응답하지 못한” 경우. 9를 늘리는 방법은 두 가지입니다: 더 튼튼하게 만들거나, 정의를 좁히거나.
DynamoDB의 Global Tables 조항도 같은 구조입니다. 표준은 99.99%인데 여러 리전에 걸치고, 문제가 나면 사용자가 직접 페일오버를 시도할 것을 조건으로 걸면 99.999%로 올려 줍니다. 다중화의 대가로 9를 하나 더 준다는 게 계약서에 그대로 있습니다.
오래 멈출수록 덜 보전받는다
크레딧은 비율입니다. 얼마나 멈췄든 그 등급의 정해진 퍼센트를 줍니다. 잃는 매출은 시간에 비례합니다. 나누면 이렇게 됩니다.
크레딧 = 크레딧% × c · R
잃은 매출 = 정지 × R/M
보전배수 = 크레딧% × c × M ÷ 정지 ← R 이 약분된다. 회사 크기와 무관하다.
손익분기 정지 = 크레딧% × c × M 이보다 길게 멈추면 계약서로는 못 메운다
↓ 이 톱니가 말하는 것
사고 시각은 AWS 자신의 사후 요약에 인쇄된 값입니다 · 2021-12-07 · 2025-10-19. 등급 판정은 각 서비스의 SLA 표를 그대로 적용한 것이고, 보전배수는 위 식으로 화면이 그 자리에서 계산합니다.
네 해 간격으로 같은 문장이 인쇄됐다
마지막이 진짜 물음입니다. 계약이 재는 정지와 내가 겪는 정지가 다릅니다. EC2 리전 레벨 SLA가 정의한 정지는 “내 인스턴스가 전부 동시에 외부 연결을 잃은 시간”입니다. 서비스가 죽어 있어도, 인스턴스가 살아서 연결돼 있으면 그 정의로는 정지가 0분일 수 있습니다.
“Existing EC2 instances that had been launched prior to the start of the event
remained healthy and did not experience any impact for the duration of the event.”
— AWS 사후 요약, 2025-10-19∼20 (사고 872분)
“while running EC2 instances were unaffected by this event,
the EC2 APIs … experienced increased error rates”
— AWS 사후 요약, 2021-12-07 (사고 412분)
네 해 간격을 둔 두 사고에서 같은 문장이 나옵니다 — 돌고 있던 것은 멀쩡했다. 두 번 다 사실이고, 두 번 다 계약서 정의에 정확히 부합합니다. 그리고 두 번 다, 그 시간에 세상의 상당 부분이 안 돌아갔습니다.
2025년 사고의 원인으로 AWS가 적은 것은 “DynamoDB DNS 관리 시스템의 잠복 경쟁 조건이 빈 DNS 레코드를 만들었다”였습니다. 이름을 풀어 주는 한 곳이 잘못된 답을 내놓자 그 위에 얹힌 것들이 함께 멈췄습니다 — 이 조각의 β가 무엇을 가리키는지, 그 사고가 이름까지 붙여 말해 줍니다.
식이 맞는지, 굴려서 확인한다
위 계기가 내놓는 Q(n, q, β) = ((1−β)·q)n + β·q는 닫힌 식입니다. 같은 규칙으로 한 달치 분을 하나씩 굴려서 멈춘 분을 세면 실측이 그 식으로 수렴해야 합니다. 안 좁혀지면 둘 중 하나가 틀린 것입니다.
굴리는 규칙은 식을 그대로 옮긴 것입니다. ① 확률 β·q로 공통원인 사고가 나면 전부 한꺼번에 죽습니다(화면이 붉게 번집니다). ② 아니면 각 벌이 저마다 확률 (1−β)·q로 죽고, 전부 죽었을 때만 서비스가 멈춥니다.
★여기서 눈으로 봐야 할 것은 ‘얼마나 자주 어두워지는가’가 아닙니다. 대수를 1벌에서 2벌로 올려도 랙 하나가 어두워지는 빈도는 그대로입니다 — 99.5%면 어느 쪽이든 0.5%의 시간에 죽습니다. 달라지는 건 둘이 같이 어두워지는 일이 거의 없다는 것뿐이고, 99.5%에서 99.99%로 건너뛰는 두 개의 9는 전부 거기서 나옵니다.
★한 칸은 30분입니다. 그 30분 안에 한 번이라도 멈추면 어둡게 칠합니다 — 1분씩 그리면 눈에 안 보입니다. 세는 건 어디까지나 1분 단위이고, 묶는 건 그리기 위해서입니다.
★대수를 늘려도 천장이 있습니다. β=1.0%면 공통원인만으로 1 − β·q = 99.9950%가 한계입니다. 각 대수에서 600달씩 굴려 보면 실측이 이렇게 나옵니다 — 1벌 99.49978% → 2벌 99.99262% → 3벌 99.99474% → 4벌 99.99494% (공식과의 차이는 전부 ±2.5 ppm 안). 1벌에서 2벌은 9를 두 개 벌어 주는데, 3벌은 이미 천장에 붙고 4벌은 거의 제자리입니다. 그 다음부터 벌을 더 사는 돈은 β를 줄이는 데 써야 합니다.
★몬테카를로는 흔들립니다. 한 달(43,200분)에 멈추는 시간이 1분 남짓이라 달마다 0분일 수도 3분일 수도 있습니다. 계속 돌릴수록 실측이 공식에 붙습니다 — 차이(ppm)가 줄어드는지를 보세요.
풀고 있는 식
Q(n) = ((1−β)·q)n + β·q 베타팩터 공통원인 모형
A = 1 − Q(n) = SLA의 Monthly Uptime Percentage
M = 그 달의 일수 × 1440 SLA가 “the percentage of minutes during the month”라고 쓴다
정지 = Q(n) × M 분
문턱 = (n = 1) ? 99.5% : 99.99% 둘 다 컴퓨트 SLA 인쇄값
크레딧% = 문턱 이상 → 0% / 99.0% 이상 → 10% / 95.0% 이상 → 30% / 그 밖 → 100%
Amax = 1 − β·q 대수를 무한히 늘려도 못 넘는 천장
βmax(n) : Q(n, β) = 10−4 를 만족하는 β 이분법 60회
한 대가 죽는 순간을 랙에서 본다
가용성 숫자는 추상적이지만, 실제로는 이 상자들 중 하나가 꺼지는 일입니다. 아래에서 무작위로 한 대씩 죽습니다 — 여벌이 있으면 서비스는 살고, 없으면 같이 죽습니다.
여벌 한 대만 두면 한 대까지 견딥니다. 두 대가 동시에 죽을 확률은 낮지만 0이 아니고, 위 판의 9의 개수가 그 확률을 세는 일입니다.
보이는 것은 독립적인 고장입니다. 현실에서 무서운 것은 같이 죽는 고장이고요 — 같은 전원, 같은 스위치, 같은 배포. 그때는 랙 전체가 한꺼번에 붉어집니다.
고장 확률과 복구 시간은 보이기 위한 값입니다. 실제 수치는 위 판의 손잡이로 넣으세요.
‘두 벌’은 슬라이더가 아니라 건물이다
위 화면에서 손잡이 하나로 넘기는 ‘n=1 → n=2’가 현실에서 무엇인지 봅니다.
① AZ는 개념이 아니라 셀 수 있는 건물이다
AWS us-west-2 가용영역을 위에서 찍은 것입니다. 큰 건물이 나란히 서 있고, 그 사이 마당에 컨테이너형 발전기가 줄지어 있으며, 오른쪽에는 자체 변전소가 통째로 붙어 있습니다.
손잡이의 n이 재는 것이 이것입니다. 1에서 2로 넘기는 데 드는 건 숫자 하나가 아니라 부지·전력·공사입니다.
② 대수를 늘리는 데 걸리는 시간
같은 리전의 다른 자리입니다. 여러 동이 서 있고 각 동을 따라 흰 컨테이너가 열 지어 붙어 있습니다. 사진 아래쪽에 철골만 올라간 건설 중인 동이 보입니다.
이 조각의 넷째 계기가 “대수를 늘려도 못 맞춘다”로 뒤집힐 때, 그게 왜 무서운 말인지를 이 사진이 대신 말해 줍니다 — 늘리는 데 몇 년이 걸리는데, 늘려도 안 되는 구간이 있습니다.
③ 다중화는 식이 아니라 물건이다
미국 애리조나주 메사의 데이터센터 예비 발전기입니다. 똑같이 생긴 흰 컨테이너가 두 줄로 여덟 대 넘게 늘어서 있고, 위에 갈색 배기 소음기가 얹혀 있습니다.
저 줄을 세면 그게 n입니다. 그리고 이 사진이 β 이야기도 같이 해 줍니다 — 발전기가 아무리 많아도 그 앞단의 모선 하나가 죽으면 다 같이 죽습니다. 대수로는 절대 못 지우는 몫이 그것입니다.
이만한 이익률로 파는 물건의 유일한 배상
클라우드 사업이 장부에서 어떻게 생겼는지 놓고 보면 이 계약이 좀 다르게 읽힙니다. 아래는 전부 각 회사의 연차보고서(10-K)에 인쇄된 값이고, 비율은 그 값끼리 나눈 것입니다.
| 부문 | 매출 | 영업이익 | 영업이익률 | 회계연도 |
|---|---|---|---|---|
| AWS | $128,725M | $45,606M | 35.43% | 2025-12-31 종료 |
| 아마존 전사 | $716,924M | $79,975M | 11.16% | 2025-12-31 종료 |
| MS Intelligent Cloud | $137,791M | $56,972M | 41.35% | 2026-06-30 종료 |
| Google Cloud | $58,705M | $13,910M | 23.69% | 2025-12-31 종료 |
★회계연도가 어긋납니다 — 마이크로소프트만 6월 결산이라 나란히 놓되 같은 해로 읽으면 안 됩니다. ★마이크로소프트는 Azure 단독 금액을 공시하지 않습니다. 인쇄된 건 성장률뿐(“Azure and other cloud services revenue grew 41%”)이라 위 칸은 서버 제품·기업 서비스까지 포함한 더 넓은 부문입니다.
아마존 쪽 두 문장이 특히 눈에 띕니다. AWS는 아마존 매출의 17.96%인데, 영업이익의 57.03%입니다. 그리고 같은 10-K가 2025년 설비투자 1,283억 달러를 적으며 “그 대부분이 AWS 성장을 뒷받침하기 위한 것”이라고 씁니다.
규모를 분으로 환산하면 이렇습니다. AWS 매출은 분당 약 $244,911(= $128,725M ÷ 525,600분). 99.99%가 허용하는 4.32분에 AWS 자신이 파는 돈이 약 106만 달러입니다. 그 4.32분을 넘겨야 비로소 크레딧이 걸리고, 그 크레딧은 내 청구서의 10% 차감입니다.
한 줄 더. 같은 10-K에 “2025년 1월 1일부로 일부 서버·네트워크 장비의 내용연수를 6년에서 5년으로 다시 잡았다”고 적혀 있습니다 (감가상각 14억 달러 증가, 순이익 10억 달러 감소, 주로 AWS 부문에 영향). “한 대는 어차피 망가진다”가 회계장부에 나타난 얼굴입니다.