E

EdgeUp Cloud Economics

Executive decision matrix · 5 projects × 5 hosting options · sized by concurrency
Registered
total sign-ups
Peak concurrent
5% · 1:20 ratio
sizing rule  concurrent = 5% × registered
📐 How the numbers work — concurrency ↔ user-base sizing rule

Server size depends on concurrent users (online at the same second), not total sign-ups. Total users = everyone who signed up. Concurrent = how many use the app in the same second — always a small slice, since most are offline. (Like a gym with 2,000 members but ~100 on the floor at peak — you equip for the 100.)

The rule: peak concurrent ≈ 5% of total registered users — a 1:20 ratio — the industry norm for self-paced apps (≈50% active monthly × ≈30% daily × ≈33% online at the evening peak). After launch this estimate is replaced by the measured number and the servers autoscale to it.

Change the selectors above — concurrent load, infrastructure sizing, and every option's monthly cost recompute live. All cloud figures are estimated minimums: list price × 18% GST × 5% safety buffer.

📋 Cost-benefit analysis (full page) →

Decision matrix

🗺 Architecture
✓ 20/20 prices verified against official sources · 12-Jun-2026 ✓ Colleges curve anchored on own JMeter load test — 2,000 concurrent: nodes 5→20-22, Aurora 0.5→3.2 ACU ✓ Competitive-B2B curve anchored on own 7-May load test — 2,000 concurrent: Aurora 1.6→32 ACU (ceiling) — DB-heavy profile