LiveOps

Watch an AI agent build real AWS infrastructure, break it, and fix it live teaching cloud reliability through real incidents, not slides. Powered by GPT-5.6.

Comment

Inspiration

Cloud infrastructure is usually taught through diagrams, slides, and toy environments. That helps explain the vocabulary, but it does not show what failure actually feels like. As a team of IT students , we have been in constant loop of AWS learning and it's certifications and things like core production level infra , visualizing it via some images or maybe some Certification one-shot , is never a possible task but we tried simplifying it via this Project named "LiveOps"

We wanted to build something closer to the real experience of being on call: a system exists, one part fails, the data tells you why, and you recover it without guessing. LiveOps was inspired by the gap between learning “load balancing” in theory and seeing a real load balancer route around a failed server.

What it does

LiveOps teaches infrastructure reliability through a live AWS lesson. A learner builds a real Application Load Balancer with three EC2 targets, explores the running system, deliberately removes one target, diagnoses the failure from AWS target-health data, and restores it. The experience is split into five steps:

  1. Build the infrastructure.
  2. Explore the real topology and current state.
  3. Break one target safely.
  4. Diagnose the exact cause from AWS telemetry.
  5. Fix it and verify that it becomes healthy again. Every AWS action is streamed into the interface as it happens. The diagram, command feed, target health, lessons, and checkpoints are driven by the same event stream.

How we built it

We built the frontend in Next.js and TypeScript, with a live topology view, lesson panels, checkpoints, replay mode, and Socket.IO updates. The backend is built with NestJS, PostgreSQL, Socket.IO, the AWS SDK, and the OpenAI SDK. It uses a session-based state machine: created → building → ready → broken → diagnosing → fixing → completed The AWS layer provisions and controls a real ALB, target group, EC2 instances, health checks, and listener. We added an allow-list so the model can only trigger the verified action for the current lesson phase. GPT-5.6 narrates the process and interprets live DescribeTargetHealth data during diagnosis. We used Codex throughout the build to design the backend flow, review frontend/backend contracts, improve the AWS lifecycle, add tests, and audit safety and cleanup paths.

Challenges we ran into

The hardest part was making real AWS safe enough for a public learning product. Provisioning infrastructure is slow, billable, and easy to leave behind if something fails halfway through. We had to handle partial failures, operation locking, session expiry, explicit teardown, resource TTLs, concurrency limits, rate limits, sandbox-account verification, and a separate budget alarm. Another challenge was avoiding a fake demo. We wanted the interface to look polished, but the diagram and health timeline had to reflect live AWS responses rather than canned animations. A full live build can also take several minutes. To make the project reliable for judges, LiveOps includes a clearly labelled replay of a real completed session.

Accomplishments that we're proud of

  • Turning a real AWS failure-and-recovery loop into a lesson someone can follow without prior cloud experience.
  • Building a live event pipeline where every AWS action is persisted, streamed, and reflected in the UI.
  • Keeping the model useful without giving it arbitrary cloud access.
  • Letting GPT-5.6 read real target-health telemetry and explain the specific failure in plain language.
  • Treating cost control and cleanup as product requirements, not an afterthought.
  • Capturing a real run and replaying it through the same interface used for live sessions.

What we learned

We learned that the hardest part of an agentic infrastructure product is not making an API call. It is defining safe boundaries around what the agent can do, making failures understandable, and ensuring the system cleans up after itself. We also learned that education improves when the learner can connect an action to an outcome immediately. “A target was deregistered” is abstract. Watching traffic continue through the remaining healthy targets makes the idea stick. Most importantly, we learned that reliability features—locks, retries, cleanup, rate limits, diagnostics, and replay—are not background engineering. They are what make a real demo trustworthy.

What's next for LiveOps

Next, we want to expand beyond load balancing into more reliability lessons:

  • Caching: visualize cache hits, misses, and invalidation.
  • Container orchestration: show scaling, scheduling, and failover.
  • Database replication: demonstrate replication lag, failover, and recovery.
  • More failure scenarios: unhealthy health checks, bad deployments, network failures, and capacity exhaustion. We also want to add learner progress over time, richer incident timelines, and guided scenarios where learners choose the diagnosis or remediation before seeing the answer.

Built With

Share this project:

Updates