Shoham Fellner

Selected Work
Case Study

Aura Cloud

AWS Resource Monitoring · Academic Project · 2026

Resolves who can actually do what across AWS, and flags where identity and policy disagree.

RoleFull-Stack Developer & UX/UI
Stack

[React] [Node.js] [AWS] [MCP]

Source Code
Dashboard - identity permission status
Academic Project
Aura Cloud interface

Real screenshots from the working app, run locally against our own test AWS account - not a hosted, public product yet.

01

The Stakes

A year-long academic project, built with two teammates - not a company, though the shape of it could support real usage.

Identity and policy drift apart constantly in a real AWS account, and the two places you'd normally check - IAM policy, and what's actually allowed - rarely agree on their own. Getting that resolution wrong means either missing a real over-permission, or flagging one that isn't real.

02

My Role

A team of three, and I covered the most ground across it: UX/UI, the frontend, the API server, and part of the MCP server - the parts of the system a user or an LLM client actually touches, all reading from the same MongoDB.

My teammates owned the rest: managing our AWS test environment, the crawlers that pull live data from AWS into Redis, and the logic service that reads Redis and writes verdicts back to MongoDB.

03

The Problem

Aura Cloud resolves something narrower and harder to get right than a resource map: which policies actually apply to a given identity, and whether AWS would allow or deny a specific action once those policies, and the account's cross-account rules, are all applied together.

IAM's own evaluation logic isn't simple. An explicit deny always wins, an unmatched action is denied by default, actions and resources can match on wildcards, and the same-account rule - identity or resource allows it - is not the cross-account rule, where both have to. Reproducing that correctly, not approximately, was the actual work.

04

Decisions

A stale verdict outranks a blocked one

Constraint
A permission verdict is only as good as how recently it was computed - and a resource can look blocked when the real cause is that nobody's re-evaluated it recently.
Decision
Any verdict older than 60 seconds shows as stale, even when the last real answer was "blocked".
Trade-off
A genuine active block becomes briefly invisible once it goes stale - deliberate, since we'd rather a user re-check a stale resource than chase a block that's already been fixed.

A throwaway write to catch a real race condition

Constraint
Two requests demoting the last manager of a company at the same time could both succeed, leaving the company with no manager at all - and a plain count-then-check has a window where that race slips through.
Decision
Force a shared-document write inside a Mongo transaction purely to trigger write-conflict detection, so the second concurrent request fails instead of racing.
Trade-off
A write whose only purpose is to make the database catch the race for us - simpler to reason about than managing the lock ourselves, at the cost of looking odd out of context.

Login identity and AWS identity are two different documents

Constraint
A customer can sign up before Aura Cloud has discovered anything about them in AWS - the two identities don't necessarily arrive together.
Decision
Keep Company, Customer (login identity) and User (AWS-discovered identity) as separate documents, linked by an external id, instead of one combined record.
Trade-off
Every permission lookup needs an extra hop between documents to resolve - accepted so a customer's account isn't blocked on AWS discovery finishing first.
05

Evidence

Real screenshots from the working app, run locally against our own test AWS account.

Permission status per identity, resolved from IAM.
Permission status per identity, resolved from IAM.
The same evaluator, queried conversationally through MCP.
The same evaluator, queried conversationally through MCP.
The watchlist a user manages, resources tracked over time.
The watchlist a user manages, resources tracked over time.
A manager's view across the company's users and permissions.
A manager's view across the company's users and permissions.
06

Outcome

Built end to end over a full academic year: six live crawlers pulling real AWS data through the AWS SDK, a logic service resolving IAM's evaluation rules correctly, a dashboard, and an MCP server exposing the same evaluator to an LLM client.

Done developing. The initial architecture held without a rework from the first version through to now - the one real cost it carries is covered below.

07

What I'd Change

Extend coverage to more AWS resource types beyond what's there now - identity-to-policy resolution is solid, and the natural next step is breadth, not a rebuild.

The one real cost in the current design is the extra indirection every permission lookup pays for keeping login and AWS identity separate - worth watching if this ever became a real product rather than a project.