How to use a Righthand with AWS

Quick answer

Use Righthand to prepare an AWS EC2 inventory review from a scoped account snapshot. Resource state, account, and region must remain visible in every proposed action.

Start with a reviewable deliverable, keeping AWS as the accepted home for its records. This guide uses an explicitly approved snapshot or browser read; it does not assume that every provider API action is exposed by your Righthand connection.

Evidence and access

AWS documents EC2 instance lifecycle states and their transitions. See the official AWS reference. Provider capabilities and Righthand's available tools are separate checks.

Request a read-only owner-prepared inventory for named accounts, regions, and resource types, with the organization's approved review criteria. Verify the required tools and owner-approved scope through Righthand integrations; use the supplied packet when a native read is unavailable.

Define the objects and authority

Include these fields in the working input: account ID, region, instance ID, state, tags, owner, observation time. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

A stopped instance is not a deleted resource, and a running instance is not proof its application works. Infrastructure changes need operator review.

Illustrative first-run brief

Use the owner-provided AWS snapshot or approved read-only view. Review the supplied development-instance inventory. Identify resources with missing owner tags and unclear retention purpose. Do not stop, terminate, or resize anything. Run once for the agreed sample, using America/Los_Angeles for the review deadline and preserving source timestamps separately. Return the draft in this conversation by Friday at 3 PM Pacific for the cloud operator to review. Include source references and missing fields. Do not write records, spend money, change permissions, or send external messages. Stop and report an unavailable source rather than substituting another account.

Expected result and verification

An unowned running instance becomes an owner question, not an automatic cleanup target. The report distinguishes stopped from terminated states.

Match instance IDs against the exact account and region, then check owner evidence separately. Record the source cutoff, applied filters, and items excluded from the sample. The reviewer should be able to follow each consequential finding back to an original object. A well-written summary is not evidence that a proposed action happened. If a later write is authorized, verify its specific result separately before changing the task's status.

Illustrative input and draft output

These synthetic entries show the requested review, not live account results or a provider field schema.

Common failure and recovery

A cross-region query can miss resources. Report the reviewed regions explicitly and request additional scope before declaring the inventory complete.

If a resource's owner or region is absent, retain it as unclassified and ask the cloud administrator; do not recommend deletion from its name.

FAQ

What should the reviewer verify first?

Verify account, region, resource ID, lifecycle state, and declared purpose. Idle-looking resources may still support backups, recovery, or another owner's work.

How should a repeat run be scoped?

Keep account and region scope fixed between inventories. Recheck lifecycle and ownership before any separate cleanup request; a previous snapshot is not authority to terminate resources.

For connection and permission details, use Righthand Docs. Review Pricing alongside any separate provider charges before expanding the workflow.