Skip to main content

​
How Amnify authenticates

You connect AWS with an IAM identity that you create in your own AWS account and grant read-only access. Amnify supports two modes:
  • Assume role (recommended). You create an IAM user with a read-only access key, plus a dedicated scan role the user is allowed to assume, gated by an external ID. Amnify uses the access key only to call AWS STS AssumeRole and take on the scan role for the duration of a scan. 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.
  • Static credentials. You provide the read-only access key directly and Amnify uses it as-is, without assuming a role. Simpler to set up, but it keeps a single long-lived credential in play — prefer assume-role.
In both modes the access key is validated once, with an STS GetCallerIdentity call, and then stored encrypted at rest (AES-256-GCM). 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 (assume role)

1

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 — see Tier 1 below. Create an access key for it; you will paste the access key ID and secret into Amnify.
2

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 — you will reference it in the scan role’s trust policy in the next step.
3

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.
4

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.
For static credentials, skip the scan role: choose Static credentials in the connect dialog and paste only the read-only access key ID and secret. Amnify uses that key directly.

​
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 (S3), compute (EC2), 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.
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).
  • No way to assume the scan role without the external ID you set. Amnify holds only the read-only access key you provide, stored encrypted, and you can rotate or revoke it in IAM at any time.