Skip to content
CloudPouch Docs

AWS read-only access

CloudPouch needs read-only access to your AWS account — nothing more. It does not create, modify, or delete AWS resources, and it needs no IAM administration rights: no attaching policies, no creating users, no changing roles. You can run CloudPouch under a policy that grants only read actions.

Why reads are enough

Section titled “Why reads are enough”

CloudPouch’s job is analysis: it joins your AWS billing data with the metadata of deployed resources to explain where spend comes from and what could be optimized. That means calls like describing EC2 instances and EBS volumes, listing RDS databases, reading Lambda configuration, or inspecting S3 and EFS metadata — reads of configuration and cost data, never changes to it.

When CloudPouch finds something worth fixing — a fleet of GP2 volumes, an idle NAT Gateway, snapshots nobody needs — acting on it is your decision, made through your own change process. CloudPouch shows the finding and the estimated saving; it does not delete or modify anything on your behalf. That separation is deliberate: a cost-analysis tool with write access is a much harder security conversation than one that can only look.

How to scope access

Section titled “How to scope access”

Use any existing identity that already has the read access you need — an AWS profile, an IAM Identity Center (SSO) role, an IAM role, or an IAM user. The simplest setup is a profile whose role already carries broad read access to the account you want to analyze.

If your security process requires a minimal policy instead, start from the read-oriented policy in AWS permissions and narrow it after confirming the Cost Insights you rely on still run. The step-by-step IAM policy guide walks through creating a dedicated identity for CloudPouch.

What happens when a permission is missing

Section titled “What happens when a permission is missing”

Nothing breaks, and nothing is guessed. CloudPouch distinguishes “there is nothing to optimize here” from “I could not check this.” Blocked AWS API calls — AccessDenied, OptInRequiredException, and similar — are collected and shown as permission issues listing the affected service, region, API operation, and AWS error code, so you can extend the policy precisely instead of granting broad access to make errors disappear.

A missing permission is never a reason to grant write access. If a Cost Insight reports a permission issue, add the specific read action it names.

Section titled “Related pages”