Skip to content

Limitations

CloudPouch cannot restore per-opportunity detail to a Savings Scan saved on the Free plan, applies a plan change only after you restart the application, and can lose a just-finished scan if you quit CloudPouch before it is saved. Those three boundaries catch people out most often. The rest of this page covers analysis accuracy, the AWS credential profiles CloudPouch does not resolve, one keyboard shortcut, cached AWS cost data, and very large AWS accounts.

Runs saved on the Free plan stay summary-only after you upgrade to Pro. A Savings Scan captured while CloudPouch is on Free never gains per-opportunity detail retroactively. Upgrading does not backfill detail into runs that were already saved. Run one fresh Savings Scan on Pro to restore full detail for that AWS profile going forward.

CloudPouch validates its license once per application start. Any plan change — including a Pro trial expiring, or an upgrade you just completed — takes effect the next time CloudPouch starts, not during a session that is already running. CloudPouch does not re-validate periodically while it runs.

See CloudPouch Free and Pro plans for what each plan includes.

A finished Savings Scan can be missing after an immediate quit. CloudPouch saves runs asynchronously. If you quit the application right after a scan completes, the save may not have started or finished, and the run is absent when you start CloudPouch again. Writes are atomic once they begin, so a partial or corrupted run file is not the hazard — a missing run is, and one fresh scan recreates it. If you want to be sure a run is kept, give CloudPouch a moment before quitting.

An EC2 instance with no CloudWatch utilization metrics can still be classified as over-provisioned. When metrics are unavailable — for example on an instance launched very recently — CloudPouch classifies from configuration and pricing alone. The opportunity carries a callout warning you about this, but the classification itself is a known exposure: treat those findings as candidates to investigate, not as measured waste.

Some AWS credential-profile shapes are not resolved in this version of CloudPouch. CloudPouch deliberately declines a defined set of AWS credential-profile configurations. Each one fails with a specific error naming the profile and the configuration CloudPouch cannot resolve, rather than a generic credentials failure.

The complete list of unsupported profile shapes, and the guidance that is available for them, is on Credential helpers and role chains. A verified workaround does not exist for every shape.

Cmd/Ctrl + A opens the Billing view instead of selecting all. Outside text fields, Cmd + A on macOS and Ctrl + A on Windows and Linux is a CloudPouch view shortcut, not select-all. Inside an input or text field it still selects that field’s text. This is an accepted trade-off. The full list is on Keyboard shortcuts.

The cache compatibility check does not reject files written by newer CloudPouch versions. Cached cost files written by CloudPouch 1.49.0 or newer are reused after you upgrade, so upgrading does not force a fresh round of Cost Explorer calls. The check is one-directional: a cache file written by a CloudPouch version newer than the one currently running is also treated as compatible — which only matters if you manually downgrade to an older CloudPouch. See Data refresh and cache.

CloudPouch is built to survive accounts far larger than typical ones, and the product team has measured that on real accounts — but measurements are evidence, not promises.

  • A bulk Savings Scan on one real AWS account that produced roughly 50,000 opportunities across 16 regions completed without exhausting the application’s memory, persisted the finished run, and showed the completion dialog.
  • Large Cost Insights tables mount only the rows you can see. Tables above 200 rows render inside a bounded scroll viewport, with every row reachable by scrolling and the visual design unchanged; tables at or below 200 rows render exactly as before. On that same account, expanding an EBS snapshots section of roughly 42,000 rows mounted only the couple of dozen rows on screen.
  • Filtering the Opportunities table is still heavier on very large runs. On accounts producing roughly 9,000 opportunities, filtering the Opportunities table feels slower than on a typical account, even though the account-wide slowdown itself is resolved. This is an open residual, not a fixed problem.

These figures come from instrumented runs on single real AWS accounts. They are not a supported maximum, a capacity limit, a sizing guide, or a performance guarantee. CloudPouch does not publish a supported account size.