Connect AWS read-only and produce your first inventory

By the end of this you have an AWS credential that provably cannot change anything, one completed discovery scan behind it, and an inventory in which every discovered resource has been deliberately marked rather than left sitting as an unreviewed row. Allow about 45 minutes - most of it spent in the AWS IAM console rather than in Sencai.

Nothing in steps 1 to 5 creates, modifies, or deletes anything in your AWS account. Step 6 has one exception, and it is called out there.

Before you start

• Admin or Owner in the Sencai organization you are connecting the account to. Adding a credential, validating it, and running a scan are all Admin-or-Owner actions; adopting resources afterwards needs Member or higher. See Roles & permissions.
• Enough access in AWS to create an IAM user and an IAM policy in the account you want to inventory.
• Read Permissions your credentials need first, at least its AWS sections. It is the longest page in this section and it carries the per-provider traps this tutorial can only summarize.
• Decide which AWS account this is before you start. A sandbox and a production account deserve different answers in step 1.

1. Write the IAM policy before you create anything else

Open the IAM console in the AWS account you want to connect, go to Policies, create a policy, and switch the editor to its JSON view. Paste in the read-only policy published at Read-only policy and give it a recognizable name such as SencaiReadOnlyInventory.

Do this before the user and before the access key. The policy is the only thing that decides what Sencai can do with the credential, so it is the decision worth making while you still have nobody’s key sitting in a clipboard. Deciding it afterwards is how accounts end up with whatever was convenient attached to them.

That policy is 39 actions and every one of them is a Describe, List, or Get. It reads bucket names but no objects, secret names but no secret values, table names but no rows - the page enumerates exactly what it cannot reach under What this credential provably cannot do.

The AWS-managed ReadOnlyAccess policy is not the same thing

It works, and it cannot write anything either, but it grants s3:Get* - every object in every bucket - along with DynamoDB reads and function source code. It also grows on its own as AWS adds services. The explicit policy is about a thousand characters and pastes in just as fast.

2. Create the IAM user and its access key

Still in IAM, go to Users and create a user - name it for what it is, such as sencai-inventory. Leave console access turned off; this user never signs in. Attach the policy from step 1 on the permissions step.

Then open the finished user, go to its Security credentials tab, and create an access key. AWS asks what the key is for - choose the option that describes an application running outside AWS. Copy both the Access key ID and the Secret access key before you leave the page: AWS shows the secret exactly once and cannot show it again.

Note

The current IAM console does not offer a “programmatic access” checkbox while you create the user. Access keys are created afterwards, from the user’s own Security credentials tab. Guides that tell you otherwise are describing a console that no longer exists.

Full console walkthrough: Creating the credential: AWS.

3. Add the account in Sencai and validate it

In the app, go to Settings → Cloud Credentials (/gravity/settings/cloud-credentials) and click Add Cloud Account. Choose AWS and fill in the three fields it asks for: Access Key ID, Secret Access Key, and a region. Give it a descriptive name - “Production AWS (inventory)” beats “aws1” the first time you connect a second account.

Leave automatic scanning off for this run. It is off by default, it makes Sencai re-read the account roughly every six hours indefinitely, and manual scans work whether or not it is on. Turn it on later, as a decision.

Saving stores the credential but does not check it. The row shows as awaiting validation until you click Validate, which makes a read-only call to AWS and reports Valid or Invalid with the provider’s own error message.

A green Validate does not prove the policy is sufficient

Validation calls sts:GetCallerIdentity, and AWS does not let an IAM policy restrict that call - so validation succeeds even on a key with a completely empty policy. It proves the key is live, nothing more. An under-privileged policy produces a short inventory with no error at all, because each service is scanned independently and a denial on one is recorded and skipped. Judge this credential by the resource counts in step 5, not by the validation badge.

See Connect a cloud provider for the rest of the form and how credentials are stored.

4. Run one discovery scan

On the validated credential’s row, click Run scan. The scan is read-only: it lists what exists in your account and never creates, changes, or deletes anything there.

It runs in the background, so you get a confirmation that it started rather than a result. Results appear in the inventory shortly afterwards.

A denied region listing silently shrinks the scan to one region

The scan calls ec2:DescribeRegions first and then sweeps every region enabled on the account. If that one call is denied, it falls back to scanning only the single region stored on the credential - and a one-region inventory looks exactly like a complete one. Keep ec2:DescribeRegions in the policy even if you are certain you only use one region.

Note

Four services are always read from us-east-1 regardless of the region on the credential, because their endpoints are global: Cost Explorer, IAM, Route 53, and CloudFront. That is correct for standard AWS accounts and wrong for GovCloud and China accounts.

More on what a scan covers per provider: Import existing infrastructure.

5. Check the result by counts, not by the badge

Open Compliance & Audit → Inventory (/gravity/inventory). Every discovered resource is listed with its provider, region, type, the provider’s own external ID, its tags as set at the provider, and its ownership state. You can filter by provider, region, resource type, tag, or ownership, search across everything, and export the current view as CSV or JSON.

This is the step that actually tells you whether step 1 worked. Compare the counts against what you know is running in that account, region by region. A short list here means the policy, a service control policy on the account, or a region fallback trimmed the scan - not that the account is empty.

If it comes back empty or obviously incomplete, work through Discovery scan finds nothing before changing anything.

Everything the scan found starts as Unmanaged: visible, but not yet reviewed or claimed.

6. Give every resource an ownership state

Select one or more rows and choose Adopt (Member role or higher). Each resource ends up in one of four states - Unmanaged, Managed, Read-only, or Ignored - and the point of this step is that nothing is left in the first one by accident.

Choose	When
Manage with Sencai	You intend Sencai to perform write operations on it later
Read-only tracking	You want it visible and monitored, with writes blocked
Ignore	Legacy or decommissioned - stop showing it as an open item

Adopting something shaped like a compute instance also offers to adopt the network, subnet, or security groups found alongside it, so you do not end up tracking a server without the network it depends on.

This is the one step that writes to your AWS account

Manage with Sencai and Read-only tracking both add a small set of Sencai tracking tags to the real resource at the provider. The read-only policy from step 1 deliberately contains no tagging permission, so that write fails - loudly rather than silently. Ignore adds no tags and changes nothing at AWS.

If you want the tracking tags applied, widen the credential to the full provisioning policy on Permissions your credentials need first, and read the cautions attached to it - it is not just tagging that it grants.

Adoption is a label, not a lever: it does not let Sencai start, stop, or destroy anything. Turning a discovered instance, network, or disk into a first-class managed record is a separate, larger step called promotion (Admin role or higher), and it is deliberately outside this tutorial. When you want it, Import existing infrastructure covers it, including what a promoted host does not automatically get.

Re-running the scan later is safe and repeatable, and changes made to adopted resources outside Sencai show up as drift rather than being silently overwritten.

What’s next

• Import existing infrastructure - the full discover, adopt, and promote flow this tutorial walks the first half of
• Inventory - ownership states, drift, tag compliance, and export in depth
• Permissions your credentials need - the full provisioning policy, and what to weigh before attaching it
• Cloud infrastructure - the rest of the section, including the distinction between screens that change your provider account and screens that only record intent
• Troubleshooting - when a scan, a credential, or a cost figure does not behave