> ## Documentation Index
> Fetch the complete documentation index at: https://docs.amnify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# AWS Permissions

> How Amnify connects to AWS with read-only access, using either an assumed scan role or an access key.

## How Amnify authenticates

You connect AWS with an IAM identity that you create in your own AWS account and grant read-only access. There are two ways to do it, and you choose in the **Connect AWS** dialog.

<CardGroup cols={2}>
  <Card title="Assume role" icon="shield-halved">
    **Recommended.** An IAM user with a read-only access key, plus a dedicated **scan role** that user may assume, gated by an **external ID**. The access key is used only to call STS `AssumeRole` and take on the scan role for the duration of a scan.
  </Card>

  <Card title="Access key" icon="key">
    **Simpler.** A read-only access key that Amnify uses directly, with no role to assume. Fewer steps to set up, but it keeps one long lived credential in play, which is why assume role is the better default.
  </Card>
</CardGroup>

With assume role, the scan role's trust policy is authored by you and names your own IAM user as the trusted principal. The external ID is a condition on that trust, so the role cannot be assumed without the value Amnify generates for you, even by someone holding the key.

Either way, the access key is validated once with an STS `GetCallerIdentity` call, then stored **encrypted at rest**. Amnify never returns the secret back through its API, and it scrubs the stored credentials when you disconnect. You supply a credential you control and can rotate or revoke in IAM at any time.

## Steps to connect

<Tabs>
  <Tab title="Assume role (recommended)">
    <Steps>
      <Step title="Create a read-only IAM user and access key">
        In the AWS console, create an IAM user (or reuse a dedicated one) and attach read-only access, described in [Tier 1](#tier-1-account-read-access-required) below. Create an **access key** for it; you will paste the access key ID and secret into Amnify.
      </Step>

      <Step title="Copy the external ID from Amnify">
        In Amnify, open **Connect AWS** and choose **Assume role**. Amnify pre-fills an **external ID** (you can regenerate it). Copy this value, because you will reference it in the scan role's trust policy in the next step.
      </Step>

      <Step title="Create the scan role">
        Create an IAM **role** in the target account and attach the same read-only access from Step 1. Set its **trust policy** to allow the IAM user from Step 1 to assume it, with a condition requiring the external ID from Step 2 (`sts:ExternalId`). Copy the role's **ARN**.
      </Step>

      <Step title="Save the connection in Amnify">
        Back in the **Connect AWS** dialog, paste the **access key ID**, **secret access key**, the scan **role ARN**, and the **external ID**, then click **Save connection**. Amnify validates the credentials against STS and connects the account.
      </Step>
    </Steps>
  </Tab>

  <Tab title="Access key">
    <Steps>
      <Step title="Create a read-only IAM user and access key">
        In the AWS console, create an IAM user (or reuse a dedicated one) and attach read-only access, described in [Tier 1](#tier-1-account-read-access-required) below. Create an **access key** for it.
      </Step>

      <Step title="Save the connection in Amnify">
        Open **Connect AWS**, choose **Access key**, paste the **access key ID** and **secret access key**, then click **Save connection**. There is no scan role and no external ID to configure. Amnify validates the credentials against STS and connects the account.
      </Step>
    </Steps>

    <Note>
      The access key carries the read-only access on its own here, so scope it to exactly the permissions in Tier 1 and rotate it on your normal schedule.
    </Note>
  </Tab>
</Tabs>

## Tier 1: Account read access (required)

**What:** read-only access to the AWS account, attached to the IAM user and scan role above. Amnify does not require a specific named policy. It needs read-only visibility sufficient for its posture checks. The AWS-managed **`SecurityAudit`** policy is the standard, least-privilege way to grant this, as it is purpose-built for read-only security review; pair it with the managed **`ViewOnlyAccess`** policy if a check needs to read additional resource metadata.

**Why:** Amnify runs read-only posture checks across the account (networking, storage, compute, IAM, logging, and more) to flag insecure settings. Read-only access grants visibility into that configuration only: no ability to change, create, or delete resources, and no access to the data held inside them, such as S3 object contents, database rows, or Secrets Manager values.

Scanning is scoped to a single AWS account per connection. Amnify does not enumerate or scan an entire AWS Organization from one connection. Connect each account you want assessed. Unlike Azure, there is no separate identity tier; IAM configuration is read as part of this same read-only access.

<Warning>
  **What Amnify never asks for on AWS**

  * No write, modify, or delete permissions. Read-only access only.
  * No access to data-plane contents (S3 object contents, database rows, Secrets Manager values).
  * With assume role, no way to assume the scan role without the external ID you set.
  * No credential Amnify generated. In both modes it holds only the read-only key you created, stored encrypted, and you can rotate or revoke it in IAM at any time.
</Warning>