Deploy Resource Atlas

• ▸Terraform 1.3 or later, and AWS CLI v2
• ▸A VPC with two private subnets in different availability zones, each with outbound internet access (e.g. through a NAT gateway)
• ▸The 12-digit ID of the AWS account you are deploying into
• ▸Permission to create ECS, ECR, IAM, S3, SSM Parameter Store, CloudWatch Logs, EventBridge rules and schedules, CodeBuild, Lambda, EC2 security groups, ELB and ACM resources
• ▸Your Resource Atlas licence key, which starts ra_live_. It is on your the console page, next to the download

1. 01

   Download the bundle

   Sign in and open the console. Copy your licence key, then download resource-atlas-<version>.zip. Each download link is created when you click it and expires after 15 minutes.

2. 02

   Unzip it

   $ unzip resource-atlas-*.zip && cd resource-atlas-terraform

   Copy command
3. 03

   Configure it

   $ ./setup.sh

   Copy command

   Asks for your region, your VPC, the two private subnets, the account ID you are deploying into, and your licence key. It writes locals.tf and terraform.tfvars, and fills in the account details in create_cross_account_iam_role.sh for later. It is safe to re-run — whatever you answered last time comes back as the default.

4. 04

   Deploy it

   $ ./deploy.sh

   Copy command

   Checks you are signed in to the account you named, then runs terraform init and terraform apply and shows you the plan. Type yes to go ahead, or run ./deploy.sh --yes to skip the prompt.

   Creating the stack takes a few minutes, and the app can take around ten more to come up. The first inventory scan starts on its own as part of the deployment, so there is data waiting when you first sign in.

   This is a convenience wrapper. Plain terraform init / plan / apply works exactly the same — you would just run ./access.sh yourself afterwards.

5. 05

   Get your sign-in details

   $ ./access.sh

   Copy command

   Prints the URL and the current admin and read-only passwords. They are read live from Parameter Store rather than from the Terraform outputs, which only ever show what was seeded and go stale the moment a password is changed in the app. Run it any time, from any machine with credentials for the account.

6. 06

   Sign in

   The load balancer is internal, so the URL resolves only from inside the VPC. access.sh checks whether you can reach it and prints the port-forward command if you need one. The certificate is self-signed, so your browser warns once.

The account you deployed into is scanned out of the box. Every other account you want in the inventory needs two things: a read-only role inside that account, and its ID added in the app. Repeat these steps once per account.

1. 01

   Authenticate to the account you want to scan

   Credentials for the target account, not the one Resource Atlas is deployed into — that is the step people get wrong. Authenticate however your organisation normally does: SSO, an assumed role, a named profile, whatever you use.

2. 02

   Create the read-only role

   $ ./create_cross_account_iam_role.sh

   Copy command

   Run it from the same bundle directory. It shows you which account your credentials actually resolved to and asks you to confirm before creating anything, so a wrong profile is caught rather than acted on.

   It creates a role that trusts only the Resource Atlas backend in your deployment account and attaches the AWS-managed ReadOnlyAccess policy — Resource Atlas can read your inventory and nothing else. Running it again on an account that already has the role updates the trust policy rather than failing.

3. 03

   Add the account in the app

   Open Settings > AWS Accounts, paste the 12-digit account ID into the box and press Add. You need to be signed in as admin. How many accounts you can add depends on your plan — see pricing.

4. 04

   Check it works

   Press Check next to the account. That verifies this deployment really can assume the role you just created, which is the fastest way to catch a mistyped account ID or a role created in the wrong place.

   The account is included from the next scan onwards. To see it straight away, run a scan now from Settings > Backend.

terraform.tfstate and terraform.tfvars hold your licence key and the seeded login passwords in plain text. The bundle ships with a .gitignore that already excludes them, so they will not reach a repository by accident — but back them up somewhere private. Losing the state file means Terraform can no longer manage what it created.