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

Aurora Robotics (Demo)

Generated 2026-06-15 00:00 UTC

Advisory only — CloudJaeger executes nothing against your cloud.

Executive summary

Architecture health

81 / 100 partial (5/6 scored)

medium confidence

Total projected savings

$365.45/mo

Projected across 1 modeled figure

What to do first

1. Reduce NAT + data-transfer spend$365.45/mo Projected
2. Apply storage lifecycle + snapshot cleanup

Current architecture

Resources reviewed

Billed spend

$66,301 · 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,600/mo +6% MoM
Virtual Machines$7,139/mo +7% MoM
Amazon Relational Database Service$6,463/mo +8% 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

4 changed · 0 added · 0 removed

Projected cost movement

−$365.45/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

NAT-gateway-heavy layout

VPC endpoints are NOT free: interface endpoints carry an hourly charge PLUS a per-GB data-processing fee, so below a traffic threshold the endpoint cost can EXCEED the NAT saving, and some destinations have no endpoint at all.

Mitigation: Remove the VPC endpoints and restore the original route tables; traffic falls back to the NAT gateway.

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 — CPU utilization (p95) for the candidate instances; 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)
NAT-gateway-heavy layout — Per-destination NAT/egress breakdown to replace the assumed endpoint-eligible share with a measured one