AEGIS AI Cloud Engineer

AI cloud engineer that monitors AWS infra, predicts overload before it happens, simulates fixes, and auto-applies + rolls back changes with full Postgres audit trail.

Comment

Inspirati## Inspiration

Cloud infrastructure teams live in a reactive loop: something breaks, an alert fires, and only then does anyone touch the auto-scaling group. We wanted to flip that — an AI cloud engineer that watches infrastructure continuously, predicts trouble before it happens, lets you safely simulate a fix, and only then applies it to AWS — with a human still in the loop, and an automatic rollback if the fix doesn't hold.

What it does

Aegis is a full 5-stage pipeline in one dashboard:

  1. Monitor — live KPI cards (CPU, memory, requests/min, network, error rate, DB latency), a 14-day traffic/latency chart, and an AI-written daily report.
  2. Predict — a least-squares forecast projects request volume 7 days out and flags exactly when current capacity runs out, plus an anomaly/risk feed.
  3. Simulate — an interactive Load Balancer → Servers → Database diagram. Adjust traffic multiplier, server count, cache and DB-scaling toggles, and the backend computes real latency, utilization, and monthly cost for three candidate configurations.
  4. Recommend — a plain-language recommendation naming the best-tested configuration, with alternatives shown side by side, waiting on Approve/Dismiss.
  5. Automate — Approve triggers a real backend pipeline: it calls AWS (if configured), verifies the result, and automatically rolls back if verification fails — every step logged to Postgres as an audit trail, replayed in the UI as a live console log.

How we built it

  • Frontend: Next.js 14 (App Router) + React, Recharts for the two live charts, hand-built inline SVG for the architecture diagram that redraws from live simulator state.
  • Backend: Next.js API routes (app/api/*/route.js) — genuinely server-side: all math, request handling, and persistence happen there, not in the browser.
  • Database: PostgreSQL via the pg driver (raw SQL) — four tables (metric_snapshots, simulations, automation_runs, automation_steps), with every simulation and automation run persisted with a full step-by-step audit log.
  • Cloud: AWS SDK v3 (@aws-sdk/client-cloudwatch, @aws-sdk/client-auto-scaling) wired in for real — GetMetricData for live CPU/network telemetry, UpdateAutoScalingGroup to actually resize a target Auto Scaling group.
  • Graceful degradation by design: neither AWS credentials nor a database are required to run the app. Without them, it transparently falls back to realistic simulated telemetry and an in-memory audit log with the exact same API contract — honestly demoable in two minutes, and a real integration the moment credentials are added. A badge in the header always shows which mode you're in.

Challenges we ran into

  • Designing a data model and API contract where the same endpoints behave correctly whether or not external services (AWS, Postgres) are configured, instead of hard-failing — every write path needed an in-memory mirror of the SQL schema.
  • Making the "AI recommendation" text actually derived from computed forecast/simulation numbers rather than scripted, so the pipeline stays honest end-to-end.
  • Wiring real AWS SDK v3 calls inside Next.js API routes and handling failure/timeout paths safely enough that a demo never breaks, even with invalid or missing credentials.

Accomplishments that we're proud of

  • A genuinely working 3-tier app — not a static mockup — that still runs with zero configuration.
  • A real, server-side cost/latency simulation model instead of faked UI numbers.
  • An automation loop (apply → verify → rollback) implemented as an actual state machine, not a canned animation.

What we learned

Building infrastructure tooling that degrades gracefully is harder than it looks — the pattern real ops tools need (CI environments, local dev, partial outages) forced us to think about every write path twice: once for the real service, once for the fallback.

What's next for Aegis

  • Swap the templated report/recommendation strings for a real LLM call (e.g. the Anthropic API), fed the same computed metrics/forecast/simulation JSON the app already produces.
  • Replace the linear forecast with a proper time-series model.
  • Stream automation pipeline steps over Server-Sent Events instead of client-side replay of the final log.
  • Add a Terraform-backed apply step for full plan/diff/apply auditability.on

Built With

Share this project:

Updates

Submission history