Skip to content

Desktop app vs SaaS

CloudPouch is a desktop application, not a SaaS platform. Your AWS cost and resource data flows between AWS and your computer, and CloudPouch does not store it — or your credentials or analysis results — on CloudPouch servers. If your security team asks “where does our billing data go?”, the answer is: it stays between AWS and the analyst’s machine.

AWS account <-> your computer (cost and resource data)
your computer -> CloudPouch servers (license key + machine ID, at app launch)
your computer -> GitHub Releases (update check, at app launch)

CloudPouch reads AWS cost and resource metadata through the local AWS profile you select, using your existing credentials on your machine. Analysis results, cache files, logs, and configuration are stored locally on your desktop — see Local files for the exact paths.

There is no vendor-side copy of your data. CloudPouch does not store your AWS cost data, resource metadata, AWS credentials, or Cost Insight results on CloudPouch servers, and it sends no telemetry, crash reports, or product analytics. Its outbound connections besides AWS API calls are exactly two: license key verification at app launch (the license key plus a machine identifier) and an update check against CloudPouch’s GitHub Releases. Neither carries your AWS data.

CloudPouch does not require deploying infrastructure into AWS. No cross-account IAM role for a vendor, no CloudFormation stack, no agent, no data-export pipeline. You grant nothing to a third party’s AWS account.

Instead, CloudPouch reads the same AWS CLI-compatible configuration you already have on your machine:

  • Static credentials in ~/.aws/credentials.
  • AWS IAM Identity Center (SSO) profiles in ~/.aws/config, including shared sso-session blocks.
  • Role-chaining profiles that use source_profile.

Profiles built on these patterns work with CloudPouch unchanged. Details in AWS credentials and SSO profiles.

A hosted cost-analysis platform typically needs your AWS billing and resource data copied into the vendor’s cloud environment, and usually a persistent connection to your account — commonly a cross-account role the vendor assumes on a schedule. That creates a second copy of sensitive data whose storage, retention, and access controls you have to assess and keep assessing.

With CloudPouch there is no second copy. The sensitive data stays between AWS and your computer, so there is no vendor-side copy of your billing data to attack. This matters when:

  • Your security policy restricts sending billing and resource data to third-party data stores.
  • You want to reuse existing local AWS profiles and SSO sessions instead of provisioning vendor access.
  • You cannot, or do not want to, install third-party infrastructure into your AWS account.
  • You need analysis results and cached data to stay on the analyst’s machine.

The claims your security team will want, in one list — each verifiable:

  • Access is read-only. CloudPouch needs no permissions to create, modify, or delete AWS resources. See AWS read-only access and the exact IAM policy in AWS permissions.
  • No telemetry. CloudPouch sends no telemetry, crash reports, or product analytics.
  • Credentials stay local. CloudPouch uses the credentials already in ~/.aws/ to sign AWS API requests; they are not sent to CloudPouch servers.
  • Cost data stays local. All analysis runs on your machine; results and caches live in local files you can inspect.
  • No vendor-side data store. CloudPouch servers handle license key verification, and the app checks GitHub Releases for updates at launch; your cost data, resource metadata, credentials, and Cost Insight results are not stored on CloudPouch servers.
  • Revocation is instant and on your side. Remove or restrict the local AWS profile and CloudPouch has no access — there is no vendor-held credential to rotate.