# AWS IAM permissions

> ZopNight needs 248 read-only IAM permissions to discover an AWS account, read CloudWatch metrics and pull Cost Explorer data. Write access is a separate CloudFormation stack you can decline: 186 permissions covering only start, stop, scale and remediation. Neither grant can read object contents or database rows.

Source: https://zop.dev/integrations/aws/permissions
Updated: 2026-08-20

---

## Common questions

### What IAM permissions does ZopNight need on AWS?

248 read-only permissions to discover the account, read CloudWatch metrics and pull Cost Explorer data. Write is a second, separate CloudFormation stack of 186 permissions covering start, stop, scale and remediation. Most teams run on the read grant indefinitely and never install the second.

### Can ZopNight read my S3 objects or database rows?

No. Neither grant reaches object contents, database rows or secret values. It reads metadata, metrics and billing, and stopping a resource is the most it can do even with write installed.

### How do I check what a credential can actually do?

The probe permissions exist for that. After you connect, ZopNight runs a per-action check and shows a verdict per capability, so a policy missing ec2:StopInstances surfaces before a schedule fails silently at 8pm rather than after.

## Two separate IAM grants, read then write

ZopNight asks for two grants, and they are separate on purpose. The first is read-only: 248
permissions that let it discover your estate, read CloudWatch metrics and pull cost data. It
cannot start, stop, resize or delete anything with that grant. Most teams run on it
indefinitely and never issue the second.

The second grant adds 186 write permissions and only matters if you want ZopNight to act:
schedules that stop instances at night, or one-click remediation. It ships as its own
CloudFormation stack, so declining it is the default rather than an exception.

## Which connection method should I use?

Three are supported. Prefer the first.

- **Assume role**: a cross-account IAM role ZopNight assumes via STS. No secret is ever stored
  on our side. Created by a one-click CloudFormation stack, and the only method that supports
  the one-click billing upgrade.
- **Static access keys**: a long-lived key pair. Works everywhere, but you own rotation, and
  the secret sits at rest in our credential store.
- **Temporary credentials**: short-lived STS credentials. Most restrictive, but they expire,
  so something has to refresh them.

You can switch between all three in place on an existing account.

## What the read-only role is used for

| Purpose | What it reads |
|---|---|
| `discovery` | Resource inventory across every region, on a 6-hour cycle |
| `cost` | Cost Explorer or CUR 2.0, for per-resource spend |
| `recommendations` | The signals rules evaluate: utilisation, attachment state, configuration |
| `probe` | A permission self-check, so the UI can tell you what is missing before you hit an error |

## What the write role can do, and what it can never do

Write permissions are scoped to lifecycle and remediation: start and stop instances, scale
groups to zero, pause databases, delete resources a recommendation identified. They are grouped
under `scheduling`, `remediation`, `provisioning` and `deployments`.

Nothing in either grant can read object contents, database rows, or secret values. ZopNight
reads metadata, metrics and billing, and never your data.

## How do I check what a credential can actually do?

The `probe` permissions exist for this. After connecting, ZopNight runs a per-action check and
shows a verdict for each capability, so you find out that a policy is missing
`ec2:StopInstances` before a schedule fails silently at 8pm rather than after.