Cloud Disaster Day

Simulate outages, scaling events, and cascading failures in cloud architectures using an AI-powered Cloud World Model before they happen in production.

Comment

Inspiration

Every cloud engineer has lived through the 3 AM page: DynamoDB starts throttling, a region goes dark, a queue backs up, and the bill quietly explodes while you scramble. The hard part isn't knowing the services exist it's developing the instinct for which architectural decisions actually hold up under fire, and which ones look fine on a diagram but crumble the moment real chaos hits.

We wanted to turn that high-stakes, war-room pressure into something you could practice safely and actually enjoy. So we built Cloud Disaster Day: design an AWS architecture, then survive a barrage of escalating disasters while an AI world model scores how your infrastructure really behaves. No live AWS account, no real bill, no career-ending outage required.

What it does

Cloud Disaster Day is an SRE war-room simulation game:

  1. Build it — Compose an architecture from 11 AWS services (EC2, EKS, DynamoDB, RDS, ElastiCache, SQS, ELB, CloudFront, S3, AWS Backup, WAF/Shield) on a strict hourly budget. Bump instance counts, toggle Multi-AZ, and watch your $/hr spend against the ceiling.
  2. Break it — Pick a difficulty tier (Recruit / Operator / Chaos Lord) and the system throws a randomized sequence of disasters at you: traffic spikes, DynamoDB throttling, queue backlogs, region outages, database corruption, and cost explosions. Traffic escalates every round, so later disasters hit harder.
  3. Survive it — Between disasters you make real architecture decisions: reinforce with services that counter the incoming threat, or decommission over-provisioned infrastructure to free budget (at the cost of a migration penalty). The Cloud World Model simulates each outcome and returns live telemetry — error rate, CPU load, p95/p99 latency, throughput, and cost per hour.
  4. Score it — Each round blends resilience with operational metrics and budget efficiency into a score and letter grade, scaled by difficulty. Completed runs publish to a global leaderboard.

The core scoring intuition is simple: reward designs that stay up, stay fast, and stay cheap. Resilience is weighted most heavily, but uptime, latency, and budget pressure all factor in:

$$score = (resilience \times 6 + uptime \times 1.5 + latency + efficiency + bonus) \times multiplier$$

How we built it

  • Frontend: Next.js (App Router) and React, styled with Tailwind CSS and shadcn/ui in a dark "mission-control" theme — grid background, scanlines, and live status colors for a tense ops-console feel. Vercel v0 let us go from concept to a polished, fully interactive UI incredibly fast.
  • Simulation engine: The Cloud World Model API (cloudworldmodel.ai) is the brain. We create a simulation from the player's resources, step it with elevated traffic to pull real metrics, and run chaos scenarios (zone failures, database crashes, network partitions, CPU stress, and more) to measure resilience. We added a deterministic local fallback engine so the game stays fully playable even if the API is unavailable.
  • Persistence: Amazon DynamoDB stores everything — architecture state, full event history, scores, and the leaderboard — using a composite PK/SK key with a single sorted partition for fast top-N leaderboard queries, accessed via IAM auth (no static keys).
  • Backend: Next.js route handlers orchestrate the game loop: create game, inject the next queued disaster, apply reinforce/decommission decisions, and finalize scores.

This project sits at the intersection of AI, simulation, education, gaming, and AWS databases.

Challenges we ran into

  • Reverse-engineering a live API: The Cloud World Model docs are client-rendered, so we probed the real endpoints directly to learn the exact request/response contracts resource type enums, auth scheme, and which routes are guest-accessible versus key-gated.
  • DynamoDB key schema: Our first writes failed with Missing the key SK because the table uses a composite key. We inspected the live schema, then redesigned our access layer around a PK/SK model with query-based leaderboard reads instead of scans.
  • Base UI vs Radix: The dialog components used a render prop instead of asChild, which broke our triggers until we adapted the pattern.
  • Making decisions meaningful: A game where you can only add resources isn't a real trade-off. We added budget ceilings, per-service costs, escalating traffic, and a costed decommission action so every choice has tension.

Accomplishments that we're proud of

  • A genuinely fun, end-to-end playable game wired to a real AI world model and a real AWS database not a mockup.
  • Resilient by design: the local fallback engine means the experience never breaks, even if the upstream API hiccups.
  • A mission-control UI that makes infrastructure feel dramatic and alive live telemetry, an event log, and disaster cards with real stakes.
  • Replayability: randomized disaster order, three difficulty tiers, budget management, and a global leaderboard keep runs fresh.

What we learned

  • How to model cloud resilience as a scoreable system translating chaos-engineering outcomes into game mechanics that teach real intuition.
  • Practical patterns for DynamoDB single-table design and IAM-based access from a serverless app.
  • That the best educational games hide their lessons inside tension and trade-offs budget pressure taught more about architecture than any static diagram could.
  • How fast a well-scoped idea can go from prompt to production with v0.

What's next for Cloud Disaster Day

  • Cascading failures where one disaster can trigger another, and multi-region topologies.
  • Custom scenario builder so educators can author their own disaster sequences.
  • Team mode — co-op war rooms where players own different parts of the stack.
  • Visual architecture canvas with drag-and-drop connections and dependency-aware blast radius.
  • Post-mortem export — a shareable after-action report summarizing every decision and its impact.

Built With

Share this project:

Updates