This is what a 14-day read-only pilot returns for your estate — a genuine architecture-cost review, here generated from a fictional demo estate so you can read the shape of the output before connecting anything. Every figure is projected and stays projected until your real bill settles.

CloudJaeger

Architecture-cost review AWS only

Aurora Robotics (Demo)

Generated 2026-06-15 00:00 UTC

Advisory only — CloudJaeger executes nothing against your cloud.

Executive summary

Architecture health

84 / 100

medium confidence

Total projected savings

$688.95/mo

Projected across 2 recommended actions

Not evaluated: rules cover AWS only (5 Azure and Google Cloud resources unchecked).

What to do first

1. Reduce NAT data-processing spend$365.45/mo Projected
2. Rightsize 2 underutilized resource(s)$323.50/mo Projected
3. Apply storage lifecycle + snapshot cleanup

Current architecture

Resources reviewed

Billed spend

$66,784 · billing 30d

18 resource(s) across the synced estate, grouped account → region → VPC.

Architecture map

Grouped account → region → cluster from your synced inventory. Cost rollups are shown in the interactive review; this print map shows structure only.

Resource-attributed inventory cost

$3,868/mo · known inventory nodes only, not the complete bill

Top billed cost groups

Amazon Elastic Compute Cloud - Compute$12,710/mo +7% MoM
Virtual Machines$7,139/mo +7% MoM
Amazon Relational Database Service$6,759/mo +13% MoM
Compute Engine$5,051/mo +11% MoM
Amazon Simple Storage Service$4,046/mo +8% MoM

Recommended target architecture

Conservative — optimize in placeConservative posturelow confidence

Component swaps

Node changes

5 changed · 0 added · 0 removed

Projected cost movement

−$323.50/mo Projected

Migration & rollback

Migration risk: LowRollback: Low

Top risks & rollback

2 instance(s) hosting the candidate workload

Containerizing a single, efficient, stable, poorly-understood, or compliance-constrained workload adds operational surface with no density or elasticity payoff — the decision tree refuses those cases.

Mitigation: Keep the original instances (stopped, not terminated) and the pre-migration AMIs/launch templates until the containerized workload has run a full billing cycle; cut traffic back to the instances if regressions appear.

Migration: MediumRollback: High

2 instance(s) on x86 families

This rests on ARM64 compatibility we have NOT confirmed: if any runtime dependency, vendor agent or native binary lacks a working ARM64 build, the move breaks for that instance. A family match alone is not proof the workload runs on ARM.

Mitigation: Relaunch the instance from the original x86 launch template / AMI; the change is a family swap, fully reversible.

Migration: MediumRollback: Low

2 instance(s) with measured CPU headroom

A downsize removes burst headroom: an infrequent spike outside the sample window, a latency-sensitive burst, or burstable-credit behaviour can throttle the smaller size — validate against peak events before applying.

Mitigation: Resize back to the original instance type from the same AMI / launch template; an instance-size change is fully reversible.

Migration: LowRollback: Low

Missing-data caveats

What would firm up these figures. Until then, projections carry the confidence shown above.

2 instance(s) on x86 families · blocking — ARM64 dependency-compatibility check per instance (confirm every binary/agent has an ARM64 build); Real per-family price delta to project the saving
2 instance(s) hosting the candidate workload · blocking — Memory utilization (p95) for the candidate instances; Request/throughput metrics for the workload; Whether the workload is stateless, adaptable, or stateful; Software licensing terms (container portability); The current deployment model (manual / scripted / container-ready); The team's container/orchestration skill (or willingness to use Fargate)
2 instance(s) with measured CPU headroom — Confirm the target instance size + its real price delta per instance before applying